Make the PackageReference support general purpose for all languages

[davkean]

We added support for <PackageReference /> this release, but other languages/project types are interested in consuming it including C++, MSIX deployment and NuGetizer.

The work required, that I can see is:

• General purpose the PackageRestoreInitiator and make it work for all project types. Done - works via PackageReferences capability (16.1)
• General purpose the ProjectAssetsFileWatcher and make it work for all project types. Done - works via PackageReferences capability (16.1)
• Embed restore rules into .NET Project System
• NuGet features should light up for projects that have the capability; "PackageReferences" (NuGet features should light up for projects that have the capability; "PackageReferences" NuGet/Home#9957, Enable custom CPS projects to be restored NuGet/NuGet.Client#3644)
• <ProjectAssetsFile> needs to be moved lower than the SDK
• Figure out how all these project types pick up the NuGet SDK tasks/targets that produce assets (references, copy to output items, etc) for consumption during build and assets that are used to populate the DependenciesTree.
• Move PackageRestore code to CPS -or- install .NET Project System in all the same places as CPS
  • Without this, Package Restore code would not light up if we weren't installed.

[kzu]

Is there an update on when the "Microsoft.PackageDependency.Sdk` will ship @natidea?

I'm on 15.6 Preview 3 but it's not there yet :(

[natidea]

Is there an update on when the "Microsoft.PackageDependency.Sdk` will ship

@kzu our most recent discussions on this have focused on refactoring these tasks because of performance concerns. The SDK team has already made changes to the command line build to avoid this code path because it was too expensive. For the dependencies tree, we are considering several options including perhaps bypassing MSBuild to improve the performance profile. /cc @nguerrera @livarcocc

I don't have any other updates yet, but will post something as our plans unfold.

[kfertitta]

Is there an update on this issue? We have a custom project system for which we really need to support PackageReference. We'd be happy to require the latest shipping VS version as the minimal version, but it's not clear if support is yet available.

Thanks in advance.

[kzu]

Ditto, would love to see this happen 👍

[DevKumar4Git]

We are providing guidance to package build tools as NuGet & use package reference to pull it down while using build/restore.
https://docs.microsoft.com/en-us/nuget/create-packages/creating-a-package#including-msbuild-props-and-targets-in-a-package

If CPS doesn't support this for custom project types, then its an adoption blocker & lot of overhead for developers who intend to quickly use this to build project systems. Would love to get this prioritized or hear about a workaround that can be easily removed once the support comes back.

[amis92]

Since it's a blocker for sfproj supporting SDK-style, shouldn't this be triaged a bit higher than 'Unknown/Backlog'?

[aL3891]

Any update on this one?

[bhardwajs]

Since it's a blocker for sfproj supporting SDK-style, shouldn't this be triaged a bit higher than 'Unknown/Backlog'?

Any updates on this one? Unblocking microsoft/service-fabric#885 will be helpful.

[stevenbrix]

I've run into problems when adding nuget references into the .wapproj, nuget will add the assemblies as references, which causes the .wapproj to fail. just want to mention it in case this scenario needs to be tested

[edwardskrod]

@stevenbrix

I've run into problems when adding nuget references into the .wapproj, nuget will add the assemblies as references, which causes the .wapproj to fail. just want to mention it in case this scenario needs to be tested

Have you tried again? We added the ProjectReferences capability to wapproj a few weeks back. I don't know whether that will make it work for you.

[kfertitta]

@davkean I saw the 16.8 Preview 4 bits up today and tried them out on our VM with our actual custom CPS-based project system (that also uses a custom MSBuild SDK). It seems to be working. I can now see the obj folder populated with the restore spew upon opening the solution. I was also able to open the NuGet package manager on our custom project and use it to install/uninstall some well-known NuGet packages.

So, is there outstanding work to be done on this issue (and the others that fan out from this one)? Definitely unblocks us, it seems. Are there more scenarios I should test or that may be helpful in verifying your work on this?

Thanks in advance.

[asklar]

Hey @edwardskrod when can we expect this to work for C++ projects?

[wjk]

@asklar As it turns out, PackageReference support in C++ projects works today. You will need to do the following:

1. Add <ProjectCapability Include="PackageReferences" /> to an item group in your vcxproj file or a targets file included by it.
2. Add a Directory.Build.props file or above the project’s directory, and add an Import element to it with the following value: $(MSBuildProjectExtensionsPath)$(MSBuildProjectFile).*.props. (You can technically add this anywhere that MSBuild will see it, but I find that putting it in Directory.Build.props ensures that it is both included at the correct place, and is also easily shared between all the projects in your solution.)
3. Add a Directory.Build.targets file in the same location, and add an Import element to it with this value: $(MSBuildProjectExtensionsPath)$(MSBuildProjectFile).*.targets.
4. Unload and reload your C++ project(s).

After that, not only will NuGet packages auto-restore like with csproj, but the NuGet Package Manager UI will also add and remove PackageReference elements from the project instead of creating a packages.config file. (If this doesn’t seem to work, you may need to use the VS 16.11 beta; that’s what I’m using, and it works great for me.) Note that vcxproj will require you to run File > Save All before changes made in the NuGet UI will persist to the project file, as with any other changes to a vcxproj made using the GUI. Hope this helps!

[asklar]

we should try this out! thanks for the tip @wjk !

[JunielKatarn]

@wjk I tried this in our project but couldn't get it to work. It complains about a missing framework reference.

I prepared a minimal MSVC solution to reproduce this. Could you please take a look in case I'm missing anything?
Note, the sample project only has one VCXPROJ, so all the necessary configuration is consolidated there.

https://github.com/jurocha-ms/vcpkgref-sample

What I tried with a 100% clean clone:

msbuild /t:restore
<SUCCEEDS>
msbuild /t:rebuild

Sample error output:

       "R:\vcpkgref\VcPkgRef.sln" (rebuild target) (1) ->
       "R:\vcpkgref\VcPkgRef\VcPkgRef.vcxproj" (Rebuild target) (2) ->
       (ResolveNuGetPackageAssets target) ->
         C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Microsoft\NuGet\16.0\Microsoft.NuGet.targets(198,5): error : Your project does not reference ".NETFramework,Version=v4.0" framework. Add a reference to ".NETFramework,Version=v4.0" in the "TargetFrameworks" property of your project file and then re-run NuGet restore. [R:\vcpkgref\VcPkgRef\VcPkgRef.vcxproj]

So far, using the MSBuild properties TargetFramework or TargetFrameworks doesn't change anything.

Note, using MSBuild "${env:ProgramFiles(x86)}\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\amd64\MSBuild.exe", version 16.10.2.30804.

[wjk]

@JunielKatarn My apologies, I forgot a step. Add this to the .targets file, above the MSBuildExtensionsPath import.

<PropertyGroup>
  <ResolveNuGetPackages>false</ResolveNuGetPackages>
</PropertyGroup>

[asklar]

Is any of this documented / stable enough? I couldn't find any docs on this on my cursory search so I worry about relying on implementation details that could change. @rainersigwald ?

[wjk]

@asklar After a quick test, I have found that the ExcludeRestorePackageImports property is apparently unneeded; I have removed it, and both restore and build still work. The ResolveNuGetPackages property is required to disable this task, which is the source of @JunielKatarn’s error. While I agree there are no hits on docs for this property, I do not believe that this property is actually an implementation detail, for three reasons. First, I have been using this property across several versions of VS (including some that predate proper C++ PackageReference IDE support), and have never run into any problems. Second, the name does not start with an underscore, which is the MSBuild convention for denoting implementation details. Third, the fact that there is this easy a way to bypass that task in the first place suggests that the property is public API; disabling private targets usually entails much more work. Hope this helps!

[JunielKatarn]

@wjk That worked. Thanks a bunch.

[beevvy]

For anyone interested, I needed to use one more hack to make the PackageReference C++ NuGet restore work in VS2022, as described in this comment:

<AssetTargetFallback>$(AssetTargetFallback);native</AssetTargetFallback>
<TargetFrameworkMoniker>native,Version=v0.0</TargetFrameworkMoniker>

[JunielKatarn]

@beevvy We use that configuration too in react-native-windows.

I believe it's required for mixed C++ and C# interoperability.

[beevvy]

I should also note that setting TargetFrameworkMoniker in VS2022 appears to break ConfigurationType=Makefile projects, as the GetReferenceAssemblyPaths target fails. Normally for C++ projects it's prevented from being executed by Microsoft.CppBuild.targets unsetting TargetFrameworkMoniker within the relevant target scope.

[matlemuzic]

Hi all, is anyone having issues referencing a C++/CLI with package references from a C# project ?

My C++/CLI project compiles ok with .NETFramework 4.8, but I get the following issue from the C# project that references it:

error NU1201: Project MyCppCLIProject is not compatible with net48 (.NETFramework,Version=v4.8). Project MyCppCLIProject supports: native (native,Version=v0.0)

[Schniefel]

Can someone please post a guide how to get Packagereference work for .vcxproj (native and c++/cli) with visual studio?
I have seen various different hacks, but nothing worked for me.

[zivkan]

https://devblogs.microsoft.com/cppblog/announcing-nuget-packagereference-support-for-c-cli-msbuild-projects-targeting-net-core/

One of the new features for C++ developers in Visual Studio 2022 version 17.3 is NuGet PackageReference support for C++/CLI MSBuild projects that target .NET Core and .NET 5 or higher. More specifically, this impacts CLR Class Library (.NET) and CLR Empty Project (.NET) project templates. This functionality allows you to manage NuGet packages while bringing the benefits of PackageReference support to your dependencies. This feature is on by default for new projects. To enable this feature for your existing projects, add the following property to your project file:

<PropertyGroup Label="Globals">

<EnableManagedPackageReferenceSupport>true</EnableManagedPackageReferenceSupport> </PropertyGroup>

and later in the blog post

For native C++ projects, we recommend using vcpkg for both C++ open-source and closed source libraries.

So, PackageReference should "just work" for C++/CLI projects, if you're using a recent version of VS2022 and you're targeting .NET (Core). It's unclear what happens if you're using C++/CLI and still targeting .NET Framework.

PackageReference for native C++ isn't supported.

[Schniefel]

Yes, i know. But we have native C++ Nugets and C++/CLI Nugets using .NET Framework. So I am interested in the existing workaround, which may not be officially supported.
I hope, Microsoft will some day understand, that only supporting C++/CLI on .NET (Core) won't help in many use cases on mixed environments.