Mehran Nikoo's Notes

The decision has been made  We have just announced that we will release much of the source code for the .NET Framework libraries with the final release of Visual Studio 2008 (which will be later this year). This means that anyone who accepts the Microsoft Reference License will be able to browse and view the source code. The initial publication will include the BCL (System, System.IO, System.Collections, System.Configuration, System.Threading, System.Net, System.Security, System.Runtime, System.Text, etc), ASP.NET (System.Web), Windows Forms (System.Windows.Forms), ADO.NET (System.Data), XML (System.Xml), and WPF (System.Windows). More libraries including WCF, WF and LINQ will be added to this list over time.

More information on Scott Guthrie’s blog.

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 or if you have a Premier support agreement with Microsoft, you should be able to get 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.

Although the MenuStrip class in WinForms 2.0 is originally designed to support MDI applications, it is a life saver when it comes to other applications types. Some of the new applications prefer SDI style over MDI. One of our current smart client projects is using the SDI style and we have been missing the automatic menu management features of the MDI world. Most of you know that in MDI applications, the menus from the child menus are automatically merged into the MDI parent window when the child windows are activated.

Our application follows the SDI style so we don’t have this luxury.  The application has a main window and allows the users to create multiple instances of child forms that show Customer Details. These Customer Details forms have their own menus and everything is fine as long as they are displayed as floating windows. But as soon as they are docked to the centre of the main window (or shown as tabbed documents, similar to open files in Visual Studio 2005), we do have a requirement to merge their menus to the parent window. Obviously, we need to unmerge these menu items once the child window is closed or reverted back to the floating mode.

The previous version of our application (based on .NET 1.1) had its own menu subsystem, which used a custom and complex mechanism to manage the menus and merge/unmerge them as needed. After the upgrade to .NET 2.0, the ToolStripManager class has come to the rescue. The overloaded Merge method enables you to merge the menus very easily. All you need to do is to pass a reference to the menu you want to merge (source) and the menu you want to merge into (target) to this method and everything will be taken care of. When you want to unmerge the items, you just call the RevertMerge.

protected void OnMenuMerge()
{
    ToolStripManager.Merge(this.childMenuStrip, ApplicationController.View.MenuStrip);
    this.childMenuStrip.Visible = false;
}

protected void OnMenuUnmerge()
{
    ToolStripManager.RevertMerge(ApplicationController.View.MenuStrip, this.childMenuStrip);
    this.childMenuStrip.Visible = true;
}

Just make sure don’t underestimate the power of this feature because of its simple interface. It is a rather powerful and robust piece of functionality that allows you to customise the way the menus are merged by allowing you to provide the merge action and merge index for each individual menu item. For example, you can choose the child menu item to replace the parent item or to remove the parent item when a child menu item matches the parent. I don’t want to go into the details here as there are some good sources on the net with more details.

Please note that you don’t have do call Merge and RevertMerge in MDI applications as automatic merging takes place when you set MainMenuStrip property on an MDI parent form. Also note that Merge and RevertMerge expect parameters of type ToolStrip, so you can merge/unmerge toolbars and status bars too (however, they do not participate in automatic merging in MDI applications so you always need to call Merge and RevertMerge explicitly).

I have created a class diagram that shows the players in the menu merge functionality. All items that can be added to MenuStrip and ToolStrip inherit from ToolStripItem so merge operation can be customised for all of those items by setting the merge action and index.

                             Click for a larger view [opens in a new window]

Have fun!