Marking libraries as IsTrimmable

[MichalStrehovsky]

Library or service name.
All libraries.

Is your feature request related to a problem? Please describe.
I've filed this as Azure/azure-libraries-for-net#1274 where our customer hit it, but this is probably applicable to a lot of the SDK assemblies.

I work on the .NET Runtime team and one of the customers I was working with had trouble with excessive size of their app. Looking at their app, I saw that a lot of the big assemblies in their app are produced in this repo (e.g. Microsoft.Azure.Management.Network.Fluent.dll that has 4.7 MB).

The customer was using the PublishTrimmed .NET SDK option to remove unnecessary code from their app. By default, the .NET SDK removes unused code only from libraries that manifest themselves as trimming friendly. This is to prevent breaking code that uses unpredictable reflection (and might end up reflecting on parts of the program that were trimmed).

It would likely a be a good idea to manifest the Azure SDK libraries that are not particularly reflection heavy as trimming friendly. Manifesting them as such is easy - one just need to add an [AssemblyMetadata("IsTrimmable", "True")] attribute. The entire process is described at https://docs.microsoft.com/en-us/dotnet/core/deploying/prepare-libraries-for-trimming. Would it be possible to mark the SDK libraries as such? It would be especially helpful for libraries that are over 1 MB, but everything helps.

Cc @vitek-karas @sbomer who work on IL Trimming in .NET.

[jsquire]

Thank you for your feedback. Tagging and routing to team members for discussion and consideration.

[jsquire]

//cc: @AlexGhiondea, @weshaggard, @maririos

[vitek-karas]

If possible assemblies should be marked as trimmable only once all of the trimmer related warnings are resolved in them. Currently the only way to get all of the warnings is to use the library in an app and trim that app - the setup is described here https://docs.microsoft.com/en-us/dotnet/core/deploying/prepare-libraries-for-trimming#show-all-warnings.

[pakrym]

Most new libraries have a limited amount of reflection in them. There is some in the core but we can annotate it appropriately.

What worries me more is how do we test libraries and ensure that trimmed versions are functional.

@vitek-karas @MichalStrehovsky what testing strategies do you employ for BCL libraries?

[vitek-karas]

We mostly rely on the trimmer warnings. We run the trimmer in a special way (similar to building an app using the libraries as mentioned above) and gather all warnings from the BCL. We then go and fix those warnings. In cases where the fix is complex/tricky we add a special trimming test - for example. These tests are basically tiny apps which are published with trimming and executed.

[pakrym]

@vitek-karas is there some doc describing how 3-rd parties can run the trimmer this way?

[vitek-karas]

The above page has that info - the runtime doesn't run it this exact way, but that's because runtime is special in many ways. We know it's not exactly user friendly right now... working on it...

[pakrym]

My bad. Not enough coffee. Missed the link.

Thank you for the information!