irob's blog.

Software Developer @ Engage Software. DotNetNuke Training Instructor

Creating DotNetNuke Modules using a Web Application Project (WAP)

When creating a DNN module, you have the option to choose from the web site project (WSP), or a web application project (WAP). I prefer the web application project approach, and I'll explain it for developers who are new to module development, or unfamiliar with the WAP approach for developing modules.

There are two major reasons why I feel WAP is generally better than WSP for DNN module development.

1. Conciseness - the project contains only your module's code, nothing more. Separating your module from the DNN web site itself in Visual Studio really helps with performance and maintainability.

2. Compiled - I like having the code compiled into an assembly. This makes it easier for me to build a module package and distribute. I like to use a NAnt script for each module that creates the packages for me. The WAP project style lends itself to this approach.

If you'd like to give it a try - here are the steps involved.

  1. Create a new WAP project, or alternatively, use a C# DNN Module WAP Template

    Template: ASP.NET Web Application
  2. Place the root of the project in the DesktopModules directory of your DNN development web site's file system (e.g. ..\DesktopModules\MyModule\)

    Location: C:\inetpub\wwwroot\DotNetNuke\Website\DesktopModules
  3. Set the project to build the assembly and place it in the "bin" directory of the DNN web site

    Output path: ..\..\Bin\
  4. Set the project to launch your DNN web site (e.g. http://localhost/DotNetNuke) when you F5/run.

    Start URL: http://localhost/dotnetnuke 
  5. In order for Visual Studio to know about your development web site, make sure to set your project to use your IIS server, and set the Override application root URL to the root of your web site.  When you do this, Visual Studio knows that paths starting with "~" are really pointing to the DNN web site, and not just to your project.  This makes it possible to include controls from within the DNN site, like the DNN Label or URL control.

    Project Url: http://localhost/DotNetNuke/desktopmodules/MyModule, Override application root URL: http://localhost/DotNetNuke

After your module is set up, you can import it (by importing the .dnn manifest file) into your development site, and run any database scripts that the module may have. Your module is now fully integrated into your DNN site.

TIP: to debug the module, you may find it helpful to "attach to process" in Visual Studio while you already have the web site running in a browser. This saves you from having to launch the web site multiple times.

Posted: Oct 15 2008, 12:03 PM by irobinson | with 4 comment(s)
Filed under: , ,

Comments

Dave Armstrong said:

Ian - thanks for the help - it took me several hours to finally find the answer here to the "~" path problem I was having with the setup of a new WAP module.  Thanks again, Dave

# December 13, 2008 12:45 PM

Store Integrator said:

Hi,

I was wondering how the DNN is setup? As a project file in the solution or as a web application in the solution (without project file) ?

Could you add screenshot of the final look in VS2008 for this?

J.

# January 10, 2009 6:46 AM

Ian Robinson said:

There are two Visual Studio solutions. The first is the DotNetNuke solution. The second is the module solution. I never open the first one for development purposes. The second solution (and it's project file) all live within the module's directory under the DesktopModules directory (i.e. everything about this module is contained within that folder, the only exception is the assembly that it outputs to the website's bin directory).

# February 20, 2009 3:42 PM

Dan F said:

I know this is an old blog post, but it stopped me tearing my hair out today, so thanks! I've got a project that is broken up much like DNN (main web site, secondary sites with user controls) that I've recently upgraded to .net 3.5 and studio 2008. Debugging was fine and dandy back in the 2003 days, but since upsizing I was having hells own trouble debugging. In desparation I hit up google for the 456th time and came across your post. A couple of quick clickety clicks later and I'm hitting breakpoints again. Yay!! Thanks Ian!

# June 11, 2009 6:26 AM
Leave a Comment

(required) 

(required) 

(optional)

(required)