Bug 52743

Summary: denied loading problems
Product: [Mono] Runtime Reporter: Marek Safar <masafa>
Component: GeneralAssignee: Rodrigo Kumpera <kumpera>
Status: RESOLVED FIXED    
Severity: major CC: alkpli, david.karlas, mhutch, mono-bugs+mono, mono-bugs+runtime
Priority: ---    
Version: master   
Target Milestone: ---   
Hardware: PC   
OS: Mac OS   
Tags: 2017-02 Is this bug a regression?: ---
Last known good build:
Attachments: test
test2

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