We Keep Coding

.NET Core - why do 'classic' assembly references not get put into the generated <app>.deps.json files at a higher level?

In .NET core, the generated .deps.json file controls assembly loading - if your dependencies aren't in the .deps.json for your top level application, they will not get loaded unless you start handling AssemblyResolve events and all that stuff.
The situation I have is as follows
.NET Core 6
Class Library Assembly - lets call it 'ClassLib'
Application (exe) - lets call it 'App' - that depends on 'ClassLib' as a project reference
If I use a Nuget package (PackageReference) inside ClassLib then the Nuget package shows up in the generated App.deps.json and everything works. (Newtonsoft.json used as an example of this below)
However, I have several cases where there are legacy assemblies that I wish to reference that are not in Nuget packages. Those can be added as references using the UI (Add COM Reference then 'Browse' to the assembly) or via a <Reference ...> node in the csproj.
When you build 'App', the App.deps.json does not include any sign of the dependencies on the legacy assemblies via ClassLib, just the nuget packages. This means that at runtime, the legacy assembly is not going to get loaded, leading to all sorts of interesting failures...
Details of the situation
ClassLib.csproj contents
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net6.0</TargetFramework>
<ImplicitUsings>enable</ImplicitUsings>
<Nullable>enable</Nullable>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Newtonsoft.Json" Version="13.0.2" />
</ItemGroup>
<ItemGroup>
<Reference Include="Legacy">
<HintPath>..\path\to\Legacy.dll</HintPath>
<SpecificVersion>True</SpecificVersion>
</Reference>
</ItemGroup>
</Project>
App.csproj contains
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net6.0</TargetFramework>
<ImplicitUsings>enable</ImplicitUsings>
<Nullable>enable</Nullable>
</PropertyGroup>
<ItemGroup>
<ProjectReference Include="..\ClassLib\ClassLib.csproj" />
</ItemGroup>
</Project>
Generated App.deps.json shows the dependency of ClassLib on NewtonSoft.Json (imported as Nuget) but not on Legacy.dll
"ClassLib/1.0.0": {
"dependencies": {
"Newtonsoft.Json": "13.0.2"
},
"runtime": {
"ClassLib.dll": {}
}
}
I have tried various combinations of options in the node such as CopyLocal/Private etc with no change to the outcome in terms of the generated App.deps.json
I can make things work if I pack Legacy.dll into a nuget package, but to be honest I have a number of legacy dlls to deal with and making each into a nuget package (they come from various sources and may be updated separately) seems rather a 'sledgehammer to crack a nut' solution.
so...
Is there a way that I can persuade the build system to treat the old-fashioned assembly reference in the same way as the package reference and propagate the dependencies up to higher level projects? Failing that, is there a way that you can customize the build process to inject dependencies into the .deps.json file at build time? (hey, a different sort of dependency injection!) Or am I stuck making nuget packages or hacking around in AssemblyResolve events?

MSBuild: Remove Reference to Assembly added via NuGet

In the process of moving some legacy code from packages.config to PackageReference.
I have a NuGet package (let's say A.nupkg) that has a reference to a different NuPkg (B.nupkg). B.nupkg includes a reference to Foo.dll.
A project referenced A.nupkg in packages.config, but B.nupkg was not (despite being a transitive dependency). The problem is that the project references a drop-in replacement (same namespace and classes, but including bug fixes) for the Foo API in the form of a Foov2.dll
Now with the change to PackageReference the transitive dependency is picked up, Foo.dll is referenced by the project and we end up with ambiguous references between Foo.dll and Foov2.dll. I can't change the NuGet package (wish I could) so I need a workaround.
I tried adding a target that removes the unwanted reference before building it, but I can't find the right spot to put it - or maybe references from NuGets are handled different to normal references:
<Target Name="RemoveOutdatedReferences" BeforeTargets="BeforeBuild">
<Message Importance="High" Text="All references: #(Reference->'%(FileName)').
Sadly no Foo.dll so no wonder I can't remove it."/>
<ItemGroup>
<Reference Remove="Foo, Version=1.2.3.4, Culture=neutral, PublicKeyToken=7dd5c3163f2cd0cb" />
</ItemGroup>
</Target>
Alternatively I also tried to remove the whole transitive NuGet package, but using <PackageReference Remove="Foo"/> didn't work either.

It appears like PackageReference Alias feature is designed specifically for scenarios of namespace collisions.
https://learn.microsoft.com/en-us/nuget/consume-packages/package-references-in-project-files#packagereference-aliases
In some rare instances different packages will contain classes in the
same namespace. Starting with NuGet 5.7 & Visual Studio 2019 Update 7,
equivalent to ProjectReference, PackageReference supports Aliases. By
default no aliases are provided. When an alias is specified, all
assemblies coming from the annotated package with need to be
referenced with an alias.

According to our little discussion, the only option so far I see is to create a custom NuGet package which encapsulates A.nupkg without its dependencies:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net6.0</TargetFramework>
<PackageId>My.Wrapper.Around.A<PackageId>
<PackageVersion>1.0.0<PackageVersion>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="A" Version="x.y.z">
<PrivateAssets>all</PrivateAssets>
</PackageReference>
</ItemGroup>
</Project>
According to the Microsoft docs, <PrivateAssets>all</PrivateAssets> should prevent all transitive dependencies from A.nupkg flowing up to the consumer.
And in your target project:
<Project Sdk="Microsoft.NET.Sdk">
<ItemGroup>
<PackageReference Include="My.Wrapper.Around.A" Version="1.0.0" />
<PackageReference Include="Foov2" Version="1.0.0" />
</ItemGroup>
</Project>

Changes to how references work in .Net-Core [duplicate]

I'm writing an MVC website using ASP.NET Core 2.0.
In the ASP.NET Core project (let's call it Web), I reference a .NET Standard 2 project in the same solution (let's call it Service). The Service project also references a third .NET Standard 2 library in the solution (let's call this one Business). The Business project declares a type called Model.
The problem is that I can use Model in the Web project (i.e. the compiler sees the type Model and I can do var a = new Model();) as if the Web project has referenced Business, but it actually only has a reference to Service.
How can I hide Model from Web? Is this a new feature in ASP.NET Core 2 or all .NET Standard projects are like this?
Edit
As specified here, this is due to transitive project references which is a new "feature" in .NET Standard, but how do I fix it?

Transitive project references (ProjectReference)
Transitive project references are new feature of SDK-style csproj (1,2) format used in .NET Core/.NET >= 5. You can also use this csproj for old .NET Framework projects (1,2,3) but with some exceptions.
In this SDK-style format project references (represented by <ProjectReference> entry in .csproj file) are transitive. This is different to old non-SDK .csproj used previously.
But you have three options to go back to old non-transitive behavior.
Use <DisableTransitiveProjectReferences>true</DisableTransitiveProjectReferences> property in .csproj that references projects for which you don't want their transitive dependencies to be visible by compiler.
In your case you can add it to Web project. (first project that reference other projects, Web -> Service -> Business)
You can also set this behavior globally for all .csprojs by doing it in Directory.Build.props file that you put in the root folder that contains your source.
<Project>
<PropertyGroup>
<DisableTransitiveProjectReferences>true</DisableTransitiveProjectReferences>
</PropertyGroup>
</Project>
With this file you basically have old project reference behaviour. Useful when you do migration of old .NET Framework solution that uses old csproj format to new SDK-style .csprojs.
On the project that you reference you can set which dependencies shouldn't flow further when the project is referenced. You use PrivateAssets="All" attribute on <ProjectReference> for this. So for example you can edit Service.csproj like this:
<ItemGroup>
<ProjectReference Include="..\Business.csproj" PrivateAssets="All" />
</ItemGroup>
This is more flexible and fine-grained approach. You can control with particular transitive project references should be visible when the project is referenced.
Use ItemDefinitionGroup to define default <PrivateAssets>all</PrivateAssets> metadata for all ProjectReferences. You can also define it in Directory.Build.props file if you want to apply it globally to all projects.
<ItemDefinitionGroup>
<ProjectReference>
<PrivateAssets>all</PrivateAssets>
</ProjectReference>
</ItemDefinitionGroup>
The effect would be the same as setting <ProjectReference Include="..."> <PrivateAssets>All</PrivateAssets> </ProjectReference> (or PrivateAssets="All" attribute on all ProjectReferences entries.
The difference from using 1. approach (DisableTransitiveProjectReferences) is that if you explicitly define PrivateAssets metadata on ProjectReference item then this value is used. You can think of using ItemDefinitionGroup as a way to provide default value of PrivateAssets metadata it it is not provided explicitly.
What should you use? It depends what you prefer. If you are used to old csproj behavior or want to migrate old solution to .NET Core then using DisableTransitiveProjectReferences or ItemDefinitionGroup in your Directory.Build.props is the easiest solution.
Nuget references (PackageReference) are also transitive by default.
This is not strictly answering your question but is something that you should be aware too.
If you are using new PackageReference format for nuget packages (and you probably do because this is the default in new SDK-style csproj files) then you should also be aware that these references are transitive. If your project references another project (with ProjectReference) that references nuget package (with PackageReference) then your project will also reference this nuget package.
Here ProjectA will have implicit reference to Newtosoft.Json library.
Unfortunately there is no DisableTransitivePackagesReferences for package references. But you can use PrivateAssets metadata like you did for ProjectReference in 2nd option or use ItemDefinitionGroup like you did in 3rd option.
That's why if you want to disable transitive dependencies both for project and package references for all projects then this is how your Directory.build.props file should look like:
<Project>
<ItemDefinitionGroup>
<ProjectReference>
<PrivateAssets>all</PrivateAssets>
</ProjectReference>
<PackageReference>
<PrivateAssets>all</PrivateAssets>
</PackageReference>
</ItemDefinitionGroup>
</Project>
(source: I learned about this technique from this blog )
or
<Project>
<ItemDefinitionGroup>
<DisableTransitiveProjectReferences>true</DisableTransitiveProjectReferences>
<PackageReference>
<PrivateAssets>all</PrivateAssets>
</PackageReference>
</ItemDefinitionGroup>
</Project>

Well my question was close to one marked as duplicate here but to solve it requires different tactic.
Thanks to comment from "Federico Dipuma" and the answer given here I was able to solve this problem.
You should edit the Service.csproj file and add PrivateAssets="All" to ProjectReference keys you don't want to flow to top.
<ItemGroup>
<ProjectReference Include="..\Business.csproj" PrivateAssets="All" />
</ItemGroup>

All the above answers currently do not work for nuget package dependencies.
For the following library project (PrivateAssets="all"):
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
<GeneratePackageOnBuild>true</GeneratePackageOnBuild>
<Authors>Roy</Authors>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Newtonsoft.Json" Version="13.0.1" PrivateAssets="all" />
</ItemGroup>
</Project>
The following nuspec file will be produced:
<package xmlns="http://schemas.microsoft.com/packaging/2012/06/nuspec.xsd">
<metadata>
<id>MyLib</id>
<version>1.0.0</version>
<authors>Roy</authors>
<requireLicenseAcceptance>false</requireLicenseAcceptance>
<description>Package Description</description>
<dependencies>
<group targetFramework=".NETStandard2.0" />
</dependencies>
</metadata>
</package>
Notice how "Newtonsoft.Json" is not even specified as a dependency.
This will obviously not work as Visual Studio will not even be aware of that dependency and the consuming project will fail to resolved "Newtonsoft.Json" at runtime.
The correct answer is setting PrivateAssets="compile".
Which will result in the following nuspec file:
<package xmlns="http://schemas.microsoft.com/packaging/2013/05/nuspec.xsd">
<metadata>
<id>MyLib</id>
<version>1.0.0</version>
<authors>Roy</authors>
<requireLicenseAcceptance>false</requireLicenseAcceptance>
<description>Package Description</description>
<dependencies>
<group targetFramework=".NETStandard2.0">
<dependency id="Newtonsoft.Json" version="13.0.1" include="Runtime,Build,Native,ContentFiles,Analyzers,BuildTransitive" />
</group>
</dependencies>
</metadata>
</package>
This will prevent the consuming project from accessing the Newtonsoft.Json namespace in code, while compiling and copying all the required assemblies to allow the "encapsulating" library work.

Empty Nuget package for just dependencies

I have a project I'd like to put all my dependencies into one nuget package. The idea is that when I need to I can just pull in that one nuget package instead of 10 that I require. Is this possible to do?
When I created a library I removed the class file and just pulled in the dependencies but could not get a package to create.

You can do this by setting the IncludeBuildOutput property to false while creating the package.
For example [using VS 2017] -
File > New Project > .NET Core class library
Right click on project and edit csproj to have the following content -
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net46</TargetFramework>
<PackageId>MetaPackage</PackageId>
<GeneratePackageOnBuild>true</GeneratePackageOnBuild>
<IncludeBuildOutput>false</IncludeBuildOutput>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Newtonsoft.Json" Version="11.0.2" />
<PackageReference Include="NuGet.Versioning" Version="4.7.0-rtm.5104" />
<PackageReference Include="NUnit" Version="3.10.1" />
</ItemGroup>
</Project>
Right click and build project
Look at the package at <project_dir>\bin\Debug\MetaPackage.1.0.0.nupkg
This will create a package that has no \lib and the nuspec file should have package reference dependencies.
You can read more about IncludeBuildOutput here.

How to include a library in .NET Core 2.0

I don't know much about .NET yet, so I guess I'm missing something obvious.
I created a library (targeted as a DLL file, set for .NET standard 2.0), packaged it both as a DLL file and as a NuGet package. Now I want to use the library in another project, on ASP.NET Core 2.0. How should I do it?
I am currently on a Linux VM, so I use Visual Studio Code, and therefore I would prefer some solution without using the full Visual Studio. I tried some solutions using the full Visual Studio, but that didn't work for me, because I haven't found a reference explorer anywhere.

You would have to reference your library in the .csproj file:
An empty .csproj file would look like this:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp1.1</TargetFramework>
</PropertyGroup>
</Project>
Now, you can have two types of references:
Project Reference - You have a project that serves as a class library in your solution and you want to reference it directly:
<ProjectReference Include="..\..\src\mylib.csproj" />
Package Reference - You have a link to a NuGet package:
<PackageReference Include="Microsoft.EntityFrameworkCore.Sqlite" Version="1.1.2" />
Inside your .csproj file, the references should be inside an "ItemGroup" block, and each reference type should have its own "ItemGroup".
Here's an example of a .csproj file with some package references and some project references:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netcoreapp1.1</TargetFramework>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Autofac.Extensions.DependencyInjection" Version="4.1.0" />
<PackageReference Include="Microsoft.AspNetCore" Version="1.1.1" />
<PackageReference Include="Microsoft.AspNetCore.Mvc" Version="1.1.2" />
<PackageReference Include="Microsoft.NET.Test.Sdk" Version="15.0.0" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Design" Version="1.1.2" />
<PackageReference Include="Microsoft.EntityFrameworkCore.InMemory" Version="1.1.2" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Sqlite" Version="1.1.2" />
<PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="1.1.2" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Tools.DotNet" Version="1.0.1" />
<PackageReference Include="xunit" Version="2.2.0" />
<PackageReference Include="xunit.runner.visualstudio" Version="2.2.0" />
</ItemGroup>
<ItemGroup>
<ProjectReference Include="..\..\src\mylib.csproj" />
<ProjectReference Include="..\..\src\mylib2.csproj" />
</ItemGroup>
</Project>

A lot of people recommend one of two solutions:
Copy the library into your solution folder.
cp -r foo/foo ./foo
dotnet sln add foo/foo.csproj
cd bar
dotnet add reference ../foo/foo.csproj
This is a terrible solution.
Don't do this (i.e., copy and paste your library code every time you want to use it. It is bad for obvious reasons).
Setup a local NuGet repository, copy your library into the local repository, and then add it.
nuget add -name "Local" -source /home/doug/packages
nuget add ~/foo/foo.nupkg -source /home/doug/packages
Then install the package:
cd bar
dotnet add package foo
This is an acceptable solution, but the workflow is quite irritating if you are actively working on your library (foo), because the -source path must be absolute.
--
I recommend you look at dotnet add package with local package file, which explains how you can have a local cache of any custom .nupkg files you want to work with.
Basically, just drop this into your solution folder:
File NuGet.Config
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<add key="local" value="./packages" />
</packageSources>
</configuration>
(Notice that ./packages is a relative path, that will work even when you check your project out on an entirely different machine or OS.)
Now if you call dotnet add package X it will also look for any file called x.nupkg in your ./packages/ folder.
Now if you want to use any custom local library, all you need to do is:
cp ~/foo/foo.nupkg ./packages
cd bar
dotnet add package foo
(Note: by default NuGet caches your .nupkg files in ~/.nuget and will restore packages from that folder if you call dotnet add package X, even if you have a different X.nupkg in your local ./packages folder. You may find the command dotnet nuget locals all --clear useful if you encounter strange behaviour to ensure you're getting the exact version of the .nupkg file you want, not some arbitrary cached version)

Another way to reference the local package in the .csproj file:
<ItemGroup>
<Reference Include="MyAssembly">
<HintPath>path\to\MyAssembly.dll</HintPath>
</Reference>
</ItemGroup>

Given that the DLL file you want to reference in the new ASP.NET Core 2.0 project is relatively fresh, I suspect you will need to make changes to this original DLL file as you develop the ASP.NET project.
In this situation I would add the original DLL project as part of the ASP.NET solution so you can work on both sets of source code, including setting of breakpoints within the same solution workspace.
NuGet packaging of the original DLL project can be delayed until the first release of your whole combined solution has stabilised and you want to make that DLL file available to a larger developer audience beyond the scope of your ASP.NET application.

A good solution will be to add the library (.dll file) that you want to use to the Project's References of your project in which you want to use the library:
Right Click on the project → Add → Reference → Project → Browse → Path_to_your_generated_library (.dll)
This will automatically generate the following node in the .csproj file:
<ItemGroup>
<Reference Include="DotNetCoreClassLibraryCodeParser">
<HintPath>..\..\DotNetCoreClassLibrary\DotNetCoreClassLibrary\bin\Debug\netcoreapp2.1\DotNetCoreClassLibrary.dll</HintPath>
</Reference>
</ItemGroup>