mojoPortalAdvanced Web Sites Made Easy

Packaging a Build of mojoPortal

I don't recommend trying to use the Visual Studio publish feature to package a build of mojoPortal. That feature is designed to base everything on whether a file is included in a particular project. In mojoPortal, some features are in external projects and are copied to the Web folder by post build events, and these files are not part of the Web project so the VS publish feature doesn't include them when it makes a package.

Whether using VS 2005 or VS 2008, I highly recommend the free tool Unleash It for deployment. It deploys just the typ of files you configure and is ideal for packaging a set of compiled files for xcopy deployment on a server without unnecessarily including C# source code or solution and project files. UnLeashIt lets you decide which files to package by their file extension and doesn't care about whether a file belongs to a Visual Studio project or not. Thats why it is such an ideal tool for packaging builds of mojoPortal. It works well with the way we have our solutions structured whereas the built in VS publish feature does not.

Be sure and do a Release Rebuild of the solution then open Unleash It and browse to the web folder under the solution for the source folder and browse to a destination folder of your choosing.

You can adjust the files that it includes in the deployment by clicking the little red check mark next to the dropdown that says Quick Deploy Profile.

In addition to the defaults, you need to add masks for
*.html
*.asmx
*.ashx
*.xml
*.xsl
*.master
*.skin
*.xsd
*.browser
*.svc
*.theme
*.png
*.ico
*.resx
*.htm
*.xap
*.swf


I alway deploy first to a local folder in order to do some additional cleanup before deploying to production. My cleanup steps are as follows:

1. Open the Web.config file with a text editor and change near the bottom, change <compilation debug=true to false. This is for best performance on production servers.
2. Look in Data folder and delete currentlog.config and test.config files, these will be re-created as needed so best not to deploy them.
3. Look in Data/Sites/1 and delete test.config
4. Look in Data/Sites/1/systemfiles and delete any files in there. These are temporary files that will be created on the server so they should not be deployed from your dev machine.
5. Delete the obj folder under the root of the web

Now the files are ready to copy to the production server

Deployment To Production

When I speak of deployment to production, I mean deployment of an updated build of the code. I do not mean deployment of data from a development or staging machine to production. I recommend that you always create and edit data on the production server and never try top push data from a development or staging machine up to production. Data should always go the other way, that is you get a backup from production and restore it in your development or staging environment. Creating data on your development machine and then trying to move it to production will lead you to more difficulty.  You will especially have trouble if your development url is a virtual directory like http://localhost/mojoportal and your produciton environment is a root web site like http://www.somesite.com. Also trying to push data up to production will leave the search index on production out of sync with the content in the database. Save yourself some grief and follow my advice on this.

So the general flow will be as follows:

1. get a backup of the database from production and restore it on your development machine
2. get the latest mojoPortal from svn and rebuild the solution
3. then visit the /Setup/Default.aspx page on your development machine to run the upgrade scripts for the database.
4. if all goes well you can expect it to go the same way on production, it may be prudent to do some testing on development or staging before proceeding with production deployment
5. rebuild your solution in release mode
6. package your files using UnLeashIt as documented above
7. deploy your packaged build to production
8. visit /Setup/Default.aspx to run the upgrade scripts on the production db

Thats it, your production system is up to date and in sync with your development or staging environment.