13

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!

Steven Day
  • 323
  • 2
  • 4
  • 8
  • Could you clarify what you mean by "they only include dependencies in NuGet on packages that I've added to the projects via NuGet"? I don't see what you mean by that. I'm not using Azure Pipelines etc, but normal dotnet pack adds the relevant dependencies – Jon Skeet Feb 25 '19 at 17:15
  • How are you packaging the .net Framework project? Are you using .NuGet Pack task or MSBuild -t:Pack? – Josh Gust Feb 25 '19 at 17:18
  • From the title of the question: are you currently rewriting your netFW .csproj on the build server to change the project reference to a package reference, or is that an idea of what you want to do? – Josh Gust Feb 25 '19 at 17:19
  • If your .net Framework package is referencing the .net Standard project as a project reference, the binary of the .netSrd project should be included in the `/lib` directory of your .netFW package. – Josh Gust Feb 25 '19 at 17:22
  • Use MSBuild conditions to have two references in your project at the same time. The condition can be testing against an environment variable or anything else suitable. Then on any machine you can set/reset the variable to test compilation. – Lex Li Feb 26 '19 at 15:15
  • @JonSkeet What I mean by that is NuGet packages I've referenced in the local version of my application are added as dependencies in the NuGet package that is created (for things like Entity Framework Core, EF Core MySQL driver, AutoMapper etc). – Steven Day Feb 27 '19 at 10:39
  • @JoshGust I am packaging the .NET Framework project using 'nuget pack'. As it stands right now I'm not doing anything on the build server to change the project reference to a package reference - it seems from the replies given so far that this is the part I'm missing. – Steven Day Feb 27 '19 at 10:57
  • @JoshGust Also I've tried using the '-IncludeReferencedProjects' switch on the 'nuget pack' build step in my pipeline to include the .NET Standard library, however I get the error message "Unable to cast object of type 'System.String' to type 'NuGet.Frameworks.NuGet.Frameworks1069249.NuGetFramework'." I got a similar error when trying to pack the .NET Standard library using 'nuget pack' which I solved by using 'dotnet pack' instead. It seems the Nuget CLI doesn't "like" .NET Standard libraries. – Steven Day Feb 27 '19 at 10:58
  • What you want to happen (as I understand it) is exactly what happens in my own build. It would help if you could provide a [mcve] with the two projects - partly so we can know what style of project file they are. (If you're using an "old style" project for the .NET project, then try to move it to the "SDK style" project - that may well be all you need to do.) – Jon Skeet Feb 27 '19 at 12:02
  • @StevenDay It seems that you should be using `dotnet pack` or `msbuild -t:pack` with either an "SDK style" project or a package reference to **Nuget.Build.Tasks.Pack** for the .net framework project, as mentioned in both my answer and that of @zivkan. – Josh Gust Feb 27 '19 at 15:41
  • @StevenDay [this](https://github.com/NuGet/Home/issues/4808) may help explain the `unable to cast` error you're getting, and [this](https://github.com/NuGet/Home/issues/5979) was helpful for me to understand that the nuget cli has issues creating dependency references when not using `.nuspec` files. – Josh Gust Feb 27 '19 at 15:44

4 Answers4

7

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 learn.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.

zivkan
  • 12,793
  • 2
  • 34
  • 51
2

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>
Josh Gust
  • 4,102
  • 25
  • 41
0

Changing a project reference to a NuGet package reference on build

I am afraid you could not convert the project reference to the nuget package reference during building. That because they are two different ways of dealing with references. Although there are now some extensions that can convert a project reference to a nuget package reference, they need manual operation, we could not use it during the building.

Check the another thread for some more details.

So, we could not change the project reference .NET Standard (2.0) library to a NuGet package reference and add to your .NET Framework (UI) library on build.

Personally, to resolve this issue, you could use reference the .net Standard (.netSrd) project as nuget package reference on your local, when you have updated version number nuget package for .net Standard project, you could update this package in your Azure Artifacts, and use custom nuget task command to call nuget update command to update the packages to the latest version when you build your .NET Framework (UI) library.

Check the details info from:

Update NuGet package to last version after build in VSTS

Hope this helps.

Leo Liu
  • 71,098
  • 10
  • 114
  • 135
  • It is absolutely possible to "swap" the project reference for a package reference if one is willing to make those changes to the `.csproj` file before performing a NuGet restore and build. – Josh Gust Feb 27 '19 at 15:27
0

If you have a ProjectReference, it will override any package references to the same package ID in the restore graph.

Source: Resolve package references to projects (dotnet github issue)

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.

brz
  • 1,846
  • 21
  • 21