|
|
May
26
Posted by:
Shaun Walker
5/26/2006
Michael Washington blogged about this subject earlier in the week and I would like to provide some more detail on how Web Application Projects will impact DotNetNuke.
Way back in September 2005, we had a variety of meetings with Microsoft to discuss the complications of migrating DotNetNuke from ASP.NET 1.1 to ASP.NET 2.0. During these discussions we identified a variety of use cases which were not possible using the *new* ASP.NET 2.0 project model. Some of these use cases were critically important to specific developer groups and I predicted that there would be significant backlash when the issues came to the surface. To be honest, I was a bit surprised that Microsoft never got this feedback earlier in their community beta testing program but based on my own experience with DotNetNuke beta releases, developers are often hesitant to really get their hands dirty with bleeding edge code. Based largely on our feedback, Microsoft immediately went to work to address some of the issues identified. This resulted in the Web Deployment Project add-on which was announced not long after the official Visual Studio 2005 launch on November 7, 2005. Unfortunately, the Web Deployment Project option only addressed a specific subset of the items raised, and did not address one of the most critical issues - the migration of VS2003 web projects to VS2005. Realizing ( too late ) the importance of this item, Microsoft began furiously working on another VS2005 project model which has been dubbed Web Application Projects ( or WAP ). Beta versions of WAP have been available to select stakeholders for a number of months already and on May 8, Version 1.0 was announced for free public download. It has been amazing to see the Microsoft public relations machine at work throughout this process... Microsoft has been able to generate a massive amount of positive community feedback - ironically for giving back something which they ignorantly took away in the first place.
So if we now shift our focus to the DotNetNuke web application framework, even though we identified some serious deficiencies in ASP.NET 2.0, we were still able to release DotNetNuke 4.0 on November 7, 2005 with full support for VS2005. In addition we were able to provide backward compatibility for modules created in VS2003/ASP.NET 1.1 ( from a RUN-TIME perspective ). We did this by reorganizing our project structure to conform to the VS2005 Web Project model. This involved a lot of time and effort but it also paid dividends by providing a number of new project benefits including support for the new Express development tools and support for some new RAD development concepts. However, one thing which we were not able to provide ( due to the limitations in VS2005 ) was a simple method for migrating the development environment for a DotNetNuke Module which was developed as a VS2003 web project and built/deployed as a private assembly.
The lack of a decent migration strategy for early adopters of the DotNetNuke web application framework has created some confusion and frustration within the community. Although we were able to provide detailed tutorials and samples on how to create modules in DNN4, there is no simple method to convert an existing DNN3 module to DNN4. Luckily, developers have understood that the limitation is mainly related to the changes which Microsoft made in VS2005, an issue which is largely out of our hands. However with the recent announcements by Microsoft regarding the availability of the Web Application Projects, there is a large group of developers who think that their migration problems have been solved. Unfortunately, these conclusions are based more on marketing propaganda rather than fact.
Recently, we have spent some time analyzing the Web Application Project model to determine its potential benefit to DotNetNuke. Almost immediately we ran into some serious technical challenges which we had not anticipated. It turns out that from a development perspective the two web project models are incompatible with one another. This means that within the same web project, you can only use one model or the other - not both. On the surface this may not seem like a big a deal but from a product development perspective, it certainly has an impact on the ways in which your developer audience will be able to use your application. Before we dig into the technical details, let's consider the high level business cases of the two project models:
1. Web Site Projects ( WSP ) - supported out-of-the-box in VS2005. Can be leveraged by ALL product SKUs from Express to Enterprise. Provides RAD development and deployment.
2. Web Application Projects ( WAP ) - supported as a separate download from the Microsoft site ( will be included as a fully supported model in VS2005 SP1 *official release date unspecified* ). Can only be leveraged in higher level SKUs - Standard Edition and above ( no support for Express Editions ).
As you can see, the developer tool support aspect of Web Application Projects is sorely lacking. This is unfortunate as the changes made in DotNetNuke 4.0 to support the Express tools resulted in a massive benefit to our community. It completely eliminated the barrier of entry for developers by providing a rich set of development tools at absolutely no cost. And the Web Site Project model used in DotNetNuke 4.0 provides a RAD development environment which satisfies the needs for 90% of the developer community. For the other 10%, a free development environment is not a critical requirement; therefore, the Web Application Project model is a viable alternative. So why can't we have one DotNetNuke code base which supports both Web Site Projects and Web Application Projects simutaneously - providing the maximum flexibility and benefit to all stakeholders? Here is where we dive into the technical details...
1. WSP uses the app_code folder for dynamic compilation. If you switch a project to use WAP and do not remove the app_code folder, you will get "double" compilation - as ASP.NET 2.0 will automatically compile anything in app_code whether there is a WAP project file present or not. So basically you will end up with assemblies that have namespace clashes in the /bin.
2. All user interface files ( ie. *.aspx, *.ascx ) have a different syntax in WAP than they do in WSP. WAP projects use the old "CodeBehind=" attribute and must have an associated *.designer file for each user interface file. WSP projects use the new code-beside model which does not require "CodeBehind=". You can not have a mixture of these 2 types within the same development solution. In order to support WAP for the DNN core, we would need to convert every user interface file to use the WAP syntax - producing a completely different code base ( one that no longer supports WSP ).
3. WAP has different settings in web.config than WSP, since they use totally different compilation models.
As a result of the technical issues noted above, we can not have a single DotNetNuke code base which supports both we project models. And since we feel that the Web Site Projects satisfy the needs of the majority of the developer community,
WE WILL NOT CONVERT DOTNETNUKE TO A WEB APPLICATION PROJECT
So what is the good news?
We CAN support both web project models from a RUN-TIME perspective. Even though the core framework we ship will conform to a Web Site Project model, modules which are built using the Web Application Project model can be deployed directly into DotNetNuke ( just like the modules built with ASP.NET 1.1 modules today ). So this does offer us the best of both worlds.
That being said, we recognize that there are still some challenges for members of our community and we absolutely do not want to ignore or neglect their needs. So lets examine some of the issues:
1. Commercial Modules
We have a group of stakeholders who are building commercial modules for DotNetNuke. Protection of intellectual property is an important requirement for these stakeholders - so including source code for dynamic compilation is not really an option. Packaging, versioning, and distribution of assemblies is an important requirement.
Possible Solution #1:
As part of our release offering, we could create a WAP release version of DotNetNuke. This version would be created at the end of our dev cycle using the automated conversion utility within WAP. This version would primarily be used by developers who create commercial DNN components.
Possible Solution #2:
Construct and document a development model which allows you to build WAP modules outside of the core DotNetNuke WSP.
2. Legacy Migration
We have developers who have created modules for themselves or their clients as ASP.NET 1.1 private assemblies. In this case, the new dynamic compilation option would be acceptable; however, they need an efficient mechanism to upgrade their VS2003 projects.
Possible Solution:
Create a migration utility which provides an automated process for upgrading a private assembly module. This would include moving the code to the appropriate folders, parsing the code files to include the necessary attributes, and modifying any config files. The utility would need to prompt for source and destination parameters in order to migrate files.
3. Resistance to Change
We have stakeholders who have a deep knowledge and expertise in building modules using the private assembly approach. Obviously there are some psychological aspects to learning new concepts but there is also a cost involved in training developers and migrating legacy code. Some of these stakeholders are also using utilities and tools which are hard-wired to the old private assembly structure ( ie. code generators, build scripts, etc... ).
Possible Solution:
Beyond automated utilities to ease the transition ( see #2 ), education is the key to making people comfortable with new concepts. We need to provide more examples and tutorials on how to develop using the new Web Site Project model.
24 comment(s) so far...
Re: Web Application Projects
I am confident that the DotNetNuke community will work together and develop some sort of documented procedures and conversion mechanisms as we all become more familiar with Web Site Project model.
Thanks Shaun. That solves this dilemma and gives us newfound enthusiasm when we understand the development path.
By djbaldwin on
5/26/2006
|
Re: Web Application Projects
Re: 1. Commercial Modules
"Possible Solution #2:
Construct and document a development model which allows you to build WAP modules outside of the core DotNetNuke WSP."
I am currently using (on occassion) a development model where I create the App_Code codebase in a separate class library project that the DNN WSP references. It gives me the benefits of a) "intellectual property protection" through dll generation (excluding the presentation layer ascx code-behind, of course), and (more importantly) b) the opportunity to leverage nUnit & TDD in my software development. So, having read Shaun's blog, I'm starting to wonder....
[...musings...] An alternative to get building WAP modules with WSP solutions might be done in a similar way that allows the bulk of the DNN WSP to be more of a "black box." I haven't tried it, but perhaps this would work:
1) Have a DNN WAP Solution that creates a structure similar to the structure of the DNN 4.x source:
[root folder]
- DNN solution file
- WAP VSproject file
- [Website] folder (DNN WSP files, but with most files not "included" in the WAP VSproject)
- default.aspx (included in the WAP VSproject, and set as the default startup page)
-
- [DesktopModules]
- [MyModule]
- [Library] folder (Class library project, referenced by the WAP VSproject)
-
2) Subsequent DNN modules in the solution would be multi-project modules that are made up of the following (similar to what I've noted above)
[root folder]
- WAP VSproject file
- [Website] folder
-
- [DesktopModules]
- [MyModule]
- [Library] folder (Class library project, referenced by the WAP VSproject)
-
Given the above construction of the solution & project files, perhaps it could allow a single code-base for the DNN core and still resolve [most?] of the technical issues Shaun's noted:
1. App_Code dynamic compilation still works with the WSP-style files, 'cause that's really a Web Server issue, not a "build" issue of the solution (as long as the buld of the DNN WSP files are not included in the WAP project - hence the "black box"). Double-compilation and namespace clashes would only happen if the developer starts including things into their project that they shouldn't (or if they start putting their [Library] folder code into the App_Code folder, rather than using a class library project).
2. The WAP project module can use the "CodeBehind=" without conflicting with any code-beside (again, bypassing what is really a build issue, I think, by "black boxing" the DNN core - the bulk of the DNN core files/controls are not included in the WAP project)
3. As for the differences in the web.config for WSP and WAP, I don't really know if this suggestion would address the problems ('cause I haven't looked at the differences :). However, if the web.config file is *not* included in the WAP project model, perhaps the issue could be "by-passed" yet again, leaving the Web Server (IIS or Cassini) free to read the web.config as it serves the site, while allowing Visual Studio to build the WAP site with only the bare minimum of the DNN core included.
As I mentioned, this is only a set of thoughts. I haven't tried any of it, but it might bring up some avenues of R&D ("Research & Development", or "Rants & Digressions"?)....
By dagilleland on
5/26/2006
|
Re: Web Application Projects
(Sorry - when I posted that comment, I see it took out my leading spaces, which would have made my suggested folder/file structure easier to read/visualize. Here is a "fixed" version...)
--
1) Have a DNN WAP Solution that creates a structure similar to the structure of the DNN 4.x source:
.[root folder]
...- DNN solution file
...- WAP VSproject file
...- [Website] folder (DNN WSP files, but with most files not "included" in the WAP VSproject)
.....- default.aspx (included in the WAP VSproject, and set as the default startup page)
.....-
.....- [DesktopModules]
....... - [MyModule]
...- [Library] folder (Class library project, referenced by the WAP VSproject)
.....-
2) Subsequent DNN modules in the solution would be multi-project modules that are made up of the following (similar to what I've noted above)
.[root folder]
...- WAP VSproject file
...- [Website] folder
.....-
.....- [DesktopModules]
....... - [MyModule]
...- [Library] folder (Class library project, referenced by the WAP VSproject)
.....-
By dagilleland on
5/26/2006
|
Re: Web Application Projects
(... don't flame me ... I just noticed that it took out all my angle-bracket comments, so here it is again with curly braces ... time for me to get some sleep ...)
--
1) Have a DNN WAP Solution that creates a structure similar to the structure of the DNN 4.x source:
.[root folder]
...- DNN solution file
...- WAP VSproject file
...- [Website] folder (DNN WSP files, but with most files not "included" in the WAP VSproject)
.....- default.aspx (included in the WAP VSproject, and set as the default startup page)
.....- {references the Class library project for the BLL/DAL of the module - see below}
.....- [DesktopModules]
....... - [MyModule]
...- [Library] folder (Class library project, referenced by the WAP VSproject)
.....- {references needed DNN .dll files in the [Website/bin]}
2) Subsequent DNN modules in the solution would be multi-project modules that are made up of the following (similar to what I've noted above)
.[root folder]
...- WAP VSproject file
...- [Website] folder
.....- {references the Class library project for the BLL/DAL of the module - see below}
.....- [DesktopModules]
....... - [MyModule]
...- [Library] folder (Class library project, referenced by the WAP VSproject)
.....- {references needed DNN .dll files in the [Website/bin]}
By dagilleland on
5/26/2006
|
Re: Web Application Projects
i'm an "old-school" module developer for DNN 4. will any of the proprosed processes speed up the development process (ie runtime startup, debugging)?
By afromobile on
5/27/2006
|
Re: Web Application Projects
i'm assuming since we're having this conversation now that the DNN4.1 release timeframe will be pushed back or will WAP for DNN be post 4.1 release?
By afromobile on
5/27/2006
|
Re: Web Application Projects
The release of WAP does not impact our release schedule for DNN 3.3/4.1.
By sbwalker on
5/27/2006
|
Re: Web Application Projects
Shaun,
You mentioned above "You can not have a mixture of these 2 types within the same development solution"
This is actually not true. I have created a solution with both types. The difficulty with this approach is needed user controls from the web project in the module project. This coudl be worked around if the core controls were converted to server controls from user controls
Bert
By Bertcord on
5/27/2006
|
Re: Web Application Projects
Shaun,
I put together a sample that you can look at here http://www.dotnetnuke.com/Community/ForumsDotNetNuke/tabid/795/mid/2108/threadid/40609/scope/posts/Default.aspx
By Bertcord on
5/27/2006
|
Re: Web Application Projects
trendoid,
what the heck are you talking about.....The issue that exists is the way Microsoft changed the model used for web applcations. This discussion revolves arounf coming up with a soultion that casues the least impact to all involved. If you have any ideas or suggestions feel free to provide them.
What is annoying are people like you that love to complain but offer nothing else.
By Bertcord on
5/31/2006
|
Re: Web Application Projects
trendoid,
I've posted my solution, maybe it can help you?
http://vladan.strigo.net/Projects/tabid/75/Default.aspx
By vladan on
5/31/2006
|
Re: Web Application Projects
If you use my model, you don't have to - it's the same in which language you build your module or in which language DNN is
Vladan Strigo
By vladan on
6/1/2006
|
Re: Web Application Projects
Well actually, for module developers (who in most cases do not recompile the core) it does not matter if the core itself is made with WAP - what matters is that the modules can be made in this way.
That beaing said... I have made a solution like this which works perfectly, but due to my *jams* at work in the last 2 weeks wasn't able to publish it.
Basically the WAP model solves the problem which we had in VS2003 when we've built class libraries with .ascx controls - you get the same thing - only now VS can provide you with "Add new..." option for controls in your module. It works perfectly.
Vladan Strigo
By vladan on
5/28/2006
|
Re: Web Application Projects
Ou and also, in VS2005 you cannot add .ascx files to class libraries - in VS2003 if you've *tricked* the studio and added them it worked, in the new version - it simply does not compile.
Vladan Strigo
By vladan on
5/28/2006
|
Re: Web Application Projects
Well even with the Website model you can sort this out to be ok.
But the problem is that it's too messy and slow to work on anything more serious in that way. At least that's my experience.
Vladan Strigo
By vladan on
5/29/2006
|
Re: Web Application Projects
Shaun,
Thanks for your extensive post. We spoke about this subject shortly at the SDC and it's great to see things moving.
What I love most in VS2003 Module Development is the "Freedom of choice" for the developers. For example, for the customer who's site I showed you, we developed about 20-30 modules.
Now, when developing a new module, a developer would normally only have our class libraries in his working solution and the new module off course. Some like to have the DNN source in there too.
When we need to do the testing before a release, we use a soltution with every module and library we made in it. Again, some like to have the DNN source in there, some don't.
IMHO, using the WSP model will work very inefficient, because a developer can't get rid of a lot of codefiles he doesn't need.
I have a feeling I'd opt in for the option "1. Commercial Modules, Possible Solution #1."
Greetings,
Stefan Kamphuis
By superska on
5/27/2006
|
Re: Web Application Projects
I must say that Possible Solution #2 to the Commercial Modules problem sounds more interesting to me than Possible Solution #1, but this is largely in the hopes that this alternate development environment could improve the development experience for my developers. Any chance you could spell out your ideas about this possible solution in more detail, Shaun?
By Michael_Dorfman on
5/28/2006
|
Re: Web Application Projects
I managed to get a WAP module working in the WSP solution, but I had to copy the core DNN controls (with the usercontrols) folder, which was a pain. I think Solution #1 would best suit developers like myself who develop and sell modules. I think this would also require the least effort, but I am still fine tuning.
By rodneyjoyce on
5/30/2006
|
Re: Web Application Projects
My main concerns are
1) On a production server, I do not have to include sources and have dynamic compiling
2) When I produce commerical modules, the DLL will not use unprofessional mangled names.
Beyond these, whatever works best for development works for me.
By RockyMoore on
5/29/2006
|
Re: Web Application Projects
Another constituency are C# developers who write DNN modules. I'd like to use the WSP model, but since the WSP project is a VB project, I need to build my modules in a separate project.
By Haacked on
6/1/2006
|
Re: Web Application Projects
If this is the way things are going to go with DNN, I can't wait to see 4.1. I'm sure whatever limitations you create in 4.1 will be the last straw and I can move on to another framework. We have only been working with DNN for a few months now but your growing pains are just getting annoying.
By trendoid on
5/30/2006
|
Re: Web Application Projects
I would be happy seeing either options 1 or 2 used, perhaps with an emphasis on option 2 so that there is really only one single distribution of DNN. I undertand the desire to stick with the model that the express editions support as that is the way to gain wider acceptance and get more involvement for the product. I have long felt the express editions were meant to help the .NET Open Source efforts move forward since until they came into being the .NET Open Source efforts were mainly from developers like myself who would purchase VS.NET and then do Open Source work with it.
By irasmith on
6/22/2006
|
Re: Web Application Projects
I think the only valid cause of sticking to WSP model, is, it is VWD compliant, but then let us hope (and may be pursued) Microsoft introduces the WAP compliant Add-on to VWD too, like it did for VS2005 :)
By Jaydeep on
6/21/2006
|
Re: Web Application Projects
You can develop c# modules within the WSP website. Install the starter kit, create a site, and then add a DNN module from the c# template. It tells you to just add the modules directory to the codeSubDirectories element in web.config...
***** from the intro file*****
In addition, as the main project uses Visual Basic you need to add a node to your web.config as shown below:
*****
Aaron Prenot
By aprenot on
6/2/2006
|
|
|