Packaging DNN extensions

Editor's Notes

• #2: Extension packaging is a powerful tool that extension creators have at their disposal to create a rich, consistent, safe experience for their users. Learn how you can take advantage of all of the tools that DNN provides for the installation experience, and how to avoid some of the more common pitfalls when creating installable extensions for DotNetNuke.
• #7: Left side: extensions Right side: other types of installer components
• #8: Packages with the same name (e.g. maybe related Skin & Container packages) will install correctly, but then you can't update or repair them.
• #9: DNN 5 doesn't automatically check your Business Controller Class for its supported features, as it did in DNN 4. You can specify Searchable and Portable in the supportedFeatures element in the manifest, but you have to specify that eventMessage section to get IUpgradeable to work (and it only runs for the versions in the updateVersionsList node).
• #10: In order to not have to specify every file in your manifest, you can use the ResoureFile component to reference a .zip of those files, instead. This doesn't work, however, for files that the installer needs to reference (i.e. SQL scripts, assemblies, cleanup files, license files, etc)
• #11: The files in the assembly component are implicitly rooted to the bin directory (so you don't need to specify that in a basePath or path element). You can use the sourceFileName element to tell the installer the path to that assembly in your package (i.e. just tell it the name of the assembly if the assembly is in the root of your package)
• #12: If you install a DNN 4 module in a DNN 5 site, all of its assemblies will be marked with the version of the module. If the module's version is higher than the actual version of that assembly, you'll have trouble overwriting the older assembly once your package is using the DNN 5 manifest (or if you have a different module that uses a DNN 5 manifest with that same assembly)
• #13: You can use these to get started with automated packaging
• #14: Looking in the Install folder of a DNN site before it has been installed will give you a great number of examples of packages, as well as examples in the Install/Config folder of the types of config changes you can make. . The Config component lets you update an XML file (usually web.config), removing the need to tell your customers to muck around in there. Remember to also include an uninstall script, as necessary, so you don't break their site upon uninstall.
• #15: You can use a cleanup component to delete old files, either through the manifest or an external file. The external file specifies one file per line, using ticks for comments.
• #16: You can specify that your package is dependent on a specific version of DNN (or higher), or another package, type, or that it requires a certain permission.
• #17: If you put correct version numbers for your assemblies, DNN will manage making sure that the latest version of a shared component is used.
• #18: You can use the .dnn5 file extension to create a package that both DNN 4 and DNN 5 can process (DNN 5 uses the .dnn5 manifest, DNN 4 uses the .dnn manifest). You can provide HTML in the release notes, license, and other fields that show in the install wizard, to provide a richer experience to your customers.
• #19: If you're interested in an excellent platform for DNN Q&A, consider committing to being a part of the DotNetNuke Stack Exchange proposal. I honestly believe it will revolutionize how we help each other and get helped when developing, integrating, and maintaining DNN sites.