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

Bryan said:

I too appologize for tacking on to an old blog post, but this is the first place I've seen address how to create a DNN module in a Web Application Project.

My questions is two fold:

1.  How do you handle items in the App_Code folder?

2.  You must have missed something about references.  You'll need to reference the various DotNetNuke libraries in order to compile properly, right?

# August 21, 2009 4:13 PM

Ian Robinson said:

Hey Dan,

Glad the post helped! Thanks for the kind words.

Take care,

Ian

# August 25, 2009 12:14 PM

Travis said:

Thanks for this post, it has been a great benefit!

I was wondering how you might resolve an issue of having two separate compiled modules reference a GAC assembly for the same DNN site?

In my case, I have two standard modules that I would like to convert to compiled modules that both use a charting library that is installed in the GAC.

How can I avoid having a web.config in both compiled module projects and still resolve the GAC reference?

If I can figure this out, I can abandon non-compiled modules completely...

# August 26, 2009 11:27 AM

Rmartin said:

In this way is possible to debug in real time the code?

thanks Rmartin

# September 22, 2009 6:06 AM

Jeff Martin said:

Thanks for keeping the post up, this is the first place I have found describing this well that doesn't want to charge me money to learn how to do it.   I have been working on this module for many years and it has moved from being a web application project to web site and now its back where it belongs.

# May 31, 2010 11:12 AM

Jan van Bodegraven said:

This worked great for me, I needed 2 perform additional steps:

1) Reference de DotNetNUke.dll inside my module project,

2) Remove the web.config file of the module project.

Thanks

# June 3, 2010 12:06 PM

Joshua said:

Yeah, it happens sometimes ... Nothing special.

# March 27, 2012 8:57 PM

Victor Marques said:

Thanks for the post.

# April 13, 2012 7:24 AM