We Keep Coding

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>

Compile .bond files of projects using my NuGet package

I have a NuGet package with a .bond file. Users of my package can derive their Bond structs from the structs in my package's .bond file.
I want the user's Bond files to be compiled when they include my NuGet package. Today they must include my NuGet and the Bond.CSharp NuGet. But, my NuGet already has a reference to Bond.CSharp.
How can I author my package so that the consumers do not need to have their own <PackageReference Include="Bond.CSharp" ... />?

Bond codegen is run from the Bond.CSharp's build targets.
By default, the build targets of packages you consume do not flow to your consumers. The default value of a PackageReference's PrivateAssets is "contentfiles;analyzers;build".
You can override this behavior in your csproj's PackageReference:
<ItemGroup>
<PackageReference Include="Bond.CSharp" Version="[9.0.3]">
<!-- removing "build" from default so that consumers also run codegen -->
<PrivateAssets>contentfiles;analyzers</PrivateAssets>
</PackageReference>
</ItemGroup>
I assume you are compiling the base struct into an assembly in your package. Bond codegen assumes that the generated code and the runtime library exactly match, so I've used an exact match version bound in the PackageReference: [9.0.3]
You said that you want your consumers to be able to derive from your Bond structs, so you'll probably also want to configure their BondImportPath to include the .bond file inside your package. To do this, you need to
make sure the .bond files are included in the package and
add a package .props file to set the BondImportPath to the package directory with said .bond files.
The make sure the .bond files are included in the package, add something like this to your package's .csproj file:
<ItemGroup>
<None Include="bond/**">
<Pack>true</Pack>
<PackagePath>build/bond/</PackagePath>
</None>
</ItemGroup>
This assumes that your .bond files live in a bond\ subdirectory.
To automatically add something to BondImportPath, you need to add a package .props file that will be automatically imported by consumers. Create a file named ExactNameOfPackage.props with the following content:
<Project>
<ItemGroup>
<BondImportDirectory Include="$(MSBuildThisFileDirectory)bond" />
</ItemGroup>
</Project>
This .props file also needs to be packed. Add this to your project's .csproj file:
<ItemGroup>
<None Include="ExactNameOfPackage.props">
<Pack>true</Pack>
<PackagePath>build/</PackagePath>
</None>
</ItemGroup>
Now, the consumer can just use a PackageReference. Any .bond files in their project will be compiled automatically, and they can use import "you-file.bond" to refer to a .bond file in your package.
Build assets do not flow transitively. The NuGet 5+ buildTransitive feature looks like it solves this, but I haven't experimented with it.
Here are the complete project files I used. The complete code is in my GitHub repository, export-bond-file-nuget.
lib-with-bond.csproj
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net5.0</TargetFramework>
<PackageId>LibWithBond</PackageId>
<Version>1.2.0</Version>
</PropertyGroup>
<ItemGroup>
<None Include="LibWithBond.props">
<Pack>true</Pack>
<PackagePath>build/</PackagePath>
</None>
<None Include="bond/**">
<Pack>true</Pack>
<PackagePath>build/bond/</PackagePath>
</None>
</ItemGroup>
<ItemGroup>
<PackageReference Include="Bond.CSharp" Version="[9.0.3]">
<PrivateAssets>contentfiles;analyzers</PrivateAssets>
</PackageReference>
</ItemGroup>
</Project>
LibWithBond.props
<Project>
<ItemGroup>
<BondImportDirectory Include="$(MSBuildThisFileDirectory)bond" />
</ItemGroup>
</Project>
consume-lib.csproj
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net5.0</TargetFramework>
</PropertyGroup>
<ItemGroup>
<!-- I had a local NuGet source pointing to the output of running
`dotnet pack` on lib-with-bond.csproj -->
<PackageReference Include="LibWithBond" Version="1.2.0" />
</ItemGroup>
</Project>
I was able to make this work for a PackageReference. My initial experiments making it work for ProjectReference were not successful, and I ran out of time to work more on this answer.

Error when building System.ValueTuple in .NetStandard 2.0 project

I have a .NetStandard project that uses System.ValueTuple.
It builds fine in visual studio whether or not I include the System.ValueTuple nuget package.
However it fails either way when I build it on team-city with the error:
error CS8137: Cannot define a class or member that utilizes tuples because the compiler required type 'System.Runtime.CompilerServices.TupleElementNamesAttribute' cannot be found. Are you missing a reference?
Teamcity is hosted on an environment with both the latest .Net Core SDK and the latest .NetFramework SDK.
When I change the target framework to .NetCoreApp2.0 it builds fine.
Any ideas as to what could be going on?
For Reference, here is my csproj:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFrameworks>netstandard2.0</TargetFrameworks>
<Version>$(VersionSuffix)</Version>
<Authors>**********</Authors>
<Product>**********</Product>
<Description>**********</Description>
<PackageTags>**********</PackageTags>
<GeneratePackageOnBuild>false</GeneratePackageOnBuild>
<Copyright>**********</Copyright>
<PackageProjectUrl>http://**********</PackageProjectUrl>
<PackageLicenseUrl>http://**********</PackageLicenseUrl>
<PackageIconUrl>http://**********</PackageIconUrl>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Google.Protobuf" Version="3.4.1" />
<PackageReference Include="RabbitMQ.Client" Version="5.0.1" />
</ItemGroup>
<ItemGroup>
<Folder Include="**********" />
</ItemGroup>
<ItemGroup>
<ProjectReference Include="..\**********" />
</ItemGroup>

The error went away when I started using DotNet Restore instead of Nuget Restore.
I have no idea why.

You most probably need to add a reference to System.ValueTuple.dll. You can do this by installing the System.ValueTuple package from nuget.

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>

Add dependency to .NET Analyzer project

I've created a .NET project of type Analyzer with Code Fix (.NET Standard) in Visual Studio 2017. The analyzer created by this project type could be deployed as either a NuGet package or a VSIX extension. I used the Generate NuGet Package on Build setting in project properties and it works very smoothly and without any problem.
The thing is, now I want to add some dependencies to the created NuGet package. I know that this is possible through a .nuspec file for other situations. But in this project type, VS creates the NuGet package in bin folders and there is no .nuspec file whatsoever.
So how can I add dependencies to the created NuGet package in the above scenario?

In Visual Studio 2017 using the new .csproj format, the NuGet dependencies are automatically copied into the NuGet package based on the .csproj file's PackageReferences.
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFrameworks>netstandard1.3;net45</TargetFrameworks>
<DefineConstants Condition=" '$(TargetFramework)' == 'netstandard1.3' ">$(DefineConstants);LIBLOG_PORTABLE</DefineConstants>
</PropertyGroup>
<ItemGroup Condition=" '$(TargetFramework)' == 'netstandard1.3' ">
<!-- /* Package references for .NET Standard 1.3 */ -->
<PackageReference Include="Microsoft.CSharp" Version="4.4.0" />
<PackageReference Include="System.IO.MemoryMappedFiles" Version="4.3.0" />
<PackageReference Include="System.Resources.ResourceManager" Version="4.3.0" />
<PackageReference Include="System.Reflection.TypeExtensions" Version="4.4.0" />
<PackageReference Include="System.Runtime" Version="4.3.0" />
<PackageReference Include="System.Threading.Thread" Version="4.3.0" />
</ItemGroup>
</Project>
So the only thing extra you need to do is add those dependencies from NuGet to your project. This can be done either by
Manually editing the project file (Right-click the project in Solution Explorer and choose Edit <projectName>.csproj)
Installing the NuGet package via NuGet Package Manager
Changing Dependencies by Updating a .nupkg File
Alternatively, since a .nupkg file is just a .zip file with a different extension, you can change its contents:
Unzip it with a standard zip utility to a temporary directory
In the temporary directory, modify the contents of its .nuspec file, adding additional dependencies as appropriate
Zip the contents of the temporary directory again
Rename the new .zip file, giving it the extension .nupkg