The SLAR (vol2) on System.Reflection.AmbiguousMatchException

Continuing in the series sharing some of the information in the .NET Framework Standard Library Annotated Reference Vol 1 and .NET Framework Standard Library Annotated Reference Vol 2 with some information on AmbiguousMatchException.


public sealed class AmbiguousMatchException : SystemException


// Constructors

public AmbiguousMatchException();

public AmbiguousMatchException(string message);

public AmbiguousMatchException(string message, Exception inner);



Joel Pobar

This exception is commonly thrown when input parameters to various non–plural XXXInfo/

Type methods (Type.GetMethod/GetField, etc.) result in multiple matches from the binder.

When calling these non–plural methods, it’s best to be specific in your BindingFlags and

always add type parameters for the methods that can accept them.

I’ve also seen this exception break deployed code where the code reflects on a library (loaded

by name) that is versioned out of band. To illustrate this, a brief example:

MyLibrary.dll (Version 1.0)

class Foo


   public void MyExtensibilityPoint() {}



MyLibrary.dll (Version 2.0)

class Foo


   public void MyExtensibilityPoint() {}

   public void MyExtensibilityPoint(int a) {}



My Deployed Code:

MethodInfo m = typeof(Foo).GetMethod("MyExtensibilityPoint");

Version 2 of the MyLibrary dll is deployed with a new overload of MyExensibilityPoint

to type Foo. Rerunning “My Deployed Code” above on Version 2 of the type results in an

ambiguous match exception because we now have two methods with the same name, and

we’re not specifying the parameters of the method for binding. To avoid this scenario, always

use the GetXXX APIs and supply as many specifics as possible (in this case, supplying a type

array specifying the methods parameters), and consider including the version part when

loading the assembly/library.


Comments (0)

Skip to main content