Bug 52743 - denied loading problems
Summary: denied loading problems
Status: RESOLVED FIXED
Alias: None
Product: Runtime
Classification: Mono
Component: General ()
Version: master
Hardware: PC Mac OS
: --- major
Target Milestone: ---
Assignee: Rodrigo Kumpera
URL:
Depends on:
Blocks:
 
Reported: 2017-02-24 13:24 UTC by Marek Safar
Modified: 2017-03-22 11:10 UTC (History)
5 users (show)

Tags: 2017-02
Is this bug a regression?: ---
Last known good build:


Attachments
test (58.04 KB, application/zip)
2017-02-27 17:15 UTC, Marek Safar
Details
test2 (2.92 KB, application/zip)
2017-03-06 16:22 UTC, Alexander Köplinger [MSFT]
Details


Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and 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 Links.

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.

Related Links:
Status:
RESOLVED FIXED

Description Marek Safar 2017-02-24 13:24:16 UTC
When assembly is denied loading, framework version redirect is ignored causing problems like bellow.

Mono has a list of framework assemblies `framework_assemblies` for which version number is ignored but that doesn=t trigger with denied loading


Relevant log

Assembly Loader probing location: '/Users/marek/git/temp/monodevelop/main/build/bin/./System.IO.Compression.dll'.
Denying load of problematic image /Users/marek/git/temp/monodevelop/main/build/bin/System.IO.Compression.dll
Unloading image /Users/marek/git/temp/monodevelop/main/build/bin/System.IO.Compression.dll [0x7f85919f1e00].
Assembly Loader probing location: '/Users/marek/git/temp/monodevelop/main/build/bin/Contents/Resources/lib/mono/gac/System.IO.Compression/4.1.2.0__b77a5c561934e089/System.IO.Compression.dll'.
Assembly Loader probing location: '/Library/Frameworks/Mono.framework/Versions/4.9.2/lib/mono/gac/System.IO.Compression/4.1.2.0__b77a5c561934e089/System.IO.Compression.dll'.
Assembly Loader probing location: '/Library/Frameworks/Mono.framework/Versions/4.9.2/lib/System.IO.Compression.dll'.
Assembly Loader probing location: '/Library/Frameworks/Mono.framework/Versions/4.9.2/lib/mono/4.5//Facades/System.IO.Compression.dll'.
Assembly Loader probing location: '/Users/marek/git/temp/monodevelop/main/build/bin/Contents/Resources/lib/mono/gac/System.IO.Compression/4.1.2.0__b77a5c561934e089/System.IO.Compression.exe'.
Assembly Loader probing location: '/Library/Frameworks/Mono.framework/Versions/4.9.2/lib/mono/gac/System.IO.Compression/4.1.2.0__b77a5c561934e089/System.IO.Compression.exe'.
Assembly Loader probing location: '/Library/Frameworks/Mono.framework/Versions/4.9.2/lib/System.IO.Compression.exe'.
Assembly Loader probing location: '/Library/Frameworks/Mono.framework/Versions/4.9.2/lib/mono/4.5//Facades/System.IO.Compression.exe'.

MonoDevelop failed to start. Some of the assemblies required to run MonoDevelop (for example gtk-sharp)may not be properly installed in the GAC.
Comment 1 Marek Safar 2017-02-27 17:15:14 UTC
Created attachment 20009 [details]
test
Comment 2 Marek Safar 2017-02-27 17:15:38 UTC
mono x.exe


Unhandled Exception:
System.IO.FileNotFoundException: Could not load file or assembly 'System.IO.Compression, Version=4.1.2.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' or one of its dependencies.
File name: 'System.IO.Compression, Version=4.1.2.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'
[ERROR] FATAL UNHANDLED EXCEPTION: System.IO.FileNotFoundException: Could not load file or assembly 'System.IO.Compression, Version=4.1.2.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' or one of its dependencies.
File name: 'System.IO.Compression, Version=4.1.2.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'
Comment 3 Rodrigo Kumpera 2017-02-28 00:56:41 UTC
PR against master:
Comment 4 Rodrigo Kumpera 2017-02-28 20:30:40 UTC
Fixed on master, 4.8 (15.1) and 2017-02 (15.2)
Comment 5 Alexander Köplinger [MSFT] 2017-03-06 16:22:45 UTC
Created attachment 20154 [details]
test2
Comment 6 Alexander Köplinger [MSFT] 2017-03-06 16:22:56 UTC
We found a new aspect that is broken, which involves binding redirects. Attached a new test case.

It seems the mapping is only done halfway:

> Mono: The request to load the assembly System v4.3.0.0 was remapped to v4.0.0.0
> Mono: Assembly Loader probing location: '/private/tmp/mono-dev/lib/mono/gac/System/4.3.0.0__b77a5c561934e089/System.dll'.
Comment 7 Rodrigo Kumpera 2017-03-07 22:56:08 UTC
Hey Alexander,

There's nothing wrong here. It's the normal remapping pipeline.

We apply platform remapping first and after that the assembly binding rules.

Which is what gives exactly what your example asked for, that System 4.3.0.0 to be used.

Even if this behavior is undesirable, it has nothing to do with the denied assembly feature which is the sole subject of this bug report.
Comment 8 Marek Safar 2017-03-09 09:08:40 UTC
Rodrigo, I think this is more complicated as denied assembly loading breaks the logic here.

Consider case where you have .config file which redirects one of the "broken" assemblies to the latest version which is e.g. 4.1.2.3 because we never allow to load such assembly the redirect will now apply to Mono system assembly but Mono does not provide all possible versions of "broken" assemblies but only 1. Which at the end means the application which works on .NET does not work on Mono.

I think we should put in another hack where we ignore binding redirects for "broken" assemblies
Comment 9 Rodrigo Kumpera 2017-03-10 10:38:14 UTC
Hey Marek,

This hack is getting too complicated with no actual fix in sight. I don't plan to further feed it.
Comment 10 Mikayla Hutchinson [MSFT] 2017-03-13 15:38:55 UTC
This is a serious compat issue. VS adds the redirects automatically, and they are necessary for apps to work on .NET in many cases. We need _some_ solution.
Comment 11 Rodrigo Kumpera 2017-03-13 18:44:48 UTC
Mikayla,

Can't XS/msbuild do the redirects then?

Running/compiling from the shell is not a dotnet thing to do anyways.

Marek,

I can see why we'd ignore a binding redirect to one of the broken assemblies name+version. Would that work?
Comment 12 Marek Safar 2017-03-14 09:09:43 UTC
Ignoring all binding redirects for broken assemblies should fix the problem
Comment 13 Mikayla Hutchinson [MSFT] 2017-03-15 04:32:09 UTC
@Rodrigo: the binding redirects are generated by VS and are part of the user's projects. XS cannot modify them without breaking compat. In theory MSBuild could modify them when copying them into the bin directory but then it would need a copy of the same invalid assembly list that Mono has, and the resulting binaries would not be portable. it's not really a viable solution.
Comment 14 Marek Safar 2017-03-22 11:10:13 UTC
Closing as this should be now fixed