Packaging modules

Jan 20, 2011 at 3:35 PM


I was thinking a bit about packaging: I don't know what you have in mind, but why can't we use DNN built-in packaging system to package XsltDb modules?

A couple of options:

1) DNN packager is now flexible and allows to package any kind of extensions, not just modules - although a module package is probably the best fitting the purpose to package XsltDb modules (I mean xslt + additional files, say css or css for example). I'll try to package one of my xsltdb modules this way soon.

BTW, dnn packager should respond to requirements you specify here:

  • Packager. The goal of packager is to put all configurations, SQL scripts, pages of solution in single archive and provide one click installation and upgrade.
  • Version management.
  • Database upgrade (per-version scripts).

It would be great to have some tool to help automating packaging, but if we use dnn built-in system we get most of the work done.


2) we could also use IImportable and IExportable to export an XsltDb module instance to an xml file,  - adding both the xslt and module settings to it.  This is not actually packaging a module, but could be useful (I rarely use such dnn feature, but it came helpful a couple of times).


Both shouldn't be difficult nor time-expensive to implement. And we could add a "facility" to let Rich Client upload packages, and delegate xsltdb to make install them (launching dnn package installer).

Were you thinking about something different?




Jan 20, 2011 at 6:02 PM


1. Firstly, I thought that I shall create a wizard that will create a package with configurations and pages probably with other modules (not only XsltDb). Just like SharePoint Solution. But now I'm switching to creating regular DNN modules that will be actually just metadata in DesktopModules table and will just reference XsltDb controls somehow. So users can easily put XsltDb-based module on page, XsltDb-oriented developers can easily create an installer directly on DNN site. 

2. XsltDb does implement IPortable interface, So you can easily export/import configurations. And if you have a super module XsltDb importer just link imported module to existing configuration (Host-wide). So super module is something like a DLL. If a module is not a super module XsltDb will always import it as new configuration with new GUID.

At the moment I'm working on advanced SQL caching. This is very important for me as my growing 20% per month and I really need a way of reducing SQL Server load. mdo:sql already has an option to put results into cache for a specific period of time, it also can poll database for data change and finally I'm going to releasea new version with ability to setup notifications and have a granular caching capabilities. Actually, just putting data in cache for 5-20 seconds reduces SQL Server load up to 2-5 times. After I deploy polling/notification to production server I plan to win even more performance and avoid displaying expired data.

Packaging features is the next task. This is very important for XsltDb promotion. If developer can easily distribute what he does he will distribute it and advertise XsltDb. Maybe I could add a kind of obfuscation or configuration encription to allow developers selling their creatures.

Jan 21, 2011 at 7:40 AM

I review new DNN 05.06.01 and found that they provide a new Razor Host module that allows creating modules online using Razor syntax. Actually, they can make it working for normal ascx files too (maybe they did - I didn't check). Actually they didn't add any functions for the moment. They just created Razor scripts repository manager as list of files with create/edit/delete command.

What is important here - they provided a special web control that is capable to render Razor script. So we can create redistibutable package putting Razor script togethet with single-line ascx file. This is what we are talkig above!


I believe that Razor Host will make online development process very popular.


Jan 21, 2011 at 9:04 AM


I also upgraded yesterday, but could not test razor host since I don't have .net 4 available for now (shared server). Hope I can soon, since what you say  we can have both xsltdb and razor's features in one solution... and this looks like to be VERY VERY VERY interesting :-)

And yes, I agree caching is very important. Not for a small site like mine, but that's necessary for "real" sites. Great job. I was also thinking to try using something like an XML db (file based) to manage storage for xslt modules, but didn't have time to check for solutions yet.

I don't know sharepoint packaging (nor sharepoint itself actually), but agree we can start with standard packaging dnn users already know how to use - this would allow easier distribution of xsltdb modules indeed, as you tell. Ok no obfuscation/encryption there, but you can always hide code in controls and DLLs if you really need. 

IPortable: another feature I didn't notice! I just made a test exporting a module from one site and trying to import it to another, but got an error when importing. Will try again anyway.

Hear you soon,






Jan 25, 2011 at 8:40 AM


I just installed beta .43: no problems at all.

HTTPS: I still have to setup correctly cacert certificate, otherwise I get SSL validation errors when loading data from mdo:service, but the module is right. Will try to fix cert today so that I can do more tests.

Packaging: wow! :-D Installed google news sample flawlessly, and it behaves like a standard DNN module! Great option to distribute modules. I also did a quick test with package generator, and it's also working well - I'll build a full package asap for distribution tests.

I think we now have two "problems":

  • package contains the xsl (encoded) source: not good if you want to sell a module, but we could use some hashing algorithm to obfuscate code, can't we? If you don't want to protect code, it is perfect as it is now.
  • on the other hand, once installed, you cannot access module source nor on site (no "edit xslt" link) nor with rich client (module is not visible there).

Conflicting needs, I'd say. Of course we can continue to distribute source code without packaging, like we're doing now, if we want to make source code visible. Or.... what about creating two kinds of packaging? I mean, would it be possible to create a "distribution" package like this one (eventyally adding obfuscation), and a "developers" kind of package, that does install module but also makes xsl visible to rich client? Would this be useful?

Great job anyway, I very much like this feature!


Jan 25, 2011 at 10:59 AM

1. I've found that .NET allows saving compiled XSLT as Assembly in DLL file. After that we don't have XSL as text anymore. So it can be an option in XsltDb pre-packager. Ater that DNN packager will put it into ~/Bin. Those packages could be sell with common options (one domain, one installation, unlinited with sources, ...) And I even can write those verification myself and automate creation of a set of limited editions.

2. I will provide editing capabilities for XsltDb-based modules later. But I need to make some researches. I need support for multi-configuration modules (like Articles). This may require configuration version management (avoiding DLL hell). Maybe something else.

3. There's a naming problem with pure HTML controls and mdo:callable functions. If I create 2 or more XsltDb-based module instances on a page - duplications of control names and javascript functions occure. I don't know at the moment how to fix it But I definitely will. As a possible solution ASP.NET naming mechanism can be applied. Javascript function can be moved to page header using <mdo:header/> section. But mdo:callable naming is still open issue each module should call it's own callables...

If you'll find somthing like that - drop me a message.

Jan 25, 2011 at 11:40 AM
Edited Jan 25, 2011 at 11:41 AM


I finally fixed my problems with cacert certificate (see, and all is working perfectly under ssl.


1) .NET allows saving compiled XSLT as Assembly in DLL? I didn't know, great! And no need to obfuscate who-knows-how code, very well.

2)  multi-configuration modules, and/or module supporting IActionable (e.g. actions described in their own template?), would be great, and so would cfg version management. For distribution we can use DNN packager's built-in capabilities to manage module versions, and rely on compiled DLL version, but again... if DLL are compiled XSLs then we need cfg versions (or, but don't think this is a good idea, not using configuration at all for distributed modules). To be investigated.

3) I usually use moduleID to name controls and even js variables and functions, to support multi-instance. This is what I do in XSLider and XSLideshow, for example:


<div id="xslider{mdo:dnn('M.ModuleID')}" style="display:none;">

referencing controls and functions in js:




function GoSlippy{{mdo:dnn('M.ModuleID')}}(){



This is actually very similar to ASP.Net naming mechanism, thought not automated.

ASP.Net controls inside XsltDb already are ok - they use standard naming mechanism, right? As for mdo:callable, maybe we can try to automate such mechanism? 

If you declare a callable named "MyFunction", actual function should be implemented as MyFunctionNNN, where NNN is moduleID, when builing output. And we would only need a function to get the real js function name at runtime (MyFunctionNNN), like we have mdo:service-url() to get service url for the specific module.

Bad idea?