search

sboulema / NuGetMonitor

A Visual Studio extension that checks and notifies about available updates for the installed NuGet packages for the open solution.
MIT License
16 stars 1 forks source link

[Feature Request] Check compatibility of upgrade with the project's current TargetFramework #50

Open jrdodds opened 2 days ago

jrdodds commented 2 days ago

Background

I have a project targeting net8.0 that uses the Microsoft.Build package. Version 17.11.4 of the package supports net8.0. The next released version, 17.12.6, supports net9.0 and doesn't support net8.0.

NuGet Monitor showed the package update from 17.11.4 to 17.12.6. After updating the build produced a NuGet NU1701 warning:

Package 'Microsoft.Build 17.12.6' was restored using '.NETFramework,Version=v4.6.1, .NETFramework,Version=v4.6.2, .NETFramework,Version=v4.7, .NETFramework,Version=v4.7.1, .NETFramework,Version=v4.7.2, .NETFramework,Version=v4.8, .NETFramework,Version=v4.8.1' instead of the project target framework 'net8.0'. This package may not be fully compatible with your project.

For this specific issue I changed the PackageReference to use Version="17.11.*". The NU1701 warning is resolved and NuGet Monitor doesn't show the upgrade.

Feature Request

NuGet Monitor is a great tool already but it would be nice if NuGet Monitor checked the compatibility of a package upgrade against the current TargetFramework and indicated that the upgrade is not just a change to the package version -- that the upgrade requires either changing the TargetFramework or changing the package version specification.

I don't have a suggestion on how this information might be reported by NuGet Monitor.

tom-englert commented 2 days ago

Also updating would become slow

jrdodds commented 1 day ago

Also updating would become slow

Instead of checking as part of the check for updated versions, adding a verification step as part of performing the upgrade makes sense. The compatibility check would only be done when the user actually needs it.

If your point is that the compatibility check shouldn't be implemented at all because of the extra work and time, for my recent case a compatibility check would have saved me time. Is my example an unusual case? I don't know. If it is common enough then, overall, the compatibility check would save a developer's time.

tom-englert commented 1 day ago

I never had such an issue, so I would consider it a rare edge case. However if you think it's worth spending time on this, you can provide a PR.

135620 commented 14 hours ago

I came here specifically looking to see if this issue was being addressed. I don't think it's a rare edge case at all. I think it is very common to not move to the latest .Net Framework immediately upon release.