Make the PackageReference support general purpose for all languages
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:
- [x] General purpose the PackageRestoreInitiator and make it work for all project types. Done - works via PackageReferences capability (16.1)
- [x] General purpose the ProjectAssetsFileWatcher and make it work for all project types. Done - works via PackageReferences capability (16.1)
- [x] Embed restore rules into .NET Project System
- [x] NuGet features should light up for projects that have the capability; "PackageReferences" (~https://github.com/NuGet/Home/issues/9957~, https://github.com/NuGet/NuGet.Client/pull/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.
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 :(
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.
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.
Ditto, would love to see this happen 👍
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.
Since it's a blocker for sfproj supporting SDK-style, shouldn't this be triaged a bit higher than 'Unknown/Backlog'?
Any update on this one?
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 https://github.com/microsoft/service-fabric/issues/885 will be helpful.
Filed https://github.com/dotnet/project-system/issues/6594 to track the the dependency tree, and making this bug just about PackageReference support (restore, lighting up NuGet features, etc).
@davkean Great to see this. We've been blocked on it for quite some time on one of our project systems. I'd like to setup a test VM to check this out. Traversing the fan-out of issues from this one, I can see there's a lot of cross talk with NuGet.Client. Do I just need to build master branches of this repo and NuGet.Client, or other repos as well? And, what version of VS do I need to use?
Really eager to jump on this and validate things. Any advice/guidance is very much appreciated.
Kirk, understand your excitement. :)
However, this is still all very experimental and all the pieces don't land until Preview 4. We needed changes in CPS to make this work.
@davkean Thanks much for the quick reply. Really appreciate you taking this issue up. We managed to get the nomination to "work" in that our PRs would restore upon opening in VS, but without proper support in the Package Manager, it's just not shippable.
We'll hang tight until Preview 4. Any timing hints on that release that are able to be shared?
Thanks again.
I can't give a date, but look back at the times between previews of large releases (this release and 16.5 for example) and this should give you an indication of how this plays out.
With my capabilities change in Preview 3 (and that PR that got merged in on NuGet), the package manager will light up if you define PackageReferences, but I suspect we might not iteract well with you're own nomination.
I can't give a date, but look back at the times between previews of large releases (this release and 16.5 for example) and this should give you an indication of how this plays out.
With my capabilities change in Preview 3 (and that PR that got merged in on NuGet), the package manager will light up if you define PackageReferences, but I suspect we might not iteract well with you're own nomination.
Understood. Thanks again.
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
@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.
@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.
Hey @edwardskrod when can we expect this to work for C++ projects?
@asklar As it turns out, PackageReference support in C++ projects works today. You will need to do the following:
- Add
<ProjectCapability Include="PackageReferences" />to an item group in your vcxproj file or a targets file included by it. - 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.) - Add a Directory.Build.targets file in the same location, and add an Import element to it with this value:
$(MSBuildProjectExtensionsPath)$(MSBuildProjectFile).*.targets. - 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!
we should try this out! thanks for the tip @wjk !
@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.
@JunielKatarn My apologies, I forgot a step. Add this to the .targets file, above the MSBuildExtensionsPath import.
<PropertyGroup>
<ResolveNuGetPackages>false</ResolveNuGetPackages>
</PropertyGroup>
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 ?
@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!
@wjk That worked. Thanks a bunch.
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>
@beevvy We use that configuration too in react-native-windows.
I believe it's required for mixed C++ and C# interoperability.
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.
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)
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.