search

dotnet / runtime

.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.
https://docs.microsoft.com/dotnet/core/
MIT License
15.13k stars 4.7k forks source link

Improve single file publish to allow embedding of other digital assets without self-extraction #91202

Open nietras opened 1 year ago

nietras commented 1 year ago

In https://github.com/dotnet/runtime/discussions/90915 I asked and answered how one can use the existing single file bundling to embed other digital assets without self-extraction. This necessitated quite a bit of hacking not least modifying the bundle manifest after the single file is created. It would be great if this experience could be improved as also discussed and repeated below here.

Embedding assets into managed assemblies simply isn't usable. Consider ML and other cases where one has very large digital assets. This will only become more common. We need support for it. And all the pieces are there with the single file publishing and only a few things would be needed to allow using it for that e.g.

In general it would be nice if there was a bit more flexibility around this. I'm fine with the bundle probe delegate, as this is for advanced usage, but at least it would be nice if this does not actively try to not make this feasible and allow embedding/bundling whatever we want.

ghost commented 1 year ago

Tagging subscribers to this area: @agocke, @vitek-karas, @vsadov See info in area-owners.md if you want to be subscribed.

Issue Details
In https://github.com/dotnet/runtime/discussions/90915 I asked and answered how one can use the existing single file bundling to embed other digital assets without self-extraction. This necessitated quite a bit of hacking not least modifying the bundle manifest after the single file is created. It would be great if this experience could be improved as also discussed and repeated below here. --- Embedding assets into managed assemblies simply isn't usable. Consider ML and other cases where one has very large digital assets. This will only become more common. We need support for it. And all the pieces are there with the single file publishing and only a few things would be needed to allow using it for that e.g. * Add optional `SelfExtract` metadata to `FilesToBundle` items to allow overriding whether a given specific file should self-extracted (overrides any defaults) * Add optional `Compress` metadata to `FilesToBundle` items to allow overriding whether a given specific file should be compressed or not (overrides any defaults) * Allow embedding any kind of file disregarding hard-coded rules for which files and `IncludeAllContentForSelfExtract` perhaps via some other option `IncludeAllContent`. In general it would be nice if there was a bit more flexibility around this. I'm fine with the bundle probe delegate, as this is for advanced usage, but at least it would be nice if this does not actively try to not make this feasible and allow embedding/bundling whatever we want.
Author: nietras
Assignees: -
Labels: `area-Single-File`, `untriaged`
Milestone: -
vitek-karas commented 1 year ago

Could you please describe what the scenario for this is? We can make the MSBuild/bundler more flexible, but if there's no runtime side changes it doesn't help much. Relying on the host/runtime contract the way your solution does is not something we should promote to developers, it's just too fragile.

Some general comments:

Single-file is not meant as a replacement for installers - and we're unlikely to invest into features which are only useful for that type of scenario. The place where we see value in it are things like command line tools and other "Run tool by starting the exe by hand" scenarios.

But honestly the main consideration is that adding new capabilities like this should ideally work across most form factors. Embedded resources work regardless if the app is built as single-file, trimmed, AOT, MAUI, or anything else. Adding new capability to embed data into single-file is not going to solve the same problem for NativeAOT apps and so on.

For me, the NativeAOT compatibility specifically is something I see as important. The typical use case for single-file also fits very well the use cases for NativeAOT - and I think people will be migrating those scenarios to NativeAOT more and more. The mechanisms used in single-file will not work in NativeAOT, or would require significant changes to make them work.

/cc @elinor-fung