I have a Visual Studio solution with two projects - a .NET Standard (2.0) library containing some logic and a .NET Framework (4.6.1) class library containing user interface etc. The .NET Framework library then has the .NET Standard library added as a project reference so it can use methods contained in the logic library.
I am then using Azure Pipelines in Azure DevOps to build these two projects, pack them as NuGet packages and push them to a NuGet server provided by Azure Devops (Azure Artifacts).
However, when the NuGet packages are published, they only include dependencies in NuGet on packages that I've added to the projects via NuGet. What I want ideally is when my .NET Standard (logic) library is packaged up and pushed to the NuGet server, a reference to it on NuGet (with the updated version number etc) is added to my .NET Framework (UI) library.
Has anyone else had this issue that can give me some guidance on how to solve it please? I've had a look online and drawn a blank so far.
Thanks!
Go to Tools ->Options- > Nuget Package Manager and change the Default package management format to “PackageReference“, we have two options there- Packages. config and PackageReference. Once the format is change to PackageReference, you can go to the project which you want to migrate and click on packages.
Use dotnet pack or msbuild -t:pack to include the project reference as a nuget dependency. This also resolves issues for PackageReferences not being written as dependencies. Assuming your .net framework project is out-of-the-box from Visual Studio, you'll need to reference the Nuget.Build.Tasks.Pack nuget package to access the necessary targets.
Perform any one of the following NuGet actions: Open the Package Manager UI - Right-click on References and select Manage NuGet Packages... Open the Package Manager Console - From Tools > NuGet Package Manager, select Package Manager Console
If you have a ProjectReference, it will override any package references to the same package ID in the restore graph. I tried this myself (added both the ProjectReference and the PackageReference in the csproj file). It successfully builds and the output NuGet file contains the dependency to the other NuGet package.
In the projects you want to be released as NuGet packages you have to add in the csproj the following: Apart from that you only have to reference your other projects with ProjectReferences. MSBuild will build everything, and when publishing the NuGet packages it will change the ProjectReferences to PackageReferences.
There are two parts to my answer.
Firstly, if you're using dotnet pack
or msbuild -t:pack
, without a nuspec file, then project references automatically become nuget dependencies. I verified this using the following commands:
dotnet new classlib -n ProjectA
dotnet new classlib -n ProjectB
dotnet add ProjectB/ProjectB.csproj reference ProjectA/ProjectA.csproj
dotnet pack ProjectB/ProjectB.csproj
ProjectB.1.0.0.nupkg
has a nuget dependency on ProjectA v1.0.0
. This works "out of the box" with SDK style projects, but if you have an "old style" project (that imports Microsoft.CSharp.targets), you'll need to add a package reference to NuGet.Build.Tasks.Pack. If you use PackageReference, you may need to edit your csproj and set this dependency to set PrivateAssets to all to avoid this package becoming a nuget dependency. I don't know what the equivalent is if you're using packages.config, or if it's even possible. If you're using msbuild or dotnet pack, but you also have your own nuspec file, I recommend against it. Anything you want to do in the nuspec should be possible by setting the right properties or item attributes in your csproj, and let the pack targets generate the nuspec automatically. When you have your own nuspec, parts of nuget's auto-generation gets turned off, so you may be making things harder for yourself.
My memory of nuget pack
on old style csproj files is that nuget will automatically make a project reference a nuget dependency as long as the referenced project has a <project name>.nuspec
file in the same directory as the <project name>.csproj
file (I'm almost certain that it's documented somewhere on docs.microsoft.com/nuget). However, if your dependant project is a SDK style project (like is needed for .NET Core or .NET Standard projects), then I already advised against using a nuspec file with those projects, so you should really consider using the pack targets and stop using nuget pack
.
The second part of my answer will directly answer your question, which is about how to make a project reference a package reference on certain builds. Firstly, you need to use pack targets, either by using a SDK style project or by referencing the NuGet.Build.Tasks.Pack package. This way, you don't use a nuspec
file, and everything is defined in your csproj
, which is just a MSBuild file. MSBuild has conditions, so hand edit your csproj and make your project reference have a certain condition and have the package reference have the opposite condition. I suggest use a variable like $(CI), so you can test the pack using msbuild -t:pack -p:CI=true
, and on your CI machine just set CI as an environment variable to true. Since NuGet already has functionality built-in for making project references into nuget dependencies, I recommend using that, and not switching between package and project references, so I'm not going to give a copy-paste example on how to do this. But if this isn't a case of a XY-problem and you really need to do this, then I've already given enough pointers for you to be able to figure out how to do the rest.
NuGet CLI has issues with dependencies for PackageReferences and project references (only when the project is a .net Core or .net Standard too?) when not using .nuspec
files.
Use dotnet pack
or msbuild -t:pack
to include the project reference as a nuget dependency. This also resolves issues for PackageReferences not being written as dependencies.
Assuming your .net framework project is out-of-the-box from Visual Studio, you'll need to reference the Nuget.Build.Tasks.Pack nuget package to access the necessary targets. We write this data into the .csproj file with powershell on the build server before any nuget restore so that is isn't forgotten about for new full framework projects (which we are trying to get away from creating). As @zivkan mentioned, you will probably want to
set PrivateAssets to all to avoid this package becoming a nuget dependency
<PackageReference Include="NuGet.Build.Tasks.Pack">
<PrivateAssets>all</PrivateAssets>
<Version>4.8.0</Version>
</PackageReference>
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With