microsoft
Optimize .NET installation
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.
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?
On the possibility of using existing .NET installations instead of bundling:
Self-contained distribution (SCD) refers to a .NET runtime bundled with an app or component.
Framework-dependent distribution (FDD) refers to an existing .NET installation.
- Windows uses an FDD with the caveat that we ship with a .NET installer that runs if an existing .NET installation is not found.
- macOS uses an SCD bundled with the ServiceHub component. ServiceHub does not currently ship an FDD version for macOS, so we'd need to get them to build one for us. We'd also need to consider how to guide users to .NET installation if a suitable version can't be found. We may need to consider building a macOS installer bundled with a .NET installer similar to Windows.
- Linux snap is technically an FDD. Although we bundle the runtime when building the snap, it's more like we preinstall the latest .NET. Put another way, it's like the Windows installer but without the explicit installation steps.