Why does EnableCompressionInSingleFile require Self-Contained=true?

[robdplatt]

I was excited to see compression support in .NET 6. However, I see that it is only an option if Self-Contained is true.

Why is that? Why can't we have compression with framework dependant assemblies?

Also, I can't seem to find the option in the UI in VS 2022 17 or VS 2022 17.1.

[vitek-karas]

It's a bit technically challenging to do so. With self-contained, the entire runtime + libraries are part of the executable. Among other things this includes the native parts of the compression algorithms used in the libraries. The host in this case can directly call into the compression algorithm since it's included anyway.

If we were to enable this for framework dependent applications, either the host would have to carry the decompression code in it or it would have to pull it from the framework. The first option is problematic - currently we have only one host for FDD apps, so we would either have to make it larger for everybody, or add another one (more complexity). The second option is also relatively tricky due to the other in which the code is executed (we may need to decompress before we know which runtime we're going to use).

Both are solvable, but we simply didn't think it's worth the effort. At least yet. Framework dependent applications tend to be much smaller and thus the need for compression is probably less.

That said, I would be interested in your scenario, so that we can prioritize this work in the future.

/cc @agocke @VSadov

[robdplatt]

@vitek-karas, Thank you for the response, it's much appreciated.

I wouldn't say its necessarily a requirement for our scenario. In .NETFramework I was used to either using Fody/Costrua or an obfuscation engine to compress resources (images/libraries/etc), and the resulting assembly and its dependencies so that I have a single deployable app that is packed as much as it can be.

Some of our apps hover around 50mb in size due to 3rd party library bloat. Much of it is XML declarations that could be compressed significantly.

Would the Trim Unused Code feature allow the optional bundling of the decompresion code in the host?

[vitek-karas]

Would the Trim Unused Code feature allow the optional bundling of the decompresion code in the host?

I don't know what you mean by this. Trim Unused Code tries to remove code which is not used by the app. This only works on code, not on any data (even embedded), but it might be able to remove entire assemblies in some cases. By default it also only tries to trim the core libraries, not the application code. Note that making an application correctly trimmable is potentially lot of effort - if you turn this on you should get warnings for cases where the tooling could not figure out what the code needs.

The trimmed result is then bundled.

Note that trimming is currently only enabled on self-contained apps as well (making that work on framework dependent apps is actually rather non-trivial: dotnet/linker#2139).

Forgot to answer your question about the VS UI for compression. We don't think it will be commonly used feature, so we didn't invest into adding a UI for it. There are other publish options which don't have UI counterpart.

[robdplatt]

I might have mispoken. You said you only have one host and bundling the decompression routine would make it larger for everyone. I thought maybe the feature that trimmed unused code could remove it for those that don't need it.

[vitek-karas]

The trimming feature only operates on managed code. The decompression has to be fully implemented in native code as it's used to decompress potentially all managed code in the app. So trimming currently has no way to remove it.

[robdplatt]

I see. Well this has been a valuable insight into new areas of the framework. I appreciate the time. Thank you!