Packaging and Deployment
Compiling the Code
Note that as of July 2014 we changed our target platform for the main projects to .NET 4.5.
.NET 3.5 is no longer officially supported.
.NET 4 is no longer officially supported but it may still be possible to produce a build for that using the correct mojoportal-net40.sln and the correct webnet40.config files renamed as web.config. It also seems in some cases that if .NET 4.5 is installed on your dev machine it no longer becomes possible to really build a 4.0 package, it will compile but it will really be a build against 4.5, because 4.5 replaces 4.0 and sometimes the reference version of 4.0 doesn't get referenced even though it is supposed to.
In order to build the mojoportal.net40.sln you need to copy the contents of the Web.net40.config file into Web.config, and you need to do the same thing with the corresponding config files at the root of the mojoPortal.Features.UI project and at the root of the WebStore.UI project.
For the official releases we will provide a separate set of dlls and a Web.config file for .NET 4 (while we still support .NET 4), but the main packages will be compiled for .NET 4.5
Using the Visual Studio 2013 Publish Feature
For a long time we have not supported using the Visual Studio Publish feature, but as of 2010-07-18, the Publish feature now works. You can compile the full solution, then Publish the mojoPortal.Web project and it will correctly include all the needed feature files. This is now possible due to improvements in Visual Studio 2013. In previous versions the Publish feature could only publish files that are part of the project and listed in the .csproj file, so it did not work well with our project structure where we keep features in separate projects and use post build events to copy the needed files up to the main Web folder. Since these files were not listed in the .csproj file, then they would not be included in the package produced by Publishing. But in VS 2013, we have a configuration choice for Include All Files in project folder. So we were able to change to this and add some exclusions to leave out the C# source code. So now the Publish feature in Visual Studio 2013 works well for packaging mojoPortal. This is really good news for those who want to use continuous integration and integrate mojoPortal into their own build process. You do need to rebuild the entire solution in release mode before publishing in order to include all the features.
I usually Publish to a local file system folder but other options should also work. But definitely if you are publishing from your development machine you should publish to a local folder first and clean up extra files from your development environment that should not be uploaded to production. Things such as the /Data/currentlog.config file, any files under /Data/systemfiles or /Data/Sites/[SiteID]/systemfiles or /Data/Sites][SiteID]/index should not be included. Other files such as images related to content on your dev machine are also files you may not wish to include in your deployment package.
- Choose the Release configuration for your chosen database platform, the one that just says "Release" is for MS SQL Server.
- Rebuild the entire solution
- Right Click the mojoPortal.Web project and choose Publish
Using Unleash It
There is also a free tool Unleash It that I have used for many years to produce deployment packages without C# source code. It deploys just the type 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. It also lets you save profiles with different file and folder masks. I still use Unleash It to produce packages of my add on products but I now use the Visual Studio Publish feature to produce packages of mojoPortal.
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
I always deploy first to a local folder in order to do some additional cleanup before deploying to production. My cleanup steps are as follows:
- 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.
- 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.
- Look in Data/Sites/1 and delete test.config
- 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.
- 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:
- get a backup of the database from production and restore it on your development machine
- get the latest mojoPortal from svn and rebuild the solution
- then visit the /Setup/Default.aspx page on your development machine to run the upgrade scripts for the database.
- 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
- rebuild your solution in release mode
- package your files using UnLeashIt as documented above
- deploy your packaged build to production
- 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.