Debugging DotNetNuke Modules

Question

What is the best VS solution setup for DotNetNuke 4.8 inter-module communication development?

I currently have a solution with multiple Web Application projects in it for my DotNetNuke modules - and in each one of those have pages with the controls on them as a test harness. That all worked fine up until the point where I need the modules to start talking with each other using IModuleCommunicator and IModuleListener - but now that I'm doing inter module communication, debugging won't work out that way anymore.

I'm curious as to how other people handle this - is there a way to have your test pages mock a Nuke environment? Do you test right in a nuke website? My solution is in sourcecontrol using VSS, so I don't want to add the full nuke website as a project in my solution since that would force me to add it to source control - and I'd rather not have a full nuke site in source control.

I've been able to debug by attaching to the local IIS worker process, but that's kind of a pain. Does anyone have any suggestions as to how to ease the pain of debugging inter module communication? Any suggestions would be greatly appreciated.

Answer 1

We tend to test in a development DotNetNuke site, usually just attaching to the IIS worker process for debugging (just because it's quicker than rebuilding with F5).

I think, in general, the more you're making use of what DNN provides, the less you'll be able to test outside of a DNN environment. Since IMC is a specifically DNN process, you can't have complete testing until you let DNN be the one to perform the process.

Answer 2

After lots of trial & error, here's what I ended up with - and seems to work well.

1. Created a Post-build event on the module project to copy to the local nuke site for debugging. Found under "Properties / Build Events / Post-build event command line" ... copy $(TargetDir)$(TargetName).* C:\Inetpub\wwwroot\bin* /y
2. Changed the web settings to start the localhost website by default. Found under "Properties / Web / Servers / Use Custom Web Server" - changed to "http://localhost/"
3. Created post-build events on supporting class library projects to copy file to local webserver as well. Could also have just changed the post-build event on the module project to include the other files.

Once those setting were in place, pressing F5 to run the project will start the browser and automatically attach to the IIS worker process.

Also, keep in mind that if you are running this on a machine with UAC (Vista, win 2008, win 7) you'll have to run VS as an administrator since both the copy to wwwroot and attaching to the worker process require elevated privileges.