Slashdotted

DotNetNuke 4.0

Throughout the months of September and October, Charles Nurse was instrumental in working on the migration to the ASP.NET 2.0 platform. He invested a massive amount of time researching compatibility issues, creating various proof of concepts, and communicating regularly with Microsoft. He actually pursued two different agendas simultaneously: the upgrade of DotNetNuke 3.0 to ASP.NET 2.0 from a runtime perspective, and the creation of a new web project model for DotNetNuke 4.0 that provided a development strategy for the future.

To support the community, we concluded that we would need to support two parallel code bases for an undetermined period of time: DotNetNuke 3.x (ASP.NET 1.1) and DotNetNuke 4.0 (ASP.NET 2.0). Obviously, a more optimal solution would have been a single code base that worked on both platforms; however, this simply was not possible based on the platform compilation changes in ASP.NET 2.0. In addition, we did not know what to expect in terms of the adoption rate for the new Microsoft platform. Therefore, it seemed natural that we focus on developing for both ASP.NET 1.1 and 2.0 in the short term. An unfortunate side effect of this model involved a general recommendation to develop to the lowest common denominator (that is, not leverage ASP.NET 2.0-specific technology) and synchronizing all fixes and enhancements across the two code bases.

One of the greatest achievements in the platform migration was that we were able to fully satisfy our business requirement for no breaking changes. DotNetNuke modules and skins developed on ASP.NET 1.1 could be installed directly into the ASP.NET 2.0 environment without any changes whatsoever. This had massive benefits for the commercial DotNetNuke ecosystem because vendors could continue developing their modules as a single code base on the ASP.NET 1.1 platform but offer their packaged products for sale in both channels.

The only item that remained outstanding right up until the week before the November 7th launch was how to develop DotNetNuke 4.0 modules on the ASP.NET 2.0 platform. The new dynamic compilation model in ASP.NET 2.0 created some challenges for many of our runtime extensibility features, especially where they relied on object instantiation through reflection. As is often the case with technical problems, the answer is out there — it's just a matter of finding the right person to ask. As luck would have it, a Microsoft developer (Ting-Hao Yang) who was copied on some of the communication between our team and the Microsoft ASP.NET Product Manager group finally responded with details on a new ASP.NET 2.0 framework method that ultimately solved all of our remaining reflection issues. In the end, all that was required was a change to a single method in the DotNetNuke 4.0 core framework (to use BuildManager.GetType).

One of the benefits of the new ASP.NET 2.0 platform was that Microsoft had put a lot of focus on making the technology more accessible to the general developer community. A key deliverable in this strategy was the release of an entire suite of free "Express" tools. Included in the Express line was a tool named "Visual Web Developer" that provided a functional Integrated Development Environment (IDE) for ASP.NET 2.0. Leveraging the benefits of this powerful new tool, we created a DotNetNuke 4.0 Starter Kit that enabled a developer to configure a fully functional development environment within minutes. This had significant implications on the DotNetNuke development community because it lowered the barrier of entry and now made it possible for any aspiring software developer, from beginner to advanced, to be instantly productive with the DotNetNuke web application framework. Combine this with the free SQL Server 2005 Express database engine and you have a zero cost development environment. Visual Web Developer could not be used to develop server controls or class libraries; however, the fact that the DotNetNuke extensibility architecture was based on user controls made it a perfect fit.

Not wanting to neglect the existing DotNetNuke 3.0 community by focusing solely on ASP.NET 2.0 migration, we decided to integrate a few powerful new features that had long been requested by the general community. Core Team member Tam Tran Minh had been developing an Active Directory integration component for a number of years and agreed to contribute it as a fully supported core framework component. Additionally, Jon Henning had been busy working on a full-featured JavaScript API that would allow developers to leverage powerful client-side behavior in their modules. This included a new menu control, the DNN Menu, and an implementation of the popular Asynchronous JavaScript for XML (or AJAX) technology. AJAX technology had become one of the hottest new trends for web development, and it is important to note that DotNetNuke included a powerful AJAX library well before the announcement of ATLAS by Microsoft. The combination of these features offered benefits to both platform consumers and application developers, and further strengthened our core platform offering.

The official Microsoft launch date for ASP.NET 2.0 was set for November 7, 2005. We knew if we could release DotNetNuke 4.0 to coincide with this event, we would be able to ride the huge marketing wave created by Microsoft. Because we had always advocated "releasing software when it is ready," this hard deadline imposed some serious challenges on our meager project resources. Aside from the obvious technical deliverables, we had communication and marketing deliverables that also needed to roll out in unison. Nik Kalyani and Bill Walker showed their agility to pull things together on a tight schedule, and we launched our first monthly newsletter to the entire DotNetNuke registered user base (now 200,000 registered users) on November 7. The response was overwhelmingly positive as the significance of the achievement began to sink in. In the month of November, we recorded 165,000 downloads, far eclipsing any previous monthly download total in the history of the project.

An interesting aspect to consider in the ASP.NET 2.0 migration was that we delivered a fully managed upgrade to users of the DotNetNuke web application framework. Anyone who has ever attempted a major platform upgrade on their own should recognize the incredible value of this accomplishment. We had effectively eliminated a budget line item of considerable cost and effort from thousands of IT departments and business entities around the world. Compare this to scenarios where companies create their own custom ASP.NET 1.1 applications. In these cases, each company would need to invest significant resources and funding to work out their own web application migration strategy. Or compare this to another scenario where you adopt another web application framework, commercial or open source, which had not even considered the upgrade challenges posed by ASP.NET 2.0 and were going to force you to postpone your upgrade until it fit their own release schedule. In either case, the decision to adopt DotNetNuke as part of an organization's business infrastructure had certainly paid dividends worthy of the attention of any business decision maker.

Immediately following the DotNetNuke 4.0 release, we focused on stabilization issues that were exposed through testing by a larger community audience. Another area that received dedicated focus was the Module Item Template feature of the DotNetNuke 4.0 Starter Kit. Through research and persistence, we were able to construct a DotNetNuke Module Template that could automatically create all of the development resources required to build a fully functional module in DotNetNuke 4.0. It even had some parameterization capabilities so that the template could be customized at runtime to meet the needs of the developer. I wrote an article describing the Starter Kit and Module Template and posted it on the public forums on www.asp.net. The article proved to be popular, with nearly 30,000 views recorded in the six weeks following its publication. It turned out that the changes in ASP.NET 2.0 resulted in some decent productivity benefits for module developers, further improving the capabilities of the DotNetNuke framework.

An interesting event occurred in December 2005, well after the official launch of ASP.NET 2.0. Based largely on the feedback that we provided Microsoft during our product migration efforts, Microsoft announced some add-ons for Visual Studio 2005 that added back ASP.NET 1.1 development support through Web Application Projects as well as compilation and merge support through Web Deployment Projects. Based on its superior architecture and incredible popularity, DotNetNuke was able to unite a significant portion of the Microsoft developer community and create a much stronger voice and more compelling argument in favor of specific platform features than would have ever been possible for individual developers. Beside the fact that these add-ons provided some critical options for web application developers, it was really gratifying to see that our direct feedback could have such an immediate and influential effect on the industry.