Posted by: Peter Donker
7/13/2010 

Ah, now that was a non-trivial task. I think I requested about half a year ago that we should be able to leverage the DNN 5 manifest enhancements without sacrificing the ability to target DNN 4. The first step was for DNN to allow multiple manifests to exist in a PA (= Private Assembly = the zip file that you distribute as your module). In DNN 4 if you have multiple .dnn files the installer immediately throws you out. So the solution was to be able to have a new extension for the DNN 5 manifest: .dnn5. I was really pleased that was picked up and implemented. So far so good. Now we can add a .dnn5 which DNN 5 will pick up and the .dnn which DNN 4 (and early versions of DNN 5 until this was supported).

Cool. 2 manifests. Now packing and getting the manifests right. If you’re like me you adore the resources.zip concept. My approach is this: the PA is built up out of a bunch of files. One resources zip which is unpacked in the module directory and all other files play some essential part in the installing of the module. I.e. ascxs, images and so forth go in the resources zip. But dlls (that go to the bin folder), scripts, cleanup files, etc, all go to the root of the PA. This works like a charm in DNN 4. You have minimal worries about file management in your manifest as you minimize the files you need to list under the “files” element. This is a hobby horse of mine: keep this to a minimum: number of files times the management detail of them. Since files that do something for the installer are more essential they require more careful management. Other files (like images in your module folder) are just less critical. This is why I feel strongly about the resources file. It allows me to package all the files that need no specific manifest management overhead.

Now that I’ve laid out how I like to package you can see how the DNN 5 model diverges from this. In the new installer the idea was that you create a complete file hierarchy in your PA and that the manifest names all files to copy. One relief is that the resources file was preserved in the installer so you can actually follow the model I laid out above. Where I had a hard time was getting the installer to accept that I had all important files in the root of the PA (which DNN 4 requires) and not in a pre-structured way the DNN 5 design would rather have. Specifically: DNN 5 expects that your dlls are in a bin folder in the PA. DNN 4 will break if they are in a subfolder, however. I had gone through Charles’ posts on the new manifest multiple times but I could not get it to work on DNN 4 and 5. However I tried either the installer would complain it could not find the file in tempfolder/bin/mydll.dll or it would copy the dll to the root of the DNN installation. Aargh. I did finally crack it after consultation with Charles. The file installer happens to support an element called sourceFileName which allows you to specify where the installer should get the file from.

Now to wrap it all up this is what you do.

1. Zip whatever you want to distribute in your module folder to a file called resources.zip for instance.

2. Copy this zip, plus scripts, dlls, cleanup files, etc to a folder for your final package

3. Create the DNN 4 manifest with the extension .dnn. The manifest will resemble this:

4. Create your DNN 5 manifest with the extension .dnn5. This starts as follows:

Scripts are included as follows:

Assemblies as follows:

And resource file as follows:

5. Zip it all up and you should have a PA that installs on DNN 4 and 5.

You can now use all the advanced features of the DNN 5 manifest for DNN 5 users. This includes owner info, license, release notes, config install/uninstall, etc.

Trackback Print

Tags:

Categories:

Location: Blogs Peter Donker