All abstractions are leaky. Visual Studio and its associated files are meant to act as helpers and thus abstract away several details of the project, what it do

All abstractions are leaky. Visual Studio and its associated files are meant to act as helpers and thus abstract away several details of the project, what it does with them but there's still a process to it all. Project files are like build scripts and changing them can cause breaks. Just like wanton changes in a build script can do the same. If you proceed working with VS, I'd suggest familiarizing yourself with project files and how they're set up. All automated processes make assumptions and rely on certain conventions. I've yet to meet an automated process that can adapt itself to any situation to suit its user's whims. For new developers I generally recommend they review all changes they commit, including project files. Just because its an abstraction or things happen automatically doesn't mean you can just push all changes into the repository. When you open a 2008 project in 2010 you are prompted that changes will take place for example, so it's not like it was a stealth change. Once they're properly set up project files are pretty maintenance free, but certain behaviors can make them unstable to use. For example, if you need to support both VS2008 and VS2010, just create duplicates, it's no different than having build scripts that are not backwards compatible, you'll have to keep multiple versions around. Or just keep the VS2010 conversion locally and don't commit that back into the repository. Anyways, you can go back to a simple text editor and just use msbuild manually, if you prefer keeping track of everything manually. best of luck!