View Article


A lot of people ask me how to debug 3rd party modules because there is no well known procedure to do this. This article will attempt to show you a method that I have used over the last few years.

Before I show you those steps, I want to examine what we need to get the module running/debugging. The first is source code (well that’s what we want to debug/enhance) and the second is database tables/procedures.

Source Code is easy to add, you just add in a folder under DesktopModules and load it up into your project (I use the MyModules solution, if you are not using it; check it out because it makes things a whole lot easier). 

Database table and procedures can be a little bit trickier, you could run each script in turn modifying the scripts to remove the {objectQualifier} etc, but it can become a bit tedious and doesn’t cover scenarios where IUpgradeable is used to modify the database.

To cover both aspects I actually install the “Private Assembly” version of the first and then modify the module definitions to point to the source code version. Using this method you are assured of an upgraded database in seconds with the ability to debug and modify the source code. When new versions are released, uninstall the module and repeat. 

So the exact steps are:-

  1. Download your chosen module (both Private Assembly & Source Code)
  2. Install Private Assembly version via Host -> Module Definitions -> Upload New Module
  3. Extract the Source Code into a separate folder under desktop modules (e.g. LinkSource for the links module source)
  4. Update the module definitions of the module (Host -> Module Definitions) by modifying each control and change the source to point to your newly created source folder. Each control must point at its equivalent.
  5. Load up your project and start debugging! 

I hope you find this article useful, if you have any suggestions for futures article please send me a private message on this site.

Posted in: DotNetNuke

Post Rating


Philipp Becker
# Philipp Becker
Friday, August 12, 2005 12:04 AM
Why not just placing the source in the PA folder itself? Seems to me like repointing the module definitions to its new source is more work than necessary, is there a special reason to do so?
andy hock
# andy hock
Tuesday, August 16, 2005 11:22 AM
Yeah, I just place the source in the PA created folder, and also the projects and sln file. First, of course, I check for any absolute path specific info in the proj and sln files, or if .webinfo files, url paths, fix those, and I'm good to go. If there are no project files, I just create a vb/cs dnn module and add the files in the folder to the project. Not sure why this needs to be a separate folder. The article would be much more useful if I could understand why it's not a good idea to use the same folder the PA created.
lionel luo
# lionel luo
Wednesday, December 6, 2006 8:28 AM
MyModules solution link is broken, where can I get it?
Scott McCulloch
# Scott McCulloch
Wednesday, December 6, 2006 5:19 PM
Send me an email, and I'll send you the zip file (
# Brian
Sunday, May 27, 2007 8:23 AM

I have read your article regarding the debugging of 3rd party modules, but cannot seem to get the proper configuration in place to debug a 3rd party module I acquired (DataSprings - Dynamic Registration 2.4). I am using the DNN4.5 StartKit. The core issue seems to be that after installing the PA, the 3rd party module DLL placed in the Bin directory is always the one accessed. In fact, the only way I can even get the 3rd party source to compile is by moving all source code files (.vb's) to a newly created sub-directory within App_Code AND renaming the 3rd party DLL in the Bin directory. However, upon running the website, I received a logged error stating that the 3rd party DLL cannot be found. After reviewing the DesktopModules table in the Core DNN database it seems as if the portal is attempting to pre-load the 3rd party module based upon its installation location.

Any advice on how to get this working? I've searched the net to find solutions, but yours seems to be the closest solution for my particular scenario.


# Brian
Sunday, May 27, 2007 8:42 AM
Scott, BTW, I am using Visual Studio.NET 2005 which I know requires the use of App_Code for user control code behind.



Post Comment

Only registered users may post comments.