This article is more than 1 year old
Another piece comes to .NET Core: Microsoft will keep the runtime patched automatically
Only on Windows of course, and only for certain types of deployment
Microsoft will add the .NET Core and .NET 5.0 runtimes to the update service built into Windows - but enterprises must opt in, and applications have to be deployed using a shared runtime for this to be effective.
These .NET runtimes though, unlike the older .NET Framework, are not treated as system or operating system updates. According to Microsoft’s principal engineering manager Jamshed Damkewala, .NET Core and its successor .NET 5.0 are considered “independent products,” and therefore will only be updated if users opt into Microsoft Update, which is distinct from Windows Update.
This is in contrast to the .NET Framework, old-style Windows-only .NET, which is treated as a system component and patched accordingly.
This change has been a long time coming, with Microsoft apparently undecided about the best way to tackle the problem of keeping the runtime patched when security vulnerabilities are discovered.
Developers must publish .NET applications as “Framework dependent” in order to get the benefit of automatic runtime patching
Six years ago, not long after .NET Core was announced, Microsoft's Jay Schmelzer told us: "It's unclear exactly how it is going to work because we haven’t decided yet. We want to figure out with the community what’s the best approach across Windows, Linux and Mac."
Another burden?
The dilemma is that having the system update the runtime means that applications which make shared use of that runtime can in theory break; while not updating it shifts the burden onto developers and administrators to keep their eyes on newly discovered flaws and patch systems manually.
Microsoft had made some effort to avoid the “DLL Hell” issue of yesteryear, where an update required to make application A work might also break application B, by adopting a side-by-side policy even for centrally installed runtimes.
With .NET Core, all feature versions (which have different minor version numbers) are installed side by side and patched separately. Patch versions, distinguished in Microsoft’s system by the third number in the version – such as from 3.1.0 to 3.1.1 – will overwrite existing installs. Patch versions do include non-security fixes though, and compatibility issues are possible.
.NET Core applications have several different deployment modes, including framework-dependent (use a shared runtime) or self-contained (bundle the runtime with the application). As you would expect, only framework-dependent deployments will be patched by Microsoft Update. "NET Core Runtime (distributed with your app) can only be upgraded by releasing a new version of your app," the docs explained.
The change is welcome, though one commenter observed: "The fact that this needs to be an OPT-IN, makes it useless in non-enterprise environment."
It all hinges on how many users opt for Microsoft Update as opposed to Windows Update when presented with those options.
Developers like the idea of self-contained deployments; they know exactly what code will be running and there are fewer dependencies. This approach can work for applications that are frequently updated, such as those being actively maintained via a CI/CD (Continuous Integration/Continuous Delivery) pipeline.
In other scenarios though, it is harder to make the case for self-contained deployments; the risk of security issues being found in the runtime may be more serious than the risk of application breakage. ®
Biting the hand that feeds IT
