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)