About half a year ago I started experimenting with VS2012. It was not a smooth migration by any means, and I finally got around to recording online some of the lessons I learnt along the way.

One of the first things that greeted me was a slew of weird and uninformative error messages, whenever a build was tried: ‘The project ” has been renamed’ on sln build, ‘a build is already in progress’ on individual project build, and ‘Object reference not set to an instance of an object’ – well, just occasionally.

Others come across similar issues as well, but I believe more can be said than what was already noted. Bottom line, the issue is with native references to projects not contained in the current solution.

VS2010 did agree to try and build with such external references, and if a binary copy of them was available where VS2010 could find it – either the build would succeed or fail with surprising errors (e.g., due to debug/release version mismatch). VS2012 refuses to try and build in such a case, which is a very good thing. I only wish the error messages were more informative.

Moreover, VS2010 didn’t show the external references in the references tab. Not only does VS2012 show the missing projects, it (probably unintentionally) makes it easy to distinguish them by displaying them as the explicit path (as stored in the referencing vcxproj file), and not the referenced project name:

Thus, the solution to these error messages is to just scan the solution’s projects’ references , find the missing ones by looking for vcxproj suffixes, and either remove them (if they are redundant) or add them to the solution. If your solution is very large, it might be faster to isolate the offending projects by unloading part – say, half – of the projects at a time, and see if a build attempt still raises errors.

I really wish the reference UI (and dare I say, even the underlying mechanism) for native projects was as clear as for managed projects. But guess we’ll have to do with such hacks for now.