I currently have a VS2022 solution which includes a fully-native VC++ project that builds a native DLL, which depends on a lot of C++ libraries that are managed and versioned via VCPKG.
The native DLL is then consumed by a .NET Framework 4.8 (non-SDK) WPF application, which uses P/Invoke to call C-style APIs exposed by the unmanaged DLL. (It's not possible to upgrade this application to .NET 5+, because it also depends on a third-party .NET 4.8 SDK, which I cannot do without.)
Building this solution on a new machine is kind of a pain because setting up VCPKG involves following a page-long README of installation steps, and building my tiny 288 KB DLL (plus its 12 MB of genuine binary dependencies) transitively downloads and builds 15.5 GB of VCPKG source dependencies and intermediate objects (mostly Boost). Obviously the vast majority of that isn't actually used by the final product, but it's still required to build. The huge pyramid of dependencies takes nearly an hour to download & build on a new machine, but compiling my C++ code takes seconds at most, once its dependencies have been built.
Since the native assembly is needed for my .NET WPF project to run, it's configured as a project dependency in the VS solution. So on a new machine, the .NET project won't build until the VC++ project is built. I suppose I could check the binary outputs of the VC++ project into the Git repo, but that seems like a pretty malodorous code smell in its own right.
I'm thinking it would make sense to build the C++ project once, and publish the results as a package which can be consumed by the .NET project, rather than as a direct DLL reference. I'm assuming NuGet would be the right tool for this? I would publish the built NuGet package on my company's internal NuGet feed, and change the WPF app to depend on the package instead of depending directly on the VC++ project. That way, the release versioning of the VC++ project would be properly manageable rather than just having random Bin folders committed to my Git repo.
The MS docs for Native NuGet packages seem to be oriented towards using NuGet to manage native binary dependencies that are being consumed by other native projects. The main NuGet docs are more concerned with packaging managed dependencies for consumption by managed code.
So my questions are:
- Is NuGet an appropriate tool for versioning & distributing native code binary artefacts which are dependencies for managed-code projects?
- Assuming a "yes" answer for Q1, how does one properly create a native NuGet package that is intended for managed P/Invoke consumption, rather than native consumption?