Last week we showed how to create a basic Program Assembly (PA). You’ll remember that a lot of the process was manual. And if you make a process manual, it is always open to error.
But there is a better way. By using the Microsoft Web Deployment Project along with the MSBuild Community Task, you can completely automate all but creating the DNN file.
If you're new here, you may want to subscribe to my RSS feed. Thanks for visiting!
By now you have the basics for creating a DotNetNuke module. The only question we have left to address is, how do we package this all up so that we can install it on another server?
The file we are going to create is called the Program Assembly (PA) and is a zip file that contains all the files that are needed for your module on the server and a file with a DNN extension that defines the module so that all the configuration options we put in DotNetNuke to define the module can be placed on the DotNetNuke installation we will install the PA into.
So far we’ve done all of our development assuming that we are developing our module for internal use. To be fair, that’s what most of you all will be doing. There are a lot more of you who will be developing modules for internal use who will be fine with the architecture I’ve already given you, i.e., all of the files in one project.
But what about commercial projects?
On Monday we discussed how to save setting information for our modules. Today we want to pick back up where we left off and deal with retrieving that information, both in the LoadSettings() method and in the view module.
Since each instance of a module that we put on a page should be able to have it’s own configuration information, it is necessary to have some place that will allow us to configure it.
For example, you may have a module which could display itself in a number of different ways. You need some way to set this and the settings ASCX file and the associated codebehind file is the place to do this.
< (more…)
