I have the following scenario of project references in a C# solution, such that:

• Project A references Project B
• Project A references Project C
• Project B references Project C

This solution compiles fine.

Now I remove the reference from Project A to Project C and it still compiles! It's like Project A is indirectly referencing Project C though Project B, i.e.:

• Project A references Project B
• Project B references Project C

Is that how project referencing works? Now in Project A I can mysteriously use classes etc from Project C indirectly through Project B.

I'm developing with Visual Studio 2022 on Windows 11 with projects targeting .Net Framework 4.7.2

This isn't just a case of weirdly working on a local machine, as the same solution also compiles as part of a Jenkins CI/CD pipeline.

I have the following scenario of project references in a C# solution, such that:

• Project A references Project B
• Project A references Project C
• Project B references Project C

This solution compiles fine.

Now I remove the reference from Project A to Project C and it still compiles! It's like Project A is indirectly referencing Project C though Project B, i.e.:

• Project A references Project B
• Project B references Project C

Is that how project referencing works? Now in Project A I can mysteriously use classes etc from Project C indirectly through Project B.

I'm developing with Visual Studio 2022 on Windows 11 with projects targeting .Net Framework 4.7.2

This isn't just a case of weirdly working on a local machine, as the same solution also compiles as part of a Jenkins CI/CD pipeline.

• c#
• windows
• visual-studio

• 8 Yes, references (both project and package) are transitive. – Jon Skeet Commented 2 days ago
• 2 Doesn't it have to? If A uses a class of B and B returns an object from C, then A knows C, even if it didn't know C before. – Thomas Weller Commented 2 days ago
• 1 That's the behavior I'd expect from the C#/.Net eco system. Just imagine some projects' dll hell without that. – Fildor Commented 2 days ago
• 1 Do you take into account that A may actually not depend on C? :-) – Sergey A Kryukov Commented 2 days ago
• 2 Note that you can turn off this behaviour using PrivateAssets="All" on the ProjectReference, see here – canton7 Commented 2 days ago

1 Answer 1

This is expected - the terminology is that "C is a transitive dependency of A".

It can be logically broken down like this:

1. If project B references - i.e., includes the code of - project C...
2. And project A references/includes the code of project B...
3. Then project A must also include the code from project C.

If, for some reason, you want A to be unable to see C, you can set PrivateAssets to "all" while declaring B's dependency on C - see docs.

<ItemGroup>
    <!-- ... -->

    <ProjectReference Include="C.csproj">
        <PrivateAssets>all</PrivateAssets>
    </ProjectReference>

    <!-- ... -->
</ItemGroup>