Disable Transitive Project Reference in .Net Standard 2

Disable transitive project reference in .NET Standard 2

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>

Where isn't the transitive dependencies of my .Net Standard library copied into the executing assembly?

I believe when you initially said "recursive" you really meant "transitive" (as per your recent edit).

.NET, and .NET framework in particular doesn't really handle transitive references. It, as you have found, requires all dependencies to be explicitly referenced by the executing projects. An "implicit" reference isn't going to happen.

There seems to be better support for pulling in transitive dependencies in .NET Core, at least if the primary dependency is a Nuget package.

How do I exclude project dependencies in ASP.NET Core?

I figured it out.

In order for Project A to reference B and B to reference C, but A to not reference C, I added PrivateAssets="All" to B's ProjectReference to C, like so:

In B.csproj

<ItemGroup>
  <ProjectReference Include="..\C\C.csproj" PrivateAssets="All" />
</ItemGroup>

This setting makes C's reference private so it only exists within B. Now projects that reference B will no longer also reference C.

Source: https://github.com/dotnet/project-system/issues/2313

Project reference is enabling me to use code from other dependent projects without explicit project reference

If you reference a project that has references to another project, those references will be automatically added. In your case when you have Project A with a reference to Project B, when you reference project A in project C reference to Project B will be automatically added.

If you would like to disable transitive reference behavior you can add PrivateAssets="All" to your reference in the ProjectA.csproj (WebProject)

<ItemGroup>
    <ProjectReference Include="..\ClassLibrary1\ClassLibraryProject.csproj" PrivateAssets="All"/>
</ItemGroup>

Transitive references in .Net Core 1.1

Transitive project-to-project references are a new feature of Visual Studio 2017 and Microsoft.NET.Sdk. This is intentional behavior.

See https://github.com/dotnet/sdk/issues/200.

Problem referencing transitive dependencies when building a specific .NET Core project in TeamCity

I ended up figuring this out, implementing a bit of a hack of a solution.

The problem lies in the fact that I'm referencing .NET Framework projects from a .NET Core project, and attempting to build them all in one step.

The work around required two things:

Firstly, I had to include a NuGet installer build step. I couldn't figure out how to target specifically .NET Framework projects (it doesn't support .NET Core), so I essentially duplicated the solution file, renamed it to NetCoreBuildHelper, and deleted the Web project reference. The reference remained in the original solution. I then referenced the new NetCoreBuildHelper solution in the NuGet Installer.

Secondly, I had to create a .NET Framework MSBuild step, which built the other projects (DataProject and ContractProject), referencing the NetCoreBuildHelper solution.

I'd love to hear responses to this if I could improve the solution, as it feels like a bit of a hack

global usings and .NET Standard 2.0

I'm not sure why it doesn't work with a separated .cs file. However, a workaround that works is using the MSBuild syntax. In your .csproj you can add the following:

  <ItemGroup>
    <Using Include="System.Linq" />
  </ItemGroup>

There are some keywords you can use - like Alias or Static -, as you would do in a normal .cs file.

  <ItemGroup>
    <Using Include="Test.Namespace" Alias="Domain" />
  </ItemGroup>

And then in your code, you can do the following:

namespace Test.Namespace 
{
    public class TestClass {}
}

namespace Another.Namespace
{
    new Domain.TestClass();
}

If it helps, I found this information in the following blog post.

---

Related Topics