Project dependencies between C # and C ++ project, build order

Question

If both Alpha and project Beta projects are C # projects, we can establish that Beta depends on Alpha , and this leads to the following build order: 1) Alpha ; 2) Beta

If the Alpha project is a C ++ project, we cannot add the link from the Alpha project to Beta , because Visual Studio 2010 does not allow this. In fact, we can crack the csproj file with a notebook, but this does not help. Bu we can right-click on the solution, select Project Dependencies and say that Beta depends on Alpha .

Problem: MSBuild does not evaluate the dependencies installed in the sln file and builds projects in the wrong order - 1) Beta ; 2) Alpha . Note that Visual Studio marks the build order.

How can we set the build order for MSBuild between C# and C++ projects within the same solution?

Answer 1

Try adding a link to a C ++ project to a C # project after clearing the solution. This works for me, although I accidentally stumbled upon this “workaround”.

It seems to me that Visual Studio is checking the build product of the mentioned project, and when it notices the incompatibility, it will refuse to add the link. If, however, the build product does not validate (since you cleared the solution), Visual Studio is happy to add the link.

I tested the resulting solution both in Visual Studio and on our TFS build server (in which AFAIK uses MSBuild ), and in both cases the build dependencies were evaluated correctly.

In your question, you also note that manually editing the .csproj file .csproj not help. I can’t confirm this. I was able to add the following link and again got a positive build result:

 <ProjectReference Include="..\Foo\Foo.vcxproj"> <Name>Foo</Name> <ReferenceOutputAssembly>false</ReferenceOutputAssembly> <Private>False</Private> </ProjectReference> 

I am adding a ReferenceOutputAssembly element because this blogs.msdn.com article offers this. However, in my experience, assembly also works without an element. The article is still worth reading because it explains why MSBuild does not comply with the dependencies defined in the solution.

For completeness: I am running Visual Studio 2010, Version 10.0.40219.1 SP1Rel .