PublishTrimmed Without SelfContained Deployment

[RehanSaeed]

Being able to trim the DLL's and maybe even classes and members in framework dependant mode would be very useful for building the smallest possible Docker images.

In a Docker image, you don't need or care about a self contained deployment but you do very much care about trimming the file size as much as possible.

[kirides]

If you care about file size, why would you use a non SelfContained application with trimming?
It does not really make that much sense.

for optimal file size, one should use a very lightweight base image (like alpine) with minimum runtime dependencies for .NET and a self-contained + trimmed application.

If you use a framework dependent build, you can not trim the framework assemblies, which are a large part of the overall size.

Am i'm wrong in thinking this scenario does not really make sense?

[RehanSaeed]

If you add up the Docker image file size for multiple versions of an app, you only pay the cost of downloading the non-self contained ASP.NET Docker image once. After that the size of the app itself minus the .NET framework matters the most. Each new version of the app will only require the size of the app itself in terms of storage.

If you have multiple versions of a self contained app then Docker will store multiple copies of the .NET framework in each image which is innefficient.

[OptiStrat]

I believe this would also be useful when publishing unpackaged framework-dependent apps using the Windows App SDK: the C#/WinRT projections that ship with the Windows App SDK are large, but since CsWinRT 2.0 they are trimmable. It would be nice to be able to take advantage of this.