Autofac接口解析歧义问题技术求助

Let’s unpack that "The ambiguity, is in the box" situation you’re facing with Autofac—let’s crack open that box and figure out what’s going on.

First, let’s recap your setup to make sure I’m aligned:

• The IAmbiguous interface is defined in the ACommon project
• The AInjectable project implements this interface by linking directly to the interface file (instead of referencing ACommon)
• Your UI project calls an Inject method from ACommon and registers the AInjectable assembly
• This worked smoothly before, but now Autofac throws an ambiguity error when resolving IAmbiguous

Here are the most likely culprits and actionable fixes:

1. Duplicate CLR Types from File Linking #

This is the biggest red flag here. When you link a file instead of referencing the project/assembly, AInjectable compiles its own copy of IAmbiguous into its assembly. Even if the code is identical, the CLR treats this as a completely separate type from the one in ACommon.

Autofac sees two distinct IAmbiguous types (one from ACommon, one from AInjectable) and gets confused during resolution.

How to Verify #

Add this quick check in your UI project before registering the assembly:

var commonAmbiguousType = typeof(IAmbiguous); // From ACommon reference
var injectableAmbiguousType = Assembly.Load("AInjectable").GetType("YourNamespace.IAmbiguous");

Console.WriteLine($"ACommon Type: {commonAmbiguousType.AssemblyQualifiedName}");
Console.WriteLine($"AInjectable Type: {injectableAmbiguousType.AssemblyQualifiedName}");

If the assembly names in the output don’t match, this is your problem.

Fix #

Ditch the file link and have AInjectable directly reference the ACommon project. Interfaces are type contracts—they need to be shared via assembly references to ensure type identity across projects.

2. Multiple Implementations of IAmbiguous #

If the type identity checks out, the next thing to look for is multiple classes implementing IAmbiguous in the registered assemblies.

How to Check #

• Double-check the AInjectable project for accidental duplicate implementations of IAmbiguous
• Review your UI project’s registration code—did you recently add a registration for another assembly that also has an IAmbiguous implementation?

Fix #

• If you only need one implementation: Delete the extra classes or remove the unwanted assembly registration
• If you need multiple implementations: Use named registrations to distinguish them:

  // Register with names
  builder.RegisterType<AmbiguousImpl1>().Named<IAmbiguous>("Impl1");
  builder.RegisterType<AmbiguousImpl2>().Named<IAmbiguous>("Impl2");
  
  // Resolve by name
  var resolvedInstance = container.ResolveNamed<IAmbiguous>("Impl1");
  

3. Changed Registration Logic #

Since this worked before, a recent tweak to your registration code might be introducing the ambiguity.

How to Troubleshoot #

• Roll back to a version of your code where resolution worked, then compare the registration logic line by line
• Check if you switched from registering individual types to batch-registering all types in an assembly (which might pick up unexpected implementations)
• Verify if the Inject method in ACommon was modified to add extra registrations

4. Assembly Version Conflicts #

Rare but possible: If your UI project loads different versions of ACommon or AInjectable, this can cause type confusion even if the code is identical.

How to Check #

• Look in your UI project’s output directory—do you see multiple copies of ACommon.dll or AInjectable.dll?
• Check NuGet package references (if used) to ensure all projects reference the same version of shared assemblies

Fix #

• Clean your solution’s output directories and rebuild from scratch
• Standardize version numbers across all related projects to avoid mismatches

9 times out of 10, the file linking issue is the root cause here—fixing that should resolve the ambiguity. If not, work through the other checks to narrow it down.

内容的提问来源于stack exchange，提问作者Roark