Add a third way of distributing applications: bootstrapped deployment

[CanePlayz]

Basically, I'd love to see an implementation of Tyrrrz/DotnetRuntimeBootstrapper.

The Readme over there perfectly explains what kind of problem we're currently facing and how that problem can be solved. Official support for bootstrapped deployment as an alternative to framework-dependent and self-contained deployment would be a great addition.

I wasn't quite sure into which repository this issue belongs, so if this isn't the right place, please let me know.

[vitek-karas]

This is actually pretty tricky to do correctly everywhere. Especially on Linux figuring out where to download from and how to install is non-trivial. It's also not really doable automagically because it might require sudo.

I assume the ask is predominantly for Windows GUI apps, right?

[CanePlayz]

Well, CLI and Linux users should be technical enough to install the Runtime themselves.

Jokes aside, I totally understand your points. It could also apply to CLI apps, I guess, but honestly, I just wanted to throw this in the room. I'm not experienced with the technical side of it, so feel free to with this issue whatever you want.

[vitek-karas]

Thanks a lot for bringing it up.

I was mostly curious what is your scenario when you think about this. Knowing what problem you're trying to solve will help us think about this the right way and hopefully come up with a good answer. I'm sorry - I should have started with that question first.

[CanePlayz]

All good. And whoops, I thought I had put the right link to the repo into the issue. I'll just copy the text from there because if perfectly describes the drawbacks of current methods and how they can be solved with bootstrapped deployment:

Currently, .NET offers two main ways of distributing applications: framework-dependent deployment and self-contained deployment. Both of them come with a set of obvious and somewhat less obvious drawbacks.

Framework-dependent deployment:

• Requires the user to have the correct .NET runtime installed on their machine. Not only will many users inevitably miss or ignore this requirement, the task of installing the correct .NET runtime can be very challenging for non-technical individuals. Depending on their machine and the specifics of your application, they will need to carefully examine the download page to find the installer for the right version, framework (i.e. base, desktop, or aspnet), CPU architecture, and operating system.

• Comes with an application host that is not platform-agnostic. Even though the application itself (the dll file) is portable in the sense that it can run on any platform where the target runtime is supported, the application host (the exe file) is a native executable built for a specific platform (by default, the same platform as the dev machine). This means that if the application was built on Windows x64, a user running on Windows x86 will not be able to launch the application through the exe file, even if they have the correct runtime installed (dotnet myapp.dll will still work, however).

Self-contained deployment:

• While eliminating the need for installing the correct runtime, this method comes at a significant file size overhead. A very basic WinForms application, for example, starts at around 100 MB in size. This can be very cumbersome when doing auto-updates, but also seems quite wasteful if you consider that the user may end up with multiple .NET applications each bringing their own runtime.

• Targets a specific platform, which means that you have to provide separate binaries for each operating system and processor architecture that you intend to support. Additionally, it can also create confusion among non-technical users, who may have a hard time figuring out which of the release binaries they need to download. Snapshots a specific version of the runtime when it's produced. This means that your application won't be able to benefit from newer releases of the runtime — which may potentially contain performance or security improvements — unless you deploy a new version of the application.

• Is, in fact, not completely self-contained. Depending on the user's machine, they might still need to install the Visual C++ runtime or certain Windows updates, neither of which are packaged with the application. Although this is only required for older operating systems, it may still affect a significant portion of your user base. .NET Runtime Bootstrapper seeks to solve all the above problems by providing an alternative, third deployment option — bootstrapped deployment.

Bootstrapped deployment:

• Takes care of installing the target .NET runtime automatically. All the user has to do is accept the prompt and the bootstrapper will download and install the correct version of the runtime on its own.

• Can also automatically install the Visual C++ runtime and missing Windows updates, when running on older operating systems. This means that users who are still using Windows 7 will have just as seamless experience as those running on Windows 10.

• Does not impose any file size overhead as it does not package additional files. Missing prerequisites are downloaded on-demand.

• Allows your application to benefit from newer releases of the runtime that the user might install in the future. When deploying your application, you are only tying it to a minimum .NET version within the same major. Is truly portable because the provided application host is a platform-agnostic .NET Framework 3.5 executable that works out-of-the-box on all environments starting with Windows 7. This means that you only need to share a single distribution of your application, without worrying about different CPU architectures or other details.