Does not warn about direct references already included transitively

[janthomasQS]

Imagine we have the following dependency structure with ProjectReference:

graph TD;
    Executable-->DeepLibrary;
    Executable-->MiddleLibrary;
    MiddleLibrary-->DeepLibrary;

Loading

If Executable uses code from DeepLibrary then the ProjectReference from Executable to DeepLibrary is unneccesarry as long as one does not define <DisableTransitiveProjectReferences>true</DisableTransitiveProjectReferences>

Would detecting these sorts of scenarios be possible?

[dfederm]

I would consider that not unnecessary if Executable directly uses DeepLibrary.

Otherwise, if MiddleLibrary ever decided to decouple from DeepLibrary, it would break downstream projects. In this 3 project example that's pretty trivial, but you can see how in large repos this would cause quite a maintenance nightmare.

Best practice is that projects should depend on things they directly depend on, and transitivity allows for implementation details of the dependencies to be abstracted away. But if a project happens to share a dependency with one of its dependencies, it's best that it be declared as the direct dependency that it is.

[janthomasQS]

I see your point about maintainability when used projects are not referenced directly.
But if someone wanted to make sure this practice is followed i would argue they should define <DisableTransitiveProjectReferences>true</DisableTransitiveProjectReferences>. In that case this project should also not warn about these references because removing them would lead to compiler errors anyways.

When transitive project references are enabled then the user supposedly wants this behaviour that he can access classes of transitively included projects and in that case a direct reference is unneeded.