-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Automatically import NuGet packages from intermediate C# projects into C++/CLI projects. #4
Comments
Update on this! Currently NuGet support for CMake is missing some essential features. I will update on them here, as soon as they are contributed. In order to get a fully working out-of-the-box NuGet experiences, here's what I want to continue to contribute to CMake
The |
This is now in CMake starting from version 3.23 |
I know! As mentioned above, I am the author of the MR that implements this feature. 🙂 I will update the comment now to make clear that this works. I've also started working in restoring using |
Ah whoops! I've missed that part, sorry. Thank you for working on this, it seems like one of the most obscure cmake corners. I'm mostly interested in the third point, since as of now the support for install is practically non-existant. I was setting out to write a Python script for that (I use this kind of set up in project), but I wouldn't mind helping make that part of cmake |
I agree! I think currently your best bet is to simply set the If you do not want to re-write this on your own, I guess you could also try to add vcpkg as a submodule and simply use its toolchain file, then set this variable to If you only need |
Adding NuGet packages to C++/CLI projects is surprisingly hard. Whilst purely managed assemblies can simply be referenced by a C++/CLI project, the
TargetFramework
property not beeing properly set for C++/CLI projects, results in errors when NuGet tries to restore the package:You might also experience other errors, such as
NU1201
orNU1202
.Whilst in theory it is possible for C++/CLI projects to use NuGet packages that target the same .NET Framework version, it is currently not properly implemented by Microsoft. The naïve approach of defining a
VS_PACKAGE_REFERENCE
, as you would do for a C# project, will result in NuGet not beeing able to resolve the target framework for the project and you will receive the errors mentioned earlier. There are two possible workarounds for this issue, both of which require an intermediate C# project that has aVS_PACKAGE_REFERENCE
set, so that MSBuild is able to restore the package. In this template this could be the CommonLib project.VS_DOTNET_REFERENCE_*
) to the package assembly. However, this approach is not ideal, since you have to know where the current NuGet package cache resides, which might cause forward compatibility problems.The second option could be made much more feasible by exploiting the fact, that the proper assemblies are automatically copied over to the output directory during the build. If those assemblies could be added to the CMake export config for the project, than a simple
TARGET_LINK_LIBRARIES
would be enough to properly reference them within the C++/CLI project or other dependent projects.However, my CMake expertise is actually limited and I spent way to many hours trying to fix this issue. So if you feel you could contribute to a solution to this problem, feel free to join the discussion in this issue or open an PR! 🙂
Related resources:
%USERPROFILE%
now.The text was updated successfully, but these errors were encountered: