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

I also prefer self contained structure of WAP project, but any code change seems to trigger update to GAC which forces reload of entire solution. Each time I make change to code-behind it is 45+ seconds to reload WAP, however with WSP I can make live edits without reload. Is this issue for others?

By Lauren on Tuesday, June 01, 2010 at 7:03 AM

That is the nature of WAP, it is a compiled change, therefore the DLL's must be reloaded.

By mitchel.sellers@gmail.com on Tuesday, June 01, 2010 at 7:38 AM

That recompile time is probably the major reason I prefer the WSP model. Its just som much faster make a change, test it, make a change, test it, and so on. For me, if I am not planning to sell the module (or otherwise need to protect the IP) then WSP is a much faster development environment.

By Jay Mathis on Thursday, June 24, 2010 at 10:20 AM

Now that I have more modules installed my reload times are approaching 2 minutes. Given the number of F5 iterations I do in a day, this adds up. In other non-compiled web dev environments, response is near instantaneous. Can't believe how patient .Net developers are...

By Lauren on Friday, August 06, 2010 at 12:15 PM

Lauren,

I can understand your frustration about this, but at the same time I think you will find that it isn't much of a deal in many situations.

For example my test installation I reset every so often to avoid having too many modules, but overall I don't find that I am doing the debug, update, debug process, so the startup time isn't critical.

By mitchel.sellers@gmail.com on Friday, August 06, 2010 at 12:20 PM
Click here to post a comment

Disclaimer