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 explanations 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 the 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 its own solution you have instant control to build your own module assembly. You are not forced to re-build the DotNetNuke core every time you want to compile your project. This grants you easy flexibility 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 fairly simple process to complete it is considered timely and complicated to some developers. I have a tutorial available Debugging WAP DotNetNuke Module 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 in 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.