VS_PACKAGE_REFERENCES does not work for native (C/C++) Nuget packages that use packages.config
When I use VS_PACKAGE_REFERENCES
in a CMake, like so:
set_property(TARGET ${TARGET_NAME} PROPERTY
VS_PACKAGE_REFERENCES "boost_1.7.0")
, it generates PackageReference
in .vcxproj
files, which doesn't do anything for C/C++ projects that require packages.config
. The docs describe PackageReference
as unsupported for C/C++ projects:
CMake expects to find a package on a user's system, which works for system-wide packages, like dnf or apt, but doesn't work at all for project-level packages, which cannot be found at the CMake generation phase and instead need to be installed after project generation, but before the build phase.
VS_PACKAGE_REFERENCES
or, some appropriately-named C/C++ equivalent of it, should translate into creating packages.config
and packages.<project-name>.config
for C/C++ projects and should work as if this sequence of steps was used.
- Generate VS solution and projects
cmake -S . -B build -G "Visual Studio 17 2022"
- Switch to Visual Studio UI and install Nuget packages for the generated VS solution, as if by this Nuget package console command:
Install-Package boost -ProjectName my-project-using-boost
This step downloads referenced Nuget packages, unpacks them into the packages
directory in the solution directory and injects a series of elements into .vcxproj
files that come from Nuget packages in the form of .props
and .targets
files, which sets up C/C++ includes and libraries.
- Build all configurations
cmake --build build --config Debug
cmake --build build --config Release
This step uses includes and libraries injected into .vcxproj
files in the previous step.
Note that there is no way find_package
could possibly find these headers/libraries because they don't exist until project directory structure is generated.
The only way today to accomplish this is to patch generated projects, but this cannot be automated reliably because Nuget doesn't have a CLI to install a package outside of VS UI and patching generated projects is error-prone, as CMake may generate different structure when other options change. Plus, it doesn't work at all in the new Visual Studio's Open Folder feature, which re-generates projects every time CMakeLists.txt
is changed.