This document describes .NET Core acquisition and deployment by beginning with how each area is handled in .NET Core 2.1 and identifying new scenarios for .NET Core 3.0 which expose gaps in the experiences. For the purposes of this document, acquisition and deployment are defined as follows:
- Acquisition: Discovery and installation of .NET Core assets on a target system. This includes discovering that updates are available for the Runtime and SDK.
- Deployment: Delivery of the .NET Runtime, applications and application updates.
The table below outlines all of the artifact types used to deliver .NET Core to target systems, basic action someone must take to use the artifact and whether an update notification and acquisition mechanism is available. Note that any 'update' action, is a complete installation of .NET Core. There is no concept of a delta patch.
| Artifact | Platform | Customer action | Update Notification |
|---|---|---|---|
| Visual Studio installer | Windows, Mac | Download and install | Yes |
| pkg/msi/exe | Windows, Mac | Download and install | No |
| deb/rpm | Linux x86_64 | Native package manager | Some distros |
| zip / tar.gz | All supported platforms | Download and manual unpack | No |
| snap | All Linux which support Snap subsystem | Native Snap management tool | Yes |
| dotnet-install.* | Powershell or Bash script | Run script with parameters | No |
| Docker images | All which support Docker | Manual or automated Docker execution | ? |
Note: Because .NET Core is an active open source project, it is expected that some communities will independently fill unique acquisition needs. Two examples we are aware of are installation packages available from chocolatey.org and the Fedora .NET SIG.
Once a customer has installed .NET Core (SDK or Runtime), there are few mechanisms for discovering that an update has been released which do not require custom work on their side.
Discoverability is the most significant shortcoming in the .NET Core acquisition story. Other than a few Linux exceptions, there is no system-provided or user gesture available which answers a question such as "Is there an update available for my .NET Core installation?". The dotnet-install script and release metadata file can be (and are) leveraged by some customers to enable this functionality but there is no turn-key solution or published guidance provided.
Roadmap of improvements:
- Guidance for using, and/or samples leveraging, releases-index.json and releases.json
- A web service which provides an abstraction layer between the above json data, returning version and other support-related answers.
- Provide a user gesture from the host such as
dotnet --check-for-updatewhich could return appropriate data and status (ala --info) based on the json or utilize the web service. This data would provide sufficient information which could be acted on by the customer.
Update acquisition:
Outside of leveraging the Linux package managers and Snap system, there is no notion of 'automatic' update delivery for .NET Core. Further, .NET Core updates are complete, side-by-side installations rather then delta patches which complicates delivery of updates through system level services such as Microsoft Update or the Windows Stores.
Where native installers are used, installation of updates must take place using the platform appropropriate tooling. For this reason, improving update acquisition is an exercise in providing customers with notification that udpates are available as described in the section above. With the data returned from the notification channel, the customer can take appropriate actions to update applications and systems which they maintain.
New Developer Scenarios:
Targetting packs Runtime packs
The application deployment story for .NET Core through version 2.1 has been intentionally simple and, other than publishing to Azure from Visual Studio, leaves the means and process entirely in the developer's hands. Deployment is, at its root, an xcopy-based model. This is the case for Self-Contained and Framework Dependent applications. Framework Dependent application developers have an additional burden of ensuring the appropriate .NET Core Runtimes are present on target systems.
XCopy deployment has been adequate for server-based targets but is not an sufficient for client desktop deployment scenarios which come into play with Winforms and WPF applications in .NET Core 3.0. We have customer input which shows that shops of varying sizes deploy and maintain large numbers of internal .NET Framework applications to large numbers of desktops. Formal deployment mechanisms (eg ClickOnce) are used to manage the deployment and update processes in most cases.
.NET Core 3.0 will use existing technologies to enable deployment of .NET Core 3.0 applications. Initially, only Self-Contained applications will be supported. A Store solution is out of scope for 3.0 though may make sense for a later release.
Bootstrapper could also be used to deploy the .NET Core Runtime MSI (This implies Framed Dependent could be in play for ClickOnce?)
[from Olia's notes] Here is the scope for ClickOnce design side:
- Enable ‘Publish’ for .NET Core Visual Studio projects
- Publishing process should generate another project for the activation bootstrapper, if it does not already exist. This needs to be a desktop .NET application for ClickOnce runtime to work correctly.
- Publishing process should add all Core project outputs as payload files (not references) to the activation bootstrapper project
- Publishing process would then create a deployment
MSIX is not yet a ubiquitous technology which is guaranteed to exist on supported .NET Core platforms (Win7+). We cannot take a dependency on MSIX as a primary deployment mechanism until this gaurantee is a reality. That said, there is an opportunity to begin supporting the technology as a packaging format with broader deployment capabilities coming into scope as MSIX adoption matures.
For .NET Core 3.0:
- Runtime and SDK will continue to be packages as MSIs.
- MSIX support will be limited to .NET Core self-contained applications.
- MSIX as a deployment type will be exposed through Visual Studio Package and .NET Core projects.
Container Registry New architectures
What would it mean to have Shared Frameworks available on the Store? Would this enable a Framework Dependent application to automatically acquire the appropriate Framework?
From the beginning, the servicing model for .NET Core has been 'pull' rather than 'push'. This means that the customers need to discover that an update is avaible, download it through some channel and update applications and/or install the updated runtimes as appropriate. A key weakness in this model is the discoverability of updates as highlighted in the acquisition section above and the solutions are the same.
Developers would have the ability to leverage either the release metadata directly or utilize the web service for update detection. With .NET Core update availability accessible via code, developers could easily automate the update acquistion pipeline from discover to rebuild, CI/CD, testing and into their deployment channels.
Enterprise admins would likewise have the means to easily script Runtime update detection using the same metadata or web service. Guidance could be written to cover strategies for deploying Runtime updates at scale within enterprises.
Need to explore what it would look like to remove previous on successful install. Only needed for Mac and Windows as this is already a feature of our Linux native installers.
I think this is a good start. Some initial comments around structure and scope: