-
Notifications
You must be signed in to change notification settings - Fork 3.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Loading denied assemblies via Assembly.LoadFrom
can cause issues, eg. for VSMac
#8726
Comments
Nice find! |
@lambdageek did your context load changes fix the problem? |
@marek-safar No: the load context work did nothing about "problematic images" - that's an entirely orthogonal concept. The load context work changes the semantics of What's not clear to me is what should The simple answer is: fail - in that case we can just drop the Lines 1364 to 1370 in 3d8125e
But that will break all callers of A better answer might be - " So let me know what it should do. |
Rewinding and adding full context :) NuGet packagers assume that ".net framework" means "windows", so folks end up with windows-specific assemblies (often transitive dependencies) copied into their output folder without even realizing it, which then breaks on Windows. This is an issue with several very common system.* packages, so we have the Load deny mechanism for these specifically. The problem in this case is that VSMac uses LoadFrom to load extensions' assemblies, and the deny mechanism only works with Load, not LoadFrom. I think silently redirecting LoadFrom to load the good variant when an image is denied is entirely reasonable and consistent. This isn't totally general, so scope is limited. It's just swapping out specific known bad assemblies for good replacements that are bundled with Mono. One could argue that the extensions shouldn't be shipping these assemblies. For the assemblies that are included in MD core that's definitely true, and perhaps VSMac could add special handling to avoid loading them from extensions. However, for assemblies that are not bundled in MD core, the extension needs to bundle them to work on .NET Framework. I understand the concern about backporting the patch. As a stopgap, we could implement the same blocklist in Mono.Addins so MD doesn't get broken by extensions. We've seen this breakage in the wild with the stable 7.5 release. /cc @slluis. |
The "problematic images" are Windows-specific assemblies that are often included with applications that do not work on Mono, but for which Mono has its own implementation. Previously (9ec8ec5) we changed mono to deny loading problematic images using Assembly.Load or when one assembly references another and we find a problematic image using the usual assembly search. For Assembly.LoadFrom, we used to emit a warning and then load the assembly anyway. In this commit, we change the behavior: If Assembly.LoadFrom tries to open a problematic image, we will instead probe for an assembly of that name in the default context. That should eventually end up opening Mono's version of that assembly. Example: Suppose a problematic System.Runtime.InteropServices.RuntimeInformation.dll is in the application bin path: /home/user/myapp/bin 1. User code does (for whatever reason) Assembly.LoadFrom ("/home/user/myapp/bin/System.Runtime.InteropServices.RuntimeInformation.dll") 2. We find the image and try to open it; add it to the images absfpath to image hash; note that there are no binding redirects; but that it is a problematic image. We extract the assembly name ("System.Runtime.InteropServices.RuntimeInformation", version x.y.z.w and public key token 123456789a) from the problematic image. 3. We probe for "System.Runtime.InteropServices.RuntimeInformation version x.y.z.w public key token 123456789a" in the default context. 4. We find /home/user/myapp/bin/System.Runtime.InteropServices.RuntimeInformation.dll in the application bin path; we try to open it, we see it's already in the images hash, but it's a problematic image, and we're not in a loadfrom context (we re-probed with default!) so we keep probing 5. We find <prefix>/lib/mono/4.5/Facaded/System.Runtime.InteropServices.RuntimeInformation.dll, it's not a problematic image, so we open that and return it to (3) 6. We return to (2) and close the problematic image and return the good one instead. 7. Assembly.LoadFrom returns with the good image. Fixes mono#8726
@lambdageek I certainly prefer consistent behaviour in this case and we should use same logic as we do when loading the assembly using other API. That leaves use with only reflection context APIs behaving differently but that sounds reasonable to me. I'd like to see this in 2018-04 because we are still testing the release and we can take it out if necessary. I agree that backporting to earlier versions (15.8 and before) might be problematic but we'd have to find a different workaround in that case. |
The "problematic images" are Windows-specific assemblies that are often included with applications that do not work on Mono, but for which Mono has its own implementation. Previously (9ec8ec5) we changed mono to deny loading problematic images using Assembly.Load or when one assembly references another and we find a problematic image using the usual assembly search. For Assembly.LoadFrom, we used to emit a warning and then load the assembly anyway. In this commit, we change the behavior: If Assembly.LoadFrom tries to open a problematic image, we will instead probe for an assembly of that name in the default context. That should eventually end up opening Mono's version of that assembly. Example: Suppose a problematic System.Runtime.InteropServices.RuntimeInformation.dll is in the application bin path: /home/user/myapp/bin 1. User code does (for whatever reason) Assembly.LoadFrom ("/home/user/myapp/bin/System.Runtime.InteropServices.RuntimeInformation.dll") 2. We find the image and try to open it; add it to the images absfpath to image hash; note that there are no binding redirects; but that it is a problematic image. We extract the assembly name ("System.Runtime.InteropServices.RuntimeInformation", version x.y.z.w and public key token 123456789a) from the problematic image. 3. We probe for "System.Runtime.InteropServices.RuntimeInformation version x.y.z.w public key token 123456789a" in the default context. 4. We find /home/user/myapp/bin/System.Runtime.InteropServices.RuntimeInformation.dll in the application bin path; we try to open it, we see it's already in the images hash, but it's a problematic image, and we're not in a loadfrom context (we re-probed with default!) so we keep probing 5. We find <prefix>/lib/mono/4.5/Facaded/System.Runtime.InteropServices.RuntimeInformation.dll, it's not a problematic image, so we open that and return it to (3) 6. We return to (2) and close the problematic image and return the good one instead. 7. Assembly.LoadFrom returns with the good image. Fixes mono#8726
The "problematic images" are Windows-specific assemblies that are often included with applications that do not work on Mono, but for which Mono has its own implementation. Previously (9ec8ec5) we changed mono to deny loading problematic images using Assembly.Load or when one assembly references another and we find a problematic image using the usual assembly search. For Assembly.LoadFrom, we used to emit a warning and then load the assembly anyway. In this commit, we change the behavior: If Assembly.LoadFrom tries to open a problematic image, we will instead probe for an assembly of that name in the default context. That should eventually end up opening Mono's version of that assembly. Example: Suppose a problematic System.Runtime.InteropServices.RuntimeInformation.dll is in the application bin path: /home/user/myapp/bin 1. User code does (for whatever reason) Assembly.LoadFrom ("/home/user/myapp/bin/System.Runtime.InteropServices.RuntimeInformation.dll") 2. We find the image and try to open it; add it to the images absfpath to image hash; note that there are no binding redirects; but that it is a problematic image. We extract the assembly name ("System.Runtime.InteropServices.RuntimeInformation", version x.y.z.w and public key token 123456789a) from the problematic image. 3. We probe for "System.Runtime.InteropServices.RuntimeInformation version x.y.z.w public key token 123456789a" in the default context. 4. We find /home/user/myapp/bin/System.Runtime.InteropServices.RuntimeInformation.dll in the application bin path; we try to open it, we see it's already in the images hash, but it's a problematic image, and we're not in a loadfrom context (we re-probed with default!) so we keep probing 5. We find <prefix>/lib/mono/4.5/Facaded/System.Runtime.InteropServices.RuntimeInformation.dll, it's not a problematic image, so we open that and return it to (3) 6. We return to (2) and close the problematic image and return the good one instead. 7. Assembly.LoadFrom returns with the good image. Fixes #8726
The "problematic images" are Windows-specific assemblies that are often included with applications that do not work on Mono, but for which Mono has its own implementation. Previously (9ec8ec5) we changed mono to deny loading problematic images using Assembly.Load or when one assembly references another and we find a problematic image using the usual assembly search. For Assembly.LoadFrom, we used to emit a warning and then load the assembly anyway. In this commit, we change the behavior: If Assembly.LoadFrom tries to open a problematic image, we will instead probe for an assembly of that name in the default context. That should eventually end up opening Mono's version of that assembly. Example: Suppose a problematic System.Runtime.InteropServices.RuntimeInformation.dll is in the application bin path: /home/user/myapp/bin 1. User code does (for whatever reason) Assembly.LoadFrom ("/home/user/myapp/bin/System.Runtime.InteropServices.RuntimeInformation.dll") 2. We find the image and try to open it; add it to the images absfpath to image hash; note that there are no binding redirects; but that it is a problematic image. We extract the assembly name ("System.Runtime.InteropServices.RuntimeInformation", version x.y.z.w and public key token 123456789a) from the problematic image. 3. We probe for "System.Runtime.InteropServices.RuntimeInformation version x.y.z.w public key token 123456789a" in the default context. 4. We find /home/user/myapp/bin/System.Runtime.InteropServices.RuntimeInformation.dll in the application bin path; we try to open it, we see it's already in the images hash, but it's a problematic image, and we're not in a loadfrom context (we re-probed with default!) so we keep probing 5. We find <prefix>/lib/mono/4.5/Facaded/System.Runtime.InteropServices.RuntimeInformation.dll, it's not a problematic image, so we open that and return it to (3) 6. We return to (2) and close the problematic image and return the good one instead. 7. Assembly.LoadFrom returns with the good image. Fixes #8726
@lambdageek how confident are you to landing this to 2018-02? |
The "problematic images" are Windows-specific assemblies that are often included with applications that do not work on Mono, but for which Mono has its own implementation. Previously (9ec8ec5) we changed mono to deny loading problematic images using Assembly.Load or when one assembly references another and we find a problematic image using the usual assembly search. For Assembly.LoadFrom, we used to emit a warning and then load the assembly anyway. In this commit, we change the behavior: If Assembly.LoadFrom tries to open a problematic image, we will instead probe for an assembly of that name in the default context. That should eventually end up opening Mono's version of that assembly. Example: Suppose a problematic System.Runtime.InteropServices.RuntimeInformation.dll is in the application bin path: /home/user/myapp/bin 1. User code does (for whatever reason) Assembly.LoadFrom ("/home/user/myapp/bin/System.Runtime.InteropServices.RuntimeInformation.dll") 2. We find the image and try to open it; add it to the images absfpath to image hash; note that there are no binding redirects; but that it is a problematic image. We extract the assembly name ("System.Runtime.InteropServices.RuntimeInformation", version x.y.z.w and public key token 123456789a) from the problematic image. 3. We probe for "System.Runtime.InteropServices.RuntimeInformation version x.y.z.w public key token 123456789a" in the default context. 4. We find /home/user/myapp/bin/System.Runtime.InteropServices.RuntimeInformation.dll in the application bin path; we try to open it, we see it's already in the images hash, but it's a problematic image, and we're not in a loadfrom context (we re-probed with default!) so we keep probing 5. We find <prefix>/lib/mono/4.5/Facaded/System.Runtime.InteropServices.RuntimeInformation.dll, it's not a problematic image, so we open that and return it to (3) 6. We return to (2) and close the problematic image and return the good one instead. 7. Assembly.LoadFrom returns with the good image. Fixes mono#8726
@marek-safar I think it's probably worth backporting. It's not too disruptive. #8845 |
We had to revert the fix for this issue on |
@lambageek is that a temporary revert or do we need to think about alternative workarounds for MD running on those releases? /cc @slluis |
What about 2018-02 (5.12 series)? |
We can do a backport to |
@lambdageek why not? 2018-02 is part of the 15.8 release. |
Our MSBuild builder just started crashing, so yes, it was a regression. |
Fixes: #1130 Fixes: #1561 (comment) Fixes: #1845 Fixes: #1951 Context: https://bugzilla.xamarin.com/show_bug.cgi?id=10087 Context: https://bugzilla.xamarin.com/show_bug.cgi?id=11771 Context: https://bugzilla.xamarin.com/show_bug.cgi?id=12850 Context: https://bugzilla.xamarin.com/show_bug.cgi?id=18941 Context: https://bugzilla.xamarin.com/show_bug.cgi?id=19436 Context: https://bugzilla.xamarin.com/show_bug.cgi?id=25444 Context: https://bugzilla.xamarin.com/show_bug.cgi?id=33208 Context: https://bugzilla.xamarin.com/show_bug.cgi?id=58413 Context: https://bugzilla.xamarin.com/show_bug.cgi?id=59184 Context: https://bugzilla.xamarin.com/show_bug.cgi?id=59400 Context: https://bugzilla.xamarin.com/show_bug.cgi?id=59779 Context: https://bugzilla.xamarin.com/show_bug.cgi?id=60065 Context: https://bugzilla.xamarin.com/show_bug.cgi?id=60843 Context: mono/mono#6174 Context: mono/mono#6178 Context: mono/mono#6180 Context: mono/mono#6181 Context: mono/mono#6186 Context: mono/mono#6187 Context: mono/mono#6211 Context: mono/mono#6266 Context: mono/mono#6579 Context: mono/mono#6666 Context: mono/mono#6752 Context: mono/mono#6801 Context: mono/mono#6812 Context: mono/mono#6848 Context: mono/mono#6940 Context: mono/mono#6948 Context: mono/mono#6998 Context: mono/mono#6999 Context: mono/mono#7016 Context: mono/mono#7085 Context: mono/mono#7086 Context: mono/mono#7095 Context: mono/mono#7134 Context: mono/mono#7137 Context: mono/mono#7145 Context: mono/mono#7184 Context: mono/mono#7240 Context: mono/mono#7262 Context: mono/mono#7289 Context: mono/mono#7338 Context: mono/mono#7356 Context: mono/mono#7364 Context: mono/mono#7378 Context: mono/mono#7389 Context: mono/mono#7449 Context: mono/mono#7460 Context: mono/mono#7535 Context: mono/mono#7536 Context: mono/mono#7537 Context: mono/mono#7565 Context: mono/mono#7588 Context: mono/mono#7596 Context: mono/mono#7610 Context: mono/mono#7613 Context: mono/mono#7620 Context: mono/mono#7624 Context: mono/mono#7637 Context: mono/mono#7655 Context: mono/mono#7657 Context: mono/mono#7661 Context: mono/mono#7685 Context: mono/mono#7696 Context: mono/mono#7729 Context: mono/mono#7786 Context: mono/mono#7792 Context: mono/mono#7805 Context: mono/mono#7822 Context: mono/mono#7828 Context: mono/mono#7860 Context: mono/mono#7864 Context: mono/mono#7903 Context: mono/mono#7920 Context: mono/mono#8089 Context: mono/mono#8143 Context: mono/mono#8267 Context: mono/mono#8311 Context: mono/mono#8340 Context: mono/mono#8409 Context: mono/mono#8417 Context: mono/mono#8430 Context: mono/mono#8698 Context: mono/mono#8701 Context: mono/mono#8712 Context: mono/mono#8721 Context: mono/mono#8726 Context: mono/mono#8866 Context: mono/mono#9023 Context: mono/mono#9031 Context: mono/mono#9033 Context: mono/mono#9044 Context: mono/mono#9179 Context: mono/mono#9318 Context: mono/mono#9318 Context: xamarin/maccore#628 Context: xamarin/maccore#629 Context: xamarin/maccore#673
Fixes: #1130 Fixes: #1561 (comment) Fixes: #1845 Fixes: #1951 Context: https://bugzilla.xamarin.com/show_bug.cgi?id=10087 Context: https://bugzilla.xamarin.com/show_bug.cgi?id=11771 Context: https://bugzilla.xamarin.com/show_bug.cgi?id=12850 Context: https://bugzilla.xamarin.com/show_bug.cgi?id=18941 Context: https://bugzilla.xamarin.com/show_bug.cgi?id=19436 Context: https://bugzilla.xamarin.com/show_bug.cgi?id=25444 Context: https://bugzilla.xamarin.com/show_bug.cgi?id=33208 Context: https://bugzilla.xamarin.com/show_bug.cgi?id=58413 Context: https://bugzilla.xamarin.com/show_bug.cgi?id=59184 Context: https://bugzilla.xamarin.com/show_bug.cgi?id=59400 Context: https://bugzilla.xamarin.com/show_bug.cgi?id=59779 Context: https://bugzilla.xamarin.com/show_bug.cgi?id=60065 Context: https://bugzilla.xamarin.com/show_bug.cgi?id=60843 Context: mono/mono#6174 Context: mono/mono#6178 Context: mono/mono#6180 Context: mono/mono#6181 Context: mono/mono#6186 Context: mono/mono#6187 Context: mono/mono#6211 Context: mono/mono#6266 Context: mono/mono#6579 Context: mono/mono#6666 Context: mono/mono#6752 Context: mono/mono#6801 Context: mono/mono#6812 Context: mono/mono#6848 Context: mono/mono#6940 Context: mono/mono#6948 Context: mono/mono#6998 Context: mono/mono#6999 Context: mono/mono#7016 Context: mono/mono#7085 Context: mono/mono#7086 Context: mono/mono#7095 Context: mono/mono#7134 Context: mono/mono#7137 Context: mono/mono#7145 Context: mono/mono#7184 Context: mono/mono#7240 Context: mono/mono#7262 Context: mono/mono#7289 Context: mono/mono#7338 Context: mono/mono#7356 Context: mono/mono#7364 Context: mono/mono#7378 Context: mono/mono#7389 Context: mono/mono#7449 Context: mono/mono#7460 Context: mono/mono#7535 Context: mono/mono#7536 Context: mono/mono#7537 Context: mono/mono#7565 Context: mono/mono#7588 Context: mono/mono#7596 Context: mono/mono#7610 Context: mono/mono#7613 Context: mono/mono#7620 Context: mono/mono#7624 Context: mono/mono#7637 Context: mono/mono#7655 Context: mono/mono#7657 Context: mono/mono#7661 Context: mono/mono#7685 Context: mono/mono#7696 Context: mono/mono#7729 Context: mono/mono#7786 Context: mono/mono#7792 Context: mono/mono#7805 Context: mono/mono#7822 Context: mono/mono#7828 Context: mono/mono#7860 Context: mono/mono#7864 Context: mono/mono#7903 Context: mono/mono#7920 Context: mono/mono#8089 Context: mono/mono#8143 Context: mono/mono#8267 Context: mono/mono#8311 Context: mono/mono#8340 Context: mono/mono#8409 Context: mono/mono#8417 Context: mono/mono#8430 Context: mono/mono#8698 Context: mono/mono#8701 Context: mono/mono#8712 Context: mono/mono#8721 Context: mono/mono#8726 Context: mono/mono#8866 Context: mono/mono#9023 Context: mono/mono#9031 Context: mono/mono#9033 Context: mono/mono#9044 Context: mono/mono#9179 Context: mono/mono#9318 Context: mono/mono#9318 Context: xamarin/maccore#628 Context: xamarin/maccore#629 Context: xamarin/maccore#673
Bumps to mono/llvm:release_60@117a508c Bumps to xamarin/xamarin-android-api-compatibility:master@7ccb4802 $ git diff --shortstat e1af6ea..ab3c897d # mono 1443 files changed, 66049 insertions(+), 45745 deletions(-) $ git diff --shortstat bdb3a116..117a508c # llvm 26794 files changed, 4110589 insertions(+), 754376 deletions(-) $ git diff --shortstat c550d1bd..7ccb4802 # xamarin-android-api-compatibility 2 files changed, 16260 insertions(+), 12347 deletions(-) Incomplete summary of easily `grep`able fixes: Fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=11199 Fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=19436 Fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=23668 Fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=26983 Fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=33728 Fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=46917 fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=60065 Fixes: mono/mono#6173 Fixes: mono/mono#6466 Fixes: mono/mono#6647 Fixes: mono/mono#6834 Fixes: mono/mono#7058 Fixes: mono/mono#7137 Fixes: mono/mono#7260 Fixes: mono/mono#7305 Fixes: mono/mono#7402 Fixes: mono/mono#7525 Fixes: mono/mono#7610 Fixes: mono/mono#7649 Fixes: mono/mono#7655 Fixes: mono/mono#7683 Fixes: mono/mono#7685 Fixes: mono/mono#7716 Fixes: mono/mono#7731 Fixes: mono/mono#7785 Fixes: mono/mono#7828 Fixes: mono/mono#7944 Fixes: mono/mono#7947 Fixes: mono/mono#8036 Fixes: mono/mono#8074 Fixes: mono/mono#8089 Fixes: mono/mono#8112 Fixes: mono/mono#8122 Fixes: mono/mono#8143 Fixes: mono/mono#8149 Fixes: mono/mono#8152 Fixes: mono/mono#8175 Fixes: mono/mono#8177 Fixes: mono/mono#8250 Fixes: mono/mono#8267 Fixes: mono/mono#8273 Fixes: mono/mono#8282 Fixes: mono/mono#8310 Fixes: mono/mono#8311 Fixes: mono/mono#8329 Fixes: mono/mono#8340 Fixes: mono/mono#8372 Fixes: mono/mono#8407 Fixes: mono/mono#8409 Fixes: mono/mono#8422 Fixes: mono/mono#8430 Fixes: mono/mono#8439 fixes: mono/mono#8447 Fixes: mono/mono#8469 Fixes: mono/mono#8504 Fixes: mono/mono#8575 Fixes: mono/mono#8597 Fixes: mono/mono#8623 Fixes: mono/mono#8627 Fixes: mono/mono#8698 Fixes: mono/mono#8701 Fixes: mono/mono#8712 Fixes: mono/mono#8721 Fixes: mono/mono#8726 Fixes: mono/mono#8759 Fixes: mono/mono#8787 Fixes: mono/mono#8820 Fixes: mono/mono#8848 Fixes: mono/mono#8866 Fixes: mono/mono#8897 Fixes: mono/mono#8915 Fixes: mono/mono#8970 Fixes: mono/mono#8979 Fixes: mono/mono#9023 Fixes: mono/mono#9031 Fixes: mono/mono#9033 Fixes: mono/mono#9179 Fixes: mono/mono#9234 Fixes: mono/mono#9262 Fixes: mono/mono#9277 Fixes: mono/mono#9318 Fixes: mono/mono#9542 Fixes: mono/mono#9753 Fixes: mono/mono#9839 Fixes: mono/mono#9869 Fixes: mono/mono#9870 Fixes: mono/mono#9943 Fixes: mono/mono#9996 Fixes: mono/mono#10000 Fixes: mono/mono#10303 Fixes: mono/mono#10447 Fixes: mono/mono#10483 Fixes: mono/mono#10488 Fixes: xamarin/maccore#628 Fixes: xamarin/maccore#673 Fixes: #1561 (comment) Fixes: #1845 Fixes: xamarin/xamarin-macios#4347 Fixes: xamarin/xamarin-macios#4617 Fixes: xamarin/xamarin-macios#4618
The "problematic images" are Windows-specific assemblies that are often included with applications that do not work on Mono, but for which Mono has its own implementation. Previously (mono/mono@9ec8ec5) we changed mono to deny loading problematic images using Assembly.Load or when one assembly references another and we find a problematic image using the usual assembly search. For Assembly.LoadFrom, we used to emit a warning and then load the assembly anyway. In this commit, we change the behavior: If Assembly.LoadFrom tries to open a problematic image, we will instead probe for an assembly of that name in the default context. That should eventually end up opening Mono's version of that assembly. Example: Suppose a problematic System.Runtime.InteropServices.RuntimeInformation.dll is in the application bin path: /home/user/myapp/bin 1. User code does (for whatever reason) Assembly.LoadFrom ("/home/user/myapp/bin/System.Runtime.InteropServices.RuntimeInformation.dll") 2. We find the image and try to open it; add it to the images absfpath to image hash; note that there are no binding redirects; but that it is a problematic image. We extract the assembly name ("System.Runtime.InteropServices.RuntimeInformation", version x.y.z.w and public key token 123456789a) from the problematic image. 3. We probe for "System.Runtime.InteropServices.RuntimeInformation version x.y.z.w public key token 123456789a" in the default context. 4. We find /home/user/myapp/bin/System.Runtime.InteropServices.RuntimeInformation.dll in the application bin path; we try to open it, we see it's already in the images hash, but it's a problematic image, and we're not in a loadfrom context (we re-probed with default!) so we keep probing 5. We find <prefix>/lib/mono/4.5/Facaded/System.Runtime.InteropServices.RuntimeInformation.dll, it's not a problematic image, so we open that and return it to (3) 6. We return to (2) and close the problematic image and return the good one instead. 7. Assembly.LoadFrom returns with the good image. Fixes mono/mono#8726 Commit migrated from mono/mono@9ad5255
Usually, if an assembly depends on a known "bad"(windows specific implementation) assembly then the mono runtime can deny loading
it. But if the load is initiated explicitly like via
Assembly.LoadFrom
, then the assembly gets loaded (https://github.com/mono/mono/blob/2018-02/mono/metadata/image.c#L1363-L1365)with a
Loading problematic image ...
.For example, take
System.Runtime.InteropServices.RuntimeInformation.dll
. It'sRuntimeInformation.IsOSPlatform
API's responsedepends on what platform it was built was for. So, a windows specific version would return true even it is running on macOS. Normally,
this gets caught and denied loading. But if it is explicitly loaded via
Assembly.LoadFrom
, then that will breakany subsequent code that depends on that API!
This can show up in VSMac, if some addin loads the bad assembly before the good copy has been loaded into the app domain. Then the
subsequent use of msbuild APIs that depend on
IsOSPlatform
break:Here the windows specific code path runs on macOS, because of the
IsOSPlatform
's result!Related: mono/monodevelop#4788
The text was updated successfully, but these errors were encountered: