I'm building a module for our local developer use... ie it doesn't have to be packaged up and available to the DNN Universe at large.

I'm using SCC for our local portal, and so I put the configured code base into SCC for safekeeping.

Now, I'd like to enable people to develop modules in projects outside the DNN website tree, and then have post-build events copy the stuff into the right places so DNN will get the update.

Most of the tutorials just assume you want to set up and develop module projects right in the DesktopModules folder, but it seems like the wrong place for .csproj files and makes it tough to determine where the basic DNN code base ends and our local extensions begin.

I'd like to develop a project template (similar to some others that were put out for use) but that let you keep your module projects outside the actual website tree and deploy all the right contents to the proper places in the DNN website tree so that the new code will be recognized.

To do this, I would like to know exactly WHAT is truly required for DNN to actually run your module. Does /App_Code HAVE to have a module dir with your .cs code-behind files?

I would really like it if someone could make a sticky-post with what, exactly, is required by DNN to a) recognize and b) run a module properly, OUTSIDE of a particular way of structuring module projects or deploying them (ie assuming that we want to use the .zip form of module deployment to the DNN Universe). It would be cool if there was some command line utility or something to register a module.

I guess there is so much effort given to providing a specific implementation style, that I don't have enough understanding to do it in any other way.

Thanks,

Jesse W.

Jesse,

Take a look at using the Web Application Project model of development.  This keeps all of your code in one project, compiled into one dll file (in addition to .ascx controls and other content).  The DNN core code is not in the project file, just the files for your module.  When you use this model, you can just reference the DotNetNuke.dll assembly in order to have your controls inherit from PortalModuleBase, and otherwise you don't need to develop anywhere near a DNN website.  This model doesn't support having code in the App_Code folder (since it all gets compiled into an actual assembly).

However, in our experience, placing your module inside of a DNN website offers great benefit when trying to make changes to the module.  Rather than having to copy the module to another site after each change, any change you make is quickly seen on the site.

The basics of the situation are that you need to register one or more controls with DNN (either through installing a package, importing a manifest, manually creating the module on the site, or manually accessing the database).  These controls need to inherit from DotNetNuke.Entities.Modules.PortalModuleBase.  If they use any logic outside of the control itself (code-behind or other classes), these need to be accessible to the site (either compiled into an assembly in the bin folder, or placed in the App_Code folder to be autmatically compiled, or, for code-behind, placed alongside the control).

I hope that answers your questions, let me know if you need clarification or any more information on these topics,