WCF: service references, CoreWCF services and the test client

Codalus IDE builds WCF clients and CoreWCF services on Windows, macOS and Linux: nothing here needs Windows. Clients use WCF's client libraries (System.ServiceModel.*), services use CoreWCF, and references are generated by dotnet-svcutil, all MIT-licensed .NET.

Add Service Reference

A project's context menu → Add → Service Reference (WCF)… (or Project → Add Service Reference (WCF)…) opens the project's Service References on its WCF page:

Document: the service's metadata address (http://localhost:5000/Service.svc?wsdl; a service address without ?wsdl works for CoreWCF and WCF services), or a WSDL file (Browse). Discover finds the services you run: CoreWCF projects started with Run (Ctrl+F5) or being debugged, whose metadata answers on their listening addresses.
Name: the folder under Connected Services (ServiceReference1, then 2, 3…). Namespace: the generated code's namespace (the name when empty).
Collection type and Dictionary type: what arrays and dictionaries in the contract become (System.Array, List<T>, ObservableCollection<T>…).
Synchronous operations too (task-based ones are always generated), Reuse types in referenced assemblies (types the project already references aren't generated again), Internal (internal classes instead of public ones).

Add Reference runs your dotnet-svcutil in the project's folder; its output is in the Service References output, and Reference.cs opens. The reference is kept as Visual Studio keeps it: Connected Services/<name>/Reference.cs and a ConnectedService.json with its options, so the project opens and updates the same in Visual Studio and with dotnet-svcutil --update from the command line. dotnet-svcutil also adds the System.ServiceModel.* packages the client needs to the project.

A WCF reference in the list can be changed: edit its options and Save, or Refresh to generate it again from the service as it is now. Open Document opens Reference.cs, Test Client opens the service in the WCF Test Client, and Remove sends the reference's folder to the trash (the packages stay). References made with dotnet-svcutil's own layout (a ServiceReference folder with dotnet-svcutil.params.json) are listed and updated too.

dotnet-svcutil is yours: a local tool of the solution (dotnet-tools.json) or a global tool. The page says which one runs and its version; when there's none, Install asks, then installs it as a local tool from your NuGet sources (or restores the manifest's tools). Generating a reference builds the project to reuse its types, so it runs only in trusted folders.

CoreWCF services

File → New → Project lists CoreWCF Service once CoreWCF's templates are installed. Until then the list offers Install the CoreWCF templates…, which runs dotnet new install CoreWCF.Templates (from nuget.org) and shows the list again. The template makes an ASP.NET Core app with a CoreWCF service and its metadata (WSDL) published over HTTP.

Run the service (Ctrl+F5 or F5), then point Add Service Reference or the test client at it with Discover or Running Services: they read the endpoints the project adds (AddServiceEndpoint<TService, TContract>(binding, "/Service.svc")) and ask the program's listening addresses for ?wsdl, on this machine only. The metadata answers when the service publishes it: services.AddServiceModelMetadata() and ServiceMetadataBehavior.HttpGetEnabled = true.

The WCF Test Client

Tools → WCF Test Client calls a WCF or CoreWCF service's operations without writing a client:

Service: enter the metadata address or a WSDL file (the folder button) and Load (or Enter), or Running Services to pick a service you run from its list. The metadata's imports (WCF's ?wsdl=wsdl0, ?xsd=xsd0…) are followed.
Endpoint and Operations: each endpoint of the service, with its binding, and its contract's operations with their signatures (Greet(Person person) → string).
Request: a form generated from the operation's message, as a grid of name, type and value: a row per parameter and data member, with its type; a red * marks a value that's expected (a required field, or a number or enumeration that can't be nil); enumerations and booleans are lists; nested data contracts are indented under a header that collapses; an array or list is one row (Tags string[] 2 items) with + to add an item and a delete button on each item ([0], [1]…); the Nil check box sends xsi:nil. An empty optional field is left out. Form or XML switches to the SOAP envelope, which follows the form until you edit it; edited XML is sent as it is.
Invoke (or F5) checks the values against their types (a number, a date…), sends the request and shows the status as a chip with the time; Esc cancels. Response shows the result as a tree, in the editor's colors, or as formatted XML (Tree or XML); the copy button copies the XML. A fault shows as a red chip with its code (Fault s:Client), its reason and the HTTP status.

The test client speaks SOAP over HTTP: BasicHttpBinding (SOAP 1.1) and WSHttpBinding without security (SOAP 1.2 with WS-Addressing headers), and other SOAP bindings over HTTP without message security. An endpoint it can't call (message security, reliable sessions, NetTcp or named pipes) is listed with the reason; duplex contracts aren't supported. It runs inside the IDE with plain HTTP and no System.ServiceModel, so nothing is generated or compiled.

Configuration files

app.config, web.config, their transforms (web.Release.config) and *.exe.config files know WCF's <system.serviceModel> section:

Completion of its elements, attributes and values: bindings (basicHttpBinding, wsHttpBinding, netTcpBinding…), security modes, credential types, booleans; bindingConfiguration and behaviorConfiguration offer the names the file declares. Under <configuration>, system.serviceModel itself.
Hover shows what an element or attribute is for, and an attribute's values.
Checks: unknown elements and attributes, and values that don't fit (a size that isn't a number), as warnings. The rest of the file isn't checked.

This is useful with .NET Framework projects, whose WCF configuration lives there; .NET clients and CoreWCF services configure WCF in code.