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…
