I like to leave the DNN core code untouched when I do my module development. Also, I like to work with a clean VS.Net solution which has my custom modules and none of the core projects. After playing around with it for some time, I have created a VS.Net Solution that allows me to do exactly that and I would like to share it with anyone interested. It's called "My Modules" and can be used to develop/debug DNN modules without requiring any core project references.

I have blogged about my solution in detail and also posted it for download. In the download package, I have also included the complete source to two modules:

- Speerio Random Image (displays a random image from a sub-folder) -- C#
- Speerio Weather Outlook (displays 7-day weather images for U.S. zip code) -- VB.Net

Also included is a control that looks up Stock Quotes. I just wanted to test my solution out with a good mix of C#/VB.Net projects that also called webservices so I quickly threw these together. And since they were done, I included them in the package.

Details and download here: My Modules

Nik

thanks a lot Nik

I allready cooked up something like this myself but after checking yours is muc cleaner so I compiled on of my modules in it and it worked, very nice. Now I have to make some errors and test that other debug script.

Thanks for this share. Once again, I bow in your presence. ;)

Very cool! A great "solution" that makes DNN development easier and faster.

The only thing I might add in the instructions for those newbies amongst us - and I include myself in that group - is:

* In addition to modifying the url in *.webinfo, also change any references in My Modules.sln.
* Make _DNNStub the startup project.
* Set Default.aspx as the startup page.

And it just works!

Thanks for sharing.

Simon

How relaible is the stub project? Will it have to be updated with each new release of DNN?

Also, I had an issue once where one of my modules wouldn't work because I didn't have the FreeTextBox provider project as a part of my solution. Do you think that would be a problem with this setup?

I'll test it out now and see how far I get.

Thanks for the feedback.

Simon: I'll change the instructions on the references, but I am a little puzzled by the startup project/page bit because I thought I had already had it that way. Hmmm...I must have messed it up before zipping up the package.

Nik

The Stratup Project/Page appears to be a local setting within VS. Every solution I have moved to another system always required re-setting Startup. To my knowledge, the only option is to include the steps in the instructions.

alexdresko,

The stub project does not have references to anything other than the projects within that solution (i.e. your projects). The only core file it references is Default.aspx. So the answer to your question is "no", it will not need to be changed with new releases.

About the FTB, I will test it out. Are you doing something FTB-specific in that module? If not, it may be better to use the HtmlEditorProvider so you don't have to worry about the editor during development.

Nik

Maybe I missed this part of the instructions, but shouldn't you also add that one needs to add references to any related DotNetNuke assemblies. How else would you derive your pages from PortalModuleControl. And if you reference the assemblies in the DNN root /bin folder, wouldn't there be locking problems when compiling?

Also, you say you prefer to use web projects, but how do you create a new web project without creating a virtual directory in IIS? The VS.NET 2003 wizard always tries to create a virtual directory at the address specified in the new project dialog. Just curious.

mbblum

Did some research and discovered that these values are stored in the Solution User Options (.suo) file which is re-written when the solution is opened on a different computer. Instructions it is....

Nik

The difference I see between your method and Bo's method is that your method allow you to use a web project, right?

Oh and I meant HtmlEditorProvider in my previous post, not FreeTextBox provider. I always use the built in EditControl.ascx in my modules. The module would compile fine, but wouldn't display properly on the live site because, I believe, the assembly wasn't being built. In your case, however, the DNN assemblies are never destroyed upon rebuild, so there's a good chance your solution avoids this problem.

Works great! One problem I'm having though is that when I try to debug (Debug/Process/aspnet_wp.exe), VS.Net never gets a handle to the running assembly (breakpoints have a '?' and it never breaks).

Did I do something wrong?

alexdresko: Any individual projects you create in this solution can reference any required DotNetNuke assemblies. This will not cause a problem. In fact the custom module projects I have included in the solution do just that.

The difference is that since you are not referencing any DotNetNuke *projects*, DNN essentially remains a black-box. There are no locking problems with assemblies. VS.Net, by default sets Copy Local to True when you reference an assembly. In my solution, I set this to False when referencing any core assembly so I don't have multiple of copies of DotNetNuke.dll and CountryListBox.dll, etc.

When I create new modules, after VS.Net does its thing, I run a little app I wrote that sits on my system task bar. It goes through the entire DNN folder hierarchy and removes any IIS application flags from the metabase, deletes web.config, global.asax and webform.aspx files it finds. I am so used to clicking it, I forgot about this. But it is only mildly annoying to do this manually via the IIS MMC.

rccrash: Most likely you are debugging with a release build. Check the drop-down on the VS.Net toolbar and make sure it's set to debug.


michael: I looked at the information Bo had on his site. Unless I am misunderstanding, his preferred approach is to create a Solution for each module. I have only one Solution. I am unclear on whether he prefers web projects or not. Clearly, I do because it makes development easier. If you Google around, you will also find the registry keys one can change so VS.Net allows web project files to be created in a class project, eliminating the need to do anything in IIS.

Nik

off topic, sorry...

if I say reference a project VS never lets me anyhow... so how do you reference a project vs. assembly? As long as I am selecing the DotNetNuke.dll in bin .. is that all I care about?

Thanks....