Optimize .NET installation

[craxal]

Storage Explorer comes prepackaged with the .NET runtime, either as a sub-installer (Windows), bundled runtime (macOS), or dependency (Linux snap). Whatever the form or installation, it is difficult to ensure the .NET runtime remains up-to-date. We should find a way to allow users to update .NET.

Goal

Drop .NET bundles from installations to simplify dependencies. Give users to sufficient guidance for installing appropriate versions of .NET.

[craxal]

Initial findings

Windows

The Storage Explorer installer comes bundled with a .NET runtime installer pulled from the .NET website. Before running the installer, the Storage Explorer installer checks the registry for an existing installation of .NET. If the minimum required version is not found, Storage Explorer runs the .NET installer.

ServiceHub is preconfigured to look for existing .NET installations.

Since the installer writes to the registry, Windows Update should be able to keep this version up-to-date without any user input.

macOS

Storage Explorer does not ship with any .NET components directly, because ServiceHub already comes with a self-contained .NET runtime.

Because ServiceHub comes with a self-contained .NET runtime, .NET effectively becomes an app component that we must maintain. If .NET needs to be updated, so does ServiceHub. This in turn means Storage Explorer would need to release a new version in order to update .NET.

Linux (snap)

The Storage Explorer snap declares a dependency on the dotnet-runtime-8.0 package. Although this package pulls patch updates, the version of .NET effectively becomes a self-contained components with a fixed version at the time the snap is created. Updating .NET would require a new snap, and thus a new release.

ServiceHub is similar to Windows in that it is preconfigured to look for existing .NET installations. But since Storage Explorer has effectively taken responsibility for maintaining the .NET component, it still means a new release would be needed to update.

Options

"Hard" dependency

Considering that two platforms essentially provide .NET as a self-contained component already, we could consider .NET as a "hard" dependency for all platforms.

Pros:

• Simplifies installation.
• Decouples app from user's system and preexisting components.

Cons:

• Increases app size (for Windows).
• Requires new app release to update .NET and other components, which is time consuming.

"Hard" dependency with updates

As an alternative to full releases, we could enhance the Storage Explorer update features to check for and update components as they become available, sort of like updating extensions separately from the base application.

Pros:

• Reduces app cost by updating components separately, avoiding full releeases.

Cons:

• Adds complexity to app.

"Soft" dependency

Instead of "hard" dependencies, we forgo shipping Storage Explorer with any .NET components. Users would need to make sure .NET is installed. Storage Explorer's auto-update feature could be enhanced to check for updates to other components, including .NET, and alert users that updates are available.

Pros:

• Reduces app installation complexity and maintenance costs.

Cons:

• Potentially a step back from when the .NET installer was first included.
• Puts responsibity on users to make sure their installation of .NET is correct or up-to-date.

Questions

• Is it possible to override the default configurations that come with the ServiceHub packages?
• What were the initial reasons for including a .NET installer with Storage Explorer?
• Is a separate installation of .NET feasible for the Storage Explorer Linux snap? Would it be able to work in the snap sandbox environment?