Introduction

If you have ever seen the C# compiler error CS0433, you know how confusing it can be. The error reads something like "The type 'X' exists in both 'A.dll' and 'B.dll'" and it means the compiler found the same fully-qualified type name in two different referenced assemblies. Understanding why this happens is the key to fixing it quickly, because the root cause is almost always a dependency management issue rather than a problem with your own code.

What Triggers CS0433

The compiler needs every type reference to be unambiguous. When two assemblies both export a type with the identical namespace and class name, the compiler cannot decide which one you mean, so it raises CS0433. This can surface during a fresh build, after updating a NuGet package, or seemingly out of nowhere in ASP.NET projects.

The error message itself tells you the two assemblies involved. For example:

error CS0433: The type 'JsonConvert' exists in both
'Newtonsoft.Json, Version=12.0.0.0' and 'Newtonsoft.Json, Version=13.0.0.0'

That output is your starting point for diagnosis. Take note of both assembly names and their versions.

Common Causes

Duplicate NuGet Packages

The most frequent cause is having two NuGet packages that each bundle or depend on different versions of the same library. For instance, PackageA might depend on Newtonsoft.Json 12.x while PackageB depends on Newtonsoft.Json 13.x. If NuGet cannot unify them, both versions end up in your output directory.

You can inspect this in Visual Studio by opening the Solution Explorer, expanding the Dependencies or References node, and checking for duplicate entries. From the command line, run:

dotnet list package --include-transitive

This shows every transitive dependency and makes duplicate versions easy to spot.

Manual DLL References

Adding DLL files manually to a project is another common trigger. If you copy a DLL into your lib folder and also reference a NuGet package that contains the same types, the compiler sees both. This often happens when teams migrate from manually managed dependencies to NuGet but forget to remove the old DLL references from the project file.

ASP.NET Temporary Files

ASP.NET web projects compile pages into a Temporary ASP.NET Files folder. Stale compiled assemblies in that folder can clash with freshly built ones. This is particularly common after renaming classes or moving them between projects without cleaning the output.

How to Diagnose the Problem

Start by reading the error message carefully. It names both assemblies. Then follow these steps:

1. Open your .csproj file and search for both assembly names to see if one is a manual <Reference> and the other comes from a <PackageReference>.
2. Check the NuGet Package Manager's Consolidate tab in Visual Studio. It highlights packages where different projects in the same solution reference different versions.
3. Look at the build output directory (typically bin/Debug or bin/Release) for two copies of the same DLL with different version numbers.

1<!-- Example: conflicting references in a .csproj -->
2<ItemGroup>
3  <!-- Manual reference to an older version -->
4  <Reference Include="Newtonsoft.Json, Version=12.0.0.0">
5    <HintPath>lib\Newtonsoft.Json.dll</HintPath>
6  </Reference>
7  <!-- NuGet pulls in a newer version -->
8  <PackageReference Include="Newtonsoft.Json" Version="13.0.3" />
9</ItemGroup>

Remove the manual <Reference> to resolve the conflict.

Fixing via NuGet Consolidation

The cleanest fix is to make every project in your solution agree on a single version of the conflicting package. In Visual Studio, right-click the solution, choose Manage NuGet Packages for Solution, go to the Consolidate tab, and update all projects to the same version. From the command line you can use a Directory.Build.props file at the solution root:

1<!-- Directory.Build.props -->
2<Project>
3  <ItemGroup>
4    <PackageReference Include="Newtonsoft.Json" Version="13.0.3" />
5  </ItemGroup>
6</Project>

This forces every project in the directory tree to use version 13.0.3, eliminating version splits.

Using Extern Alias

When you genuinely need both versions of an assembly at the same time, C# offers the extern alias feature. First, assign an alias to one of the references in your project file:

1<Reference Include="Newtonsoft.Json, Version=12.0.0.0">
2  <Aliases>OldJson</Aliases>
3  <HintPath>lib\Newtonsoft.Json.v12.dll</HintPath>
4</Reference>

Then use the alias in your code to disambiguate:

1extern alias OldJson;
2
3// Use the old version explicitly
4var oldSerializer = new OldJson::Newtonsoft.Json.JsonSerializer();
5
6// The default (global) alias points to the newer version
7var newSerializer = new Newtonsoft.Json.JsonSerializer();

This approach is rarely necessary, but it is the correct tool when you truly cannot unify versions.

Cleaning Temporary and Output Files

For ASP.NET projects, clearing the Temporary ASP.NET Files folder often resolves phantom CS0433 errors. The folder is typically located at:

C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\

Delete the subfolder for your application, then rebuild. For all project types, a clean rebuild helps:

dotnet clean
dotnet build

In Visual Studio, use Build > Clean Solution before rebuilding.

Binding Redirects

In .NET Framework projects, binding redirects in app.config or web.config tell the runtime to map old assembly versions to a newer one. While this does not fix the compile-time CS0433 error directly, it prevents related runtime FileLoadException errors after you unify to a single version:

1<configuration>
2  <runtime>
3    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
4      <dependentAssembly>
5        <assemblyIdentity name="Newtonsoft.Json"
6                          publicKeyToken="30ad4fe6b2a6aeed"
7                          culture="neutral" />
8        <bindingRedirect oldVersion="0.0.0.0-13.0.0.0"
9                         newVersion="13.0.0.0" />
10      </dependentAssembly>
11    </assemblyBinding>
12  </runtime>
13</configuration>

In .NET Core and .NET 5+ projects, binding redirects are not used because the runtime handles version unification automatically.

Common Pitfalls

• Forgetting to remove manual DLL references after adding the same library via NuGet.
• Having multiple projects in a solution that each pin different versions of the same package.
• Not cleaning the Temporary ASP.NET Files folder after renaming or moving types.
• Confusing compile-time CS0433 with runtime assembly loading errors, which require different fixes.
• Using extern alias as a first resort instead of consolidating to a single version.

Summary

• CS0433 occurs when two referenced assemblies export the same fully-qualified type name and the compiler cannot choose between them.
• The most common cause is duplicate or version-split NuGet packages across projects in a solution.
• Diagnose by inspecting the .csproj references and using dotnet list package --include-transitive.
• Fix by consolidating NuGet versions across the solution, removing manual DLL references, or cleaning stale temporary files.
• Use extern alias only when you genuinely need two versions of the same assembly side by side.
• Add binding redirects in .NET Framework projects to prevent related runtime errors after version unification.