Karlston Posted December 6, 2020 Share Posted December 6, 2020 Microsoft .NET Core updates will be offered via Microsoft Update Microsoft announced this week that .NET Core updates will be offered via Microsoft Updates on Windows as of December 2020. The terminology may be confusing, especially to home users who may only know about Windows Updates. The main difference between Windows Updates and Microsoft Updates is that the latter includes updates for other Microsoft products. You may know that you can enable an option in Windows Update on your Windows system to get updates for other products via the operating system's automatic updating function. On Windows 10, you open the Settings app, go to Update & Security > Advanced Options, and check the "Receive updates for other Microsoft products when you update Windows" option on the page that opens. If you want to stop receiving those updates, toggle the option to off instead. Microsoft points out that the change gives organizations more control over the updating process, as .NET Core updates may be installed via Microsoft Update / Windows Update once it lands. It is completely optional. Up until now, .NET Core updates were not made available via Microsoft Update because of customer concerns that updates could break functionality. The concern was based on .NET Framework updates, e.g. from 4.5 to 4.8 though as these updates are installed in-place and not side-by-side. Updates for .NET Core are installed side-by-side for the most part. The only exception are monthly servicing updates as these replace previous monthly servicing updates. Here are the details on the change: .NET Core updates will be offered via Microsoft Update. The technology is an independent product; the .NET Framework is a component of Windows, and as such updated via Windows Update. Microsoft Update will maintain one update within each SDK feature band, e.g. version 3.1.10 while previous 3.1.x versions are removed; this is done to reduce the disk footprint of .NET Core installations. Microsoft Update will only offer stable .NET Core updates and not for unsupported versions, e.g. Nightly builds. Administrators may block .NET Core updates from being offered via Microsoft Update. Admins need to approve .NET Core product entries before these become available in managed deployment environments such as WSUS. If the product entries are not approved, no updates will be offered. Microsoft published a set of Registry keys to block certain or all .NET Core updates outright. The keys work on managed and unmanaged devices. .NET Core Version Registry Key Name Value Block all .NET Core updates [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NET] “BlockMU” dword:00000001 Block .NET 5.0 updates [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NET\5.0] “BlockMU” dword:00000001 Block Core 3.1 updates [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NET\3.1] “BlockMU” dword:00000001 Block Core 2.1 updates [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NET\2.1] “BlockMU” dword:00000001 You can use the following Registry files to apply the changes to the system you run them on. Just download the following archive and extract it on your system: block-net-core-updates You find four Registry files in the archive that block 1) all .NET Core updates, b) .NET Core 5.0 updates, c) .NET Core 3.1 updates, and d) .NET Core 2.1 updates on the device. Check out Microsoft's detailed post on the change for additional details. Windows home users who don't want .NET Core updates delivered via Microsoft Update need to either apply the Registry values or disable Microsoft Update on the system. Most home users may want these updates to be installed automatically though to stay up to date. Microsoft .NET Core updates will be offered via Microsoft Update Link to comment Share on other sites More sharing options...
x3r0 Posted December 7, 2020 Share Posted December 7, 2020 The current state of .NET Core is a mess, similar to ECMA Javascript... Development process it too fast while market acceptance is very slow, added with fast end of line product. Link to comment Share on other sites More sharing options...
Pete 12 Posted December 7, 2020 Share Posted December 7, 2020 Will it give us headaches , when always updating this .NET Core , better to turn these off ............??? Any benefit when updating it ??? Link to comment Share on other sites More sharing options...
aum Posted December 7, 2020 Share Posted December 7, 2020 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. ® Source Link to comment Share on other sites More sharing options...
Karlston Posted December 8, 2020 Author Share Posted December 8, 2020 Similar topics merged. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.