Announcement: Dropping older framework versions

[terrajobst]

Our packages drop support for frameworks older than .NET Framework 4.6.1, .NET Core 3.1, or .NET Standard 2.0.

Reason

Dropping a framework from a package is a source breaking change. At the same time, continuing to build for all frameworks we ever shipped increases the complexity and size of a package. In the past, we've solved this issue by harvesting, which basically means:

1. We build only for "current" frameworks
2. During build, we download the earlier version of the package and "harvest" the binaries for earlier frameworks we no longer build for

While this means that you can always update without worrying that we drop a framework it also means that you'll never get any bug fixes or new features if you consume a harvested binary. In other words, harvested assets can't be serviced which is now hidden because from your point of view you're able to keep updating the package to a later version even thought you're consuming the same old binary that we're no longer updating.

For .NET 6, we plan to no longer perform any form of harvesting to ensure that all assets we ship can be serviced. This means we're dropping anything older than:

• .NET Framework 4.6.1
• .NET Core 3.1
• .NET Standard 2.0

If you're currently referencing an impacted package from an earlier framework, you'll no longer be able to update the referenced package to a later version. Your choice is to either retarget your project to a later version or not updating the referenced package (which is generally not a huge take back because you're already consuming a frozen binary anyways).

Affected packages

These packages no longer ship old frameworks:

• Microsoft.Extensions.DependencyModel
• Microsoft.Win32.Registry.AccessControl
• Microsoft.Win32.SystemEvents
• System.ComponentModel.Annotations
• System.ComponentModel.Composition
• System.ComponentModel.Composition.Registration
• System.Composition.AttributedModel
• System.Composition.Convention
• System.Composition.Hosting
• System.Composition.Runtime
• System.Composition.TypedParts
• System.Data.Odbc
• System.Diagnostics.DiagnosticSource
• System.Diagnostics.EventLog
• System.Diagnostics.PerformanceCounter
• System.DirectoryServices
• System.DirectoryServices.AccountManagement
• System.DirectoryServices.Protocols
• System.Drawing.Common
• System.IO.Packaging
• System.IO.Pipelines
• System.Management
• System.Net.Http.WinHttpHandler
• System.Reflection.Context
• System.Runtime.Caching
• System.Runtime.CompilerServices.Unsafe
• System.Security.Cryptography.Cng
• System.Security.Cryptography.OpenSsl
• System.Security.Cryptography.Pkcs
• System.Security.Cryptography.ProtectedData
• System.ServiceProcess.ServiceController
• System.Speech
• System.Text.Encoding.CodePages
• System.Text.Encodings.Web
• System.Threading.AccessControl
• System.Threading.Channels

These packages will no longer be updated because their implementation is now part of the .NET 6 platform:

• Microsoft.Win32.Registry
• System.ComponentModel.Annotations
• System.IO.FileSystem.AccessControl
• System.IO.Pipes.AccessControl
• System.Security.AccessControl
• System.Security.Cryptography.Cng
• System.Security.Cryptography.OpenSsl
• System.Security.Principal.Windows

Timelines

Many of these changes are shipping in .NET 6 Preview 5 while some will ship in .NET 6 Preview 6.

[seangwright]

Harvesting sounds like a slightly dangerous practice. I never knew it happened before this announcement.

If I update a package to a newer version, I would expect to get that newer version's features and not the previous versions features under a new version number (dependent on my TFM).

Happy to hear this will no longer happen!

[terrajobst]

I'd agree that the old model broke customer expectations but I don't believe it to be dangerous. It's not any different from the customer not upgrading their package.

[GrabYourPitchforks]

To expand on Immo's comment above - when we build security patches for packages, we ensure that all binaries in the package are patched. This means that if we make an announcement "version 4.0.0 of <some package> has a vulnerability, and you should use version 4.0.1 instead," then every single binary contained within the 4.0.1 package will have the patch. We backport the patch and reharvest the patched binary if needed in order to fulfill this contract. So there shouldn't be any danger (from a security perspective) to consuming apps.

This "backport and reharvest" process generally only applies to security patches. We don't tend to backport new features or non-security bug fixes to harvested versions.

[MagicAndre1981]

But does not show that a lot of nuget updates in NuGet UI, because PackageReferenceInclude this doesn't allow version ranges like packages.config ?

[terrajobst]

Potentially. Hence, the recommendation to update the consuming project to a later framework version.

[joperezr]

@terrajobst for ZBB tracking, is it ok if we move the milestone of this issue to future?

[terrajobst]

We can just close the announcement here. We should probably leave the milestone as 6.0.0 for clarity. Of course, people can still post comments here :-)