Skip to main content

How to Resolve Error "CS0433: The type 'TypeName1' exists in both 'TypeName2' and 'TypeName3'" in C#

The Compiler Error CS0433 is a Type Ambiguity error. The message reads: "The type 'MyClass' exists in both 'AssemblyA.dll' and 'AssemblyB.dll'".

In C#, every type is identified by its Fully Qualified Name (Namespace + Class Name). This error occurs when your project references two different assemblies (DLLs) that both contain a type with the exact same fully qualified name. When you try to use that type, the compiler does not know which DLL's version to pick.

This often happens due to version conflicts (referencing v1.0 and v2.0 of the same library), improper project migration (referencing .NET Framework DLLs in a .NET Core app), or issues with ASP.NET temporary files.

Understanding the Collision​

Imagine you have code that uses MyNamespace.Utility.

  • Reference A (LibV1.dll): Contains MyNamespace.Utility.
  • Reference B (LibV2.dll): Also contains MyNamespace.Utility.

When you write new MyNamespace.Utility(), the compiler sees two valid candidates. Even if the code inside them is identical, they are distinct types because they live in different physical files. To prevent runtime casting errors, the compiler stops and demands you fix the ambiguity.

Scenario 1: Version Conflicts (NuGet Dependency Hell)​

This is the most common cause. Your project might reference Library A (which uses Newtonsoft.Json v10) and Library B (which uses Newtonsoft.Json v13). If the build system fails to unify these versions, both DLLs might end up referenced, causing a clash for types like Newtonsoft.Json.JsonConvert.

The Diagnosis​

Look at the error message carefully. It usually points to two paths:

The type 'Class1' exists in both 'c:...\bin*Library.v1.dll**' and 'c:...\bin*Library.v2.dll**'

Solution: Consolidate Versions​

  1. Check NuGet: Open the NuGet Package Manager for your solution.
  2. Consolidate: Look for the "Consolidate" tab. If multiple projects use different versions of the same package, upgrade them all to the same version.
  3. Binding Redirects: In older .NET Framework projects, check your app.config or web.config for <bindingRedirect> elements to ensure the runtime maps all versions to the single version you actually deployed.

Scenario 2: ASP.NET Temporary File Corruption​

If you are working with ASP.NET WebForms, MVC, or Razor Pages, you might see this error referencing seemingly random file names in the AppData folder:

The type 'MyPage' exists in 'App_Web_a1b2c3d4.dll' and 'App_Web_e5f6g7h8.dll'

This happens because ASP.NET dynamically compiles your views and pages into DLLs. Sometimes, old versions of these DLLs get stuck in the temporary folder, and the compiler tries to load both the old and new versions.

Solution: Clean Compilation Folders​

  1. Close Visual Studio.
  2. Delete bin/obj: Delete the bin and obj folders in your project directory.
  3. Clear Temp Files: Navigate to the ASP.NET temporary files folder and delete everything inside.
    • Path: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files
    • (Or %AppData%\Local\Temp\Temporary ASP.NET Files depending on configuration).
  4. Rebuild: Open Visual Studio and Rebuild Solution.

Scenario 3: Framework Conflicts (.NET Core vs .NET Framework)​

When migrating legacy code to .NET Core or .NET 5+, you might accidentally keep a manual reference to a system DLL (like mscorlib.dll or System.Data.dll) inside your .csproj.

However, .NET Core includes these types automatically in the SDK references. By manually referencing the old DLL, you introduce a duplicate definition of types like System.String or System.Console.

Solution: Remove Manual References​

  1. Open your .csproj file.
  2. Look for <Reference Include="System..." />.
  3. Delete these lines. Let the SDK handle the system dependencies.

Solution: Using Extern Aliases (Advanced)​

If you absolutely must reference two different DLLs that contain the same type (e.g., using GridControl from v1 and GridControl from v2 simultaneously), you cannot solve this by deleting files. You must use Extern Aliases.

Step 1: Configure the Alias in .csproj​

Assign a specific alias to each reference so they don't both load into the global namespace.

<ItemGroup>
  <Reference Include="MyLibraryV1.dll">
    <Aliases>LibV1</Aliases>
  </Reference>
  <Reference Include="MyLibraryV2.dll">
    <Aliases>LibV2</Aliases>
  </Reference>
</ItemGroup>

Step 2: Use the :: Operator in Code​

Use the extern alias directive and the double-colon operator to distinguish them.

// Import the aliases defined in the project file
extern alias LibV1;
extern alias LibV2;

public class Program
{
    static void Main()
    {
        // ⛔️ Incorrect: 'MyClass' is still ambiguous if we don't specify the source.
        // var x = new MyNamespace.MyClass();

        // ✅ Correct: Use the alias to specify V1
        var item1 = new LibV1::MyNamespace.MyClass();

        // ✅ Correct: Use the alias to specify V2
        var item2 = new LibV2::MyNamespace.MyClass();
    }
}

Conclusion​

CS0433 means "Two DLLs, One Name."

  1. Read the Paths: The error message tells you exactly which two files are conflicting.
  2. Clean Up: For ASP.NET, delete temporary files. For standard projects, run "Clean Solution".
  3. Check Dependencies: Ensure you don't have Version 1.0 installed in one project and Version 2.0 in another.
  4. Use Aliases: Only use extern alias if you legitimately need both libraries active at the same time.

Table of Contents