Why do project dependencies become project references?

Sometimes you want certain projects to be built before others in a solution, even if there shouldn’t be a project reference between them. An example might be a test project that uses artifacts produced by the build of another project, yet it does not contain a direct project reference to it.

If you right-click on the test project (say) to tweak the Project Build Order...:

you are instructed to use the Project Dependencies tab to modify the build order:

And easy enough, you can just check the project you want to build before the current project:

There is, however, a “slight” side-effect of doing this. When building from MSBuild, here’s the relevant build log before checking that little checkbox:

and this is what it looks like after:

Yes, that’s a proper Project Reference that’s been added for the project dependency you declared in the IDE.

NOTE: this project reference is only added automatically when building from MSBuild. Visual Studio already determines the build order itself so it won’t be added for IDE builds by default.

When you think about it, it sort of makes sense: how would MSBuild know to build the given projects in the right order? Its only mechanism to affect the build order is indeed project references. But this might have unintended consequences in certain cases (i.e. bringing in dependencies that you didn’t intend, for example).

If your build scripts already take care of building the dependent project at the right time, you can easily turn off this behavior by adding the following property to the project that declares the dependency (i.e. the test project):

<PropertyGroup>
    <AddSyntheticProjectReferencesForSolutionDependencies>false</AddSyntheticProjectReferencesForSolutionDependencies>
</PropertyGroup>

This property comes from the Microsoft.Common targets which are always an interesting way of learning more about your builds.

Happy MSBuilding!