Hi,

I am new to module development. I am wondering how you debug a module. I can see that you cant just press F5 in vs.net as there is only one real web page and all module are user controls. I am also able to build a hello world module and view it in DNN by adding a new module definition.

But I cant work out how to go about debugging and testing in an efficient way. How do you add a few lines of code and then execute and see the results come to think of it how do you step through to debug problems ?


Any advice would be much appreciated.


Thanks

Rob

Nik has a good solution for this.

Ling

Thanks Ling.

I now have the MyModules solution and it works well. I see there is a Default.aspx in the stub project.

I still dont see how you step through code though. If I insert a break point in my ascx file it is not stepped into because DNN is using the compiled dll.
 
So even with this solution do I still have to make a change > complie dll> open Default aspx>navigate to my control ?.. and also work with out break points?

I think I am missing something.


Cheers

Rob

My method: my VS 'solutions' do not include DNN, only the module as a dll project. Then go to Debug menu and select 'Processes ...'. Select the asp.net worker process and you're in debugging mode.

donker wrote:

My method: my VS 'solutions' do not include DNN, only the module as a dll project.

Interesting... I assume your solution would contain two projects: the module and the dataprovider?
Could you please elaborate on this method, the set-up, etc?

Hey Robbie,

I think Nik includes a DNNDebug.aspx page to walk through the code.  Not used it myself, though, I bet I will soon.

Ling

SamTanner wrote:

donker wrote: My method: my VS 'solutions' do not include DNN, only the module as a dll project. Interesting... I assume your solution would contain two projects: the module and the dataprovider? Could you please elaborate on this method, the set-up, etc?

It is pretty straightforward: you have your solution with module and dataprovider projects. Then you reference in each of them the dotnetnuke.dll. I compile the debug version straight into the dotnetnuke/bin dir, the release version into it's own bin directory. If you want examples: all the modules on my site are done this way. Just check out one of the source versions.
Peter

I code modules the same as Donker.  My modules are DLL projects and the solution only contains the module project and it's data provider.  (References are setup as...Data provider references the module project and the core DNN dll.  The module project references DNN.)  None of my projects are web projects, just component libraries.  Having your module setup as a web project adds additional unnecessary processing with the IDE.

For me, it's the only way to code for DNN.  Having the DotNetNuke project and related in your solution is a mess. 

For debugging, I just build and then hit refresh on my browser.  If I find a spot that needs to be debugged, I set break points and then attach to the aspnet_wp.exe process from the debug menu.

Attaching to the ASP.Net process involves a few more steps rather then just hitting F5.  But... after experimenting with all the different possabilities of debuging a DNN module I found this to be the best solution over-all.   

Peter has it streamlined about as far as one can take it.  I have been developing my last few modules this way.  It works great without all of the complications from the core projects.  I was getting some build warnings that I am trying to work through which is why I was introduced to MyModules.  I am still getting those build warnings.  I wonder if it has something to do with files being open by the IIS...anyway, I digress.  I will also try the MyGeneration software, too.  I am curious how that handles the project development (although, I doubt I will seriously lean on it for my custom mods).

Well, it's time for wading into the MyModules setup a little futher.

Enjoy!
Ling

www.dnndirectory.com

Btw, the link does not seem to work.

onyaktech wrote:

I set break points and then attach to the aspnet_wp.exe process from the debug menu.

Very interesting.  Which program types do you select?  And, then...how do you start the debugger?

Ling

I use Class Library as project type.

When you select aspnet_wp.exe from the Processes window from the Debug menu, Visual Studio .Net automatically starts the debugger and attaches to IIS.  Note that you must first have initiated ASP.net by browsing to your local DNN site in order to even see aspnet_wp.exe listed.

This is also a great way to remotely debug modules as well.  For example, I had a problem with a module running on a production server and I couldn't duplicate it on the test server.  So I remotely attached to the aspnet_wp.exe process running on the production server and set break points in code.  Then...debugged away.

Raw, unbridled debugging power!  Suh-weet!

Thanks a ton for the tip!  Good stuff.

Ling

Thanks All for some great debugging  tips.

Lovely stuff