search

dotnet / core

.NET news, announcements, release notes, and more!
https://dot.net
MIT License
20.87k stars 4.89k forks source link

.NET Package Maintenance (deprecation) #7420

Open leecow opened 2 years ago

leecow commented 2 years ago

.NET Package Maintenance

.NET Core was released in June 2016, and over the last six years, many thousands of NuGet packages have been published under the .NET umbrella. Many of these packages are legacy or out-of-support already. As things stand today, there is no information associated with these packages to indicate their support status.

To provide developers with better package support status information, the .NET team will start using the NuGet Package Deprecation feature. Deprecated packages remain visible on nuget.org, to clients such as Visual Studio and the .NET CLI, and can be restored by projects. In addition to updating existing packages, we will mark packages as appropriate when new versions are released so that developers can access up-to-date information on the packages they use.

Which Packages will be deprecated

As a general principle, packages that are out of support per the .NET Support Policy will be marked deprecated. Packages that were part of abandoned projects, such as dnx, will be marked deprecated, as will packages that were part of earlier preview releases.

After we are caught up marking previously released packages, we will update packages when new versions are released. For example, when .NET 6.0.10 releases, package versions for 6.0.9 will be marked deprecated.

AspNetCore 2.2 is a unique category, particularly around .NET Framework usage. We will work out how best to address these packages getting caught up and staying current at each release.

Timing

We would like to begin the package marking process next week and first want to hear if there are any issues that have not been considered. Please see the .NET Package Deprecation list and use this issue to comment.

SeanKilleen commented 2 years ago

I appreciate the heads up on this.

My only concern -- In my mind, when I think of deprecation, I think:

However,

We will update packages when new versions are released. For example, when .NET 6.0.10 releases, package versions for 6.0.9 will be marked deprecated.

Seems like it could risk creating a noise issue in the ecosystem. There isn't anything wrong with the package in that instance; we're just trying to encourage users to stay current. And while I think encouraging to stay current is a good goal, I think deprecating all prior packages beyond current seems a bit heavy-handed to get there, and may risk users treating deprecation as less concerning or worthy of their investigation, harming the overall goal.

A better investment toward this goal may be tooling or guidance or upgrade guides that make upgrading and testing upgrades minimally risky, thus enabling more to feel "safe" about approaching them.

KalleOlaviNiemitalo commented 2 years ago

AspNetCore 2.2 is a unique category, particularly around .NET Framework usage.

Do you mean AspNetCore 2.1? That's what is supported on .NET Framework. https://dotnet.microsoft.com/platform/support/policy/aspnetcore-2.1

terrajobst commented 2 years ago

@SeanKilleen

A better investment toward this goal may be tooling or guidance or upgrade guides that make upgrading and testing upgrades minimally risky, thus enabling more to feel "safe" about approaching them.

I like that. I have seen folks running "update all" in VS's UI just in case. Some folks even forget to uncheck "include prerelease" which then creates more problems down the road.

Maybe NuGet should have safe update all, i.e. update to latest stable minor version? /cc @JonDouglas @clairernovotny 

$ dotnet refresh

or 

$ dotnet restore --refresh

Basically "update package references to latest stable minor (if the package reference is a stable version) or latest minor prerelease (if the package reference is a prerelease).

SeanKilleen commented 2 years ago

@terrajobst yes, I think something like that would lead to more impact.

If the goal is ".NET projects keep their dependencies up to date", I think tooling like the above -- as well as great release notes and upgrade guidance -- will better enable it without the negative impact of diluting the meaning of a deprecation.

schemburkar commented 2 years ago

Can the packages be marked outdated rather than deprecated?

The subtle difference being that it tells consumers that the package is still fine, just not latest vs it might have known vulnerabilities and is now deprecated

I do agree with @SeanKilleen that there might be noise in the ecosystem when this happens.

leecow commented 2 years ago

Thanks, @KalleOlaviNiemitalo. What I'm referring to with AspNetCore 2.2 is that a number of new features were added which are not in 2.1 creating a support culdesac. Some AspNetCore / .NET Framework customers depend on these features so we need to be thoughtful in how we handle that set of 2.2 packages.

leecow commented 2 years ago

@schemburkar - I understand the distinction you're pointing out. We want to use the NuGet feature so that the marking is leveraged by appropriate tools (VS, etc) as seamlessly as possible. I didn't see outdated in the NuGet catalog-resource docs though certainly may have missed it?

schemburkar commented 2 years ago

I didn't see outdated in the NuGet catalog-resource docs though certainly may have missed it?

I thought it was but I could be wrong

Additional point is that would there be a ingestion period from the day newer version arrives and the older version is marked? Coz I'm thinking of extensions and library authors talking some time till they consume the latest version and update pinned dependencies

SeanKilleen commented 2 years ago

@schemburkar

Can the packages be marked outdated rather than deprecated?

Doesn't this happen by virtue of a new package being created? Nuget automatically finds that there's a new package available. What purpose would such a label serve in that case? (just curious.) At that point it seems like it's a solved problem?

schemburkar commented 2 years ago

@SeanKilleen agreed. I was looking at it from the angle of project maintenance perspective where you would now see a ton of packages that are marked deprecated and some of them due to vulnerablities vs some just being stale.

@leecow I was looking into the nuget announcement of the deprecated feature and it turns out the package can post a message why it's deprecated. So if all the packages that will be deprecated have a clear message it would help

JonDouglas commented 2 years ago

Hi friends,

We have three words we use over at NuGet. TL;DR:

Similar to Immo's idea, we would like to work on https://github.com/NuGet/Home/issues/4103#issuecomment-802321117 but it will need time for a thoughtful design to account for cases like this.

Go 👍 and comment! https://github.com/NuGet/Home/issues/4103 though if you're interested in that experience.

Additionally for the all-up experience, we're trying to provide warnings/errors for each of these three words. Right now it's proposed as dotnet audit:

Go 👍 and comment! https://github.com/NuGet/Home/pull/11549

Hope this helps.

SeanKilleen commented 2 years ago

Based on @JonDouglas's comment above (thanks Jon!), it would seem that:

We will update packages when new versions are released. For example, when .NET 6.0.10 releases, package versions for 6.0.9 will be marked deprecated.

...would not be considered the correct approach. The packages will naturally be considered outdated, and so to mark them as deprecated with a message in this instance would be a sort of duplicate meaning that unintentionally overloads the concept of package deprecation.

Given that, I'd suggest holding off on that particular aspect for now, and focusing that effort elsewhere. (I still agree with deprecating unsupported/unmaintained packages as I think that's a clear indicator that a change needs to be considered on the consumer side.)

teo-tsirpanis commented 2 years ago

First of all that's great news, thanks for taking action on this. I have some feedback:

huoyaoyuan commented 2 years ago

I think we should do this step by step.

Tragetaschen commented 2 years ago

I would like to discuss the deprecation of the the Microsoft.AspNetCore.Components.DataAnnotations.Validation package. It's really an odd one out as it was never actually released during the 3.2 time frame and remains as an rc1 version on NuGet.

It's my understanding that there was an attempt to solve the problem within the framework (https://github.com/dotnet/runtime/issues/31400), but it was decided to continue providing this within the Blazor context. This effort does not seem to result in a package in the .NET 7 timeframe (https://github.com/dotnet/aspnetcore/issues/28640)

For the time being, the documentation calls out to continue using the prerelease package normally, so I propose to remove the deprecation label.

guardrex commented 2 years ago

Let me second that remark/question by @Tragetaschen. It is still in the Blazor docs, and I was just asked on the docs repo about the depreciation move. It's marked for .NET 8 now, so don't we want to keep it viable for use as "experimental" at this time, not depreciated/legacy? cc: @mkArtakMSFT

mkArtakMSFT commented 2 years ago

I would like to discuss the deprecation of the the Microsoft.AspNetCore.Components.DataAnnotations.Validation package. It's really an odd one out as it was never actually released during the 3.2 time frame and remains as an rc1 version on NuGet.

Thanks for bringing this up, @Tragetaschen. That one wasn't intended to be deprecated. I've fixed it on NuGet already. Hopefully, we'll get to review the issue that you've pointed out in .NET 8 timeframe and decide how we will move forward with this package.

Thanks for bringing this to my attention, @guardrex!

HolidayLighting commented 2 years ago

So if a package is depricated like Microsoft.AspNetCore.SignalR.Core how do we know what its replacement is?

mkArtakMSFT commented 2 years ago

So if a package is depricated like Microsoft.AspNetCore.SignalR.Core how do we know what its replacement is?

Some packages don't have a replacement. Some have been moved to be part of the framework, so there is no separate package being published to NuGet. The best way to find out how to move forward for a specific package is to look up the documentation for corresponding APIs in our docs. For SignalR specifically, take a look at https://docs.microsoft.com/en-us/aspnet/core/signalr/introduction and switch the framework version to match the version that your project is targeting:

image

The documentation will guide you how to get access to the appropriate APIs, including referencing the packages that may be required.

KalleOlaviNiemitalo commented 1 year ago

For ASP.NET Core 2.1 on .NET Framework, are Microsoft.AspNetCore.SignalR 1.0.4 and Microsoft.AspNetCore.SignalR.Core 1.0.15 the supported versions? Versions 1.0.* have not been marked as deprecated at nuget.org, although version 1.1.0 has.

BrennanConroy commented 1 year ago

are Microsoft.AspNetCore.SignalR 1.0.4 and Microsoft.AspNetCore.SignalR.Core 1.0.15 the supported versions?

Yes, they were released as part of ASP.NET Core 2.1 and have the same EOL

CoolDadTx commented 1 year ago

I'm confused about System.ComponentModel.Annotations being deprecated. That is where the core data annotations like Required are at. The latest released package is marked deprecated but the pre-release 6.0 version is not released yet. Some companies, like ours, do not allow the use of pre-release packages. Furthermore the official docs for things like Required point to that assembly. If I remove that dependency from my project then it won't compile anymore. This seems like a catch-22. If your company policies requires that you keep all packages up to date for security reasons AND you are not allowed to rely on pre-release packages because of stability then there is no way to correctly compile your code anymore.

Bear in mind here that we are using TFMs here (.NET 4.7.2 and .NET 6.0). NF comes with these attributes built into the framework so we could add a conditional reference to that assembly. .NET 6 should be using the package (that is now deprecated). But historically in this situation you just reference the package for both frameworks and let the compiler deal with it. This would no longer work.

I would strongly recommend a policy around deprecating packages to avoid this situation. If a package is being deprecated in lieu of a newer package then the deprecation should not occur until the newer package is released (not pre-release). If a package is obsolete then provide clear documentation on what the replacement is. I've looked for the "replacement" for the annotations package and other than the pre-release version I see none.

huoyaoyuan commented 1 year ago

Bear in mind here that we are using TFMs here (.NET 4.7.2 and .NET 6.0). NF comes with these attributes built into the framework so we could add a conditional reference to that assembly. .NET 6 should be using the package (that is now deprecated).

@CoolDadTx The package System.ComponentModel.Annotations is also built-in in .NET Core. That's the exact reason for all the packages that disappears after .NET 6 preview X. If you are not targeting .NET Standard, the package shouldn't be required.

CoolDadTx commented 1 year ago

@huoyaoyuan Yes, it is built into NF and NC but for TFMs the solution is now broken. Previously if you were targeting .NET 4.7.2 AND .NET 6 then you would add the (deprecated) package. Then it compiles for both frameworks. Now however you have to manually edit your project file and add a conditional reference to the assembly for .NET 4.7.2 projects because for NF it isn't automatically included. This is a step back from what used to work well.

BrennanConroy commented 1 year ago

You can add a framework reference in libraries targeting 3.1+ (note: 6.0+ are the only supported versions today) https://learn.microsoft.com/aspnet/core/fundamentals/target-aspnetcore?view=aspnetcore-7.0&tabs=visual-studio#use-the-aspnet-core-shared-framework

joesdu commented 1 year ago

You can add a framework reference in libraries targeting 3.1+ (note: 6.0+ are the only supported versions today) https://learn.microsoft.com/aspnet/core/fundamentals/target-aspnetcore?view=aspnetcore-7.0&tabs=visual-studio#use-the-aspnet-core-shared-framework

This article is very helpful, thanks.

tfujii commented 1 year ago

To make sure I understand the intended direction, for things like the IHttpContextAccessor interface definition (https://learn.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.http.ihttpcontextaccessor?view=aspnetcore-7.0), is the idea here that I should look at the "Package:" line from the documentation page and switch from the now deprecated "Microsoft.AspNetCore.Http.Abstractions" package to the "Microsoft.AspNetCore.App.Ref" package and ignore the warning about it not being intended for use as a normal PackageReference?

cremor commented 1 year ago

You should use a <FrameworkReference> instead of a <PackageReference>. See the link in the comments just above yours.

chekm8 commented 1 year ago

What is the expected migration path when using something like Microsoft.AspNetCore.Server.IIS which now has all versions marked deprecated?

BrennanConroy commented 1 year ago

Many ASP.NET Core packages are no longer published as NuGet packages because we have moved them into the Microsoft.AspNetCore.App shared framework. The shared framework is a group of assemblies that are included by default when writing an ASP.NET Core app, and are installed via the .NET Core SDK and Runtime installers. If you are writing a library that was using the deprecated packages and want to continue using those APIs, you will need to add a framework reference to your libraries' .csproj: <FrameworkReference Include="Microsoft.AspNetCore.App" />. Applications and libraries should remove the deprecated packages in favor of using the implicit (Microsoft.NET.Sdk.Web projects) or explicit framework references. More information about this can be found at https://learn.microsoft.com/aspnet/core/fundamentals/target-aspnetcore

chekm8 commented 1 year ago

@BrennanConroy , Thanks but that article doesn't help a ton. First it seems a bit dated, talking about Core 2.x and 3.0 neither of which we are using.
We have a library, not an application, that multitargets net4.8 and netstandard2.0. We are referencing Microsoft.AspNetCore.Server.IIS which houses a netstandard2.0 dll which currently has all versions marked as deprecated.

Are you saying that we need to add "FrameworkReference Include="Microsoft.AspNetCore.App" " to a Standard library? I thought the whole point of standard was to be the bridge between framework 4.x and Core applications.

tfujii commented 1 year ago

You should use a <FrameworkReference> instead of a <PackageReference>. See the link in the comments just above yours.

Ah, thank you! Perhaps it would help to have this tip included in the deprecation notice?

BrennanConroy commented 1 year ago

We are referencing Microsoft.AspNetCore.Server.IIS

That package was only ever supported for netcoreapp2.2 which has been out of support for years. The migration guidance if you still want to run on netfx 4.8 would be to use the Microsoft.AspNetCore.Server.IISIntegration package which is still supported.

jaredtait commented 1 year ago

We are referencing Microsoft.AspNetCore.Server.IIS

That package was only ever supported for netcoreapp2.2 which has been out of support for years. The migration guidance if you still want to run on netfx 4.8 would be to use the Microsoft.AspNetCore.Server.IISIntegration package which is still supported.

Thanks for this dialog. What is the support for Microsoft.AspNetCore.Server.IISIntegration tied to? .NET FW? .NET6?

cremor commented 1 year ago

See https://dotnet.microsoft.com/en-us/platform/support/policy/aspnet/2.1-packages

hugoqribeiro commented 1 year ago

Bear in mind here that we are using TFMs here (.NET 4.7.2 and .NET 6.0). NF comes with these attributes built into the framework so we could add a conditional reference to that assembly. .NET 6 should be using the package (that is now deprecated).

@CoolDadTx The package System.ComponentModel.Annotations is also built-in in .NET Core. That's the exact reason for all the packages that disappears after .NET 6 preview X. If you are not targeting .NET Standard, the package shouldn't be required.

We are targeting .NET Standard. What would be the right way to deal with this for that target?

KalleOlaviNiemitalo commented 1 year ago

Comparing https://web.archive.org/web/20221201093821/https://dotnet.microsoft.com/en-us/platform/support/policy/aspnetcore-2.1 to https://dotnet.microsoft.com/en-us/platform/support/policy/aspnet/2.1-packages and https://dotnet.microsoft.com/en-us/platform/support/policy/aspnet/external-packages, I see the following have been removed from the list of supported packages:

Of these, the MVC packages are listed in the .NET Package Deprecation list, but Microsoft.AspNetCore.DataProtection.Redis is not.

Although I did not use Microsoft.AspNetCore.DataProtection.Redis, this makes me feel uneasy about the other aspnetcore-2.1 packages. Can I somehow subscribe to updates of the lists, in order to know when the "minimum of 12 months notification prior to the end of support" starts ticking? Will packages be marked as deprecated in NuGet Gallery when the notification period starts, or only when support ends?

By the way, these versions in https://dotnet.microsoft.com/en-us/platform/support/policy/aspnet/2.1-packages look wrong:

Package name Version
Microsoft.Diagnostics.Tracing.EventSource. edist
Microsoft.DotNet.PlatformAbstra tions
jaredtait commented 1 year ago

We are referencing Microsoft.AspNetCore.Server.IIS

That package was only ever supported for netcoreapp2.2 which has been out of support for years. The migration guidance if you still want to run on netfx 4.8 would be to use the Microsoft.AspNetCore.Server.IISIntegration package which is still supported.

Where did the GetIISServerVariable(string) (or GetServerVariable(string) extension method land? It does not seem to be in Microsoft.AspNetCore.Server.IISIntegration

See https://dotnet.microsoft.com/en-us/platform/support/policy/aspnet/2.1-packages

This only states that the latest is supported with no timeframes for future support. Makes me think it could go at any time.

Thanks @BrennanConroy and @cremor for helping!

cremor commented 1 year ago

This only states that the latest is supported with no timeframes for future support. Makes me think it could go at any time.

One level above that page you will find this one: https://dotnet.microsoft.com/en-us/platform/support/policy/aspnet That states the following:

To help facilitate migrating applications to ASP.NET Core on .NET Core, the specified ASP.NET Core 2.1 packages (latest patched version only) will be supported on the .NET Framework and follow the support cycle for those .NET Framework versions. ASP.NET Core 2.1 is defined as "Tools" in the Microsoft Support Lifecycle Policy. A "Tool" requires a minimum of 12 months notification prior to the end of support. For more information, see this KB Article.

soenneker commented 1 year ago

This approach is causing confusion, and you're going to have many here shortly who will be asking for guidance.

You need to have replacements ready to go if you're going to deprecate. Otherwise why deprecate? The 'last updated date' is enough of an indicator that something isn't being updated. I don't like using libraries that are deprecated, but there are no other alternatives.

What we need is the ability to see where types are going after deprecation. I need to be able to pick up the new package from NuGet's package recommendation and use it right out of the box with minimal changes. Instead I'm searching MS docs, I'm seeing packages that are marked 'internal only', and after 10 minutes it's clear they don't have a replacement.

The definition of 'deprecation': "to withdraw official support for or discourage the use of (something, such as a software product) in favor of a newer or better alternative."

I understand libraries need to be deprecated, and there's a need to rewrite and organize. I don't understand why you would deprecate a huge chunk of your libraries without having their replacements (and documentation) ready... I think this is a blunder by the .NET team, and again I think many here will be asking soon 'so where do I go to get X type'.

China-Mr-zhong commented 1 year ago

This approach is causing confusion, and you're going to have many here shortly who will be asking for guidance.

You need to have replacements ready to go if you're going to deprecate. Otherwise why deprecate? The 'last updated date' is enough of an indicator that something isn't being updated. I don't like using libraries that are deprecated, but there are no other alternatives.

What we need is the ability to see where types are going after deprecation. I need to be able to pick up the new package from NuGet's package recommendation and use it right out of the box with minimal changes. Instead I'm searching MS docs, I'm seeing packages that are marked 'internal only', and after 10 minutes it's clear they don't have a replacement.

The definition of 'deprecation': "to withdraw official support for or discourage the use of (something, such as a software product) in favor of a newer or better alternative."

I understand libraries need to be deprecated, and there's a need to rewrite and organize. I don't understand why you would deprecate a huge chunk of your libraries without having their replacements (and documentation) ready... I think this is a blunder by the .NET team, and again I think many here will be asking soon 'so where do I go to get X type'.

I'm also confused right now, being marked as deprecated but can't find a replacement package

China-Mr-zhong commented 1 year ago

您可以在面向3.1+的库中添加框架参考(注意:6.0+是目前唯一受支持的版本) https://learn . Microsoft . com/aspnet/core/fundamentals/target-aspnetcore？view = aspnet core-7.0 & tabs = visual-studio # use-the-aspnet-core-shared-framework

This method works, but fortunately my current projects are all NET6

ChristopherVR commented 1 year ago

This seems extremely confusing now.

What should Microsoft.AspNetCore.Http.Features be replaced with? I can't seem to find the replacement. If there is no replacement, how does it make sense to deprecate the package until there is a replacement available?

cremor commented 1 year ago

@ChristopherVR See Use the ASP.NET Core shared framework

This is also visible on the documentation page of the types. E.g. on the ISessionFeature Interface page you can see the note "Package: Microsoft.AspNetCore.App.Ref".

@leecow Maybe include the link Use the ASP.NET Core shared framework in the initial post of this issue (and in the anncouncement itself)?

codelovercc commented 1 year ago

I want to use model binding attributes in namespace Microsoft.AspNet.Mvc.ModelBinding in my class library project(etc: BindNeverAttribute BindRequiredAttribute ..) , but I don't want to reference the entire Microsoft.AspNetCore.App libraries in my class library project. What can I do?

louiecampagna-okta commented 1 year ago

What would be the replacement for Microsoft.AspNetCore.Authentication.Cookies ?

cremor commented 1 year ago

@louiecampagna See my comment which is just 2 comments above yours.

damiensawyer commented 1 year ago

but I don't want to reference the entire Microsoft.AspNetCore.App libraries in my class library project. What can I do?

Well @codelovercc, it appears that Microsoft.AspNetCore.App is also now deprecated (which is what brought me here)... so there's no joy there either.

I agree with @soenneker that this decision is fraught with issues. Why deprecate something without a replacement lined up and easily locatable (ideally as part of the message signalling the depracation)? Are we to take the opinon that those deprecated and not replaced features are 'gone' and we should avoid them? From an optics point of view, this is sending a very negative message. One might be led to believe that dotnet is 'ramping down' rather than growing.

cremor commented 1 year ago

@damiensawyer The Microsoft.AspNetCore.App NuGet Package is deprecated because that package was never released for any version after ASP.NET Core 2.2. Since ASP.NET Core 3.0 the Microsoft.AspNetCore.App shared framework is used instead and that is not deprecated. Just use <FrameworkReference> instead of <PackageReference>. See Use the ASP.NET Core shared framework.

@leecow I repeat my request to include that information in the first post of this issue.

damiensawyer commented 1 year ago

Thanks @cremor - that's really useful! I'd never before gone down the rabit whole of Framework References. It all makes sense now. Thanks.