Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on
GitHub to continue tracking issues. Bugzilla will remain
available for reference in read-only mode. We will continue to work
on open Bugzilla bugs, copy them to the new locations
as needed for follow-up, and add the new items under Related
Our sincere thanks to everyone who has contributed on this bug
tracker over the years. Thanks also for your understanding as we
make these adjustments and improvements for the future.
Please create a new report on
GitHub or Developer Community with
your current version information, steps to reproduce, and relevant error
messages or log files if you are hitting an issue that looks similar to
this resolved bug and you do not yet see a matching new report.
Created attachment 18863 [details]
Using attached test do
mcs v1/lib.cs /target:library /keyfile:strong.snk
gacutil -i v1/lib.dll
Installed v1/lib.dll into the gac (/Users/marek/mono/lib/mono/gac)
mcs v2/lib.cs /target:library /keyfile:strong.snk
cp v2/lib.dll .
mcs app.cs -r:v1/lib.dll
System.MissingMethodException: Method 'X.M1' not found.
(The first half of this is just notes on how I understand our loader, the second half is a proposed fix)
Why this is happening:
I did not know this, but apparently Mono and .NET Framework consider the GAC and the codebases/ApplicationBase directories in different orders:
1. .NET Framework looks in the GAC first if the request is for a strong named assembly https://msdn.microsoft.com/en-us/library/yx7xezcf(v=vs.110).aspx If that doesn't work out it considers a collection of directories.
2. The key function in Mono's implementation is mono_assembly_load_full_nosearch ()
a. First we do various things to remap versions and apply bindings
b. Then we call the "preload hook" of which the one that's installed in a vanilla Mono is mono_domain_assembly_preload () (from appdomain.c) which tries to load the requested assembly from the domain search path (which, if you do nothing at all, includes the dir where app.exe lives) and then MONO_PATH.
c. If that didn't work out, we then try the GAC, then the base dir.
What I can't do:
I wish I could just change the preload hook to run after the GAC lookup (ie make Mono behave like .NET), but I'm told this will break customers who expect Mono's existing behavior (the earliest commit that I can find that codifies our order is from 2004, so).
What I'm doing:
I'm changing mono_assembly_load_from_full to take a predicate callback, and I'm threading the requested MonoAssemblyName from mono_domain_assembly_preload down to load_from_full.
The idea is that before we commit to an assembly (announced by calling mono_assembly_invoke_load_hook ()) we invoke the predicate and check that the candidate assembly we've got is good. The check has to be in load_from_full because it's both where the new MonoAssembly is created and the place where invoke_load_hook is called - anywhere else is too late or too early.
load_from_full doesn't have the original MonoAssemblyName that we're looking for - it only has a MonoImage and a filepath - so at the very least we need to get the requested name down there, but since this is the second time I'm working in this function in less than a year, it seems better to have a bit more abstraction in case we have more reasons for not loading something.
This is enough both to keep roslyn building Mono's BCL and also get the above reproduction steps to work. Please let me know if there are other scenarios I should try.
Fixed on mono master https://github.com/mono/mono/commit/b8285f3c9951354be07f693dd5996790d5764e3a
Not backporting to mono 2017-02 branch at this time - too risky a change.
We should probably update the release notes once we make a mono release from master to document the new behavior.
The version check, as committed on master is too strong when running with --runtime=mobile
The public key token on framework assemblies is different for the mobile profile.
Running with --runtime=mobile will remap requests to load certain framework assemblies (see mono/metadata/assembly.c:94 "framework_assemblies" table) to different versions. This is done because the mobile assemblies in Mono come from a variety of places (Silverlight, CoreFX, etc) and aren't the same as on the desktop.
However the framework assemblies not only have different versions that on desktop, they also are signed with different public keys.
So if some assembly references "System.Xml", Version=188.8.131.52, PublicKeyToken=XYZ, the runtime will remap that request to Version=184.108.40.206, PublicKeyToken=ABC.
The code committed in Comment 2 assumed that ABC is always the silverlight public key token. But it's not. For some framework assemblies it's Silverlight, but for others it might be CoreFX (or possibly ECMA, or something else, I'm not sure).
What I'm doing:
I'm reverting the part of https://github.com/mono/mono/commit/b8285f3c9951354be07f693dd5996790d5764e3a that remaps the public key token to silverlight when --runtime=mobile is specified. That's just wrong.
I need to either:
1. Ignore the public key token if the request is for a framework assembly, and the version got remapped.
2. Extend the remapping table to include public key tokens. (There's already a promising looking remap_keys() function in assembly.c but it's actually for going the other way - it's for the situation where an assembly on a desktop mono runtime tries to load a Silverlight framework assembly, for example. I'd either need to generalize this, or use another table.)
I think we can ignore public key token match if the request is for a framework assembly and the public key is one of the few known ones. Alternatively we could extend MonoRuntimeInfo::public_key_token to be an array of known/allowed values.
Fixed (take2) on mono master https://github.com/mono/mono/commit/5d72ee7c92ce64d2d14aa9828217523deb18ff11
Fixed on mono 2017-04 branch https://github.com/mono/mono/commit/42fa7589d30055b2f7e2766ef23468033bf98366