Skip to main content

How to Resolve Warning "CS0435: The namespace 'Name1' in 'AssemblyA' conflicts with the imported type 'Name1' in 'AssemblyB'. Using the namespace defined in 'AssemblyA'." in C#

The Compiler Warning CS0435 is a Naming Collision warning. The message reads: "The namespace 'Name1' in 'AssemblyA' conflicts with the imported type 'Name1' in 'AssemblyB'. Using the namespace defined in 'AssemblyA'."

This warning occurs when you reference two different libraries (assemblies) that contain definitions with the exact same name, but different constructs. specifically:

  • Assembly A has a Namespace (e.g., MyLib.Web).
  • Assembly B has a Class (or Type) named exactly the same (e.g., MyLib.Web).

Unlike Error CS0434 (where the compiler gives up), in CS0435 the compiler makes a choice: it prefers the Namespace. It warns you that it is ignoring the Type from Assembly B to resolve the conflict. This effectively makes the class in Assembly B inaccessible via that name.

This guide explains how to restore access to the hidden type using Extern Aliases.

Understanding the Conflict​

In C#, Types (Classes, Structs) and Namespaces share the same lookup rules.

If you have:

  1. namespace Utils.Log (A container for other classes).
  2. class Utils.Log (A class you want to instantiate).

When you type Utils.Log, the compiler has to decide if you are pointing to the container or the object definition. The C# specification states that Namespaces take precedence in this specific cross-assembly scenario. The warning tells you: "I found a class with this name too, but I'm ignoring it so I can use the namespace."

Scenario: Namespace vs. Class Collision​

Imagine referencing two third-party libraries: Data.Core.dll and Data.Entities.dll.

Code in Data.Core.dll:

// Defines a Namespace
namespace SmartData.Structure
{
    public class Tree { }
}

Code in Data.Entities.dll:

namespace SmartData
{
    // Defines a Class with the same name as the namespace above
    public class Structure 
    {
        public int Id;
    }
}

Your Consumer Project:

using SmartData;

public class Program
{
    static void Main()
    {
        // ⛔️ Warning CS0435: The namespace 'SmartData.Structure' in 'Data.Core.dll' 
        // conflicts with the imported type 'SmartData.Structure' in 'Data.Entities.dll'.
        // Using the namespace defined in 'Data.Core.dll'.
        
        // This fails because the compiler thinks 'Structure' is the Namespace,
        // and you cannot create an instance of a namespace.
        var data = new SmartData.Structure(); 
    }
}

Solution 1: Use extern alias (Restore Access)​

Since the compiler has chosen to hide the Class, you must give the assembly containing the Class a specific Alias. This allows you to access the Class via a unique root name, bypassing the conflict.

Step 1: Define the Alias in .csproj​

Open your project file (.csproj) and find the reference to the assembly containing the Type (the one being hidden). Add the <Aliases> tag.

<ItemGroup>
  <Reference Include="Data.Entities">
    <HintPath>libs\Data.Entities.dll</HintPath>
    <!-- Give this assembly a specific nickname -->
    <Aliases>EntityLib</Aliases>
  </Reference>
  
  <Reference Include="Data.Core">
    <HintPath>libs\Data.Core.dll</HintPath>
    <!-- This one can stay global -->
  </Reference>
</ItemGroup>

Step 2: Use the Namespace Alias Qualifier (::)​

In your C# code, declare the alias usage and use the double-colon operator to force the compiler to look inside that specific alias.

// 1. Bring the alias into scope
extern alias EntityLib;

using System;

public class Program
{
    static void Main()
    {
        // ✅ Correct: Access the Namespace (from Data.Core)
        // This works via the default global namespace
        var tree = new SmartData.Structure.Tree();

        // ✅ Correct: Access the Class (from Data.Entities)
        // We use the alias to explicitly pick the assembly containing the class.
        var dataStruct = new EntityLib::SmartData.Structure();
        dataStruct.Id = 10;
    }
}

Solution 2: Renaming (If you own the code)​

The .NET Framework Design Guidelines strongly advise against naming a class the same as a namespace.

If you have access to the source code of the library defining the class, the best long-term fix is to rename it.

Solution: rename class Structure to StructureModel or StructureDefinition.

namespace SmartData
{
    // ✅ Correct: Renaming avoids the conflict entirely.
    public class StructureModel 
    {
        public int Id;
    }
}

Conclusion​

CS0435 is the compiler making a default choice (Namespace over Type) and letting you know about it.

  1. Understand the Winner: The compiler chose the Namespace.
  2. Understand the Loser: The Class with the same name is now hidden.
  3. Restore Access: Use extern alias in your project file to give the assembly containing the class a unique root name, allowing you to access it specifically via Alias::Namespace.Class.

Table of Contents