VS2010 and MSBuild get different results on combined C++/C# solution

I have a big VS2010 solution, which contains a bunch of C# projects. One of those projects consumes a C++ (native, aka unmanaged) library via P/Invoke. To ensure everything builds correctly, I have included said C++ project in the same solution. Now, thi开发者_Go百科s is where the problems start.

In short: MSBuild mysteriously removes some output files, while VS2010 builds correctly.

.

The long story:

Previously (VS2005/2008), I would have utilized the nifty feature called "Project Dependencies". That's the thing that allows you to pick which particular projects a given project depends on, so that the environment makes sure to build those first.

VS2010, however, has moved in the direction of MSBuild, and now project dependencies just plain don't work. They just don't. (see this question for example) Now, in order to ensure that my C++ project builds before the one consuming it, I have to "Add a Reference". So I've done that. And everything seems fine.

But then, I go to my command line and fire up MSBuild to build that same solution. And everything builds fine, again. But when I look in the output folder, the C++ project's output is not there!

The MSBuild console output clearly shows that the C++ project has really been built at some point. And I even inserted some "dir bin\MYPROJNAME.dll" statements as Post-Build steps into some projects to see if the files are there - and they are! Here is a screenshot of the command-line window. Circled in red is the moment of files being there (at the top), and then the moment of files missing (at the bottom).

Another weird thing is that the project, apparently, gets built twice. See the red underline in the screenshot - this is the second message about building that same project (the first message, along with all compiler output, was way up the screen).

It really looks like this second building event is what causes the files to be removed: when I disabled building this project at all (through solution properties), it only got built one time, and the files were there in the end. I could have called this a "solution", but then it breaks in the Visual Studio itself: the VS just doesn't build the project.

Another way to fix this is to remove the "Project Reference" from the consuming C# project. Then MSBuild will only build the C++ project once, and the files will be there. But then it breaks in yet another place: changes to the C++ project would not trigger a rebuild of the consuming C# project.

So the question is: how do I make MSBuild not remove the freaking files?

Short (a bit of a hack) answer to the question:

You had the dir in the PostBuildEvents. If you add an attrib +r it will not remove your files:

<Exec Command="attrib +r $(TargetPath)"/>

(Where TargetPath should be the dll files...)

It sounds like you have 2 projects, both dependent on a third. If this isn't true, then you can ignore this whole anwser :)

Because the compiler is threaded, you need to make sure those 2 projects don't try to build before the third is done.

So projectA and projectB both have a dependent build, projectC. projectA starts, sees the output for projectC isn't there and calls Rebuild. While it is building, another compile thread comes along, and it starts to build projectB. It doesn't see the output of projectC(it hasn't finished building yet) so it calls Rebuild, cleaning the project again. Dependent builds are checked at the start of the project, not when they are needed. So if projectB has 4 other projects it has to build before it gets to projectC in it's dependency chain, it might take a while before this second Rebuild is called on projectC.

There are a few ways to solve it.

1. Try to resolve your dependent builds so that projectA relies on projectC. This might not be ideal of course.

2. I think VS2010 still has build order, so you can set which order projects are built in. Not just dependencies. Make sure projectC is listed before both projectA and projectB.

3. The easiest would be to make 2 calls to build. First call msbuild <project> /target:Clean then call msbuild <project> /target:Build not Rebuild, just Build. That way both projectA and projectB see the output of projectC and don't try to build it.

Finding out what is causing it to get built the first time is probably the way to go. Something is triggering that first build early on even if you remove the reference to it. Can you post the full msbuild log with /v:diag? The portion you posted started just after the section I was interested in :)

Make sure you are building for the right configuration and platform. If you don't specify a platform, it will build with no platform, which is a kind of a Mixed platform depending on how the msbuild file is constructed. Visual studio always build with the platform specified in the UI, that might be why it's different from the command line.

If you don't find a solution, maybe a workaround that would work is to create a property based condition that removes whatever is causing the problem in command line (such as building the project twice) and setting the property with /p: from command line.

Solution: use a different intermediate directory for each project