Explore ways to reduce Microsoft.DotNet.ILCompiler size

[LakshanF]

We bundle the build package, Microsoft.DotNet.ILCompiler, with the SDK and the size of the package is not small (zipped SDK[7.0.100-rc.2.22459.2] is around 245MB and the expanded bundle size of Microsoft.DotNet.ILCompiler is around 1MB). It will be good to help reduce the SDK size if possible.

The bulk of the size (~722K) comes from the task, ILCompiler.Build.Tasks.dll, and the associated dependency files (System.Collections.Immutable.dll and System.Reflection.Metadata.dll) under tools\netstandard directory.

The linker is currently investigating an issue around compatibility, where the solution to that problem might have similar requirements, and shadowing its progress is a good idea.

Some options to reduce the SDK size that the build package contribute;

• Given the runtime package (runtime.RID.Microsoft.DotNet.ILCompiler), is a superset of the build package, use *native.targets and the task file, ILCompiler.Build.Tasks.dll, from the runtime package instead of using the same files from the bundled build package. We currently import the gateway entry point native target, Microsoft.NETCore.Native.targets, from the build package directory. Instead explore using the runtime package location to import this target file. There are currently challenges around evaluating the runtime package directory.
  • The runtime package path happens dynamically (Import directives happen before that), and the UsingTask directive also need to be evaluated early in the MSBuild evaluation process.
• Using workload option to generate a SDK for NativeAOT. This might have the drawback of the user having to explicitly download the workload first.
• Use an implicit package reference - this is generally not encouraged by MSBuild

[jkotas]

Another issue to consider: How is the system going to work when we ship .NET 8? .NET 8 SDK should be able to publish app that targets .NET 7. Do we need to make sure that the .NET 8 version of Microsoft.DotNet.ILCompiler that is bundled into .NET 8 SDK is compatible with targeting .NET 7? If yes, what is the surface that we need to maintain for this to work?

[agocke]

I think we've shrunk things down as much as reasonable right now. We can revisit this later if it's a big problem.