MSBuild fails to build C++/CLI friend assemblies

Question

I have Visual Studio 2008 SP1, two C++/CLI projects, lets say proj1 and proj2. proj2 is dependent on proj1, but in a weird way (see below). In Project Dependencies I specify that proj2 depends on proj1. Also proj2 references include proj1. Then I want proj1 to be a friend to proj2, so, as MSDN page on "Friend Assemblies" says, I write somewhere in proj2 this code:

#using "proj1.dll" as_friend.

Compiling says that proj1.dll already referenced, and that I should remove project reference from proj2 project settings (thus removing /FU flag).

Here comes the bug(?): If I remove proj1 reference from proj2, but still specify in solution Project Dependencies that proj2 depends on proj1, everything compiles ok in VS2008. But MSBUILD parses project references, creates new temporary project for the proj2, ADDS /FU:proj1.dll and BUILD FAILS!

Question 1: is there a way to disable this MSBuild behavior?

Then, if I remove dependency in Project Dependencies, MSBuild builds fine, but Visual Studio tries to compile proj1 and proj2 in parallel, and fails, because proj2 is much smaller and compiles first... Setting max parallel builds option in Project and Solutions/Build and Run helps, but I have to do it on every developer machine, I can't save this setting in the solution, this makes build slower etc...

Question 2: is there a way to make "Project Dependencies" a conditional option? I want it on for VS2008 and of for MSBuild...

Answer 1

If ProjA depends on ProjB and ProjB depends on ProjA then I am surprised you can build it at all! This sort of circular build dependency normally kills clean builds. You often get away with it on dev machines where an old ProjA is still lying around when you build ProjB and vise-vera. But on a clean machine (build server), then this kind of dependency often breaks things.

Depending what the dependencies are, it might be simplest to move the common dependencies to a new assembly ProjC, that has no dependencioes of its own, but which both ProjA and ProjB depend on. This means you can then build ProjC, then ProjA and ProjB in any order afterwards. This kind of refactoring is often simplest when you are only depending on interfaces from ProjC rather than concrete classes.

Not sure this entirely answers your question, but it might give you an alternative way to fixing it.

Colin

Answer 2

As the OP has already found out, this is actually a bug. A bug was filed by the OP and acknowledged by Microsoft. It appears to affect VS2005, VS2008 and VS2010 (targeting VS2008).

The workaround that I used was a dummy intermediate project to "buffer" the references between the 2 dependent projects.