Feature request: in-place, upgradeable installers

[leecow]

@natemcmaster commented on Fri Jun 01 2018

Is your feature request related to a problem? Please describe.
Old versions of .NET Core are taking a lot of disk space on my dev machine. This is in part because Visual Studio so rapidly updates and automatically brings in new .NET Core versions.

Runtime: I don't need most of them because the runtime will auto-rollforward to latest patched versions.
SDK: because the SDK is highly backwards compatible, I generally don't use global.json because the latest stable SDK works well for most projects.

Describe the solution you'd like
I'd like a way to have the Windows installers upgrade in place and trim unused older runtimes and SDKs. I'd also like a way to cleanup unsued packages from C:\Program Files\dotnet\sdk\NuGetFallbackFolder.

Describe alternatives you've considered

• The runtime and SDK installers could use MSI to do the in-place upgrade
• Provide a tool such as dotnet-uninstaller which can trim unused versions of the runtime/SDK.
• Provide a tool to cleanup C:\Program Files\dotnet\sdk\NuGetFallbackFolder to remove packages matching unused, old runtimes

Additional context

---

@leecow commented on Fri Jun 01 2018

moving to core-setup

[dasMulli]

Related: https://github.com/dotnet/cli/issues/6896, dotnet/sdk#2295

[steveharter]

This is a fairly large feature; we need to prioritize this and coordinate with dotnet/cli#6896

cc @jeffschwMSFT @rakeshsinghranchi

[rakeshsinghranchi]

This feature request needs further discussion around the suggested solution list. Note that upgradeable installers will cause machine reboot.

During .NET Core 2.1, for Linux installers, we enabled producing upgradeable major.minor packages. for e.g dotnet-runtime-2.1 and dotnet-runtime-2.1.1 ( in future ) are major upgradeable . We can extend the similar upgrade story to Windows too.

cc @Petermarcu

[dagood]

Why closed? Don't we need to do this in the shared framework bundle, too?

[joeloff]

We'd need this for the hosting bundle as well

[dagood]

That would be https://github.com/aspnet/AspNetCore/tree/master/src/Installers/Windows/WindowsHostingBundle, right? Filed dotnet/aspnetcore#7729 if so.

/cc @natemcmaster

[sdmaclea]

@richlander @vitek-karas Is the roll forward policy design consistent with this direction?

[vitek-karas]

My understanding of this feature is that the installer automatically uninstalls older patch versions. So if the machine has 3.0.1 and I'm about to install 3.0.2, the 3.0.1 will be removed.

Already existing roll forward behavior is to always roll forward to latest available patch. So even if the machine has both 3.0.1 and 3.0.2, only the 3.0.2 will be used regardless of what exact version the app specifies.

Note: This roll forward to latest patch can be disabled, but it's very rare and very explicit.

The upcoming changes to roll forward behavior are not going to change the patch behavior. The host will still roll forward to latest patch version almost always (can be disabled, but should be rare).

[dagood]

Thanks, I'd say it's consistent with that: the in-place upgrade behavior removes old patch versions that the host would ignore anyway due to roll-forward.

Note: This roll forward to latest patch can be disabled, but it's very rare and very explicit.

There's a similar escape hatch in the installers: in-place upgrade is only implemented on the bundles, so you can still install older MSIs side-by-side if you really need to.

[dagood]

Closing: we've had this implemented for a while now, since dotnet/core-setup#5509. (Installing a Runtime uninstalls older Runtimes within the same product band.) Other efforts to address the general problem of having a bunch of old Runtimes installed are tracked elsewhere.