Support CMake C++ Projects (with Visual Studio Solution/Project)

[nat42]

NuGet Product(s) Involved

NuGet.exe

The Elevator Pitch

#12204 proposed changes to the Nuget CLI and was rejected. It looks like it was raised per issue https://gitlab.kitware.com/cmake/cmake/-/issues/24103 with CMake, where VS_PACKAGE_REFERENCES can not be made to work with native packages & C/C++.

Until today I didn't expect to have an easy time with CMake, Nuget and native C/C++ code, I just expect nuget to treat me right when I work within the .net ecosystem; however Microsoft tells me to use Nuget to use the Edge WebView2, even with native WIN32 C++ code https://learn.microsoft.com/en-us/microsoft-edge/webview2/get-started/win32

I don't care about the Nuget CLI change specifically requested in #12204 but if Microsoft is endorsing Nuget as the way to get the libraries and headers needed to build against WebView2, I think it's reasonable to expect it (Nuget) to work with CMake, as CMake is otherwise encouraged / supported.

Additional Context and Details

See also open tickets #6731, #8874 and maybe #10144 I believe these were all raised before the CMake team added some support via the CMake VS_PACKAGE_REFERENCES property. Per the gitlab ticket referenced the CMake team appears to need some mechanism to make this work from the Microsoft / Nuget side of things, if not the change to the Nuget CLI suggested by gh-andre than I kindly ask the Nuget team proposes and implements an alternative for CMake support.

[kartheekp-ms]

In #12204 (comment), the customer says It doesn't have to be nuget.exe - whatever the current package console is using will be just as good, even if it has to invoke devenv.exe or using something similar - there is a real need out there to be able to automate package installation similar to how one would do with dnf install and apt install.

[nat42]

In #12204 (comment), the customer says It doesn't have to be nuget.exe - whatever the current package console is using will be just as good, even if it has to invoke devenv.exe or using something similar - there is a real need out there to be able to automate package installation similar to how one would do with dnf install and apt install.

I'm a different person than that commenter with a different pitch, the comment you have cited does not reflect my views nor the concern which I have wished to raise with the Nuget team.

I have raised issue with the Nuget team and do specifically care about Nuget (and not "whatever the current package console is using") for the reason I hope is clear from my pitch. I gave a very specific use case which I came accross but which I think makes a good case for why change is required.

On MicrosoftEdge/WebView2Samples#174 I have suggested that if the Microsoft Edge WebView2 samples showed a different system other than Nuget than that would be an alternative way to address the specific issue that led to me creating this issue ticket with the Nuget team; but I see it as separate from what I have I have requested here: on that ticket with the Edge team I feel it is appropriate to suggest that solution to the need for a sample might be realised using an alternative other than Nuget at Microsoft's descretion, for aquiring the resources needed to build native solutions with WebView2; here I have raised that the Nuget team should work with CMake for C/C++ native code projects, and referenced that use case as a reason it requires futher consideration.

I believe that as Microsoft is currently using Nuget as seemingly the only way to get the required binaries and headers build against Webview2 with native code, it is not appropriate to dismiss the use case of making Nuget work with CMake for native projects, and that the Nuget team should create some mechanism (that need not be the CLI requested in 12204) to in order to facilitate this.

[nat42]

To quote the CMake ticket for 24103 " VS_PACKAGE_REFERENCES does not work for native (C/C++) Nuget packages that use packages.config", a CMake developer laments:

I've actually started working on implementing support for the packages.config format. The problem is, that providing a packages.config file is not sufficient for it to work. Instead, a manual package restore needs to be performed from within Visual Studio in order to setup the dependencies properly in the vcxproj file. The proper way to resolve package references in the legacy format would be to write the dependencies using CMake, otherwise the build cannot be feasibly done using any form of automation (since it would always require to open the project in Visual Studio, run a package restore to re-write the vcxproj file and then perform a build). Unfortunately, the NuGet client does not provide any CLI that does the re-writing of the vcxproj file, so the only way to implement this is to write the dependencies from CMake itself. However, finding the the right version to link against is not trivial. It might be easier for packages that only contain unmanaged code but all managed dependencies are a mess to resolve. This page has a comprehensive list of all target framework identifiers. It also links to both main source files in the NuGet client that are used to resolve framework dependencies within the client. At this point, I think the most straightforward way is to re-write this piece of code in C++, but then I think it is very hard to test, since there are countless version- and tfm-matches. This is where I then stopped working on this for now.

As for now, if only unmanaged NuGet packages are required, I suggest using vcpkg. It is possible to download nuget packages (as they are only zip archives) and it already provides helpers to properly setup the msbuild targets contained inside. There are some ports that do it this way, for example DirectStorage.
https://gitlab.kitware.com/cmake/cmake/-/issues/24103

It is in response to this that gh-andre says that they logged the 12204 request here (extract):

Indeed. I created a feature request with Nuget, but they aren't very responsive for feature requests, so the likelihood of this being implemented soon or at all isn't great.
#12204

[venki-thiyag]

Any update on this issue?