Hello there, fellow enterprise developer. Before we get to the solution to our problem, let’s take a minute to close our eyes and reflect on our past decisions that led us to this moment. What could we have done differently? Was SOAP inevitable? Is pain a necessary aspect of joy? Ok, now open your eyes, and we can face this reality together.

This post will show how we can consume a SOAP web API in our .NET Core projects. The steps we will take are few, but the value we derive will be limitless. Let’s get started!

Step 1. Install .NET Core 2.1

We will be using a .NET Core tool, which targets .NET Core 2.1. Don’t skip this step; we need .NET 2.1 and not some other version of the SDK. We can download the installer for our specific operating system on the .NET site.. This tool targets 2.1 and that is why we need to install this SDK specifically.

Step 2. Tool Manifest

In all likelihood, we only need to use SOAP in one of our projects, so its recommended to use a local tool manifest. In our solution directory, we can run the following command.

dotnet new tool-manifest

When the command completes successfully, we will see a .config/dotnet-tools.json file—the JSON file stores our installed .NET tools.

Step 3. Install dotnet-svcutil Tool

We need to install the dotnet-svcutil tool. We can install it locally by running the following command.

dotnet tool install dotnet-svcutil

We can install the tool globally for those of us that will be dealing with multiple SOAP APIs.

dotnet tool install --global dotnet-svcutil

Step 3. Generating The Service Client

We’re almost nearing the end of this post. From the command line, we need to generate our web service reference. In our project directory, not solution directory, we need to run the following command.

dotnet dotnet-svcutil <wsdl url>

There are many public SOAP APIs, and we can test the process using a text casing API found at here.

dotnet dotnet-svcutil https://www.dataaccess.com/webservicesserver/TextCasing.wso

When running the command, we should see the tool output the results.

dotnet dotnet-svcutil https://www.dataaccess.com/webservicesserver/TextCasing.wso
Microsoft (R) WCF Service Model Proxy Generation Tool for .Net Core platform
[Microsoft.Tools.ServiceModel.Svcutil, Version 2.0.1]
Copyright (c) Microsoft Corporation.  All rights reserved.

This tool collects information about how it is used in order to improve the tool. This functionality can be disabled by setting the environment variable "DOTNET_SVCUTIL_TELEMETRY_OPTOUT" to 1.

Resolving project references ...
Attempting to download metadata from 'https://www.dataaccess.com/webservicesserver/TextCasing.wso' using WS-Metadata Exchange and HttpGet.
Generating files...

The dotnet-svcutil will update our .csproj file with the necessary System.ServiceModel dependencies. The tool will also create a new ServiceReference folder with two files: dotnet-svcutil.params.json and Reference.cs. The Reference.cs file will have the C# implementation of our SOAP API.

Step 4. Consuming the SOAP API

Consuming the newly generated SOAP interface in our code is as straight-forward as new Client(); depending on the SOAP client we generated, the name will be different. Let’s look at the implementation from our SOAP service listed above.

static async Task Main(string[] args)
    var client = new TextCasingSoapTypeClient(

    var result =
        await client.AllLowercaseWithTokenAsync("THIS IS A STRING", "");
    // result: this is a string
    var value = result.Body.AllLowercaseWithTokenResult;



The dotnet-svcutil works on multiple different types of web services, including WCF. Anyone interested in the tool’s capabilities can run dotnet dotnet-svcutil -h to see all the options available to us. For folks who need more information on the tool, [you can find the documentation here]. (https://docs.microsoft.com/en-us/sharepoint/dev/general-development/step-2-adding-a-web-reference).

Go forth enterprise developer, and SOAP on! Thanks for reading, and let me know in the comments if this post helped.