[Mono-dev] Ambiguous matching in method resolution

Rafael Teixeira monoman at gmail.com
Wed May 31 14:49:39 EDT 2006

Pablo and mscorlib hackers,

Strange as that message is only found in the AmbiguousMatchException
default constructor, that is called inside Reflection, and inside
MonoType (an internal class) inside corlib.

So that exception would be normally thrown out, and generate a stack
trace. Unless the MonoType GetConstructorImpl method (probable
culprit) is being called from unmanaged code, that doesn't properly
handle exceptions (or can't in that particular situation).

It looks like there's a logic error in that method. If you are asking
for a parameterless constructor (by passing a null for the 'types'
array parameter), if it counts more than one constructor, REGARDLESS
bindingflags, it will throw that exception.

I think that it should first make sure it counts only methods that
expect the same number and type of parameters, before entering that

Some mscorlib hacker please take a look at that.


Probably you have more than one constructor with the same visibility
as the parameterless constructor in some of your classes, to cause
that exception, but as I think that is a common pattern, probably it
is combined with some other factors I can't guess without a
stacktrace, :(

Hope it helps,

On 5/31/06, pablosantosluac at terra.es <pablosantosluac at terra.es> wrote:
> Hi,
> I have an application that is correctly running with .NET, but as soon as I
> run it with mono (1.1.15) on Linux I get the following message:
> Error: Ambiguous matching in method resolution.
> I tried to recompile with mono on Linux with debug info, but I can't get any
> more information, neither with --trace.
> What can I do to locate the problem?
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list

Rafael "Monoman" Teixeira
As I'm currently working a lot with Java and even fixing Java VMs
(JamVM/Kaffe) and GNU Classpath code, I think I may partly borrow the
title (Javaman) from my friend Bruno Souza and become the
MonoNJavaMan. Yeah, I may currently be crazier than usual...

More information about the Mono-devel-list mailing list