Summary
I’m having a very strange behavior with Visual Studio 2010, and I’m not sure if it is a bug or if there is some twisted logic to why it is behaving in this way.
The executive summary is that when I use Batch Build->Select All->Rebuild to build all the configurations for all my projects, VS2010 produces differing output binaries depending on what is the currently selected Solution Configuration. This is really annoying because some of the project outputs fail to run correctly (giving a “[Project name] has stopped working” error dialog on startup) depending on which Solution configuration was selected during the batch build.
More details
I have a Solution with 3 C# projects in it (1 .dll outputting project, referenced by the other 2 .exe outputting projects). Of the .exe outputting projects, Project A has Release and Debug Project configurations. Project B has a Debug, Release-x86, and Release-x64 configuration because it needs some different post-build scripts run to give it the correct version 3rd party libraries.
I have 4 Solution Configurations: Debug, Release, Release-x86, and Release-x64. Release-x86 and -x64 are set to build only Project B. Release and Debug build Project A and the shared dll project.
If I select the Debug Solution configuration from the current configuration drop-down box, and the Batch Build all, then when I try to run the Release configuration of Project A it fails to run. If I select any other Solution configuration from the drop down, and then Batch Build all, then it runs successfully. When I diff the produced .exe file, I can see that it is different between these two cases.
Question
Is this some known intended behavior of VS2010? If so, can someone give a hint as to why this problem may be occurring and how I can fix it? Is this a bug in VS2010?
Follow-Up Clue? [Edit]
Could this have something to do with how VS2010 handles “Project references”? As I mentioned, both .exe projects reference the dll Project, call it Project D. I added that reference (to Project A, say) by selecting Add Reference -> Project -> Project D. But of course the different configurations of Project A want to use different configurations versions of Project D. When I examine the Project A -> Project D reference under Properties, I see a Path field that is not editable. Depending on which Solution configuration is selected, I either see ...\Project D\bin\Release\Project D.dll or ``...\Project D\bin\Debug\Project D.dll, and I don’t see any way to control this so I guess VS2010 is trying to be smart about picking the details of Project configurations. But even more strangely, if I select Batch Build -> Select All -> Clean to remove all compiled files, than these reference paths change to ...\obj\... instead of ...\bin\... when I inspect them, and I can’t seem to change them back except by removing and re-adding the project reference.
Follow-Up 2 [Edit2]
I lied a little bit earlier, I actually have 2 .dll projects (Projects D and E, say) where D references E through a project reference.
I’m pretty sure something broken or bizarre with Project References in VS2010 is the culprit, and think I have found the root cause of the selected-Solution-Configuration-dependent behavior, with the following steps
1) I Batch Build -> Select All -> Clean, to remove all previously compiled binaries.
2) I select a Debug Solution Configuration from the drop-down.
3) I Batch Build -> Select Only Project A Release -> Rebuild.
By watching the Output window, I see that VS2010 knows that Project A depends on D, and D depends on E, so it attempts to build them in reverse order. It successfully builds the Release configuration of project E. But then it tries and fails to build the Release configuration of project D, because it complains about missing the missing Debug version of E dll file. And likewise A fails to build because of the absence of the Debug version of D.
So it seems that the selection Solution Configuration is overriding the configuration of referenced projects in Project to Project references.
Is that supposed to be the case???
After some further searching, I’ve found that this is a known bug in VS2010, marked as “Wont Fix” by Microsoft. Batch Build in VS2010 is simply broken. If you think that’s as dumb as I do, go ahead and express yourself to them.
https://connect.microsoft.com/VisualStudio/feedback/details/556158/batch-build-links-to-wrong-referenced-projects