Reorganization

ASP.NET 2.0

In July 2005, we recognized that we had approximately four months to prepare for the launch of Microsoft's next-generation software development platform. ASP.NET 2.0 had been under development for three years and had finally reached the point where it was ready for public release. Aside from reading the standard marketing propaganda in the various trade magazines catering to the Windows platform, I had not done significant research into the specific challenges DotNetNuke faced as a product related to this platform upgrade. And, as is usually the case, we quickly found out it was going to be some of the unpublicized platform changes that were going to cause us the most difficulty.

Based on early community feedback for the ASP.NET 1.0 release, Microsoft decided to completely overhaul the way web projects operated, including substantial changes to the underlying compilation model. Because DotNetNuke's advanced modular architecture strayed so far from the traditional monolithic ASP.NET application model, these platform changes had a significant impact on the project. Our solid working relationship with Microsoft reaped benefits in that we were able to engage in some focused dialog and onsite meetings in Redmond with the Microsoft Product Managers who understood the nuances of the new ASP.NET 2.0 platform better than anyone. Scott Guthrie, Simon Calvert, Omar Khan, and a number of other key Microsoft resources got personally involved in assisting us to find a suitable migration path.

I have to admit I was a vocal critic during these early discussions, because I could not understand the business cases that precipitated some of the major architectural changes. But after working closely with the Microsoft Product Managers, I began to warm up to the benefits of the new model and started to envision how we could leverage its capabilities to expose some powerful new options to the DotNetNuke community. But before we could focus on these new options, our most critical requirement was that we could not have breaking changes in the DotNetNuke framework in our ASP.NET 2.0 release. The main business criteria driving this requirement was the fact we had just had a major release with significant breaking changes in March 2005, and we could not risk an all-out community revolt (or product fork) based on compatibility issues.

Research and discussion proceeded throughout the months of July and August as we worked with Microsoft to find an optimal solution. Feedback from the community seemed to be mixed. People who were victims of the Microsoft propaganda machine seemed to think that the release of ASP.NET 2.0 would signal the end of DotNetNuke, because it promised to deliver so many overlapping application features. Other people who had adopted DotNetNuke as part of their business infrastructure expressed apprehension and fear regarding ASP.NET 2.0, based on their past experience that a significant platform upgrade usually resulted in a costly migration effort. Surprisingly, out of all the feedback collected, it appeared that nobody was making a serious attempt to perform the upgrade on their own, and that they were waiting for us to provide a migration path (as we had always done in the past). This element of trust was not lost on me, and I did my best to blog on a regular basis to provide public communication of our progress.