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.

10 Comments

  • 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

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

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

  • 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?

  • Hey Dan,

    Glad the post helped! Thanks for the kind words.

    Take care,

    Ian

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

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

  • 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

  • Yeah, it happens sometimes ... Nothing special.

  • Thanks for the post.

Comments have been disabled for this content.