Further Thoughts on Adopting .NET Framework 3.5 and VS 2008
In my current role as .NET technology consultant I am trying to do all the pre-work required to get the .NET Framework 3.5 and VS 2008 adopted as the .NET development standard for our company going forward. Here are some useful resources that I have come across that I would like to share with other teams that need to do the same thing in their corporate environments.
Coding Standards
Our existing coding standards is based on C# 2.0 and Visual Studio 2005. I have now updated it to include support for C# 3.0 and Visual Studio 2008. I used the following resources:
- IDesign C# Coding Standard: Guidelines and Best Practices Version 2.32 - The IDesign folks have updated their coding standard to support the new C# 3.0 language features. If you have no coding standard at all
, this is an excellent document to use as reference. Also be sure to check out their WCF Coding Standards. - Extension Methods Best Practices - Even though we only use C#, I came across this excellent post by The VBTeam that nicely summarizes extension method best practices.
My changes included adding some formatting standards for Lambda expressions and LINQ queries; a recommendation for the use of automatic properties for simple properties and a section on the best practices for making use of extension methods.
VS 2008
There has been a lot of improvements to the Visual Studio 2008 IDE. One of my favourite features is the new multi-targeting support that allows teams to use VS 2008 but still target the .NET Framework 2.0 as deployment platform.
Moving onto VS 2008 gives a team all the benefits like improved compile times, better performance analysis, improved code metrics and code analysis etc. It also positions a team better to take future advantage of the new C# Language and .NET Framework improvements. As the VS 2008 project file format is backwards compatible with VS 2005, it leaves a team with a fallback position should anything drastically go wrong with VS 2008.
However, when making the move, please take the following into account:
- The VS 2008 .sln file format is not compatible with the VS 2005 .sln file. You will therefore have to create a separate .sln file to support VS 2005 development. This is typically a 5-minute exercise.
- If you are only targeting .NET 2.0, install only VS 2005 on your build server to catch out the scenarios where somebody has inadvertently started using some of the new language features. A concern I have here is that installing VS 2008 will also install .NET 2.0 SP1. You may therefore run into scenarios where things work in your local VS 2008 developer sandbox but not on the build server. Highly unlikely, but still something to consider. I haven't checked, but do you have to install .NET 3.5 on the server just to get NET 2.0 SP1 or is it available as a separate download? I don't like the idea of making .NET 3.5 a pre-requisite just to get .NET 2.0 SP1 installed.
- Ensure that all your existing add-ins and control libraries have been upgraded to run in VS 2008. See the tips for using ReSharper.
- If you are using Visual SourceSafe 2005 together with Visual Studio 2008, there seems to be a minor glitch that can be corrected by following the steps detailed in this blog post. The problem does not seem to apply to Visual SourceSafe 6.0d as it works fine against VS 2008.
Hope you find the information useful! 