How can we use managed nuget packages in c++/cli project - c#

I want to consume managed nuget package in c++/cli project. Is there a way to do that?
For example my scenario is almost like this:
I have created a C# project(MainProject) and added EntityFramework nuget package to that project.
I have created one more C# project(TestCSProject) and added MainProject as reference to that project. Then automatically in references entityframework is also added
I have created one C++/CLI project(TestCLIProject) and added MainProject as reference to that project so that I want to see whether I can use entityframework.
But that didnt happened.
So I want to know how can I use managed nuget package in c++/cli project

C++/CLI project can use nuget packages using packages.config (in VS2019 still there is no PackageReference support for C++, PackageReference for NuGet packages in C++ projects). As pointed in the comments, C++/CLI should be used for interop with native code only. Anyway there may be a need sometime to use nuget packages here.
In Visual Studio 2019 the following worked for me for a C++ project referencing .Net Framework:
Go to package manager console: Tools -> NuGet Package Manager -> Package Manager Console. Then install nuget package(s) (instruction from Microsoft). E.g. EF nuget installation could be like:
Install-Package EntityFramework -Version 6.4.4 -ProjectName TestCLIProject
After nuget installation a packages.config file will be created in the project's folder and added to the project. E.g. after EF nuget installation packages.config could be like:
<?xml version="1.0" encoding="utf-8"?>
<packages>
<package id="EntityFramework" version="6.4.4" targetFramework="native" />
</packages>
Add reference(s) to dll(s) from the nuget. Project -> Add Reference... -> Browse... -> locate solution's folder -> go to packages folder -> go to nuget's folder -> locate dll(s)
For example for EF this resulted as .vcxproj was updated with:
<Reference Include="EntityFramework">
<HintPath>..\packages\EntityFramework.6.4.4\lib\net45\EntityFramework.dll</HintPath>
</Reference>
<Reference Include="EntityFramework.SqlServer">
<HintPath>..\packages\EntityFramework.6.4.4\lib\net45\EntityFramework.SqlServer.dll</HintPath>
</Reference>
Project is ready for build. If Visual Studio has opted out Tools -> Options -> NuGet Package Manager -> Automatically check for missing packages during build in Visual Studio, then nugets could be manually restored e.g. in Package Manager Console with Update-Package command.

With the newest Version of VS2022 (Visual Studio 2022 version 17.3) you can now as well use PackageReference in your C++/CLI project. Just make sure you have added
<EnableManagedPackageReferenceSupport>true</EnableManagedPackageReferenceSupport>
to the PropertyGroup with Label="Globals" in your .vcxproj file. Furthermore please be aware that your C++/CLI project must be targeting .NET Core or .NET 5+. As you can read in the Release notes this doesn't work (and neither is it planned to be supported in the future) for C++/CLI projects targeting .NET Framework.
With this enabled you can now also use the NuGet Package Manager by
In Solution Explorer, right-click "References" and
choose "Manage NuGet Packages"
just like it is described in the Microsoft documentation.

Related

Reference project in two ways

I have a project that is called framework and I have modules projects which depends on this framework project.
The problem is: Some developers on my team will have this framework code and others won't. I want to know if there is a way that if Visual Studio doesn't find this reference, it will automatically get this frameworks libs from nuget package.
You could use Conditions to include the project only if it does exist:
<ProjectReference Include="..\..\Framework\Framework.csproj" Condition="Exists('..\..\Framework\Framework.csproj')" />
<PackageReference Include="MyCompany.Framework" Version="1.0.0" Condition="!Exists('..\..\Framework\Framework.csproj')" />
You have two options to reference other projects:
Project References
This is typically done using a monorepo approach and most times all projects are part of the same solution.
If you want to reference projects from other repositories, Git sub modules may be an option https://git-scm.com/book/en/v2/Git-Tools-Submodules
Project references look like this in your my-project.csproj file:
<ProjectReference Include="..\..\Modules\Core\Core.csproj" />
NuGet Packages
Here you build your framework and publish it as NuGet package. Then you reference the package (not the project) when needed and Visual Studio will download the specified version from your NuGet repository.
Two options to setup your own NuGet repository:
https://learn.microsoft.com/en-us/azure/devops/artifacts/get-started-nuget?view=azure-devops
https://www.sonatype.com/nexus-repository-oss
You can also use NuGet packages from local file system How do I install a NuGet package .nupkg file locally? (personally I'd not recommend this for most scenarios)
Reference NuGet packages in your my-project.csproj file:
<PackageReference Include="Serilog.AspNetCore" Version="3.4.0" />
Or using visual studios package manager: https://learn.microsoft.com/en-us/nuget/quickstart/install-and-use-a-package-in-visual-studio
Note that you have to add your NuGet repository feed first: https://learn.microsoft.com/en-us/azure/devops/artifacts/nuget/consume?view=azure-devops
See also
Is it possible to reference a project that exists in the solution and use NuGet package reference as fall-back if not in .NET Core?

How do I update UWP projects' nuget packages via the CLI?

All .NET framework projects that use Nuget have a packages.config per project. When I run something like:
nuget update MySolution.sln -Id PackageName -Version 1.2.3
It will update all projects in my solution that use this package to the specified version (1.2.3 in this case)
However, I'm finding that this does NOT work for UWP projects. UWP does not use packages.config and instead put the package references directly into the csproj file. As a result, this is literally what nuget update says when I run it:
Found 2 projects with a packages.config file. (A.csproj, B.csproj)
where A and B are my .NET Framework projects that still have a packages.config file. But this list doesn't include my new UWP projects.
Is there another command for nuget update that will work with UWP projects?
How do I update UWP projects' nuget packages via the CLI?
This is a known issue for the packagereference. At the moment, NuGet CLI does not support automatic package updates to the the new .NET Core .csproj format, you can refer to the below GitHub issue for details:
support for updating references into csproj from commandline(s)
Besides, as test, the workaround using following command line does not work with UWP project
dotnet add package <PackageName> --version <version>
Indeed, currently it is very inconvenient to manage packages outside of Visual Studio for UWP with packagereference.
Hope this helps.

NuGet, Packages.config, .csproj and references

I have a question so that I can better understand NuGet packages, packages.config and the .csproj file.
It is my understanding that the setting in the NuGet Package Manager >> General for default package management format determines if your project uses packages.config or the .csproj file for resolving and restoring packages.
In my project we have selected Packages.config.
No problem it compiles and runs. So I decided to test if it would run without the reference for a dll in the .csproj file, as it is my understanding it does not use or need this. This is an incorrect assumption as though the package is in the packages.config file, when I removed the reference in the .csproj file there was an error in my project and the project would not compile.
I also noticed that if the dll is not in the references in the Solution Explorer that it fails to compile as well I( I assume these are the .csproj references).
So I am not clear on the role of the .csproj file for a Packages.config Management format for NuGet packages and the references in Solution Explorer.
The difference is on how you manage your NuGet references.
Before VS2017 the information what NuGet packages to be used during assembly was stored in files packages.config.
Since VS2017 there is a new option called package references which stores this information in the project (.csproj) file.
https://devblogs.microsoft.com/nuget/migrate-packages-config-to-package-reference/
Before VS2017 and .NET Core, NuGet was not deeply integrated into MSBuild so it needed a separate mechanism to list dependencies in a project: packages.config or project.json. Using Visual Studio solution explorer's References context menu, developer adds .csproj references to restored packages in a solution-wide folder managed by NuGet.
The reference added to the project file .csproj by Visual Studio looks like this:
<Reference Include="EntityFramework, Version=6.0.0.0"><HintPath>..\packages\EntityFramework.6.4.4\lib\net45\EntityFramework.dll</HintPath></Reference>
Starting with VS2017 and .NET Core, NuGet becomes a first class citizen in MSBuild. NuGet package dependencies are now listed as PackageReference in the SDK-style project file .csproj
A reference now looks like this:
<PackageReference Include="EntityFramework" Version="6.4.4" />

Packaging project reference in nuget : .net core

Currently I have a requirement where we have separate assemblies for contract and implementation. After creating a nuget package and attempting to consume nuget package, it fails because Package manager is unable to find dependent (contract) assembly.
This seems to be an open issue in .net core.
https://github.com/dotnet/cli/issues/3959
Unable to understand why such simple thing will not work in .net core. Looking for workaround for this issue.
It is simple to solve. You have 2 options:
A) Pack and Publish all your projects as Nuget packages:
You just add your dependencies as ProjectReference into your main projects. And continue development using project references. Also must pack all dependency projects as well. When you want to publish your packages using the same version just run:
dotnet pack -p:PackageVersion=2.1.0 also can add any other pack arguments.
Since during pack all ProjectReference will be transformed to Package dependencies. And version number is cascading into all package.
In this case your original main project and all of its dependencies will be Nuget packaged. Now you have to publish ALL. And when you want to install your Nuget package it will install all of its dependencies as well with the same version specified.
B) Package all output DLLs into a single Nuget package:
You can Publish only one Project as Nuget package and pack all other DLL into that package. First suppress pack to transform dependency from Project to Package. Find your ProjectReference and add PrivateAssets="All" to it. Should look like this:
<ProjectReference Include="yourproj.csproj" PrivateAssets="All" />
And add the following section to your .csproj file (to the project which should be packaged) to package dependency DLLs, change the DLL name and Framework version in <PackagePath>.
<ItemGroup>
<_PackageFiles Include="$(OutputPath)\yourproj.dll">
<BuildAction>None</BuildAction>
<PackagePath>lib\net5.0</PackagePath>
</_PackageFiles>
</ItemGroup>
After reading documentation I understood .net core discourages project reference instead advises to use package reference. This is mentioned in description heading in following doc.
https://github.com/dotnet/docs/blob/master/docs/core/tools/dotnet-pack.md
I published my contract assembly to nuget package and consumed it in implementation as nuget package.

Nuget - Package restore failed. Rolling back package changes for 'WebApplication1'. 0

It's my own custom nuget package that I've not published yet and testing locally.
The nuget package consists of a dll file and nuspec file is as follows.
<?xml version="1.0"?>
<package >
<metadata>
<id>MyLib</id>
<version>1.0.0</version>
<authors>Author</authors>
<owners>Owner</owners>
<licenseUrl>license url</licenseUrl>
<projectUrl>project url</projectUrl>
<requireLicenseAcceptance>false</requireLicenseAcceptance>
<description>some description</copyright>
<tags>Tag1 Tage2</tags>
</metadata>
<files>
<file src="bin\Debug\netstandard1.4\*.dll" target="lib" />
<file src="bin\Debug\netstandard1.4\*.pdb" target="lib" />
</files>
</package>
I've copied the nupkg file to a location and added it to the
Visual studio Tools -> Options -> Packages -> sources directory
Error:
Package MyLib 1.0.0 is not compatible with netcoreapp1.0 (.NETCoreApp,Version=v1.0). Package MyLib 1.0.0 supports: net (.NETFramework,Version=v0.0)
Package restore failed. Rolling back package changes for 'WebApplication1'.
Not sure how can I resolve the issue or find more information.
More Info
The dll file was created using template (.Net Framework 4.5.2)
Templates -> Visual C# -> .NET Core -> Class Library (.NET Standard)
The web application was crated using template. (Empty Web Application)
Templates -> Visual C# -> .NET Core -> ASP.NET Core Web Application (.NET Core)
Edit
I found more details under Output window
One or more packages are incompatible with .NETCoreApp,Version=v1.0.
What kind of class library should I create which is compatible with .NETCoreApp?
Edit2
I saw this URL. it suggests to create the nupkg using dotnet.exe pack --no-build whereas earlier I downloaded the nuget.exe from nuget.org to create the package.
I tried above command but then visual studio says
"... Target pack doesn't exists in the project ... "
Followed instructions on this site as well but failed URL
You need clear the Nuget Cache. To do this, go to Tools -> Options and click on it like this picture
Your project is targetting an incompatible version of .Net Framework. Right click on the project, select properties and note the value of the Target Framework. Look at the Nuget package for Microsoft and then install a more suitable NuGet package. Either install the older version of the NuGet package or update your project to target a newer version.
I had to change the Build Configuration due to an NU1603: warning.
In my Build configuration the "Treat warnings as errors" was set to All.
This was blocking Nuget from upgrading the Package due to the NU1603 warning.

Categories