No DisableTransitiveProjectReferences analog for package references?

Issue #1750 introduced the <DisableTransitiveProjectReferences> property so that an SDK-style csproj project can opt out of the new implicit transitive references feature. Originally, the proposed name for the property was <DisableImplicitTransitiveReferences>; however, during Pull Request #1751, the name was changed to DisableTransitiveProjectReferences to explicitly indicate that only project references would exhibit a behavior change; package references would not be impacted by setting this property.

(My understanding of the meanings of these phrases is as follows: package reference refers to NuGet package references, while project reference refers to a reference to another project in the same solution.)

There doesn’t seem to be a mechanism to disable the transitive reference behavior for package dependencies. This makes it so that, for example, if Project A has a project reference to Project B, and Project B has a package reference to ex. Newtonsoft.Json, Project A can utilize Newtonsoft.Json without explicitly adding a package reference to it. When PrivateAssets is used, Project B’s dependency on Newtonsoft.Json fails at runtime when called from Project A, because Newtonsoft.Json.dll is not copied to the output directory of Project A. (I’m just using Newtonsoft.Json as an example here because it’s well-known and has no external dependencies when used with recent Framework/Core/Standard TFMs - this issue applies to any NuGet package dependency.)

What is the motivation for this behavior? Could an analogous property be added (named like <DisableTransitivePackageReferences>) so that in situations like the one described above, Project A would not be able to utilize Newtonsoft.Json without explicitly adding a package reference, but Project A could still utilize Project B (which relies on the dependency directly) without encountering runtime errors due to missing assemblies?

[mdrexel]

Because if you don’t get them copied in the output folder, you’d run into runtime problems.

That is the behavior that I encountered when using PrivateAssets - if Project A references Package X, and Project B references Project A, when Project B is compiled, Package X was not copied to the output directory. This then caused runtime errors.

When I say “use”, I mean whatever controls which packages are allowed to be referenced by code in a given project (barring the use of reflection or other tricks). I would like a setting like DisableTransitivePackageReferences to raise a CS0246 error when using a transitively referenced package.

Here is a small code example. I have a project named ProjectA. ProjectA.csproj includes a reference that looks like:

<ItemGroup>
  <PackageReference Include="Newtonsoft.Json" Version="12.0.3"/>
</ItemGroup>

In ProjectA, I have a class that looks like:

public class Example
{
    public static string Serialize(object value)
    {
        return JsonConvert.SerializeObject(value, Formatting.Indented);
    }
}

I have a different project named ProjectB. ProjectB.csproj includes a project reference that looks like:

<ItemGroup>
  <ProjectReference Include="..\ProjectA\ProjectA.csproj" />
</ItemGroup>

In ProjectB, I have a class that looks like:

using System;
using System.Collections.Generic;
using ProjectA;

namespace ProjectB
{
    public class Program
    {
        public static void Main(string[] args)
        {
            Console.WriteLine(Example.Serialize(new Dictionary<string, string>() { ["Hello"] = "World" }));
            Console.ReadLine();
        }
    }
}

Right now, there is nothing stopping me from writing something like this in ProjectB:

using System;
using System.Collections.Generic;
using ProjectA;
using Newtonsoft; // ProjectB transitively references Newtonsoft through ProjectA

If I go back to ProjectA.csproj and change my reference to look like:

<ItemGroup>
  <PackageReference Include="Newtonsoft.Json" Version="12.0.3">
    <PrivateAssets>all</PrivateAssets>
  </PackageReference>
</ItemGroup>

Now, trying to write using Newtonsoft; in ProjectB raises a CS0246 error, which is good. But, trying to run ProjectB results in: This is because the Newtonsoft assembly was not copied to the output directory of ProjectB.

[znakeeye]

Now it’s been two years. Come on guys! This one is super important!

The DisableTransitiveProjectReferences setting is simply great! 👍 It allows you to almost disable the new, rookie-developer friendly way of declaring dependencies. For a plugin based app, we had a team of .NET masters who spent weeks on version conflicts that could only be fixed by setting this flag. So far so good.

Now, we see that transitive nuget packages are not covered by this setting. Woah, a ticking bomb for sure. To begin with, we cannot easily see (e.g. search in .csproj) where unwanted nuget packages are being referenced. (Sorry, I just discovered this glitch and I already have a headache…)

DisableTransitivePackageReferences to the rescue? Please give us the DisableTransitivePackageReferences setting yesterday! It will serve .NET 6 developers well.