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);
}
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.