MSBuild props/targets from NuGet package are not imported into a nanoFramework project

[frobijn]

Tool

Visual Studio extension

Description

If a NuGet package contains files build\<package_id>.props and/or build\<package_id>.targets, the Visual Studio 2022 package manager is supposed to update the project file. If the type of project supports PackageReference, a package reference is added. If the project file is a .NET Framework-type MSBuild file (like the nanoFramework projects), an Import element is added to import the .props and/or .targets file that points to the files in the location of the (unpacked) NuGet package.

... but not for a nanoFramework project! All other files in a NuGet package are handled as expected, even other special file types (e.g., a NuGet package with only content files). It gets even weirder. The code of the NuGet client used by Visual Studio package managers can be found on github, and nothing in the code suggests that the imports are not supported for nanoFramework project files. That suggests that when Visual Studio saves the project file's XML as created by the package manager code (that seems to contain the imports), the imports are not properly saved but other changes are. I've asked Microsoft whether that is true and what the cause is, but that is still under investigation and may be a hard problem.

One possible cause is that one of the project (type) capabilities is required for the imports to work, and that capability is missing. I couldn't find one in the documentation, and without access to the Visual Studio source code it is hard to tell.

Even if this is fixed, it is not clear whether the fix will be applied to both Visual Studio 2019 and 2022.

There is a workaround: an install.ps1 can be added that add the imports to the nanoFramework project. The reverse (uninstall removes the imports) does not seem to work properly. I'm curious whether the core team would accept this workaround in future contributions.

How to reproduce

Required files are in this file: NuGetBuildpackage.zip

The zip file contains three packages:

• A BuildPackage.1.0.0.nupkg that contains a .props and .targets file.
• A BuildPackage_workaround.1.0.0.nupkg that contains a .props and .targets file and workaround (install.ps1 and uninstall.ps1).
• A ContentPackage.1.0.0.nupkg that contains only content files.

The zip file contains two projects:

• RegularProject.Template is a .NET Framework class library project with solution
• TestProject.Template is a nanoFramework class library project with solution

The templates are configured that the three packages can easily been installed via the NuGet package manager in Visual Studio, without affecting any other NuGet package storage locations.

The issue can be demonstrated:

• Copy/rename the TestProject.Template directory, open the solution in that directory and install the BuildPackage.1.0.0.nupkg
• The nanoFramework project does not have imports for the .props and .targets file.

Expected behaviour

The expected situation can be viewed:

• Copy/rename the RegularProject.Template directory, open the solution in that directory and install the BuildPackage.1.0.0.nupkg
• The .NET Framework project does have imports for the .props and .targets file.

Other project types behave as expected, e.g.,:

• Copy/rename the TestProject.Template directory, open the solution in that directory and install the ContentPackage.1.0.0.nupkg
• Some content files are added to the nanoFramework project conform the NuGet specs.

As a demonstration of the workaround:

• Copy/rename the TestProject.Template directory, open the solution in that directory and install the BuildPackage_workaround.1.0.0.nupkg
• The nanoFramework project now does have imports for the .props and .targets file.
• Uninstall the package
• The imports are not removed, not even by uninstall.ps1, but there is a correct project file available in the directory. That file is removed if ( newer version of) the package is installed.

Screenshots

No response

Aditional context

All latest versions: Visual Studio 2022, nanoFramework extension.

Reported here NuGet/Home#1850.

[josesimoes]

I haven't tried it myself but I'm suspecting this is because our project extension (nfproj) differs from the standard one (csproj) and the Visual Studio tools can't handle it when processing the ad slash removal off the props and targets.

Our project system doesn't support PackageReference, correct.

As you've mentioned, the work around is to use the infamous import PowerShell script. I personally don't like that approach very much because that's a security risk (that's one of the reasons for this being removed/replaced in the current .NET project system).

I suggest that we wait for the reply on the question you've raised in Developer community portal before making a decision. Because, if this is a bug in the tools, we have nothing fix at our end (as I suspect it's the case).

[frobijn]

Yes, let's hope that I get a reaction from Microsoft. I hope they can tell what aspect of the nanoFramework project Visual Studio is using to prevent the addition/removal of imports. The NuGet code seems to work fine - I repurposed one of their unit tests and debugged it, and that code adds the imports conform spec. So I suspect that Visual Studio post-processes the XML produced by the NuGet code and then ignores the added imports.

The reason I investigated a workaround is that this type of package is really very useful to add tools to a project, e.g., a test adapter, MSBuild task for version checking, debugging unit tests and more. There may be PRs in the near future that refer to this issue and propose to use the workaround while waiting two years (2022 to 2024 for icons, isn't it? ;-)) for Microsoft to implement a fix.

[josesimoes]

It really depends on the traction it gets from the developer base.
And also if it's something that's open source or not.
If that's something in our project system, we probably can fix it. If it's with nuget also fixable (I've done the implementation of the update for nfproj myself and worked with them to get a TFM for nanoFramework). Now if it's with VS, we'll probably be seeing a long turn around, like the icons. If any at all, in case this is with the old project system which isn't getting any improvements now...
Let's patiently wait for developments.