January 02, 2008

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 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.


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.

tags: DNN, ASP.NET
comments powered by Disqus

Content provided in this blog is provided "AS-IS" and the information should be used at your own discretion.  The thoughts and opinions expressed are the personal thoughts of Mitchel Sellers and do not reflect the opinions of his employer.

Content Copyright

Content in this blog is copyright protected.  Re-publishing on other websites is allowed as long as proper credit and backlink to the article is provided.  Any other re-publishing or distribution of this content is prohibited without written permission from Mitchel Sellers.