Posted by: Shaun Walker
8/30/2005 

With the major production release of ASP.NET 2.0 just around the corner ( Nov 7, 2005 ), we have been focussing our efforts on a migration strategy for the DotNetNuke application. To provide some transparency into the process, and showcase our new Blog feature on http://www.dotnetnuke.com, I thought it would be worthwhile to share some of our progress with the community.

Last year when I heard the marketing propaganda regarding 70% code reduction and 100% backward compatibility for ASP.NET 2.0, I never believed it for a second. Marketing is a fairly subjective art and I am sure it could be proven that Microsoft has achieved its stated objectives - but only if you consider the most simplistic web project scenarios. In all fairness to the Microsoft ASP.NET team, it is next to impossible to anticipate all of the subtle ways in which external parties have tweaked the framework to achieve their specific goals. And in the case of DotNetNuke, we certainly did our share of tweaking.

So as it turns out, the migration process for DotNetNuke is a non-trivial exercise. This is largely because the DotNetNuke application has been designed for granular modularity; whereas most ASP.NET applications are constructed as monolithic assemblies. Since we deviated so far from the "standard" use case in our attempts to produce an extensible web application architecture, some of the "features" in ASP.NET 2.0 actually conflict with our existing application model.

To be more specific, our problem is not with the .NET Framework 2.0 run-time environment. With minimal code tweaks we can get the current version of DotNetNuke to run on the .NET Framework 2.0. Our major challenge comes from Visual Studio 2005. Due to changes in the compilation model, the IDE does not like the folder structure of our web application and will not compile properly.

By far the biggest compatibility issues we have run up against is the major changes to the Web Project model in ASP.NET 2.0 and the deprecation of project files. In VS.NET 2003, our root project is a web project which contains numerous subfolders - each of them an independent class library project containing all of their resources in a single, organized silo. The root web project contains a project file which includes metadata on which folders/files should included in the build process for the core DotNetNuke assembly. In VS2005, this project file no longer exists which results in the IDE trying to build all folders/files into one monolithic assembly - a complete failure.

Now I hate to bring up past events, but I was invited to some Whidbey Labs nearly two years ago in Redmond where the concept of a "project-less" web was introduced. The whole purpose of the Labs was to get feedback from a wide variety of stakeholders regarding proposed Whidbey enhancements. At the time I remember there being significant negative feedback from the attendees regarding the "project-less" web approach. Regardless, there must have been enough perceived business benefit for the feature to be included as a fundamental item in ASP.NET 2.0 ( Scott Guthrie's recent Blog includes a good shopping list of benefits of the new Web Project model - many of which make a lot of sense - just not in the context of an application like DotNetNuke ).

I personally do not believe in "change for the sake of change". If something is going to be changed, there had better be a tangible business benefit. Unfortunately, this philosophy is very difficult to adhere to when it comes to platform upgrades. Often you are forced to move sideways ( or backwards ) temporarily, before you are able to move forward again. This may involve putting revenue generating enhancements on hold just so that you can achieve basic compatibility of your current feature set on the new platform. I think this is why many people fear platform upgrades and are often hesitant to construct a short-term migration strategy. I think DotNetNuke offers a compelling business advantage in this area. As long as you are using the application as a "black box" Web Application Framework, you are able to rely on the fact that someone else is taking care of the mundane base platform migration issues for you. This significantly reduces the platform upgrade impact and leaves you free to continue focussing on the delivery of your core business requirements.

In researching a solution to our problem, it forced us to examine our current architecture to identify the attributes which we believe are critical to the project. Extensibility has always been a driving factor and will continue to be an area where we strive to deliver the maximum flexibility. In order to achieve this goal we absolutely must retain our modular architecture. So although going back to a monolithic assembly would simplify our migration effort, it can not even be considered because it conflicts with one of our fundamental principles. other attributes we wish to preserve are our current module development environment as well as support for our third party developer community. Based on the attributes identified, we were now ready to judge a variety of approaches to the ASP.NET 2.0 upgrade challenge.

At this time, I must publicly thank the ASP.NET team in Redmond for providing valuable assistance in dealing with our upgrade challenges. Not only did they go out of their way to understand the full problem domain, but they also brain-stormed multiple possible solutions. There is no substitute for the level of knowledge these folks have with the ASP.NET 2.0 platform - and there is no doubt we may have spent considerable time spinning our wheels if left entirely to our own devices.

As is typical with most technology decisions, there is no approach which does not have at least some negative aspects to it. The trick is to weigh the postive with the negative to come up with the best overall solution. I will share some of the research in summary format below:

1. Virtual Directories - map virtual directories to all subfolders within the Web Project.

Benefits:

- DotNetNuke could retain its current folder structure and behave properly in VS2005.

Issues:

- configuring multiple VDIRs is not an option in most hosting environments ( a primary deployment target for DotNetNuke )
- complicates the installation experience for DotNetNuke ( one of our fundamental goals is simplified installation including no custom IIS tweaks )
- complicates the dev environment setup
- session state can not be managed effectively across VDIRs ( although DNN does not use session state - some third party modules do )

2. Web Project Reorganization - the folder structure for DotNetNuke could be re-organized to conform to the new Web Project model.

Benefits:

- could use new low level development tools offerings such as Visual Web Developer and Visual Basic Express
- allows for dynamic compilation model

Issues:

- extremely invasive changes to folder/file organization ( involves moving files/folders on upgrade, changing database fields which contain path information, updating modules which contain static path information, etc... )
- code-beside results in distribution of intellectual property
- overly complicated IDE structure in terms of the module code files being physically seperated from the UI files in completely different root folders ( constantly hunting through folder hierarchies to find the right location is not very efficient )
- more complicated development environment in terms of having to potentially leverage MSBuild rather than doing everything within the IDE

3. Class Library Conversion - the root web project could be converted to a class library project

Benefits:

- minimal code changes
- no file/folder reorganization
- allows for same development model we have today

Issues:

- will not allow people to take advantage of new low level development tools offerings such as Visual Web Developer and Visual Basic Express
- does not follow new Web Project model ( may result in barrier of entry for new/novice developers )

Trackback Print

Tags:

Categories:

Location: Blogs Shaun Walker