.NET Framework versioning, or The impact of switching from Visual Studio 2005 to 2008
With the official release of Visual Studio 2008 coming closer and its release on MSDN last november, there are more and more people asking what the impact of migrating from VS2005 to VS2008 will be and if it will have as big an impact as switching from VS2003 to VS2005 had. The answer is pretty simple: no it won't. Let's see why, and what impact it will have.
VS2003 > VS2005
VS2003 was the development environment for developing applications based on version 1.1 of the .NET framework. With this came a CLR specific to that version of the .NET framework (version 1.1.4322). When Visual Studio 2005 was released, the .NET framework 2.0 came with it. Because of several architectural changes, like for instance Generics, this version of the framework got it's own CLR too (version 2.0.50727.42). Knowing this, it is logical that taking an application that was built for version 1.1 of the framework (and CLR) would have to be modified to be able to run on the new version 2.0.
VS2005 > VS2008
VS2008 is the first member of the Visual Studio family that enables multi-targeting. You can have an application target the 2.0, 3.0 or 3.5 version of the .NET framework. That is pretty different from VS2002 (.NET 1.0) and VS2003 (.NET 1.1) that were bound to their specific versions of the .NET framework. The reason it can do that is the same reason switching from VS2005 to VS2008 will not be too hard: these versions of the .NET framework all use the same version of the CLR (version 2.0.50727.42). Although version 3.5 installs Service Pack 1 for .NET 2.0, which adds some methods and properties required for features like LINQ, these changes do not affect applications written for version 2.0 of the .NET Framework.
Switching to Visual Studio 2008 will not require you to recode parts of your application, but it does have some implications to switch. VS2008 changes your .sln file, rendering it unreadable for VS2005. The projectfiles however are not touched, or at least not in such a way that VS2005 won't understand them.* The odd one out here is the Web Application Project, which might give some trouble in a multi-VS-development-environment. Have a look at this post at Steven Harman's blog to see how to work around that.
Working on a .NET 2.0 project from VS2008 does give you quite some extras, next to the fact that the IDE itself has been greatly improved.** A nice example is from someone who posted this question on the MSDN forums:
(..) while creating properties when I used the code-snippet (...), to my surprise VS 2008 created automatic property. (...) I double-checked the target version by opening project properties and it still showed .NET Framework 2.0. I used this new class in the web page, and it worked fine. How is this possible? Is there a bug in VS 2008 and this code will fail if deployed in production where only .NET 2.0 is available, or did I do something wrong?
The thing here is that automatic properties are not so much a feature of the .NET framework, but of the compiler. So go switch to VS2008, and enjoy.
* TIP: If you need to edit a .NET 2.0 solution from both VS2008 and VS2005, create two different solutions, one for both. This way, you will be able to open the solution from both versions of Visual Studio. Do be advised! When working in VS2008, you might be tempted to use new syntax that won't work in VS2005. ;)
** Found a cool new feature or a nice improvement in Visual Studio 2008? Add it to my list @ Listas!