We have a large project at work, under source control, including an MSBuild file to run the build. Recently, the build has stopped working on my machine (I get errors saying that ‘zzz’ is ambiguous in the namespace ‘yyy’). The same MSBuild file is working fine on both the build server and my co-workers machines.
I have tried cloning a new copy of the project from the shared repository, but even with a clean copy, the build is failing for me. I think it must be a problem with the MSBuild settings on my machine, but I haven’t been able to find anything that tells me where they are. Any help would be appreciated, since I’m starting to think my machine has just gone crazy.
So, after a lot of hair pulling, I found both the solution to my problem, and the answer to my question.
MSBuild stores it’s default options in a set of .rsp files and the .targets files found in the base directory of MSBuild. In my case, this was C:\Windows\Microsoft .NET\Framework\v3.5. The trick is that the options are stored separately for the 32-bit version of MSBuild and the 64-bit version (C:\Windows\Microsoft .NET\Framework64\v3.5. Our build required modifying the default visual basic targets file, which took care of the ambiguous reference call I was getting.
My problem happened because something modified my system path to point to Framework64 instead of Framework. Since my custom .targets file was only applied to the 32-bit version of MSBuild, the ambiguous reference wasn’t being resolved correctly. Unfortunately, there isn’t a visual difference between running the 64-bit version of MSBuild and running the 32-bit version of MSBuild. When I corrected my system path, everything started working again.