Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The Nuget upgrade utility for packages.config has a hardcoded list of 3 project types #12126

Open
vsfeedback opened this issue Oct 4, 2022 · 2 comments
Labels
Functionality:PCtoPRMigrator PC to PR migrator in VS Priority:2 Issues for the current backlog. Product:VS.Client Style:Packages.Config Transferred issue This issue is transferred from VSFeedback or other github repo Type:Feature

Comments

@vsfeedback
Copy link

This issue has been moved from a ticket on Developer Community.


[severity:It bothers me. A fix would be nice]
The Nuget upgrade utility for packages.config has a hardcoded list of 3 project types that are allowed to update.

See https://github.com/NuGet/NuGet.Client/blob/631411c00f0fd494d05c77f8751b67570737d791/src/NuGet.Clients/NuGet.PackageManagement.VisualStudio/Utility/NuGetProjectUpgradeUtility.cs#L108

The UpgradeableProjectTypes are declared as (see https://github.com/NuGet/NuGet.Client/blob/631411c00f0fd494d05c77f8751b67570737d791/src/NuGet.Clients/NuGet.PackageManagement.VisualStudio/Utility/NuGetProjectUpgradeUtility.cs#L22)

new HashSet(StringComparer.OrdinalIgnoreCase)
            {
                VsProjectTypes.CsharpProjectTypeGuid,
                VsProjectTypes.VbProjectTypeGuid,
                VsProjectTypes.FsharpProjectTypeGuid
            };

This means that other project types, even when they support all the necessary interfaces will not be allowed to upgrade.
For now we have worked around this by checking (in the project.Kind property) if we are being called from NuGet (by checking for the string "NuGet" in the StackTrace) and then return the CsharpProjectTypeGuid, but that is a real kludge.
This is simply a bad design. The utility should not check the project Kind in a fixed list but should check if the project implements VSProject4. If that is the case then it should allow the upgrade to happen.
I can imagine that there is a list of project types that you do NOT want to support, but to limit the support to only these 3 types is really not OK.


Original Comments

Feedback Bot on 8/18/2022, 00:27 PM:

(private comment, text removed)

Heng Liu [MSFT] on 9/16/2022, 06:06 PM:

(private comment, text removed)

Robert van der Hulst (XSharp) on 9/16/2022, 11:18 PM:

(private comment, text removed)

Robert van der Hulst (XSharp) on 9/21/2022, 09:20 AM:

(private comment, text removed)

Heng Liu [MSFT] on 9/19/2022, 11:45 AM:

(private comment, text removed)

Robert van der Hulst (XSharp) on 9/19/2022, 02:20 PM:

(private comment, text removed)

Robert van der Hulst (XSharp) on 9/20/2022, 07:04 AM:

(private comment, text removed)


Original Solutions

(no solutions)

@RobertvanderHulst
Copy link

I raised this ticket. It would be really nice if you could fix this, so we can remove our kludge.
If you want I can give you the setup for our language and project system so you can test it

@nkolev92 nkolev92 added Priority:2 Issues for the current backlog. and removed Area:RestoreTool V1/V2 tool restore Triage:NeedsTriageDiscussion labels Oct 6, 2022
@RobertvanderHulst
Copy link

Is there any news about this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Functionality:PCtoPRMigrator PC to PR migrator in VS Priority:2 Issues for the current backlog. Product:VS.Client Style:Packages.Config Transferred issue This issue is transferred from VSFeedback or other github repo Type:Feature
Projects
None yet
Development

No branches or pull requests

4 participants