WCF Test Client: How to Test WCF Services with WcfTestClient.exe

Thousands of enterprises still run WCF services, and the fastest way to poke one — no code, no Postman collections — remains WCF Test Client (WcfTestClient.exe), the tool that ships with Visual Studio. This guide covers where to find it, how to test operations with simple and complex parameters, the settings that trip people up, and what to use when the test client isn't enough.

What WCF Test Client is

WcfTestClient.exe is a GUI that reads a service's WSDL metadata, generates a temporary proxy, and gives you a tree of endpoints and operations. Double-click an operation, fill in parameter values in a grid, click Invoke, and see the response — both as formatted values and as the raw SOAP XML. It's the SOAP equivalent of hitting a REST endpoint with Postman: indispensable for "is the service even working?" moments.

Where to find it

The tool installs with Visual Studio (the Windows Communication Foundation component under ".NET desktop development"). Typical paths:

VS 2022:  C:\Program Files\Microsoft Visual Studio\2022\<Edition>\Common7\IDE\WcfTestClient.exe
VS 2019:  C:\Program Files (x86)\Microsoft Visual Studio\2019\<Edition>\Common7\IDE\WcfTestClient.exe

Fastest launch: open the Developer Command Prompt for VS and run wcftestclient. If the file is missing, re-run the Visual Studio Installer and add the WCF development tools individual component.

Two automatic ways it appears: press F5 on a WCF Service Library project and Visual Studio hosts the service in WcfSvcHost and opens the test client against it pre-wired; or launch it standalone and add any running service by URL.

Testing a service, step by step

1. File → Add Service and enter the metadata address — the endpoint plus ?wsdl:

http://localhost:5401/CalculatorService.svc?wsdl

The service must have metadata publishing enabled (ServiceMetadataBehavior/httpGetEnabled in old WCF; AddServiceModelMetadata() in CoreWCF). "Cannot obtain metadata" almost always means it isn't.

1. The left pane shows each endpoint and its operations. Double-click an operation — say Add.

2. Fill the Request grid: for Add(double a, double b) just type the numbers. For complex types the grid expands into a tree — set each [DataMember] field; for collections, select the array node and set its length, then fill elements. For nullable/optional members, the Value dropdown offers (null).

3. Click Invoke. The Response pane shows the returned object; the XML tab at the bottom shows the actual SOAP request and response envelopes — the single most useful feature when a real client misbehaves, because you can diff "what the tool sent" against "what my code sends".

Testing our CoreWCF-hosted calculator (the same contract works identically against classic WCF):

Add(a = 2, b = 3)                → 5
Quote(Quantity = 4, UnitPrice = 149.5)
                                 → Net = 598, Gst = 107.64, Gross = 705.64

Settings that trip people up

• Bindings must match. The test client reads binding config from the WSDL, so it usually just works — but a service exposing only netTcpBinding needs its metadata over HTTP (mex endpoint) to be discoverable, and message-security bindings may prompt for credentials.
• Client config is editable: right-click Config File → Edit with SvcConfigEditor to bump timeouts or maxReceivedMessageSize — the classic fix when invoking an operation that returns a large payload throws a quota exception.
• Restart after contract changes. The generated proxy is cached; if you change the service contract, remove and re-add the service (or restart the tool) or you'll invoke against the stale shape.
• Some things it can't drive: transactions, callbacks/duplex contracts, streams, and Message-typed parameters show as untestable (grayed out). That's a tool limitation, not a service bug.

Testing from Visual Studio: WcfSvcHost

When your service lives in a WCF Service Library project, Visual Studio wires the whole loop for you. F5 launches WcfSvcHost.exe, which reads the library's app.config, hosts every service in it, puts an icon in the system tray, and opens WCF Test Client already pointed at the endpoints. Details worth knowing:

• The hosted addresses come from the library's config, not the tool — if a teammate's clone uses a busy port, edit the baseAddress in app.config rather than fighting the tray icon.
• Multiple services in one library all appear in the same test-client tree; that makes the library project a convenient integration sandbox even for services that will ultimately deploy to IIS.
• Attach the debugger and the loop gets tight: breakpoint in the service implementation, Invoke in the test client, and you're stepping through server code with the exact message the tool sent. For "works in test client, fails from the real app" bugs, do the reverse — capture the failing app's envelope and replay it with curl while attached.

From manual clicks to regression tests

The test client proves an operation works today; a test suite proves it still works after every change. Generate a modern proxy and pin the behavior:

dotnet tool install -g dotnet-svcutil
dotnet-svcutil http://localhost:5401/CalculatorService.svc?wsdl --outputDir ./Generated

public class CalculatorContractTests
{
    private static ICalculator Client()
    {
        var factory = new ChannelFactory<ICalculator>(
            new BasicHttpBinding(),
            new EndpointAddress("http://localhost:5401/CalculatorService.svc"));
        return factory.CreateChannel();
    }

    [Fact]
    public void Add_returns_sum() => Assert.Equal(5, Client().Add(2, 3));

    [Fact]
    public void Quote_applies_18_percent_gst()
    {
        var total = Client().Quote(new Order { Quantity = 4, UnitPrice = 149.50 });
        Assert.Equal(598, total.Net);
        Assert.Equal(107.64, total.Gst);
        Assert.Equal(705.64, total.Gross);
    }
}

Because dotnet-svcutil emits a proxy that runs on modern .NET, this test project targets .NET 10 even when the service under test is .NET Framework — which makes the suite portable to CI and, crucially, reusable unchanged as the safety net when you later migrate the service itself.

Troubleshooting quick table

When the test client isn't enough

• Scripted/repeatable tests — the test client is manual. For automation, generate a client (dotnet-svcutil) and write xUnit tests, or send raw SOAP with curl:

curl -s http://localhost:5401/CalculatorService.svc \
  -H "Content-Type: text/xml; charset=utf-8" \
  -H 'SOAPAction: "http://tempuri.org/ICalculator/Add"' \
  --data '<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"><s:Body><Add xmlns="http://tempuri.org/"><a>2</a><b>3</b></Add></s:Body></s:Envelope>'

• Non-Windows machines — WcfTestClient is Windows-only. SoapUI (cross-platform) reads the same WSDL, and the curl pattern above works anywhere.
• Postman speaks SOAP too: POST the envelope with the SOAPAction header — handy if your team already lives there.

Reading the SOAP when things disagree

The XML tab deserves its own habit. When a Java caller, an old VB app, and the test client get different results from the same operation, the envelopes tell you why. Compare three things first: the SOAPAction header (mismatched action = mysterious 500s with ActionNotSupported faults buried inside), the element namespaces (http://tempuri.org/ defaults leak into production contracts more often than anyone admits — a caller using the right namespace against a service still on tempuri fails to deserialize into your parameters, which arrive as nulls rather than errors), and the field order inside DataContracts (DataContractSerializer emits members alphabetically unless Order is set; strict non-.NET parsers care). Null parameters on the service side with a 200 response is the signature of the namespace/order class of bug — and thirty seconds of envelope diffing beats an afternoon of logging.

The bigger picture

WCF Test Client keeps earning its place for as long as WCF services run in production — but .NET Framework is where classic WCF stops. If you're maintaining these services in 2026, the natural next read is WCF in the AI era: testing legacy services and migrating to CoreWCF or gRPC — the same contracts on modern .NET (where everything in this article still applies), and the path beyond them. The CoreWCF calculator service used for the outputs above is runnable from the companion repository.