WAP or WSP Which to Use and Why 

 The question on which is better WSP (Website Project) or WAP (Web Application Project) has been one asked many times on this site and DotNetNuke.  Over the past months I have provided explainations that fit for each of the specific applications, however, I never really took the time to provide a full compare/contrast article that shows you the overall ease of using one over the other or the hidden downfalls of one over the other.  This article will take you through a number of steps to compare the two development models, so you can make your own decision on which is better.

Environment Compatability

Visual Studio 2005 (Standard or greater) provides support for both development models as long as you have Service Pack installed.  Without the full Visual Studio version AND SP1 you will not be able to work with WAP.  This is not typically an issue for professional developers.  However, if you are developing a module that you would like anyone to be able to edit, including individuals using Visual Web Developer Express you will want to be sure to use WSP as they will be unable to edit the WAP projects as they are not supported by the IDE.  This is typically only the case for free DotNetNuke modules that you want to allow for great flexibility on the development environments used to edit them.

Solution Structures

There is a fundamental difference in the way that solutions are structured for WAP and WSP.  In WSP there is one solution and that is the website, in this case your DotNetNuke solution.  In WAP each module is it's on solution and it simply references the DotNetNuke.dll file that is stored in the bin directory.  This is something that isn't necessarily a major issue unless you are talking about source control, or overall "ease of use".  When working with multiple projects using WSP it can be very easy for your DNN site solution file to become cluttered and very hard to navigate.

Addition to Source Control

Due to the differing solution structures listed above this provides WAP with a distinct advantage when talking about source control.  When you have a separate project for each module that you are creating you are given an easy way to check individual solutions into different areas of your source control system.  If you use WSP to develop your modules you are forced to check the entire DotNetNuke solution.  This is a situation that most of us want to avoid as it is unnecessary to check in the 1400+ core files if we are not going to use them. 

I also find that being able to create separate folders, or the ability to store modules in different repositories is a feature that I cannot live without.  This is typically one of the guiding reasons as to why individuals move to WAP over WSP.

Generating Isolated Assemblies

Since you have your module in it's own solution you have instant control to build your own module assembly.  You are not forced to re-build the DotNetNuke core everytime you want to compile your project.  This grants you easy flexability to deploy your module in a secure manner with a specific DLL.  No editing of the web config or special build options to get the isolated dll file. 

Debugging

Debugging is one item that WSP has an upper hand on.  When using WSP you can simply press F5 to start debugging and instantly debug your module.  To debug using WAP you must use the "Attach to process" method to hook into the ASP.NET worker process for debugging.  Although this is a farily simple process to complete it is considered timely and complicated to some developers.  I have a tutorial available Debugging WAP DotNetNuke Modules which walks through the debugging process for WAP.

Conclusion

Overall I think this article has hit on many of the major considerations when deciding between WAP or WSP, however, the final decision rests with the developer involved on the project.  I personally find the WAP model much easier to work with as I always use source control systems and deploy compiled modules.  This is my personal preference though and both models have their benefits and downfalls.  If you have other areas of comparison that you would like to see listed here please post a comment below and I can re-visit this article in the future.

Posted by Mitchel on Wednesday, January 02, 2008
 

Comments

Great article, thanks for comparing the approaches.

Can you add a link to a guide for setting up and using WAP for DNN module development ? That may be a barrier for many as well.

By Jim Bonnie on Wednesday, January 02, 2008 at 5:13 PM

I'll dig up a link to Michael Washington's article. I need to get one of my own built here soon..

By mitchel.sellers@gmail.com on Wednesday, January 02, 2008 at 5:15 PM

Click on my name to get to the WAP Development setup article. A side note. I use WSP with Team Foundation Server. I only check on the APP_Code and the Desktop Modules folder NOT the entire DNN Core. Works great :)

By Michael Washington on Thursday, January 03, 2008 at 12:02 PM

Opps that link should have been:
http://www.adefwebserver.com/DotNetNukeHELP/DNN4_WAP/

By Michael Washington on Thursday, January 03, 2008 at 12:04 PM

Thanks Michael!

By mitchel.sellers@gmail.com on Thursday, January 03, 2008 at 12:34 PM

Great suggestion on source control, Michael. Thanks!

By Will on Friday, January 11, 2008 at 5:08 AM

Great article !
Mitchel, any chance for a C# *WAP* module tutorial ?

By Lukasz on Thursday, January 17, 2008 at 7:24 AM

Lukasz,

It is already on the radar, I have completed 1 presentation on the topic and now I am in the process of writing up how to use the templates and to setup the development environment. There will be a matching video tutorial for it as well, as soon as I have time.

By mitchel.sellers@gmail.com on Thursday, January 17, 2008 at 7:31 AM

Beautiful :) Keep up the good work !

By Lukasz on Thursday, January 17, 2008 at 8:36 AM
Click here to post a comment

Donate

Show your appreciation for the content/modules made available by MitchelSellers.com by making a donation. Donations are used to assist with dedicating time to creating free content.