A couple of days ago, I blogged about my VS.Net Solution for DotNetNuke that allowed me to work on custom modules without making my solution file bloated with unnecessary DNN project references. After I posted about this in the ASP.Net forums, I got quite a few questions and comments. This led me to investigate further and see if it was possible to create a DNN development environment that would leave the core package untouched, yet allow you to develop your modules without having to worry about file references.

After several iterations, I believe I have a good solution. I have decided to call the solution "My Modules." Here is how it works:

1) The "My Modules.sln" file resides in the root of the DNN folder. It consists of one required project and as many custom module/control projects you wish to add to it.

2) The required project I have named _DNNStub. This is a VB web project that is so named because it will always appear at the top of your list of projects. The only purpose of this project is to have a startup project for the solution. The project has one file -- Default.aspx. This is the standard (unmodified) DNN Default.aspx file. In the file properties within the solution, the compile option is set to "None". This file is included so the solution can have a startup page for debugging.

3) You may now add any of your custom modules projects from DesktopModules to this solution. I prefer to use web projects because I can easily add web-related resources to my project without resorting to tips/tricks. Also, once I load VS.Net, I have it open for days on end so the issue of load-time (which is frequently cited as a reason not to have web projects) is not relevant for me.

4) Whenever you add a custom module project, you must remember to add a reference to this project from the _DNNStub project. This will ensure that whenever you recompile, your compiled assembly will be placed in the root "bin" folder where it belongs. Alternately, you can set your project to build directly to the root "bin" folder. However, this may cause file locking problems and is not something I would recommend you do.

I have packaged everything you need into the Speerio My Modules zip file that is attached to this post. As an added bonus (and to prove that my solution really works), I have also added two custom modules projects -- one C# and one VB.Net to the package. I have also added one webcontrol C# project. Here's the 411 on these:

- Speerio RandomImage Module: This is a C# DNN module project. This module will randomly display one image from a folder of images. As a shortcut to creating a settings page, I coded the module so that it looks for images in a sub-folder based on the title of the module. So if your module's title is "Random Images," it will look in portals/{portal id}/Random Images. The complete source code for this is included and you may do with it what you wish. If you just want to install the PA, use the included zip (in the root).

- Speerio WeatherOutlook: I have setup a Speerio webservices server with some free webservices. One of these is a simple weather service. To illustrate use of webservices in DNN modules, I have included the Speerio WeatherOutlook module. This module will display the 7-day weather outlook for any U.S. zip code (sorry to others). It calls the Speerio Weather webservice at http://speerio.ws/Weather/Weather.asmx. Same as the Random Image module, full source is included, but in VB.Net

- Speerio Stock Quotes control: Another freebie in the package, is the Speerio Stock Quotes control. Written in C#, this calls the Speerio StockQuotes webservice at http://speerio.ws/StockQuotes/StockQuotes.asmx. A test page is included called Test.aspx.

Finally, I have included a script called DNNDebug.aspx in the package. I use this script anytime I see a parser error because it tells me that something is amiss in my ascx file. DNNDebug will let you load any ascx control and will display the exact error message that is preventing it from loading. Within the DNN environment, this message is obscured by the skinning engine and you see a generic parser error. I am confident this script will save you many hours of debugging. It has saved me on countless occasions.

I have tested all of these as best as I can, but it is possible that I have overlooked something. If so, please let me know so I can fix the problem.

Enjoy, and happy DotNetNuking!!!

I like to do my DotNetNuke development treating DNN as a black-box. With version 3.x, DNN has around 50 projects and to use any of the solutions in the package is time-consuming as they contain projects that are rarely needed during module development. Is there a way in which you can keep your module development separate from DNN, maintain references to controls etc. in your module script files and maintain a way to easily upgrade? I believe there is and I have been working with such a setup for a couple of weeks now, and everything seems fine. Before I describe my solution, a few things to note:

1) This works for me. Your mileage may vary.

2) I do all of my development in C#. I did however test this with a VB.Net module and it worked fine.

3) Unlike what a lot of other DNN experts recommend, I do not setup my modules as Class projects. I prefer to set them up as a web project because it gives me the ability to use all the web capabilities of VS.Net without messing around with registry keys and such. It takes only a few seconds to remove the application flag from the IIS MMC when VS.Net creates the module project and this is too small an inconvenience to forego all the benefits of having a web project.

OK, now for my solution.

I first created a new Solution in VS.Net. I named my solution DNNDev and created it in my existing DNN3 folder. VS.Net wants to put a new Solution in a folder with the Solution name, so I exit VS.Net, moved the DNNDev.sln and DNNDev.suo files to the DNN3 folder and then deleted the DNNDev folder. Now, I had my DNNDev.sln file in the same folder as the DotNetNuke.sln file.

The next thing I did was make a copy of the Default.aspx file. I named my copy DefaultOriginal.aspx. I then opened up Default.aspx in Notepad, and removed the CodeBehind attribute of the Page directive. (This is the only change to the DotNetNuke package that my solution requires.)

I opened up DNNDev.sln in VS.Net and added a new VB.Net web project. I named the project DNNShell and created it in the DNN3 root folder. I deleted the AssemblyInfo.vb, Global.asax and WebForm1.aspx files that VS.Net automatically created. I then removed the project from the DNNDev Solution, saved the solution and exited VS.Net.

Next, I moved the files DNNShell.vbproj and DNNShell.vbproj.webinfo that VS.Net put into a DNNShell sub-folder, into the DNN3 root folder and deleted the now useless DNNShell sub-folder. I edited DNNShell.vbproj.webinfo with Notepad and fixed the project URL reference to exclude DNNShell from the path.

I then re-opened DNNDev.sln in VS.Net and used Add Existing Project to add DNNShell back to the solution. With this setup, I am now able to add my custom module projects to DNNDev Solution, and treat DotNetNuke as a black box. Each time I add a custom module project to the Solution, I add a Project Reference to that project in the DNNShell Project. This ensures that my custom module's assemblies end up in the DNN3 bin folder.

That's all there is to it. You can now develop/debug without any regard for assembly conflicts or have to wait for projects to load up in VS.Net.

If anyone wants it, I will be happy to package up my solution files so you can zip and go...

A large number of DotNetNuke portals have a dependency on third-party modules. Being a "third-party module developer," I am interested in finding out how much of an impact modules make on the decision to upgrade to DNN3.

If every module you use on your DNN 2.x portal has a 3.x-compatible version available (for free) on the day DNN 3.x is released, would you upgrade your portal to DNN 3.x?

There is a lively discussion on the DotNetNuke Core Team forums about DNN stylesheets. If there is one area of DNN that I don't care much for, it would be in how DNN handles stylesheets. It's a bit messy and leaves even the most CSS-savvy designer scratching their head about how/where/why a particular style was inherited by a particular element.

Personally, I don't think there is a need for host, portal, skin, container and module stylesheets. There should be one stylesheet used on the page and that is the skin stylesheet. All classes required by a page where the skin is applied should be defined in this stylesheet. While this may require a bit more work, it is definitive and portable.

Continuing my quest to have a fully-integrated version of DasBlog with DotNetNuke, I have made some progress.

My original intent was to leave the DasBlog core untouched, but as I poked around, it became clear that this is not to be. I started by putting the DasBlog source in a folder structure that would allow seamless conversion of the DasBlog aspx pages to DNN controls. I created something like this:

/DotNetNuke/DesktopModules/Speerio_DasBlog/{main DasBlog web files}

/DotNetNuke/DesktopModules/Speerio_DasBlog/SiteConfig

/DotNetNuke/DesktopModules/Speerio_DasBlog/Themes

etc.

After several false starts in getting the IIS application mapping correctly, I had a DOH! moment. I moved the DasBlog web.config into /DotNetNuke and made /DotNetNuke into an application. That worked...almost...got a bunch of compiler errors, but at least I was making progress.

The source of the errors was that in several places in the code, DasBlog uses Server.MapPath("somefolder/somefile"). Of course, this doesn't work too well if it's not in the app root. Time to break out the trusty and hard-working Search and Replace and replace all such instances with "~/DesktopModules/Speerio_DasBlog/". Lift-off!? Nope...no such luck. Ran into an annoying VS.Net bug that prevents strong-named assemblies from working properly some of the time. Google says lots of people are having the same problem and the known solution is to not have strong-named assemblies (what kind of solution is that?) or build twice. The assembly in question is FTB and since I am not at the point where I can yank it out, I opted for the build twice.

After more of this, I now have DasBlog working using the revised folder structure. Next step, blow away the DasBlog security and have it look to the HttpContext instead.