How do I specify dependencies in a .NET Standard Class Library? - .net-core

A .NET Standard Class Library doesn't use a .nuspec file; there is a "Package" tab in the project settings where you enter all the metadata for the NuGet package. These go in the .csproj file.
I want to create a solution with projects A and B, where project B depends on project A. Both need to go on NuGet as separate packages. But if someone installs the NuGet package for B, it should also install the package for A.
How do you specify this simple dependency for a .NET Standard Class Library? I'm not assuming that adding a reference will be enough to do this.

NET Standard .csproj files use PackageReference and ProjectReference MSBuild items to control dependencies on packages loaded from NuGet or your solution, respectively. They both support metadata tags PrivateAssets, IncludeAssets, ExcludeAssets, which control what exactly and how your project depends on in those dependencies. By default, all dependencies are auto-generated by the Visual Studio with PrivateAssets, which means those dependencies are consumed, but they're not marked as dependencies for consumers of your project (which is gonna be a package in NuGet).
So, you just need to replace the PrivateAssets metadata with the IncludeAssets (maybe with proper values).
For example, my SuperPackage.csproj file looks like below:
..................
<ItemGroup>
<PackageReference Include="Microsoft.CodeAnalysis.FxCopAnalyzers" Version="2.6.0">
<PrivateAssets>all</PrivateAssets>
</PackageReference>
<PackageReference Include="Newtonsoft.Json" Version="11.0.2">
<IncludeAssets>compile</IncludeAssets>
</PackageReference>
</ItemGroup>
<ItemGroup>
<ProjectReference Include="..\ClassLibrary1\ClassLibrary1.csproj">
<IncludeAssets>compile</IncludeAssets>
</ProjectReference>
</ItemGroup>
</Project>
So, I have the PackageReference to the 'Newtonsoft.Json' package from NuGet marked as a dependency, and the ProjectReference to the ClassLibrary1 project within the single solution.
When the SuperPackage project is built with checked 'Generate NuGet package on build', I get the following SuperPackage.nupkg:
Check this doc for more details: https://learn.microsoft.com/en-us/nuget/consume-packages/package-references-in-project-files

From what I have found it is not yet supported in .csproj files and you should use .nuspec to specify dependencies. Have a look how they do it in xUnit, for example.

Related

What does PrivateAssets='All' mean?

When I build my .NET Core (NETStandard v2.0) project I am getting the following warning:
ViewModels: [FodyPackageReference] Fody: The package reference for PropertyChanged.Fody
does not contain PrivateAssets='All'
The warning is in reference to the PropertyChanged.Fody NuGet package.
While the warning does not stop the build, I would like to resolve the warning. However, I don't understand what it is trying to communicate.
PrivateAssets is a metadata tag used to control dependency assets.
You might be using a dependency purely as a development harness and might not want to expose that to projects that will consume your package. In this scenario, you can use the PrivateAssets metadata to control this behavior.
Package references (PackageReference) in project files
In your case, unless you want to expose PropertyChanged.Fody to a consumer (i.e. you are releasing a library), setting PrivateAssets to All in your .csproj file will remove the warning.
<Project Sdk="Microsoft.NET.Sdk">
<ItemGroup>
<PackageReference Include="PropertyChanged.Fody" Version="3.3.1" PrivateAssets="All" />
</ItemGroup>
</Project>

Referencing assemblies under dotnet installation directory

Wondering if there is any legitimate reason for a .csproj to contain an assembly reference to an assembly w/ a hint path under the dotnet installation directory (default: c:\Program Files\dotnet on Windows).
In particular, the directories
packs
sdk
shared
An example of such a reference:
<ItemGroup>
<Reference Include="Microsoft.Extensions.Configuration.Abstractions">
<HintPath>..\..\..\Program Files\dotnet\packs\Microsoft.AspNetCore.App.Ref\3.1.0\ref\netcoreapp3.1\Microsoft.Extensions.Configuration.Abstractions.dll</HintPath>
</Reference>
</ItemGroup>
Surely not. This application would not work on other machines.
It looks like someone inserted code that uses Microsoft.Extensions.Configuration.Abstractions package which was not referenced and then probably applied "Quick fix" action from Resharper/Rider. Sometimes it leads not to referencing Nuget package
<ItemGroup>
<PackageReference Include="Microsoft.Extensions.Configuration.Abstractions" Version="3.1.1" />
</ItemGroup>
but to referencing locally placed assembly.

Shipping projects as NuGet packages while depending on each other

I have three projects I'm building
FooBar.Abstractions
FooBar.AspNetCore
FooBar.AspNetCore.IntegrationTesting
The FooBar.AspNetCore and the FooBar.AspNetCore.IntegrationTesting projects both have references to FooBar.Abstractions. I want to package and ship all three of these as individual NuGet packages.
I started with a NuGet.config file that looks like this locally:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<add key="aspnetcore_abstractions" value="./src/FooBar.Abstractions/bin/Debug/" />
</packageSources>
</configuration>
Then I add the package to my projects
<ItemGroup>
<PackageReference Include="FooBar.Abstractions" Version="2.0.0-preview1" />
<PackageReference Include="Microsoft.AspNetCore.Http.Abstractions" Version="2.2.0" />
</ItemGroup>
This really sucks though as each time I make a change in the FooBar.Abstractions project I have to go into my C:\.nuget\packages folder and delete the cache before my FooBar.AspNetCore project can restore the newly compiled version from my solution.
If I just add FooBar.Abstractions as a project reference, and then I ship the two packages to NuGet.org, how does that affect users that install the two packages across different projects in their solutions. Does NuGet and .Net figure it all out, knowing that they're the same referenced assembly? I assume in this case the FooBar.AspNetCore project will ship with the FooBar.Abstractions.dll in it if I add it as a project reference.
I don't know if that causes conflicts knowing that the package ships that .dll, then a customer installs the Abstractions package explicitly that contains the same .dll.
How do you handle this with NuGet packaging with the newest versions of NuGet? How do I constrain FooBar.AspNetCore to use the same FooBar.Abstractions.dll version between the package reference and the NuGet package others will install? I can't force PackageReference Include="FooBar.Abstractions" Version="2.2" if I'm adding it as a project reference instead can I?
When you pack a project with at project reference, NuGet converts the project reference into a NuGet dependency. It figures out the dependency version based on what version that project would be if it were packed. There is no need to use PackageReference when packing. As you discovered/explained, doing so makes local development much more difficult.
Therefore the solution to your problem is to just use ProjectReference when the projects are in the same source code repository.

Dependencies in Nuspec vs. csproj

I have a Dotnet Core 2.1 project which has both a nuspec and a csproj file - one major hassle is that the csproj describes dependencies like this:
<ItemGroup>
<PackageReference Include="Refit" Version="4.6.16" />
<PackageReference Include="Microsoft.AspNetCore.All" Version="2.1" />
<PackageReference Include="Refit.HttpClientFactory" Version="4.6.16" />
</ItemGroup>
While the nuspec does this:
<dependencies>
<dependency id="Refit" version="4.6.16" />
<dependency id="Refit.HttpClientFactory" version="4.6.16" />
<dependency id="Microsoft.AspNetCore.All" version="2.1" />
</dependencies>
Both are easily out of sync and keeping the same information twice is annoying.
Is there a way to avoid that?
There is certain to be a easy way for this, just use dotnet pack instead of nuget pack and .csproj files instead of .nuspec files.
dotnet pack supports 2 ways to specify the nuget package properties.
The legacy way: using .nuspec file, which would disable the 2nd way
The new way: specifying them in .csproj file
dotnet pack supports both ways but you must add a NuspecFile property to reference the .nuspec file and there are a lot of bugs and feature missings for the legacy way, which means you can only use the new one.
dotnet pack executes restore and build on the project and packs it with a automatically generated .nuspec file resolving all nuget metadata properties in .csproj as .nuspec properties and all projects references as nuget package references (This is not available with manually specified .nuspec file), so that versioning, dependency, and package file structure things can be automatically ensured.
My own library could be an example. Version and dependency things are specified for only once at where they are supposed to be and there are no longer any annoying duplicate configurations. Executing dotnet pack on the solution directory would generate all good .nupkgs on the dist directory.

Convert .Net Core to .Net Framework

I have a .Net Core project web project, and for various reasons want to convert it to a .Net Framework project.
Is there an easy way to do this, or do I have to start again and import the code from the previous projects
I have loaded core project to the VS 2017 RC Community and open *.csproj in text editor.
Just delete teg
<RuntimeFrameworkVersion>
and replace
<TargetFramework>netcoreapp1.1</TargetFramework>
to
<TargetFrameworkVersion>v4.6.1</TargetFrameworkVersion>
And after all in project properties set to any another framework and reset back (VS reload and repair *.csproj file).
This worked for me in VS2017:
Start with .net core web project template.
Edit *.csproj so it looks like this:
<Project Sdk="Microsoft.NET.Sdk.Web">
<PropertyGroup>
<TargetFramework>net472</TargetFramework>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.AspNetCore" Version="2.1.3" />
<PackageReference Include="Microsoft.AspNetCore.CookiePolicy" Version="2.1.2" />
<PackageReference Include="Microsoft.AspNetCore.Http.Abstractions" Version="2.1.1" />
<PackageReference Include="Microsoft.AspNetCore.HttpsPolicy" Version="2.1.1" />
<PackageReference Include="Microsoft.AspNetCore.Mvc" Version="2.1.2" />
<PackageReference Include="Microsoft.AspNetCore.Mvc.Core" Version="2.1.2" />
<PackageReference Include="Microsoft.AspNetCore.Mvc.RazorPages" Version="2.1.2" />
<PackageReference Include="Microsoft.AspNetCore.StaticFiles" Version="2.1.1" />
</ItemGroup>
</Project>
Save and close.
Try running project.
The PackReferences is just the NuGet files, and you can add them through the GUI if the versions are different from mine above.
There's lots of similar answers here, but I didn't see one that was quite what I ended up doing, so I'd like to leave this here just in case someone else is in the same shoes.
Just to be clear, my project was a console program. So, if you're trying to use this answer for something else, your mileage may vary.
In your .csproj file, inside of the <PropertyGroup></PropertyGroup> tag, modify <TargetFramework> to reflect the following:
<TargetFramework>net461</TargetFramework>
Now, in this example, I was using v4.6.1. I can only assume that you'll plug in your version behind the word "net", without the periods. Good luck!
None of the answers here worked for me. In .Net Core 2 the project.json file no longer exists. However, I did solve this problem using the following steps.
1) I removed all nuget packages from my existing project.
2) I created a separate .net core web app project, targeting .net 4.61. This was to get the default nuget packages.
3) I edited the temporary project's .csproj file, copied all the PackageReference nodes inside ItemGroup, and pasted them into my existing projects .csproj file.
4) Edited the TargetFramework node (inside PropertyGroup) from "netstandard2" to "net461"
I had a few package changes to track down and resolve, but otherwise I was able to run.
In my version of Visual Studio 2017 (15.6.2) after 'Unloading the Project', right-clicking and selecting 'Edit <your project file>, I had to:
Add the node:
<TargetFrameworkVersion>v4.5.2</TargetFrameworkVersion>
Delete the nodes:
<TargetPlatformIdentifier>UAP</TargetPlatformIdentifier>
<TargetPlatformVersion Condition=" '$(TargetPlatformVersion)' == '' ">10.0.16299.0</TargetPlatformVersion>
<TargetPlatformMinVersion>10.0.16299.0</TargetPlatformMinVersion>
<ProjectTypeGuids>{A5A43C5B-DE2A-4C0C-9213-0A381AF9435A};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>
There are several steps that you need to do, in order to achieve this.
Firstly right click on the .csproj file and add the following
<TargetFrameworks>netstandard2.0;netcoreapp2.0;net35;</TargetFrameworks>
<RuntimeIdentifiers>win7-x86;win7-x64</RuntimeIdentifiers> <EnableDefaultCompileItems>false</EnableDefaultCompileItems>
Once you have made these changes reload the project and build it.
This will generate the .dll files and Nuget package for this
build in the Debug/Release folder of the project.
Add these .dll to the nuget and access these projects from
nuget.
Try the above steps. This should work.
My .net standard project is relatively simple with few Nuget packages. I just changed
<TargetFramework>netstandard2.0</TargetFramework>
TO
<TargetFramework>**net461**</TargetFramework> under PropertyGroup section of .csproj file and this did the job for me.. Thanks to Brandon Barkley for your answer in the comments.
add below in csproj
<PropertyGroup>
<TargetFrameworks>netcoreapp2.1;net471</TargetFrameworks>
</PropertyGroup>
I had only a handful of source files. For me it worked best by
Closing Visual Studio 2022
Renaming away the solution folder
Creating a new Visual Studio solution of type "WPF App (.NET Framework)" with the original folder name and same project name
Copying all *.xaml. *.xaml.cs and *.cs from the old project to the new, not touching *.sln, *.csproj and *.config.
Project->Add Existing Item… and adding the copied items
Adding all the special references.
That rebuilt all without a complaint.

Resources