Asp.Net 5.0 Blazor Assembly.Load does not create types that link to types in loaded assemblies #42207
Comments
|
I suspect you'll need to load things in to the default load context |
|
Using AssemblyLoadContext.Default.LoadFromStream as an alternative does successfully load the assembly so that a cast to a common interface can be performed. I think the implementation of the custom AssemblyLoadContext created during Assembly.Load has an issue in that it should not be loading any other assemblies other than the one its given, finding other assemblies should delegate to AssemblyLoadContext.Default. |
Dotnet-GitSync-Bot
added
area-AssemblyLoader-coreclr
untriaged
|
Tagging subscribers to this area: @vitek-karas, @agocke |
|
cc @CoffeeFlux |
CoffeeFlux
added
area-AssemblyLoader-mono
and removed
area-AssemblyLoader-coreclr
untriaged
|
Tagging subscribers to this area: @CoffeeFlux |
|
I assume this is the result of our bundle check being very early in the loading algorithm, so if the assembly isn't loaded in the custom ALC it tries the load it in via the bundle before checking the default context. The solution is probably to just move the bundle check later in the process, after we've checked the default ALC. This is maybe worth backporting, so I'll have a fix up ASAP. I'll add a test as well. Thanks for such a detailed bug report, it makes a fix much easier! |
Fixes dotnet/runtime#42207 The new test is based on the sample from that issue. The naive fix (moving all bundle loading to after we check the default ALC) highlights that the satellite assembly tests were passing for the wrong reasons. The full fix here handles satellite loads correctly, putting them in the same ALC as the parent assembly. One non-satellite test that was previously passing also passed erroneously, but it makes no sense on wasm so disable it. I don't know how likely we think customers are to use custom ALCs on wasm, but the current behavior seems fairly broken. For the repro I use `Assembly.Load(byte[])` to match the customer issue, but I think you can achieve the same effect by just loading an assembly into a custom ALC and trying to cast the same way. If we do want to backport, the problem is these changes are all on top of @safern's previous bundle work, so I'd either need to backport the whole thing or manually implement some of this work on top of RC2. Maybe the latter option is the way to go here? Not sure how to proceed. cc: @marek-safar @SamMonoRT
|
As a summary of things as they stand: I have a PR up that adds a libraries test for this, along with a fix. It's not a simple backport, and there are some concerns about a previous PR this builds on, so I'm going to talk things through with @lambdageek, decide how we want to approach this, and then backport as appropriate. |
|
Backport has been merged for this. Waiting on mono/mono CI to merge the main PR. |
…20406) Fixes dotnet/runtime#42207 The new test is based on the sample from that issue. The naive fix (moving all bundle loading to after we check the default ALC) highlights that the satellite assembly tests were passing for the wrong reasons. The full fix here handles satellite loads correctly, putting them in the same ALC as the parent assembly. One non-satellite test that was previously passing also passed erroneously, but it makes no sense on wasm so disable it. I don't know how likely we think customers are to use custom ALCs on wasm, but the current behavior seems fairly broken. For the repro I use `Assembly.Load(byte[])` to match the customer issue, but I think you can achieve the same effect by just loading an assembly into a custom ALC and trying to cast the same way. If we do want to backport, the problem is these changes are all on top of @safern's previous bundle work, so I'd either need to backport the whole thing or manually implement some of this work on top of RC2. Maybe the latter option is the way to go here? Not sure how to proceed. cc: @marek-safar @SamMonoRT Co-authored-by: CoffeeFlux <[email protected]>
ghost
locked as resolved and limited conversation to collaborators
Describe the bug
When using Blazor running in the browser with dotnet 5.0.0-preview.8.20407.11 an assembly loaded using Assembly.Load(byte[] rawAssembly, byte[]? rawSymbolStore) will create types that reference assemblies that appear to be duplicates of assemblies that have already been loaded preventing any use of shared types. This behavior is different to other non WASM runtimes and to the dotnet 3.2.0 WASM runtime.
The bug is not present in the release of WASM Blazor in dotnet core 3.2.0 and was found during an upgrade of existing code.
E.g.
To Reproduce
A reproduction based on the Blazor starter project is available from: https://github.com/allderidge/BlazorBugReport_AssemblyLoad
There are two solutions:
The web page shown running in dotnet 5.0:
The web page shown running in dotnet core 3.2
Illustrative code
Further technical details
5.0.0-preview.8.20414.8dotnet --infoMicrosoft Visual Studio Enterprise 2019 Preview Version 16.8.0 Preview 2.1The text was updated successfully, but these errors were encountered: