[wasm] Fix tests failing due to trimming - System.Runtime.Loader #52088
Conversation
Test failing with:
```
fail: [FAIL] System.Runtime.Loader.Tests.AssemblyLoadContextTest.LoadAssemblyByPath_ValidUserAssembly
info: System.TypeLoadException : Could not resolve type with token 01000014 from typeref (expected class 'System.MulticastDelegate' in assembly 'System.Runtime, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a')
info: at System.Reflection.RuntimeModule.GetTypes()
info: at System.Reflection.Assembly.GetTypes()
info: at System.Reflection.Assembly.get_DefinedTypes()
info: at System.Runtime.Loader.Tests.AssemblyLoadContextTest.LoadAssemblyByPath_ValidUserAssembly()
info: at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
```
This is failing while trying to enumerate the types on a dependent test
assembly - `System.Runtime.Loader.Test.Assembly`. This assembly is
loaded by the test explicitly, into an ALC. But it is loaded from the
assembly's embedded resources.
The main test project(`System.Runtime.Loader.Tests.csproj`) has:
```xml
<ProjectReference Include="System.Runtime.Loader.Test.Assembly\System.Runtime.Loader.Test.Assembly.csproj"
ReferenceOutputAssembly="false"
OutputItemType="EmbeddedResource" />
```
- This will cause the referenced project to get built
- And the assembly(`System.Runtime.Loader.Test.Assembly.dll`) added to `@(EmbeddedResource)`
- but since we have `ReferenceOutputAssembly=false`, it won't be added
to the list of references used for compiling the main tests assembly
(`System.Runtime.Loader.Tests`).
- but this also means that the test assembly from the referenced
project does *not* get added to the list of assemblies to be linked.
- The result of all this is that when trimming:
- the linker has the set of assemblies to trim, edits the
assemblies, and updates the metadata tokens (type references, for
example) to be consistent within that set.
- Since, `*Test.Assembly.dll` was *not* in the above set, it still
has some old tokens which are no longer valid.
- and that fails when resolving the tokens in the `*Test.Assembly`
to assemblies like `System.Runtime`.
- the fix is to add such assemblies to `@(ManagedAssemblyToLink)`, so
they are included in the linker's set.
Fixes dotnet#51893
radical
added
arch-wasm
|
Tagging subscribers to 'arch-wasm': @lewing Issue DetailsTest failing with: This is failing while trying to enumerate the types on a dependent test The main test project( <ProjectReference Include="System.Runtime.Loader.Test.Assembly\System.Runtime.Loader.Test.Assembly.csproj"
ReferenceOutputAssembly="false"
OutputItemType="EmbeddedResource" />
Fixes #51893
|
|
There are other ways to fix this too, like reference the dependent project assemblies. |
|
System.Runtime.Loader is pretty fundamentally incompatible with trimming. I don't know whether it's the best idea to twist its arms into working. ManagedAssemblyToLink is explicitly documented as "do not add stuff to this". ("Do not add or remove items to/from ManagedAssemblyToLink, because the SDK computes this set during publish and expects it not to change. The supported metadata is:") Cc @vitek-karas |
|
Dynamic assembly loading will not work with trimming. I don't see much value in testing this in that mode since users should not do this. And if they it's bound to break (as visible in this test). In theory we could fix this by adding support for listing "potential plugins" in the SDK - which is what this fix is effectively trying to do, but that doesn't exist. So hacking it in tests doesn't seem right. I think we should simply disable this test for scenarios which involve trimming. |
|
@lewing @steveisok if we can't use trimming, then what should we do about AOT for this? |
|
I'd agree with Vitek. If it doesn't make sense, skip it. |
Disable |
Blazor does late loaded assemblies (but not by path) so this is definitely a thing that happens in practice. That said I think it's handled right now by linking normally and then not including the late loaded assemblies in the list to load initially which should work. |
|
@vitek-karas @MichalStrehovsky Just trying to understand this better. In case of wasm+aot, users would have to depend on trimming too, IIUC, because it takes too long to aot without that. In that case, would |
|
Ok, so in case of blazor you have to specify such late loaded assemblies with: .. so, blazor will be able to pick these up, and have them trimmed correctly. But this would be a problem, at least for non-blazor wasm scenarios, or possibly any others that use trimming. So, maybe we need to have a clear way to add such assemblies for linking, even from project references. And document that? And fix it the same way for the tests here? |
|
@lambdageek is adding some tests for hot reload on wasm. He will handle the case for trimming. I can close this PR then, and the specific tests will remain disabled. |
|
We simply didn't have a need to support trimming for plugin-enabled apps. Mainly because it would require the app to know about all of its plugins at the time the app is produced. In which case you can just build the plugins with the app and ship everything together. In which case trimming will work. You can then choose not to ship some assemblies in the app - but that happens after the whole thing is built. The one missing capability is to add assemblies to the app without having a |
|
@radical Can you please update if this is still good? |
|
Based on #52088 (comment), and #52088 (comment) , closing this PR. |
ghost
locked as resolved and limited conversation to collaborators
Test failing with:
This is failing while trying to enumerate the types on a dependent test
assembly -
System.Runtime.Loader.Test.Assembly. This assembly isloaded by the test explicitly, into an ALC. But it is loaded from the
assembly's embedded resources.
The main test project(
System.Runtime.Loader.Tests.csproj) has:This will cause the referenced project to get built
System.Runtime.Loader.Test.Assembly.dll) added to@(EmbeddedResource)ReferenceOutputAssembly=false, it won't be addedto the list of references used for compiling the main tests assembly
(
System.Runtime.Loader.Tests).project does not get added to the list of assemblies to be linked.
The result of all this is that when trimming:
assemblies, and updates the metadata tokens (type references, for
example) to be consistent within that set.
*Test.Assembly.dllwas not in the above set, it stillhas some old tokens which are no longer valid.
*Test.Assemblyto assemblies like
System.Runtime.the fix is to add such assemblies to
@(ManagedAssemblyToLink), sothey are included in the linker's set.
Fixes #51893