I was fortunate enough to participate in the ASPInsiders Summit in Redmond, Washington last week. This was my first ASPInsiders Summit as I was only officially invited to join this group a few months ago. The ASPInsiders represent a "Who's Who" of the ASP.NET development community and I was honored to be included in such distinguished company. I also appreciated the opportunity to provide representation for the DotNetNuke community at this level.
Where the MVP Summit provided a sneak peek at some of the upcoming Microsoft technologies, the ASPInsiders Summit went much deeper in these areas - discussing the architecture in greater detail and soliciting active feedback. There was also presentations of technology which had not been mentioned at the MVP Summit. One presentation in particular really impressed me - not so much from a technology perspective - but rather in convincing me that Microsoft really is capable of listening to the community and cutting through the bureaucratic red tape in order to deliver essential solutions.
About 6 weeks ago, Charles Nurse and I travelled to Redmond to discuss some of the issues we had encountered with the DotNetNuke migration to ASP.NET 2.0. There were a number of key Product Managers from the Web Platform and Tools Team ( ASP.NET ) present at the meeting and we spent quite a few hours whiteboarding the various migration scenarios. One area in particular we focussed on was the fact that in ASP.NET 2.0, the web developer no longer has control over the naming or structure of their web project assemblies. At first some of the PM's did not see the significance of this problem... but eventually the light bulbs started to go on and we had some very production discussion on the implications of this restriction - especially in Enterprise web application development scenarios.
In ASP.NET 2.0 there is now support for a dynamic compilation model for web projects. Essentially this means that you can make modifications to your source files in place which will force an automatic recompilation of the affected code. To support this new model, the compiler now takes a much more granular approach in the creation of assemblies. Instead of having one monolithic assembly for the entire web project, you now have assemblies for each file or folder ( depending on the web project compilation settings specified ). The compiler also takes over the naming of assemblies and creates a unique hash code ( based on a proprietary algorithm ) which becomes part of the final assembly name ( ie. app_code_ml4v3rju.dll ). Now if you compare this to the VS2003/ASP.NET 1.x development model, you are gaining the perceived benefits of dynamic compilation, but losing the ability to effectively manage your web project assemblies. In most simplistic cases, this is not an issue. However if you want to take advantage of advanced web development techniques, this limitation causes some severe problems ( I made a reference to this in my previous blog entry ).
ASP.NET allows you to leverage Reflection to achieve powerful results. There are a lot of capable methods in the Reflection namespace, but one of the most essential concepts is the ability to dynamically create an object based on a TypeName. In DotNetNuke we use this feature extensively to provide extensibility and interfaces between the core web application framework and our plugin resources. In all cases, the implementation relies on a fully qualified TypeName (ie. TypeName = "DotNetNuke.Data.SqlDataProvider, DotNetNuke.SqlDataProvider" ) which can be converted to a native .NET type ( objType = Type.GetType(TypeName,True) ) and then instantiated into an object ( Activator.CreateInstance(objType) ). However, you will notice that the fully qualified TypeName is actually composed of a ClassName and an AssemblyName. And if you can not create assemblies with developer-specified names, then how can you create a proper TypeName ? Well, one option is to NOT use the new app_code folder in web projects and instead create a seperate class library project outside of the web project and then copy the resulting DLL into the /bin. This works ( it is how we do it today in VS2003 ), but complicates development and restricts people from using the pure web-based development tools ( ie. Visual Web Developer can not be used for class library projects ). So what are the other options?
Well, last week Microsoft showed the ASPInsiders a new build utility called "aspnet_merge". This utility will ship on Nov 7 as part of the Visual Studio 2005 product launch. Its purpose is to allow developers to merge and custom name assemblies - basically providing even greater flexibility than we used to have in VS2003 in regards to application assemblies. For example, this utility gives you the ability to merge all of your granular pre-compiled web application assemblies into a single monolithic assembly and then name it based on your specific requirements. Couple this with a new Visual Studio "Web Deployment Project" ( which will ship as a VS.NET add-in on Nov 7 ) which essentially provides a simple user interface for developers to create sophisticated build and deployment scripts ( internally leveraging MSBuild and aspnet_merge ), and we have all the tools required to solve our assembly management problem.
Talking to one of the PM's I was told that so much effort was spent on ensuring an improved development experience in VS2005 for the entry level developer that some of the Enterprise development scenarios were missed. This could have been disastrous for many developers. But the Web Platform and Tools Team took the above item so seriously that they wrote 18,000 lines of code in the last 6 weeks in order to deliver a solution in conjuction with the Visual Studio 2005 launch on Nov 7.
So I realize that DotNetNuke was just one of many community folks who raised this issue to Microsoft in recent months ( Rick Strahl and Scott Wildermuth have been very vocal as well ). But knowing that the meeting which Charles and I had 6 weeks ago at Microsoft was convincing enough to get the Web Platform and Tools Team spurred into immediate action, really makes me feel like we accomplished something substantial. This is clearly an example where digging into the technology prior to public release had far better results than waiting and complaining about the issues when it was too late. And kudos to the Web Platform and Tools Team for their agility in making this a reality.