Skip to main content

How to Resolve Error "CS0468: Ambiguity between type 'type1' and type 'type2'" in C#

The Compiler Error CS0468 is a Type Resolution Ambiguity error. The message reads: "Ambiguity between type 'TypeA' and type 'TypeB'".

This error occurs in advanced interoperability scenarios, specifically when dealing with Embeddable Interop Types (also known as "No-PIA" or "Type Equivalence"). It happens when the compiler finds two types that are essentially the same (same GUID, same name) in two different assemblies, but because both are being embedded, the compiler cannot decide which specific definition to use for a variable declaration or method call.

This guide explains how type embedding works and how to resolve these conflicts.

Understanding Type Embedding (No-PIA)​

In .NET, "Interop Assemblies" allow C# code to talk to COM objects (like Microsoft Office apps). Historically, you had to ship huge DLLs (Primary Interop Assemblies) with your app.

To solve this, C# introduced the Embed Interop Types feature (set to True by default for COM references). Instead of referencing a DLL, the compiler copies the type definitions directly into your application's executable.

The Problem: If Reference A embeds interface ISheet, and Reference B also embeds interface ISheet (and they are physically different files or versions), the compiler sees two local copies of ISheet. Even if they represent the same COM object, the C# compiler treats them as conflicting definitions.

Scenario: Dual References with Embedded Types​

This error is most common when developing Office Add-ins or using libraries that wrap the same COM components.

Setup:

  1. Project: References Microsoft.Office.Interop.Excel.
  2. Project: Also references a 3rd Party Library (ExcelHelper.dll) which also embedded the Excel types.

Code:

using Excel = Microsoft.Office.Interop.Excel;

public class Program
{
    static void Main()
    {
        // ⛔️ Error CS0468: Ambiguity between type 'Microsoft.Office.Interop.Excel.Application'
        // and type 'ExcelHelper.Embedded.Excel.Application'.
        // Both types are marked as "Embedded", so they are floating inside the assembly.
        Excel.Application app = new Excel.Application();
    }
}

Because both libraries tried to be helpful by embedding the types, the compiler now has two identical blueprints and doesn't know which one you want to instantiate.

Solution 1: Disable "Embed Interop Types" on One Reference​

The standard fix is to stop one of the sources from embedding the types. Usually, you want your main project to manage the reference, not the third-party library, or vice versa.

  1. Open Solution Explorer in Visual Studio.
  2. Expand References (or Dependencies > COM).
  3. Right-click the reference causing the conflict (e.g., the Excel Interop reference).
  4. Select Properties.
  5. Find Embed Interop Types.
  6. Change it from True to False.

This forces your project to treat the type as a standard external reference, allowing the compiler to distinguish it from the other embedded version.

note

If you turn this off, you might need to deploy the actual Interop DLLs (PIA) with your application installer.

Solution 2: Use Explicit Casting​

If you cannot change the reference properties (perhaps because you don't control the build environment or libraries), you can try to force the compiler to resolve the type by using the fully qualified name of the specific version you want, possibly combined with an extern alias.

However, with embedded types, "Fully Qualified Name" is tricky because they don't strictly belong to an assembly in the traditional sense. A better approach is to cast the ambiguous object to a neutral type (like object or dynamic) and then cast it to the specific interface you need.

using Excel = Microsoft.Office.Interop.Excel;

public class Program
{
    static void Main()
    {
        // Use 'dynamic' to bypass compile-time type checking for the creation
        dynamic dynApp = System.Activator.CreateInstance(
            System.Type.GetTypeFromProgID("Excel.Application"));

        // ✅ Correct: Cast explicitly to the Interface you imported locally
        Excel.Application app = (Excel.Application)dynApp;
    }
}

Conclusion​

CS0468 is a side-effect of the "No-PIA" feature meant to simplify deployment.

  1. Identify References: Look at your project references. Do you have two references providing the same COM types?
  2. Check Embedding: Check the "Embed Interop Types" property on those references.
  3. The Fix: Set "Embed Interop Types" to False for one of them to resolve the ambiguity.

Table of Contents