DOCSEARCHbyAlgolia
Submit Docs

dotnet-wcf

repository·main·Indexed 23 days ago

https://github.com/dotnet/wcf

A collection of WCF libraries and tools for .NET Core and .NET Standard. Includes the dotnet-svcutil command-line tool for generating web service proxy code from WSDL, XSD, or service endpoints, and specialized libraries such as System.ServiceModel.Primitives, System.ServiceModel.Http, System.ServiceModel.NetTcp, System.ServiceModel.Duplex, and System.ServiceModel.Security.

Tokens
11.6K
Snippets
35
Records
73
Agent score
83%

What's inside dotnet-wcf

  1. Overview of available WCF Libraries

    main

    The WCF repository provides several specialized libraries for different communication needs. Depending on your requirements, you may need to use one or more of the following:

    • System.ServiceModel.Primitives: Core WCF functionality.
    • System.ServiceModel.Http: Support for HTTP-based communication.
    • System.ServiceModel.NetTcp: Support for NetTcp-based communication.
    • System.ServiceModel.Duplex: Support for duplex communication.
    • System.ServiceModel.Security: Security-related WCF functionality.

  3. Use System.ServiceModel.Duplex for two-way WCF communication

    main
    The System.ServiceModel.Duplex library provides the necessary types and abstractions required to implement duplex (two-way) WCF communication. In a duplex scenario, both the client and the service can initiate calls to each other over the same connection. Use this library when your service contract requires callbacks to allow the server to push notifications or data back to the client.

  4. Communicate with WCF using Http

    main
    The System.ServiceModel.Http library provides the necessary types for communicating with Windows Communication Foundation (WCF) services over the HTTP protocol. This is used when your application needs to interact with WCF services that utilize HTTP-based bindings in .NET Core or .NET Standard environments.

  6. Track WCF issue status via Project Management labels

    main

    WCF uses specific labels to manage the lifecycle of tasks on their Kanban Board. You can use these labels to see how close a task is to being completed:

    • 0 - Backlog: Tasks not yet ready for development or prioritized.
    • 1 - Up Next: Prioritized tasks ready for development.
    • 2 - In Progress: Tasks currently under active development.
    • 3 - Done: Finished tasks.

  7. Understand WCF Scenario Testing (Outerloop Tests)

    main

    WCF scenario tests (also known as "outerloop" tests) are end-to-end tests that involve network communication between WCF client tests and WCF test services.

    Key architectural constraints:

    • WCF Client Tests: Run on .NET Core and are cross-platform (Windows, Linux, macOS, UWP).
    • WCF Test Services: Built on the full .NET Framework and must run on a Windows machine.

    To run these tests on a non-Windows OS or in a cross-machine configuration, you must have a WCF test service running on a Windows machine reachable by the client.

  8. Limitations of running xUnit tests as UWP cross platform

    main
    You cannot run xUnit tests as UWP on non-Windows platforms. This is because UWP applications require an AOT (Ahead of Time) compilation step that is currently only supported on Windows. On Windows, xUnit test projects are treated as UWP applications and undergo this AOT step (including the xUnit framework itself). On non-Windows platforms, the lack of AOT support makes it impossible to precompile the framework or the tests for UWP.

  10. How WCF conditional tests work

    main

    WCF uses custom xUnit attributes to manage test execution in different environments. Instead of standard [Fact] or [Theory], WCF tests use:

    • [WcfFact]
    • [WcfTheory]

    These attributes support two additional features:

    1. [Condition]: Determines if a test should be executed or skipped based on the current environment.
    2. [Issue]: Marks a test that is known to fail due to an active issue, allowing it to be skipped gracefully.

    Even when a test is skipped due to these attributes, it will still appear in the final test results.

  11. Understanding WCF issue labels and categories

    main

    The WCF repository uses GitHub labels to classify issues into three main categories: Area, Type, and Ownership. This helps contributors identify the scope, nature, and current status of a task.

    Area

    Identifies which assembly the issue applies to. Common area labels include:

    • Specific assembly names (e.g., System.ServiceModel.Http).
    • Infrastructure: Issues related to build or test infrastructure.
    • Meta: Issues regarding the repository, processes, or .NET Core Platform direction.

    Type

    Classifies the nature of the issue:

    • api addition: Adding new APIs to an assembly.
    • bug: Existing bugs in an assembly.
    • documentation: Incorrect documentation or enhancement requests for docs.
    • enhancement: Improvements that do not add new APIs (e.g., performance, cleanup).
    • feature request: Proposed new features requiring community discussion.
    • not yet supported: Features that work in Windows Store but throw PlatformNotSupportedException in these libraries.
    • stress: Issues discovered in stress labs or heavily loaded environments.
    • test bug: Issues related to testing (can be further sub-labeled as infrastructure or enhancement).

    Ownership

    Indicates who is responsible for the issue:

    • up-for-grabs: Well-scoped, small tasks ideal for new contributors.
    • feature approved: Larger scale issues that are open for work but may be complex.
    • grabbed by community: An external contributor is working on the fix. Coordinate with them before attempting to address it.
    • grabbed by assignee: A WCF team member is actively fixing the issue.

  12. Configure and manage the Certificate Revocation List (CRL)

    main

    A Certificate Revocation List (CRL) is generated alongside certificates and remains valid for the duration of the CA certificate.

    Configuration and Access:

    • Default Path: The CRL is published to C:\wcftest\test.crl by default, but this can be modified via app.config.
    • CRL Distribution Point: Each generated certificate includes a CRL Distribution Point at {_base_address}_/Crl.
    • Hosting Requirements: By default, the CertificateGenerator uses HTTP port 80. If you are not using the provided automation scripts (e.g., when hosting CoreWCF on Kestrel where port sharing is unavailable), you must explicitly provide an HTTP port and ensure the endpoint is set up so the CRL is accessible. If the CRL endpoint is inaccessible, certificates may fail validation.