How to Resolve Warning "CS0437: The type 'MyName' in 'AssemblyA' conflicts with the imported namespace 'MyName' in 'AssemblyB'. Using the type defined in 'AssemblyA'." in C#
The Compiler Warning CS0437 is a Naming Collision warning. The message reads: "The type 'MyName' in 'AssemblyA' conflicts with the imported namespace 'MyName' in 'AssemblyB'. Using the type defined in 'AssemblyA'."
This warning occurs when you reference two different sources (assemblies or namespaces) that define the same identifier, but they define different kinds of things:
- Source A defines a Type (Class, Struct, Enum).
- Source B defines a Namespace.
In this specific conflict, the C# compiler's resolution rules favor the Type. It warns you that it is hiding the namespace to let you use the class. This can be problematic if you were actually trying to access classes inside that hidden namespace.
Understanding the Conflict
Namespaces are containers. Types are objects. If they share a name, ambiguity arises.
- Assembly A:
public class Monitor { ... } - Assembly B:
namespace Monitor { public class Display { ... } }
If you type Monitor.Display, the compiler has to decide:
- Are you accessing a nested class named
Displayinside the ClassMonitor? - Are you accessing the class
Displayinside the NamespaceMonitor?
The compiler defaults to the Class. It assumes Monitor refers to the type in Assembly A. Consequently, the Namespace Monitor becomes inaccessible via that name, triggering CS0437.
Scenario: Class Hiding a Namespace
Imagine you are using two libraries:
Hardware.Sensors.dll(Contains a class namedSensor).Hardware.Core.dll(Contains a namespace namedSensor).
Code in Hardware.Sensors.dll:
namespace Hardware
{
// A concrete Class
public class Sensor
{
public int Id;
}
}
Code in Hardware.Core.dll:
// A Namespace
namespace Hardware.Sensor
{
public class Temperature { }
}
Your Consumer Project:
using Hardware;
public class Program
{
static void Main()
{
// ⛔️ Warning CS0437: The type 'Hardware.Sensor' conflicts with the
// imported namespace 'Hardware.Sensor'. Using the type.
// The compiler thinks 'Sensor' is the CLASS.
// It looks for a nested class named 'Temperature' inside the class 'Sensor'.
// It won't find it, leading to a compile error on top of the warning.
var temp = new Hardware.Sensor.Temperature();
}
}
Solution 1: Use the global:: Qualifier
If the namespace you are trying to reach is rooted at the global level, you can use the global:: alias to force the compiler to look at the namespace hierarchy from the very top, bypassing the conflicting class name.
Solution:
using Hardware;
public class Program
{
static void Main()
{
// ✅ Correct: Use the class (Implicitly preferred by compiler)
var s = new Sensor();
// ✅ Correct: Access the namespace explicitly using global::
// This tells the compiler: "Start searching from the root namespaces,
// do not match variable names or local types."
var t = new global::Hardware.Sensor.Temperature();
}
}
Solution 2: Use Extern Aliases (Robust Fix)
If global:: does not resolve the issue (perhaps because the structure is complex or identical), you should use Extern Aliases. This assigns a specific nickname to each DLL, preventing them from polluting the same global namespace.
Step 1: Assign Aliases in .csproj
Open your project file (.csproj) and assign aliases to the references.
<ItemGroup>
<Reference Include="Hardware.Sensors">
<HintPath>libs\Hardware.Sensors.dll</HintPath>
<!-- Alias for the DLL containing the Class -->
<Aliases>SensorsLib</Aliases>
</Reference>
<Reference Include="Hardware.Core">
<HintPath>libs\Hardware.Core.dll</HintPath>
<!-- Alias for the DLL containing the Namespace -->
<Aliases>CoreLib</Aliases>
</Reference>
</ItemGroup>
Step 2: Use the Alias Qualifier (::)
In your code, refer to the root alias instead of the ambiguous name.
// Bring aliases into scope
extern alias SensorsLib;
extern alias CoreLib;
public class Program
{
static void Main()
{
// ✅ Correct: Access the Class via its DLL alias
var s = new SensorsLib::Hardware.Sensor();
// ✅ Correct: Access the Namespace via its DLL alias
var t = new CoreLib::Hardware.Sensor.Temperature();
}
}
Conclusion
CS0437 warns you that a Class is blocking access to a Namespace.
- Understand the Default: The compiler will always pick the Type (Class) over the Namespace in this conflict.
- Quick Fix: Use
global::MyNamespace...to force the compiler to look for the namespace. - Strong Fix: Use Extern Aliases to separate the two assemblies entirely if the naming conflict makes the code unreadable.