Correct way to handle obsolete OOB dependencies on multi-targeted packages?

[Sergio0694]

Description

Note: related to #77109.

In the MVVM Toolkit (part of the .NET Community Toolkit) we have a few APIs (mostly just ObservableValidator) that require some APIs from System.ComponentModel.Annotations. Since the package is not inbox, the dependency is only added on downlevel targets (see here), which I understand is the correct approach to take in cases like this (as also mentioned in https://github.com/dotnet/runtime/issues/77109#issuecomment-1280812484).

The issue is that with the package being obsolete, consumers using the MVVM Toolkit are seeing and reporting having an obsolete dependency in their projects, in all cases where one of those downlevel targets is being resolved (such as for .NET Framework users). This is far from ideal - you wouldn't want consumers to reference a library and end up with a NuGet warning about an obsolete dependency being pulled in, even more so if they're not even using those APIs specifically.

I'm aware there's no plans to update the OOB package now that it's inbox, but what is the recommendation for scenarios such as this? Is there a better way for library authors to make the experience better for downlevel consumers?

As an example, see this feedback from a user on the C# Discord server:

---

Partially related question: what's the logic that determines when these warnings show up? Because eg. I'm not seeing this warning when building the MVVM Toolkit (and in fact the CI is also passing with no errors/warnings), and I'm also not seeing any warnings when building other downlevel projects (specifically UWP ones) that also use the MVVM Toolkit 🤔

[ghost]

Tagging subscribers to this area: @dotnet/area-infrastructure-libraries See info in area-owners.md if you want to be subscribed.

Issue Details

---

### Description > **Note**: related to #77109. In the [MVVM Toolkit](https://learn.microsoft.com/en-us/dotnet/communitytoolkit/mvvm/) (part of the [.NET Community Toolkit](https://github.com/CommunityToolkit/dotnet)) we have a few APIs (mostly just [`ObservableValidator`](https://learn.microsoft.com/en-us/dotnet/communitytoolkit/mvvm/observablevalidator)) that require some APIs from `System.ComponentModel.Annotations`. Since the package is not inbox, the dependency is only added on downlevel targets ([see here](https://github.com/CommunityToolkit/dotnet/blob/017a4710b5aeacf98acf8d0fbfa771954f525014/src/CommunityToolkit.Mvvm/CommunityToolkit.Mvvm.csproj#L26)), which I understand is the correct approach to take in cases like this (as also mentioned in https://github.com/dotnet/runtime/issues/77109#issuecomment-1280812484). The issue is that with the package being obsolete, consumers using the MVVM Toolkit are seeing and reporting having an obsolete dependency in their projects, in all cases where one of those downlevel targets is being resolved (such as for .NET Framework users). This is far from ideal - you wouldn't want consumers to reference a library and end up with a NuGet warning about an obsolete dependency being pulled in, even more so if they're not even using those APIs specifically. I'm aware there's no plans to update the OOB package now that it's inbox, but what is the recommendation for scenarios such as this? Is there a better way for library authors to make the experience better for downlevel consumers? As an example, see this feedback from a user on the C# Discord server:  --- Partially related question: what's the logic that determines when these warnings show up? Because eg. I'm not seeing this warning when building the MVVM Toolkit (and in fact the CI is also passing with no errors/warnings), and I'm also not seeing any warnings when building other downlevel projects (specifically UWP ones) that also use the MVVM Toolkit 🤔 ### Reproduction Steps n/a ### Expected behavior n/a ### Actual behavior n/a ### Regression? _No response_ ### Known Workarounds _No response_ ### Configuration _No response_ ### Other information _No response_

Author:	Sergio0694
Assignees:	-
Labels:	`area-Infrastructure-libraries`, `untriaged`
Milestone:	-

[ViktorHofer]

Hello @Sergio0694. System.ComponentModel.Annotations/5.0.0 is marked as deprecated but still required on .NET Standard TFMs. We missed excluding that package from the deprecation effort. I just started an offline thread to un-deprecate that package with the 5.0.0 version.

I will update this thread when that work is done. Thanks for reaching out.

[Sergio0694]

Oh that is awesome, thank you for the help!! 😄

[ViktorHofer]

Completed :)