The Setup system used for the core mojoPortal features has been designed to allow developers to use it to install and configure and upgrade their custom features.

The services that the mojoPortal setup system can do for you are:

1. Run database scripts to create or modify tables and other database objects needed by your application.
2. Install the feature into the site. That is, it can make an entry into the db that represents the ModuleControl (which is the part that can be placed on pages in the content system) of your feature and it can configure module settings used by your feature.
3. For new installations, you can also configure the addition of content pages and placing instances of content features on a page. This way you can package up deployment files preconfigured to create a page and put your feature on it. You can even leave out included mojoPortal features

One important thing the Setup system does not do is install your files. You should design your feature for XCopy deployment which is the same simple deployment approach used by the core of mojoPortal. XCopy deployment simply means you copy the files to the server. For packaged releases of mojoPortal, the "wwwroot" folder represents the root of the site. Typically you ftp all the contents of the wwwroot folder to the root of your web site on your web server. You should use the same approach when creating a package of files for deploying your custom feature.

Specifically, you should have a "wwwroot" folder as the root container for your files, and files should be organized such that if you copy the contents from your wwwroot folder to the root of the site all the files go to the correct places. You should make sure that your files won't overwrite any of the core files. So for example you want to make sure you don't have a Web.config or Default.aspx file in the root folder of your custom feature because these would overwrite the corresponding files from mojoPortal core. If you need a separate Web.config for supplemental settings or if you need a Default.aspx page you should structure your application so that those are in a sub folder with a name that doesn't clash with any existing subfolders in mojoPortal. Your folder structure should be like this:

wwwroot
  bin
  yourwebpageandcontrolsfolder
  Setup
     applications
        yourapplicationname
           FeatureDefinitions
           SchemaInstallScripts
               firebirdsql
               mssql
               mysql
               pgsql
               sqlite
           SchemaUpgradeScripts
               firebirdsql
               mssql
               mysql
               pgsql
               sqlite
     indexbuilderconfig
     initialcontent


yourapplicationname should have no spaces in the name, and I recommend you use a lower case name, again it must not clash with other features. You don't have to implement all the different databases for your custom feature. For example if you will only be implementing scripts for MS SQL just put those in the mssql folder and leave the others empty. Of course if you are implementing features you would like to sell to other mojoPortal users it might be good to implement them. mojoPortal source code includes some Codesmith templates for generating code for the different data layers. I use these scripts myself when developing features for mojoPortal.

The scripts will be text files named with a version and a .config extension. For example for a brand new feature you might name the first script 0.0.0.1.config and put it in the SchemaInstallScripts/mssql folder. The script would contain all the sql statements to create your tables, stored procedures, and optionally add any needed data.

Then later lets say you add a small feature which requires a new column added to one of your tables and also requires modifying a few stored procedures. You would put the sql statements to do that in a file named 0.0.0.2.config and drop it in the SchemaUpgradeScripts/mssql folder

To run your scripts just visit the webroot/Setup/Default.aspx page. Setup will loop through the SchemaSetupScripts and SchemaUpgradeScripts folders for each application and if it finds scripts with a higher version than the last script it ran for your application it will run the script and record the new version for your application in the mp_SchemaVersion table. It will also log each script in the mp_SchemaScriptHistory table.

Typically you would create this folder structure within the Web UI app for your feature and use post build events to copy the files down to the mojoPortal Web folder during development. When you are ready to package up release files without C# source code you can use the free UnleashIT tool to deploy your files to a local folder then review to eliminate any files that would overwrite core files.

The FeatureDefinitions folder is where you put config files that define the ModuleControl(s) used in your feature(s) and also allows defining Module Settings used by your feature. You should give your feature a unique guid. The guid is used to make sure all the module settings are configured by looking up what module settings are already there for your feature. So you can add new settings at any time and visit the setup page and the settings will be added to your feature if they are not already there.

The indexbuilderconfig folder is the place to put config files for any IndexBuilderProviders you may have implemented to make your feature searchable.

The initialcontent folder is a place to put files that define what pages are created during initial setup. So you could configure a file there that creates a page and puts an instance of your custom feature on the page. This is just a simple xml file, see the included example(s) for a reference to settings you can specify in these files.

 Last Updated 2010-12-05