[Mono-devel-list] IKVM show stopper

[Jeroen Frijters]

Paolo Molaro wrote:
> On 06/10/04 Jeroen Frijters wrote:
> > To fix an IKVM bug, I had to make a change to how MethodBuilder
> > instances are converted into their baked MethodInfo 
> equivalents. This
> > exposed a bug in Mono's (0.95) ModuleBuilder.GetMethodToken().
> > 
> > The attached program demonstrates that 
> ModuleBuilder.GetMethodToken()
> > allocates a new token, instead of returning the existing 
> one, when it is
> > called with a MethodInfo (instead of a MethodBuilder).
> > 
> > I think the bug is in mono_image_create_token 
> (reflection.c), as that
> > just blindly assigns a new token value when the passed in 
> object is a
> > MonoMethod.
> 
> I fixed this for methods and ctors in cvs. Do you need it for 
> fields as well as all the other tokens?

Thanks! At the moment methods and ctors are all I need, but I think I'll
need fields as well in the future (once I fix my field reflection code),
but this isn't as critical because field names are rarely overloaded. I
don't need any other tokens though.

> > Also, if you look at the generated test.dll, you'll see 
> that the actual
> > method token is also one off from the one reported by
> > MethodBuilder.GetToken().
> 
> Yes. Do you rely on that behaviour?

No. It was just something I noticed. My understanding is that they are
supposed to match, but I certainly don't need it.

> (it's easier since we keep separate arrays for ctors and 
> normal methods).
> In the general case the tokens won't match, because the methods of a
> type need to be contiguous in the PE file, but with reflection you can
> create a few mthods for a type, then for another, then for the old one
> again and the tokesn are assigned sequentially.

I don't know anything about the PE format, so this might be a lame
suggestion, but can't you simply write them out in token order when the
assembly is saved?

Regards,
Jeroen