Yes. 700 of them in fact, from VS2008 to VS2010, a couple of years ago. Here's what I found...
- VS2010's macro system is just broken, and fails to coexist with VS2008. Basic macros using the DTE object work; more sophisticated ones (I have a few that used DTE90 - or was it DTE80? - anyway, whatever, they manipulated project properties) seemed to be literally impossible to make work, due to some kind of conflict between system-global components that both try to install. Pretty shameful.
- VS2010+ craps massive files into your solution folder, worse even than the NCB palaver, and so your more junior and/or inept programmers will keep checking that junk into source control.
- It's common in VS2008 to change the build product name by going to the Linker or Librarian property page and just changing that Output File property. VS2010 doesn't like this, though, due to some MSBuild limitation, and would much prefer you to modify the settings in the General page, leaving the output file name as its default of something like "$(OutputFolder)$(OutputName)$(OutputExt)". Of course, the project upgrade doesn't actually do anything about this for you, so after importing all your projects that work the old way way, they won't work properly, and you have to fix each one up yourself.
- VS2010 dependencies aren't like VS2008 dependencies. There's a new C#-style References section that manages the linking. Dependencies can still be set, but they only affect build order. (Also - when you change dependencies, you need to close and restart Visual Studio, because sometimes they don't take effect properly.)
- The new C#-style references are part of the project, not part of the solution, so they come with the project when you add it into a solution. Add a project but forget its references and you just get a cryptic error (along the lines of "Project has no Debug|Win32 configuration") when you try to build; to add insult to injury, when you go to the References page, the missing reference is not actually shown, because (of course...) it's not in the solution. You need to open the vcxproj in a text editor and look at its contents and compare it to the references VS2010 shows you to work out which is missing.
- When a project refers to a non-existent file, the project will be considered permanently out of date. VS2010 won't give you any clue about what's wrong, and to track the problem down you (as I recall...) have to change some random setting in a file you've never heard about, which gets MSBuild printing stuff out via fucking OutputDebugString, leaving you to scrape through its (unreadable) output with DbgView until you find the magic message that hints at the file in question. (The link I have in my notes is http://blogs.msdn.com/b/vsproject/archive/2009/07/21/enable-...)
- If a solution refers to a non-existent project configuration, you get a cryptic "The parameter is incorrect" error when trying to build, with no clue as to what's wrong.
- If you happen to open one of the built-in MSBuild files in the text editor, which can easily happen if you click on the wrong warning, all hell breaks loose and MSBuild starts to spew warnings everywhere each time you build.
This excludes a few vendor-specific issues I had, with my favourite (I think...) being the plugin that would instantly terminate Visual Studio if you used the phrase "%(ProjectFilename)" (instead of "%(ProjectFileName)") in your build output paths.
Needless to say, after this dreadful experience - and I have to say that if you have never embarked on an endeavour such as this, you probably won't (as I didn't) appreciate just how long it can take, and how time-consuming it can be to track down and fix all these issues ocurring in all these opaque black boxes - I swore off VS2010 completely. And to this day, I have yet to use it in anger.