Skip to content
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

NativeAOT's implementation of TrimmerRootAssembly is too aggressive #92271

Closed
vitek-karas opened this issue Sep 19, 2023 · 1 comment · Fixed by #92864
Closed

NativeAOT's implementation of TrimmerRootAssembly is too aggressive #92271

vitek-karas opened this issue Sep 19, 2023 · 1 comment · Fixed by #92864

Comments

@vitek-karas
Copy link
Member

For example:

TestApp.csproj (normal console app)

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net8.0</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <ProjectReference Include="..\TestLib\TestLib.csproj" />
    <TrimmerRootAssembly Include="TestLib" />
  </ItemGroup>

</Project>

And then the TestLib contains

using System.Runtime.Loader;

namespace TestLib;

internal class Derived : AssemblyLoadContext
{
}

Now running (on the TestApp):

dotnet publish --self-contained /p:PublishTrimmed=true

The output will contain AssemblyLoadContext class in CoreLib, but for example the AssemblyLoadContext.GetAssemblyName method will be missing from it (since it's not used anywhere).

Now publishing the same app with NativeAOT:

dotnet publish /p:PublishAot=true

Using sizoscope tells us that AssemblyLoadContext.GetAssemblyName is actually preserved in the app.

In short, the NativeAOT implementation of assembly rooting seems to be rooting too much. For example it seems to fully root all base types of the types from the target assembly, including all members on such base types.

This is not a problem necessarily for cases where TrimmerRootAssembly is used as a workaround to trim incompatibilities (it's adds more code), but it can matter more when it's used in a test app to validate trim/AOT compatibility of a library.

It would also be nice to make the behavior consistent between illink and ilc.

@ghost ghost added the untriaged New issue has not been triaged by the area owner label Sep 19, 2023
@ghost
Copy link

ghost commented Sep 19, 2023

Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas
See info in area-owners.md if you want to be subscribed.

Issue Details

For example:

TestApp.csproj (normal console app)

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net8.0</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <ProjectReference Include="..\TestLib\TestLib.csproj" />
    <TrimmerRootAssembly Include="TestLib" />
  </ItemGroup>

</Project>

And then the TestLib contains

using System.Runtime.Loader;

namespace TestLib;

internal class Derived : AssemblyLoadContext
{
}

Now running (on the TestApp):

dotnet publish --self-contained /p:PublishTrimmed=true

The output will contain AssemblyLoadContext class in CoreLib, but for example the AssemblyLoadContext.GetAssemblyName method will be missing from it (since it's not used anywhere).

Now publishing the same app with NativeAOT:

dotnet publish /p:PublishAot=true

Using sizoscope tells us that AssemblyLoadContext.GetAssemblyName is actually preserved in the app.

In short, the NativeAOT implementation of assembly rooting seems to be rooting too much. For example it seems to fully root all base types of the types from the target assembly, including all members on such base types.

This is not a problem necessarily for cases where TrimmerRootAssembly is used as a workaround to trim incompatibilities (it's adds more code), but it can matter more when it's used in a test app to validate trim/AOT compatibility of a library.

It would also be nice to make the behavior consistent between illink and ilc.

Author: vitek-karas
Assignees: -
Labels:

area-NativeAOT-coreclr

Milestone: -

@ghost ghost added the in-pr There is an active PR which will close this issue when it is merged label Oct 1, 2023
@ghost ghost removed in-pr There is an active PR which will close this issue when it is merged untriaged New issue has not been triaged by the area owner labels Oct 5, 2023
@ghost ghost locked as resolved and limited conversation to collaborators Nov 4, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant