Introduction

A WSDL file describes a SOAP service contract: operations, messages, bindings, and endpoints. To call that service from .NET, you usually generate a client proxy rather than hand-writing SOAP envelopes yourself. In Visual Studio, the exact path depends on the project type. Older .NET Framework projects typically use Add Service Reference, while modern .NET projects often use the WCF Web Service Reference provider or the dotnet-svcutil tool.

Know Which Toolchain You Are Using

Before generating anything, identify the project style.

Use Add Service Reference when:

• the project targets .NET Framework
• the service is classic WCF or ASMX
• you want Visual Studio to generate app.config entries automatically

Use WCF Web Service Reference or dotnet-svcutil when:

• the project targets modern .NET
• you want generated code that fits the current SDK-style project
• you want a repeatable command-line generation step

That distinction matters because many older tutorials assume a .NET Framework project even when the current solution is not using one.

Visual Studio Flow for .NET Framework

For a .NET Framework project, the classic Visual Studio path is:

1. right-click the project
2. choose Add > Service Reference
3. enter the WSDL URL or local metadata address
4. click Go
5. choose a namespace such as MyApp.ServiceProxy
6. confirm to generate the client classes

Visual Studio then creates:

• proxy types
• data contract types
• endpoint configuration in App.config or Web.config

A typical generated client is then used like this:

1using System;
2using ConsoleApp1.ServiceProxy;
3
4class Program
5{
6    static void Main()
7    {
8        var client = new CalculatorClient();
9        var result = client.Add(2, 3);
10        Console.WriteLine(result);
11        client.Close();
12    }
13}

The actual client type name depends on the service metadata.

Use dotnet-svcutil for Modern .NET Projects

For SDK-style projects, dotnet-svcutil is often the cleaner option because it can generate the proxy from a WSDL file or metadata endpoint without relying on older project-system assumptions.

Install it once:

dotnet tool install --global dotnet-svcutil

Generate the proxy from a local WSDL file:

dotnet-svcutil ./service.wsdl -n "*,MyApp.ServiceProxy"

That command generates client code you can include in the project. The -n option maps the generated service types into your chosen .NET namespace.

After generation, client usage looks like ordinary C#:

1using System;
2using MyApp.ServiceProxy;
3
4class Program
5{
6    static void Main()
7    {
8        var client = new CalculatorClient(CalculatorClient.EndpointConfiguration.BasicHttpBinding_ICalculator);
9        var result = client.AddAsync(5, 7).GetAwaiter().GetResult();
10        Console.WriteLine(result);
11    }
12}

Again, the exact class and endpoint names depend on the WSDL.

Working from a Local WSDL File

If you have a .wsdl file on disk instead of a live service URL, that is fine. The main requirements are:

• the WSDL must reference any imported XSD files correctly
• all related metadata files must be accessible from the local paths
• the service address in the metadata may need to be overridden later for the actual environment

This is important because many "failed to generate proxy" problems are not about Visual Studio at all. They come from incomplete metadata bundles where the WSDL imports schemas that are missing locally.

Configuration Still Matters After Generation

Generating the proxy is only the first half of the job. A SOAP client also needs working binding and endpoint settings.

For a simple basic HTTP endpoint, the generated config often resembles:

1<system.serviceModel>
2  <bindings>
3    <basicHttpBinding>
4      <binding name="BasicHttpBinding_ICalculator" />
5    </basicHttpBinding>
6  </bindings>
7  <client>
8    <endpoint
9      address="http://localhost:5000/Calculator.svc"
10      binding="basicHttpBinding"
11      bindingConfiguration="BasicHttpBinding_ICalculator"
12      contract="ServiceProxy.ICalculator"
13      name="BasicHttpBinding_ICalculator" />
14  </client>
15</system.serviceModel>

If the proxy compiles but runtime calls fail, the binding or endpoint settings are usually the next place to inspect.

When Generation Fails

The most common failure causes are:

• the WSDL address is wrong or unreachable
• imported schemas are missing
• the service requires authentication or network access not available from the development machine
• the metadata contains bindings not supported by your target framework or tool

When that happens, try the command-line route with dotnet-svcutil or svcutil.exe. The error messages are often clearer than the Visual Studio dialog.

Common Pitfalls

The biggest mistake is using instructions for the wrong project type. Add Service Reference is natural in .NET Framework, but modern .NET projects often work better with WCF Web Service Reference or dotnet-svcutil.

Another mistake is assuming the WSDL file alone is enough. Many services also rely on imported XSD files, and missing metadata breaks generation.

Teams also often forget that the generated proxy is only a client stub. It still needs correct endpoint addresses, bindings, and credentials before calls will work.

Finally, do not hand-edit generated code unless you have to. Regeneration becomes painful if local changes are mixed into generated files.

Summary

• A WSDL-driven proxy saves you from writing SOAP messages by hand.
• Use Add Service Reference for classic .NET Framework projects.
• Use WCF Web Service Reference or dotnet-svcutil for modern .NET projects.
• Check imported schemas and endpoint configuration, not just the top-level WSDL.
• Treat proxy generation and runtime binding configuration as two separate steps.