Recently, I got a chance to explore Microsoft Visual Studio 2010 more seriously and found some changes very surprising. Some changes have been documented well but some are very tricky to find out. Like, they have moved setting up the headers/lib/executable from solution scope to project scope and if someone try to change these things, it clearly says to do it from project level.
Also, if user wants to change the default SDK (VS2010 comes with Windows SDK 7.1/7.0A) to any other version, user really don't have any option. The only way to do this is to replace the reference wherever it's been used with the new sdk path in the project scope (Include, exclude directory, library). I found it hard to change the default SDK path as my project required latest SDK reference (Windows SDK 8.0).
With VS2010, programmer can target any framework from 2.0 to 4.0 to write code. The default framework is 4.0. If someone tries to write code say, targeting .NET Framework 3.5, it will work fine. The real problem arises at build time if the platform toolset is not selected as v100 (default with VS2010). The build fails with unusual/rarely seen errors. I saw an error like cl.exe not found. The solution to these types of error is to try installing other version of Visual Studio Version. As, the toolset get installed as part of Visual Studio installation and not as part of framework. In my case, for setting the platform toolset as v90 (for other Visual Studio Version), VS2008 has to be installed. This resulted in build being successful with VS2010.
VS2010 has many new things and made programmer life easier. But, solving these challenges, which I faced when using VS2010 to change the Target Framework of my project to 3.5 made me think. These things should have been taken care well, for the backward compatibility to make it more useful.