CopyUsed with new TrimMode

[adirh3]

Previously, TrimMode allowed using link or copyused modes for assemblies that opted in for trimming.
Since .NET 7 Preview 7 (I believe #2856), TrimMode now has partial or full to enable/disable trimming of all assemblies, but now there is no way (unless I missed it) to copy assemblies as is (previously copyused) while not trimming libraries that did not opt in for trimming (currently partial).

Is there any way to achieve copyused and partial mode at the same time?

Thanks!

[sbomer]

In .NET 6, this was accomplished by setting TrimmerDefaultAction=copy and TrimMode=copyused, but in .NET 7 TrimmerDefaultAction will be ignored if you try to set it (the build should produce a warning).

If you need a workaround, you can try setting TrimMode=copyused and _TrimmerDefaultAction=copy, but note that this is not supported. The only officially supported settings in .NET 7 are TrimMode=full or TrimMode=partial.

[adirh3]

If you need a workaround, you can try setting TrimMode=copyused and _TrimmerDefaultAction=copy, but note that this is not supported. The only officially supported settings in .NET 7 are TrimMode=full or TrimMode=partial.

Thanks, it worked! Will it be officially supported in .NET 7 (or later)? or is the copyused feature deprecated? (If so, I think it's worth mentioning in the breaking changes)

[vitek-karas]

Thanks @adirh3 - I'm adding it to the list.

We don't plan to add back support for "copyused" going forward. It's a flaky/hacky approach - if it's needed it means there are almost certainly warnings produced and using "copuysed" is a way to sort of randomly include enough in the app to make it work. For some apps it may work, but it's basically just a guess. We would rather invest in mechanisms which are more predictable in behavior.

[sbomer]

I agree that copyused is worth mentioning. We weren't explicit enough about it in the code change that deprecated TrimmerDefaultAction.

It is strange that today if you set TrimMode=copyused and target net7.0, the assemblies without IsTrimmable metadata will still get full trimming. I think that TrimMode=copyused when targeting .net7 should produce a warning too, and maybe it should even set the default action to copy.

[stevefan1999-personal]

Thanks @adirh3 - I'm adding it to the list.

We don't plan to add back support for "copyused" going forward. It's a flaky/hacky approach - if it's needed it means there are almost certainly warnings produced and using "copuysed" is a way to sort of randomly include enough in the app to make it work. For some apps it may work, but it's basically just a guess. We would rather invest in mechanisms which are more predictable in behavior.

I don't think it is a flaky/hacky approach and it is sometimes a must -- you really want to just account for all the assemblies in so that there is no need to worry about a big list of TrimmerRootAssembly, for example:

	<ItemGroup>
		<TrimmerRootAssembly Include="Cocona" />
		<TrimmerRootAssembly Include="Serilog" />
		<TrimmerRootAssembly Include="Serilog.Sinks.Async" />
		<TrimmerRootAssembly Include="Serilog.Sinks.Spectre" />
		<TrimmerRootAssembly Include="Serilog.Expressions" />
		<TrimmerRootAssembly Include="Microsoft.EntityFrameworkCore" />
		<TrimmerRootAssembly Include="Microsoft.EntityFrameworkCore.Relational" />
		<TrimmerRootAssembly Include="Microsoft.EntityFrameworkCore.Sqlite" />
	</ItemGroup>

This is because I used this for Serilog in appsettings.json:

{
  "Serilog": {
    "Using": [ "Serilog.Sinks.Async", "Serilog.Sinks.Spectre" ],
    "MinimumLevel": "Debug",
    "WriteTo": [
      {
        "Name": "Async",
        "Args": {
          "configure": [
            {
              "Name": "Spectre"
            }
          ]
        }
      }
    ],
    "Enrich": [ "FromLogContext" ]
  }
}

And this would never be scanned by the trimmer for potential reference. We need to be more conservative here regarding dynamic code. 

This is just from a toy project of mine who tried to naively include Serilog and I already have to figure a lot of things out to make Native AOT somewhat usable. Consider if I have a project with more than 100 dependencies this quickly becomes a nightmareish burden.

I don't care about the compile time or binary size, I just want it to run.

[vitek-karas]

I don't care about the compile time or binary size, I just want it to run.

What benefits are you looking for using NativeAOT for this project?

Our general approach in NativeAOT is to heavily rely on the static analysis, meaning that apps are guaranteed to work only if they produce 0 warnings. That obviously comes with lot of limitations and lot of things don't work. On the other hand, it's the only solution we could come up with which is predictable, all of the other solutions can break at any time and diagnosing why they broke was very difficult.

[stevefan1999-personal]

I don't care about the compile time or binary size, I just want it to run.

What benefits are you looking for using NativeAOT for this project?

Our general approach in NativeAOT is to heavily rely on the static analysis, meaning that apps are guaranteed to work only if they produce 0 warnings. That obviously comes with lot of limitations and lot of things don't work. On the other hand, it's the only solution we could come up with which is predictable, all of the other solutions can break at any time and diagnosing why they broke was very difficult.

Maybe give us a suggestion list of assemblies for adding into the TrimmerRootAssembly? It is quite hard to figure out the right combination to add in. In golang you can have a wildcard import* so that we can force add the needed code into the assembler. With dotnet not so much

*:

import _ "time/tzdata"

[vitek-karas]

You could root all assemblies if you wanted, but then the binary size and compile time will be really bad. I guess I don't understand the goal here. If you need all this dynamism, why not use normal CoreCLR to run the app? Why do you want NativeAOT?

[stevefan1999-personal]

You could root all assemblies if you wanted, but then the binary size and compile time will be really bad. I guess I don't understand the goal here. If you need all this dynamism, why not use normal CoreCLR to run the app? Why do you want NativeAOT?

Indeed...I used self-contained + single file + compression before to try and achieve a golang like experience...but the performance is terrible. This is for a private CLI application I wrote to convert game music into MP3 and the boot up time is like 3 seconds (alas, still better than NodeJS CLI apps which I used to take 10 seconds to launch but that's not very fair to compare with a scripted language)

If I put this solution onto a full-fledged game engine, I bet the boot up time would be even worse. Having NativeAOT also helps with some platform limitation, for example I can export functions as dynamic libraries symbols.

[stevefan1999-personal]

You could root all assemblies if you wanted

Also what is the best way to do that without manual cherrypicking?

[vitek-karas]

Sorry - forgot to answer your other question:

Maybe give us a suggestion list of assemblies for adding into the TrimmerRootAssembly?

I don't know how. What if you have code like:

void Test(object value)
{
    value.GetType().GetProperty("Prop");
}

Without more info, the only solution to make this work always would be to keep the Prop property on all types in the entire application. This would quickly grow into very large sizes of application.

And that's not even the worst. Some plugin systems (I'm not sure but I think Serilog does something like this):

foreach (var asm in GetAllAssemblies())
{
    foreach (var t in asm.GetTypes())
    {
        if (t.IsAssignableTo(typeof(IInteresting)))
            DoSomething(t);
    }
}

The only way to make this work is to preserve everything everywhere, not a solution for trying to make the app small.