Cannot install managed packages into C++/CLR .NET Core project

[abelykh0]

Details about Problem

NuGet product used (NuGet.exe | VS UI | Package Manager Console | dotnet.exe): NA

NuGet version (x.x.x.xxx): whatever comes with VS 2019

dotnet.exe --version (if appropriate): NA

VS version (if appropriate): Visual Studio Enterprose 2019 v16.1.1

OS version (i.e. win10 v1607 (14393.321)): Windows 10 v1809 (OS Build 17763.529)

Worked before? If so, with which NuGet version: never worked, see #3171, #1121

Detailed repro steps so we can see the same problem

1. Create new C++ Console application using the "Console App" template

2. Right click on project, Properties, "Common Language Runtime Support" - set to "Common Language Runtime Support (/clr)", ".NET Target Framework Version" - set to "4.7.2", OK

3. Right click on References, Manage Nuget Packages, browse to "Newtonsoft.Json", Install

Error Could not install package 'Newtonsoft.Json 12.0.2'. You are trying to install this package into a project that targets 'native,Version=v0.0', but the package does not contain any assembly references or content files that are compatible with that framework. For more information, contact the package author.

• For C++/CLI PackageReference projects, NuGet should ignore the TargetPlatformMoniker #11808

[bd4drummer]

I have been developing in C++ CLR .Net Core against VS 2019 latest Preview. I can't call this a blocker issue for that work, but I can argue that NET Core CLR projects are not going to qualify as fully supported without this being resolved.

Is there any possibility the priority of this to be escalated? Most just asking that we can depend on this to be resolved with the release of NET Core CLR development.

[Arlorean]

I'm getting the same problem trying to nuget System.Numerics.Vectors (4.5.0) into a C++/CLR project with NET Target Framework Version v4.7.2 in Microsoft Visual Studio Professional 2019 Version 16.4.3:
Could not install package 'System.Numerics.Vectors 4.5.0'. You are trying to install this package into a project that targets 'native,Version=v0.0', but the package does not contain any assembly references or content files that are compatible with that framework. For more information, contact the package author.

[Sunbreak]

I'm getting the same problem trying to nuget System.Numerics.Vectors (4.5.0) into a C++/CLR project with NET Target Framework Version v4.7.2 in Microsoft Visual Studio Professional 2019 Version 16.4.3:
Could not install package 'System.Numerics.Vectors 4.5.0'. You are trying to install this package into a project that targets 'native,Version=v0.0', but the package does not contain any assembly references or content files that are compatible with that framework. For more information, contact the package author.

There seems to be workaround: https://stackoverflow.com/questions/18694947/how-can-i-make-my-managed-nuget-package-support-c-cli-projects

[ldematte]

I am currently using the workaround, which works OK for packages.config, download and update of packages due to the fact that NuGet and/or VS does not actually care for the targetFramework in these situations (you specify native, you get the package dowloaded even if not native).
However from this point onwards everything becomes messy: you have to add references manually, you have to add all dependencies manually (and add references to the dependencies manually), you have to adjust all of them manually when performing an update... Far from ideal.
Support for non-native packages in C++/CLI projects is really long overdue.

[dominoFire]

Mention from #8195

[nkolev92]

1st NuGet part merged: #10194.

cc @olgaark @wli3

[nkolev92]

Status: The known necessary work by NuGet is done.

As of now, the C++ team wants to focus on C++/CLI .NET Core PackageReference support, so that's the only work that's been done.

[23W]

Status: The known necessary work by NuGet is done.

As of now, the C++ team wants to focus on C++/CLI .NET Core PackageReference support, so that's the only work that's been done.

@nkolev92
Does it mean that .NET Standard nuget packages can be installed in C++/CLI projects?

[nkolev92]

@23W Not yet. There's still some work leftover on C++ side.

[levicki]

@nkolev92 Will they really only support .Net Core targets?

It makes no sense not also supporting .Net Framework targets.

[nkolev92]

That's what I am aware of, but I can't speak on behalf of the C++ team about what they'd be open to supporting.

[levicki]

@nkolev92

That's what I am aware of, but I can't speak on behalf of the C++ team about what they'd be open to supporting.

Our hardware and software vendor (large US comany in the financial sector) is using a mix of C++, C++/CLI, and C# .Net Framework code in their software stack and we are interfacing with that to provide added value to our customers.

Currently they support .Net Framework 4.5.2 (will be 4.8 when customers finally migrate to Windows 10 from Windows 7 SP1 -- things move slowly in financial sector because of astronomical costs of various certifications), and we have no idea when (if ever) will they migrate to and / or support .Net Core.

I often write C++/CLI code targeting .Net Framework which has to work with vendor code and the provided OS runtime environment on the hardware preferrably without adding new dependencies, not to mention that vendor might refuse to provide software support if we mixed .Net Core into it.

While not supporting .Net Framework targets wouldn't make my job harder than it already is, supporting PackageReference with .Net Framework targets would make it much easier.

I hope you can pass the feedback and I hope they reconsider their decision.

[zivkan]

Just curious, is P/Invoke an acceptable alternative to c++/cli? I'm sure there are some disadvantages, but I think it might be a feasible workaround to dropping support for .NET Framework. I think that c++/cli is WIndows only, meaning anyone interfacing .NET with native code on Linux, Mac, iOS, Android, etc have no choice but to use P/Invoke.

[nkolev92]

cc @AugP who's the PM on that side.

[amaitland]

Just curious, is P/Invoke an acceptable alternative to c++/cli?

No. For those of us that already have existing C++/CLI code bases (https://github.com/cefsharp/CefSharp) dropping support for .Net framework would be catastrophic for the existing user base.

[levicki]

Just curious, is P/Invoke an acceptable alternative to c++/cli?

Platform Invoke purpose (as the name suggests) is for calling platform API.

C++/CLI is often used to wrap existing C++ classes in managed classes, and then expose those to both C++ and .Net Core / .Net Framework applications.

I don't see how you could accomplish the same with P/Invoke only.

Anyway, my question was why they wouldn't support .Net Framework targets for nuget package references in C++/CLI projects as well when they already went through the trouble to support .Net Core targets so I don't understand what P/Invoke has to do with my question.

[zivkan]

Platform Invoke purpose (as the name suggests) is for calling platform API.

It's used to call any arbitrary "native" library (dll on windows, so on linux, dylib on mac). It's certainly convenient to call operating system (platform) APIs. But Kestrel in .NET Core 1.x and 2.x used libuv, which is not part of any operating system, and their .NET code they P/Invoke into it. There are also packages on nuget.org that contain both native libraries, plus a pure-.NET assembly that uses P/Invoke into it. Plus blog posts, stack overflow questions, and other websites with [DllImport examples with dlls that are not part of the platform. So, evidence is that it's not limited to platform APIs. Therefore, I see P/Invoke as the way to interface with non-.NET code, just as JNI is in Java. Which is exactly what I also see C++/CLI for as well. Two different ways to achieve the same outcome.

I don't understand what P/Invoke has to do with my question.

I'm trying to learn. Maybe this is not a safe space to learn? I haven't done anything in C++ since I was studying in university, which was before .NET was even a thing, though I doubt anyone teaches C++/CLI to students today. My current understanding is that C++/CLI is Windows only (and even then, Microsoft's compiler only. You can't do this will gcc, icc, etc. Maybe someone wrote an unofficial llvm plugin?), so anyone trying to interface C++ with .NET on anything other than msvc on Windows have no choice except P/Invoke. I'm curious how they make it work.

Anyway, NuGet's side of this feature is implemented. We now need the C++ team to make changes on their side, test, and give us feedback if NuGet needs to change anything further. As previously said, it's also up to them to define the scope of what they're going to support.

[levicki]

@zivkan

Which is exactly what I also see C++/CLI for as well. Two different ways to achieve the same outcome.

But the outcome is totally not the same for the developer -- the amount of work and resulting code reeadability and maintainability are worlds apart.

Yes, you can call C++ code from a DLL using P/Invoke but that gets ugly really fast so you shouldn't do that unless that's your only option (i.e. when you don't have C++ source code but only a DLL).

Since we are discussing C++/CLI here, it goes without saying that we have C++ source code so we won't be using P/Invoke which makes discussing it off-topic.

I'm trying to learn.

Trying to learn is commendable.

Derailing discussion so that busy people from Microsoft who are supposed to answer on-topic question that I asked now have to sift through comment noise (which includes my responses to you) is what many people including myself consider rude.

Maybe this is not a safe space to learn?

You can definitely learn a lot just by reading GitHub issues on popular projects, but if I am not mistaken the primary intent of this platform is collaboration, not personal gain.

Therefore, before you decide to comment on a GitHub issue, it would be nice if you would take a moment to consider whether your comment will be a meaningful contribution towards a common goal described in an issue title.

[kuhnboy]

@AugP can you comment on the status of supporting this from the C++ side please?

[nkolev92]

Hey all,
This is scheduled to release in 17.3.
The support being added is PackageReference for C++/CLI .NET Core projets

I'll update this issue with the announcements when they're ready .

[levicki]

@nkolev92, @AugP

Hey all, This is scheduled to release in 17.3. The support being added is PackageReference for C++/CLI .NET Core projets

I'll update this issue with the announcements when they're ready .

That's great news!

However, from the feature name it does not seem .Net Framework will be supported?

Can we get any official response on whether you would consider supporting it?

[nkolev92]

@levicki

I'd refer to https://developercommunity.visualstudio.com/t/use-packagereference-in-vcxproj/351636 for any updates on the scope of the work.

[levicki]

@nkolev92

I'd refer to https://developercommunity.visualstudio.com/t/use-packagereference-in-vcxproj/351636 for any updates on the scope of the work.

Thank you, but honestly it would have been better if you didn't -- to see that people have been asking for this for 4 years already without any progress is disturbing.

@AugP
I understand Microsoft's focus on .Net Core, but it still seems somewhat less stable compared to .Net Framework, and there are many large hardware and software companies having huge codebases consisting of both C++/CLI (.Net Framework) and pure .Net Framework libraries so like it or not .Net Framework is going to stay and new code is going to be written in it for quite a while longer. You may as well make it easier for us while we have to support it for our vendors and our clients.