Introduction

An empty Reference.cs after adding a WCF Service Reference usually means Visual Studio could not generate usable proxy code from the service metadata. The problem is rarely the file itself. It is usually a metadata exposure issue, a bad import step, a type-reuse conflict, or a generation failure that Visual Studio hides unless you inspect the underlying service description.

Verify the Service Metadata First

WCF proxy generation depends on metadata. If the service does not expose valid WSDL and XSD documents, the client has nothing to generate.

Start by opening the metadata URL directly in a browser:

http://localhost:8080/OrderService.svc?wsdl

If the endpoint uses MEX, test that too with svcutil.

svcutil.exe http://localhost:8080/OrderService.svc?wsdl

If svcutil fails, Visual Studio will usually fail as well. This command is valuable because it prints the real importer error instead of silently producing a nearly empty generated file.

On the service side, make sure metadata publishing is enabled:

1<system.serviceModel>
2  <behaviors>
3    <serviceBehaviors>
4      <behavior name="metadataBehavior">
5        <serviceMetadata httpGetEnabled="true" />
6        <serviceDebug includeExceptionDetailInFaults="false" />
7      </behavior>
8    </serviceBehaviors>
9  </behaviors>
10
11  <services>
12    <service name="MyNamespace.OrderService" behaviorConfiguration="metadataBehavior">
13      <endpoint address="" binding="basicHttpBinding" contract="MyNamespace.IOrderService" />
14      <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
15    </service>
16  </services>
17</system.serviceModel>

If metadata is missing or invalid, fix that before touching the client project.

Use svcutil to Isolate the Failure

Visual Studio wraps the same metadata import process that svcutil.exe uses, so a manual generation attempt is the fastest way to isolate the problem.

svcutil.exe /out:Reference.cs /config:app.config http://localhost:8080/OrderService.svc?wsdl

If this generates code successfully, the issue is likely inside the Visual Studio project state rather than the service itself. If it fails, the console output usually points to one of these causes:

• unsupported or malformed metadata
• imported schema types that collide with existing client types
• bindings or contracts that are not exposed consistently
• inaccessible imported WSDL or XSD documents

That is more actionable than repeatedly clicking "Update Service Reference".

Check Type Reuse and Namespace Conflicts

One surprisingly common cause of a tiny or empty Reference.cs is the type reuse option. If Visual Studio thinks the relevant contracts or data contracts already exist in referenced assemblies, it may skip generating much of the proxy code.

In the Add Service Reference dialog, click Advanced and review:

• 'Reuse types in referenced assemblies'
• selected collection type
• selected dictionary type

If you suspect a conflict, temporarily disable type reuse and regenerate the reference. Also try changing the service reference namespace so imported types do not collide with existing ones.

Another useful reset is to delete the generated service reference folder, then clean and rebuild before adding it again.

msbuild YourSolution.sln /t:Clean
msbuild YourSolution.sln /t:Build

Watch the Output Window and Temporary Files

Visual Studio sometimes surfaces the real generation problem in the Output window rather than the UI dialog. If the generated Reference.cs is empty, open Output and look for metadata importer warnings.

Also inspect the generated .svcmap file in the service reference folder. That file records what metadata documents were downloaded and how code generation was configured. If a referenced schema failed to import, the .svcmap often shows the broken metadata path.

Example Recovery Workflow

A reliable troubleshooting sequence looks like this:

1. open ?wsdl in a browser
2. run svcutil.exe against the same URL
3. confirm the service exposes metadata and MEX correctly
4. disable Reuse types in referenced assemblies
5. delete the existing service reference and regenerate it

If svcutil.exe succeeds but Visual Studio still creates an empty file, the client project state is likely stale. In that case, removing the service reference, deleting bin and obj, and regenerating usually resolves it.

Common Pitfalls

• Assuming an empty Reference.cs means Visual Studio is broken instead of checking the service metadata.
• Ignoring svcutil.exe, which usually exposes the actual import error.
• Leaving Reuse types in referenced assemblies enabled when it causes collisions or incomplete generation.
• Looking only at the generated file and not at the Output window or .svcmap details.
• Troubleshooting the client before verifying that the service actually publishes valid WSDL.

Summary

• An empty Reference.cs usually means code generation failed upstream.
• Verify ?wsdl and MEX access before changing the client project.
• Run svcutil.exe manually to see the real metadata import error.
• Check type reuse settings and namespace collisions in the service reference options.
• If metadata is valid, regenerate after cleaning the project and deleting the old reference.