Skip to main content

How to Resolve Warning "CS0436: The type 'MyType' in 'MyProject' conflicts with the imported type 'MyType' in 'MyLibrary.dll'. Using the type defined in 'MyProject'." in C#

The Compiler Warning CS0436 is a Type Collision warning. The message reads: "The type 'MyType' in 'MyProject' conflicts with the imported type 'MyType' in 'MyLibrary.dll'. Using the type defined in 'MyProject'."

This warning occurs when a Type (Class, Struct, Enum, Interface) is defined in two places:

  1. Locally: In the source code of the project you are currently building.
  2. Externally: In a referenced DLL or library.

Because the Fully Qualified Name (Namespace + Type Name) is identical in both places, the compiler creates a warning. To resolve the conflict, it prioritizes the local source code and ignores the external DLL version. This can be dangerous if you intended to use the library's version, as the two types are not compatible with each other.

Understanding Source vs. Reference Priority​

When the compiler resolves a name like MyNamespace.Utils, it follows a hierarchy.

  • Top Priority: Types defined in the current source code (the files being compiled).
  • Lower Priority: Types defined in referenced assemblies (Dependencies).

CS0436 tells you: "I found two definitions. I am assuming you want to use the one you wrote in this project, but I am warning you that the one in the library is now hidden."

warning

Type Incompatibility: Even if the local class has the exact same properties as the library class, they are different types to the runtime. You cannot pass the local object to a method that expects the library object. This will cause runtime casting errors.

Scenario 1: Accidental Code Duplication​

This is the most common cause. You might copy a file from a library into your project to look at it or modify it, but forget to change the namespace. Now your project has the original reference and the copied file.

The Setup:

  • Referenced DLL (DataLib.dll): Contains public class User { ... } in namespace DataLib.
  • Your Project: References DataLib.dll.

Example of error: you create a file named User.cs in your project with the same namespace.

using DataLib; // References the DLL

namespace DataLib // Same namespace as the DLL
{
    // ⛔️ Warning CS0436: The type 'User' in 'MyProject' conflicts with 
    // the imported type 'User' in 'DataLib.dll'.
    // The compiler will use THIS class, ignoring the DLL version.
    public class User
    {
        public string Name { get; set; }
    }
}

public class Program
{
    static void Main()
    {
        // This creates an instance of the LOCAL 'User', not the DLL 'User'.
        User u = new User(); 
    }
}

Scenario 2: Polyfills and Backporting​

Sometimes developers add a class to their project to "polyfill" a feature missing in an older framework (e.g., adding System.Range or System.Index manually).

If you later upgrade your project to a newer framework (e.g., .NET 8) that includes these types natively, you will get CS0436 because your manual polyfill now conflicts with the actual system type.

Example of error:

// You manually defined this for an old .NET Framework project
namespace System
{
    // ⛔️ Warning CS0436: Conflicts with the real 'System.Range' 
    // included in newer .NET SDKs.
    public struct Range { /* ... */ }
}

Solution 1: Remove or Rename (The Standard Fix)​

The intended resolution depends on whether you meant to override the library. 99% of the time, you did not.

Option A: Delete the Duplicate​

If the file in your project is just a copy of what is in the DLL, delete the local file. Use the version from the referenced DLL.

Option B: Rename the Local Type​

If you are creating a custom extension or a different version, change its Namespace or Class Name.

// ✅ Correct: Changed namespace to avoid collision
namespace MyProject.Extensions 
{
    public class User 
    {
        // ...
    }
}

Solution 2: Use Extern Aliases (Keep Both)​

If you absolutely must have both types with the same name (for example, you are migrating logic slowly), you can use an Extern Alias to explicitly address the library version.

Step 1: Alias the Reference​

In your Visual Studio Properties for the reference (or in the .csproj), assign an alias to the external DLL.

<!-- .csproj -->
<ItemGroup>
  <Reference Include="DataLib">
    <HintPath>...\DataLib.dll</HintPath>
    <Aliases>ExternalData</Aliases>
  </Reference>
</ItemGroup>

Step 2: Use the Alias​

Use the extern alias keyword and the :: operator to force the compiler to use the DLL version.

// Bring the alias into scope
extern alias ExternalData;

using System;

namespace DataLib
{
    // This is the Local definition (Causes CS0436 usually, but explicitly handled below)
    public class User { public int LocalId; }
}

public class Program
{
    static void Main()
    {
        // 1. Use the Local version (Implicit)
        var localUser = new DataLib.User();

        // 2. Use the DLL version (Explicit via Alias)
        // ✅ Correct: Forces usage of the type inside the DLL
        var externalUser = new ExternalData::DataLib.User();
    }
}

Conclusion​

CS0436 is a warning that you are "shadowing" a library type with your own code.

  1. Check for Copies: Did you copy a file from a library into your source folder? Delete it.
  2. Check Upgrades: Did you upgrade .NET versions and now have duplicate "Polyfill" classes? Delete your manual implementations.
  3. Renaming: Changing the namespace of your local class is usually the easiest fix.

Table of Contents