.NET 1.1 to 2.0 Upgrade Post-Mortem
A while back we upgraded from .NET Framework 1.1 to 2.0 on one of our large projects and we have been developing on .NET 2.0 for the last couple of months. This upgrade was a success as we met our objective within the allocated budget and timeframe. I am going to share our experience as it may help other people who are considering upgrading from .NET 1.1 to 2.0.
Our application is a rich client (WinForms) solution that interacts with middle-tier via Web Services and is fairly large (more than 250 Visual Studio projects including unit tests) and has a 70% VB.NET / 30% C# code-base.
Our primary justification for the upgrade was saving in development effort and costs. We looked at the project plan and identified those tasks that would require less effort if we upgraded to .NET 2.0. These tasks were primarily related to enhancing the application framework (menus, transaction/session management, configuration management, etc) and as you may know many of these features are built into the .NET Framework 2.0. We then subtracted the estimated effort required for the upgrade process. This included the time required for the conversion process, non-productive time if developers had to stop development for a short period of time as well as any productivity loss across the team as they were switching to a different environment (VS2005). Since we have around 50 developers on the team, we would lose one man-day for each 10 minutes of non-productive time so we had to make sure the impact on the development team is minimised.
We planned a process where four developers were responsible for converting the projects from Visual Studio .NET 2003 to Visual Studio 2005 format and making necessary changes to the code and the automated build process while other developers carried on their development on .NET 1.1. How? Well, when you convert a project using Visual Studio 2005's conversion wizard, most of the changes are applied to the project and solution files not the source code files (Typed DataSets are an exception - .designer.cs/vb files replace the .cs/vb files). So all we had to do was to ask the rest of the team not to have any project/solution files checked out during the conversion process.
We communicated the plan to all team members and four developers started the conversion process on a Friday morning while other developers carried on as normal (with one limitation that they could not change any project/solution files through the day). We continued the conversion process on Saturday (with 3 resources) and had our first .NET 2.0 successful build on Saturday afternoon. Sunday was dedicated to testing the application to make sure the functionality of the application had not been adversely affected by the upgrade.
On Monday morning, developers started to use Visual Studio 2005 after getting the latest version from the source control and spent the rest of the day on getting familiar with the new environment and addressing any minor issues they could find.
The interesting point is that the conversion process was hassle-free in terms of code and binary compatibility between .NET 1.1 and 2.0 (a big thank you to the CLR team at Microsoft!). Before starting the upgrade, we tested the third-party controls (all compiled against 1.1) we were using to make sure they work fine when run under CLR 2.0 and although we did not find any particular problem, we were expecting some minor issues requiring attention but this never happened.
So if you are considering upgrading your application from .NET 1.1 to 2.0, here are a few points to consider:
- Don’t forget that you need a business driver for the upgrade.
- Communicate your plans and any issues/risks associated with the upgrade to the development team, project management team and the client and let everyone contribute to the planning and decision making process.
- Be patient! Yes, it may take a while before the project management team and/or your client/business sponsor make their mind, and they may ask you to wait until a more suitable time to reduce the project risk.
- Have a well-written and step-by-step plan, including roll-back procedure for each step.
- Make sure all (or most) of the developers on the team are happy with such a change.
- Make sure your source control software supports integration with Visual Studio 2005 (if you use this feature). This also applies to any other tool that integrates with the IDE like Add-ins and Macros.
- Make sure you can still use any third-party components you are currently using. First double check with your vendor to see whether they can provide you with an assembly that is compiled against .NET 2.0. If not, ask them whether you can use their existing .NET 1.1 assemblies under .NET 2.0. CLR 2.0 is backward compatible so you can run any assembly compiled against .NET 1.1 in a .NET 2.0 application domain. This happens automatically when you run a .NET 2.0 application that references an assembly compiled against .NET 1.1. But you still need to make sure the vendor supports such a deployment even if their component is not affected by the .NET 2.0 breaking changes.
Once you have made sure you get support from the component vendor after upgrading to .NET 2.0, you need to test your component under .NET 2.0 to make sure you get the same functionality. In order to do this, you can create a new .NET 2.0 project and test the component in the new project but this does not take into account every scenario you may follow in your application. The recommended approach is to configure your application to run under .NET 2.0 and then test the third-party component. This is where having a good coverage on unit tests can be very helpful.
- Practice! Before starting the conversion, you need to do a test run for the whole process at least once. You don’t want to be surprised by an unknown problem when the whole development team is waiting for the upgrade to be completed. We performed the whole upgrade process twice before doing the actual conversion and as you can imagine, we spent less time on the conversion process on the second and the third round.
- Ask for help/guidance. If you work for a Microsoft Certified Partner or a Microsoft Gold Certified Partner, there are multiple channels through which you can get help and advice from Microsoft directly. Otherwise, you can get advice from Microsoft Partners who have experience in upgrading to .NET 2.0 or talk to your account manager at Microsoft if you have one.