---- Reported by gert.driesen@pandora.be 2004-03-22 15:42:35 MST ----

In resolution_scope_from_image (reflection.c), the major version and build
number is hard coded to 1 and 3300 for references to system assemblies.

The build version should ofcourse be 5000 for compatibility with .NET 1.1.

However, I wonder if its not possible to just use the version information
from the referenced assemblies themself ...



---- Additional Comments From sebastien@ximian.com 2004-03-26 07:48:35 MST ----

You are right about the hardcoded references. However assemblies must
be strongnamed (or at least delay-signed) for the runtime to extract
this information - hence the dependency to the https://bugzilla.novell.com/show_bug.cgi?id=MONO55563.



---- Additional Comments From sebastien@ximian.com 2004-03-26 10:05:14 MST ----

The runtime code tries to get the public key and version informations
from the assembly (and not the hardcoded ones) if available. This code
(part of which will eventually be removed) is located in
/mono/mono/metadata/reflection.c, function
resolution_scope_from_image, line 1888.

So I did a quick test with a strongnamed version of Mono's
System.Security.dll. I did get the right version number (1.0.5000.0)
but not the public key token.

The problem seems that mono_metadata_decode_row_col returns NULL in
mono_metadata_decode_row_col. It may be related to the fact that
monosn can't extract the public key from the assembly while sn.exe
(both Mono's managed and MS implementation) can.




---- Additional Comments From sebastien@ximian.com 2004-03-27 15:49:06 MST ----

This patch use the mono_metadata_decode_row function (instead of
mono_metadata_decode_row_col) to fix mono_image_get_public_key.

This does fix the current problem, which is to take the information
from the referenced assemblies (when assemblies are strongnamed), but
doesn't fix the mono_metadata_decode_row_col (nor the monosn failures).



---- Additional Comments From sebastien@ximian.com 2004-03-27 15:50:11 MST ----

Created an attachment (id=165779)
/mono/mono/metadata/image.c.diff




---- Additional Comments From sebastien@ximian.com 2004-03-27 15:56:03 MST ----

Arg!!! forget that patch - it doesn't seems to work if assemblies
aren't strongnamed.



---- Additional Comments From sebastien@ximian.com 2004-03-27 17:58:09 MST ----

The patch is ok - I had another process which (but shouldn't) was
taking  way to much CPU and memory so compilation look like stalled.
Killing that process fixed it :)



---- Additional Comments From sebastien@ximian.com 2004-04-08 16:07:55 MST ----

The "hardcoded-always-used" bug cannot be reproduced as of today
(april 8, 2004). Note that complete resolution still depends on 55563.

This means that the autodetect functionality in reflection.c is
working and that the information in the referenced strongnamed
assemblies (even delay-signed) will be used (in lieu of the hardcoded
information) when available.

This bug depended on bug(s) 55563.
Imported an attachment (id=165779)

Unknown operating system unknown. Setting to default OS "Other".