I have often heard it said that people have difficulty creating skins for DotNetNuke.  I am always baffled when I hear these comments especially in light of what I see in the competing skinning engines on other platforms.  In this series of posts I’ll be looking at the basics of DotNetNuke Skinning, creating a complete DotNetNuke skin and associated containers, dispelling a few Myths and Misconceptions about DotNetNuke Skinning and finally we’ll wrap up the series by comparing the DotNetNuke skinning engine with those of some other web platforms.

• Part 1: Understanding the Basics
• Part 2: Building a Skin
• Part 3: Building Containers
• Part 4: Packaging
• Part 5: Myths and Misconceptions
• Part 6: Skin Engine Comparison

During the course of this series, we’ll be working towards building and packaging a skin that is based off of the Dreamy design template from the Open Source Web Design site.  This template uses a very simple design layout which should work well for explaining the basic concepts of DotNetNuke skinning.

Packaging

History

One of the great strengths of the DotNetNuke platform over the past 6 years has been the rapid growth of the ecosystem for modules and skins.  Very early in the project’s history we realized that in order to promote redistribution of extensions, we needed a standard method to package modules.  At the time, one of the community members contributed their code for reading a standard xml file located inside a zip file containing all of the module files.  Using this contribution as the foundation, I created the core module installation feature for DotNetNuke.  The xml file that controlled the installation process came to be known as the module manifest. 

The purpose of the manifest file was to identify key files within the package and designate where they should be installed.  This manifest also contained some additional metadata that was necessary for creating the needed entries in the different module tables within DotNetNuke.

Over time, Charles and myself continued to extend the module manifest and the packaging standard so that we could handle more and more installation scenarios. Even with these additions, the manifest and packaging standard was still basically the same as what I had originally built in 2004.

When Skinning was introduced with DotNetNuke 2.0 it used a different packaging standard.  Instead of relying on a manifest, it used a convention based approach and depended on having files follow a specific naming standard.  This worked well, but it had a number of limitations.  Like the module packaging standard, this remained largely unchanged until fairly recently.