Ask Nik: DNN terminology and development approaches
pmgerholdt asks:
If you could field a newbie question – I have your “My Modules” solution open in VS. Say I start a VB Web Project. I can do that much – build a web project. How then do I get it to appear in DNN? Do I have to copy files to a zip file and load it via DNN’s interface for modules? Or does it automagically appear in DNN by virtue of sharing its space? (That’s why I recompiled DNN – I thougth your RandomImage Mod would become part of DNN …)
And is there a difference between a module and a PA … or is a module an instance of a PA – or is a PA one way of making a module while there are others?
Aside from just building from scratch, I’ve seen three approaches. Yours looks most simple and direct to me if I can get past the fact that I don’t understand some essential basics. I’ve also looked at Bo’s instructions and gone a ways down that road. But that really is extending the core, isn’t it, rather than providing modules? Finally there are the code templates on DNNJungle.
Am I right in seeing these as three different approaches toward a similar goal?
Nik’s answer:
Newbie questions are good. They force new synaptic links.
To answer your first question, there is no co-relation between the process of adding modules (controls) to the DotNetNuke DesktopModules folder and the module listing in your DNN portal. It would be nice if this happened automagically, but the unintended consequences would not be pleasant. For this reason, you must do one of the following to have a module appear in the listing:
1) Add it manually: This is the quickest way, especially when you’re developing. Login as Host, and go to the Module Definitions page. Create a new Module definition and add the controls corresponding to your module to this definition. (I have intentionally left this description vague as it is a topic that deserves its own item.) Once this is done, your module will appear in the Modules Listing.
When you use the My Modules approach, you only need to build the custom module you are working on at that time. If you have a reference to your project from the _DNNStub project as recommended in the instructions, the important task of ensuring that your module’s PA (private assembly or DLL) is correctly placed in the DNN “bin” folder is automatically handled.
Anyway, adding the Module Definition is all you need to do. After this, you can go to a portal page and add the module to the page. At this point, you will realize that you goofed somewhere. I have no statistical evidence, but I am inclined to believe that no one has ever created a module (that does anything worthwhile) that got displayed the first time it was added to a page during development.
There are a multitude of things that could be wrong. The most likely — a problem in your ascx script file. This is where the DNNDebug.aspx script that’s included is of use. Fire up a new browser window and call up the DNNDebug.aspx script. Type in the path to your control (example: ~/DesktopModules/ModuleName/somecontrol.ascx) and DNNDebug.aspx will tell you where the problem is. If it loads without error, then you know that the problem is in code-behind. Pat yourself on the back for successfully creating a working script with ASP.Net’s mind-numbingly annoying syntax, and go back to VS.Net and your module’s code-behind.
From here, you are on your own (unless you have a specific question).
2) Add it with the installer: This is a task best left for when your module is working beautifully on your development machine and you are ready for your ego to be crushed by end-users. Packaging a module for deployment basically involves zipping up the resources and creating a .dnn file. This is too detailed a topic to discuss here so I will (lazily) skip it.
Modules, PAs and Skin Objects
When a new platform evolves, so does its terminology. Often, to the chagrin of newbies as the terminology tends to make confusing some very simple concepts. Here then, is the non-authoritative guide to these terms:
Module: A module in the DNN context is a mini-application that runs within the DNN portal framework. It is a term that represents the composite product as viewed by users of the portals (regardless of whether they are host/admin/end-user). A module may consist of ASP.Net controls, assemblies, images, stylesheets, the kitchen sink, SQL script etc.
PA: PA is an abbreviation of “Private Assembly” and is a synonym for DLL (dynamic link library). .Net assemblies can be DLL’s or executables (EXE’s). Executables are standalone Windows programs, while DLL’s need a host. In the case of DNN, the host is the ASP.Net engine. When you have an assembly that is stored in a (web) application’s bin folder it is called a “private” assembly as it is usable only by that application. At this point, as an attentive reader, you are probably thinking, “oh cool…maybe there are also public assemblies?” Well yes and no. Public assemblies exist but to avoid the syntactic challenge of having the same abbreviation, public assemblies are called Shared Assemblies. They are stored in an area of your computer called the GAC (Global Assembly Cache) and are available to all applications. More about this here.
Skin Object: DNN skins can use standard ASP.Net usercontrols and components to enhance the portal. You can develop skins as HTML files (parsed and converted to ASP.Net user controls when uploaded), or you can bypass this process and code them as an ASP.Net user control (ascx) yourself. If you go the HTML route, there has to be a mechanism by which the HTML code can indicated how/where the ASP.Net usercontrols/components that are to enhance that skin are to be embedded. For this, DNN has an XML support file that must accompany the skin. Altogether time-consuming and quite useless. I recommend you create a skin as an ascx file from the get-go. It is not that different from HTML and is a lot easier to use and troubleshoot.
Anyway, coming back to definitions. My definition of “skin object” is “a term that is useless and should go the way of the Dodo.” In all seriousness, why have a new term when ASP.Net usercontrol or ASP.Net component work. So when you see “skin object” just thing ASP.Net usercontrol or component.
Different approaches
I cannot speak for other people’s work/resources. The “My Modules” solution exists for one simple reason — to make it easy to develop modules if you have no interest in modifying the DNN core code. The solution provides clean upgradability, since when you upgrade the DNN code, you have to do nothing in the “My Modules” solution configuration. You will have to rebuild the solution and if there are breaking-changes in DNN itself, handles those in your code, but other than that, you no longer have to struggle with DLL conflicts and VS.Net cache issues while compiling. I have almost 50 projects and never see any DLL conflicts with this approach.
I will point out one thing that will help you distinguish how a resource is applicable. My approach falls in the realm of VS.Net “organization.” A way to ensure that your VS.Net solution/project works with minimal headache and maximum efficiency. The other realm is VS.Net “development.” Templates/scripts etc. are all aids to speeding up the process of development with the goal of creating an “end-user solution.”
As developers, we frequently lose sight of the end-user. Although it is fun and challenging to play with code, ultimately most of us get a pay-check only if our experimentation produces a solution — not a module, skin object, PA or executable — but a solution, for the end-user. I encourage you to use as many resources others have generously made available to create a development environment that accelerates solution development by allowing you to focus on the task and not the tool.
Peer I/O out.
