Part 1. Updating from Orchard CMS 1.6 to Orchard CMS 1.7.1 and deploying to Windows Azure

Posted Friday, Oct 11, 2013 9:18 AM EST

Arra Derderian

After running Orchard 1.6 in Windows Azure Cloud Services for about 4 months now, I was pretty excited to see all the updates that came with Orchard 1.7.1 for Azure. Making Azure a first class citizen of Orchard really will help its adoption by new users. Having an already very functionally scalable CMS along with the performance scalability that Azure brings makes this a very powerful platform.

I had been running Orchard 1.6 in Azure cloud services with two small web roles and SysCache enabled for a bit when I started to realize that any sort of caching on a web role would result in some issues. (I noticed some updates not propagating across instances, and also duplicate content items when saving/publishing.) I disabled all caching and relied solely on the out of the box speed of the site and Azure to serve my content. The second difficulty of deploying to Azure was the need to use the Azure.proj file included with the Orchard source code download. This file allowed you to run the ClickToBuildAzure.cmd and it would be package the site up into .cspkg and .cscfg files. This then allowed you to manually upload these to Azure. You could not deploy via Visual Studio web deploy due to inability of the Publish to copy the Modules & Themes directories up. This was a pain because we were not able to one click deploy from Visual Studio or take advantage of Continuous Builds in the cloud via TFS. (My team was able to modify the Azure.proj in order to get Team Foundation Services to eventually do what we needed. See this post for a walkthrough of these steps.)

Along comes Orchard 1.7.1 which alleviates both of these problems. Due to the combination of the Azure Tooling getting better in 1.7 (adding of Web Role Content folders, see the .ccproj for the “AddBeforeRoleContent” target step) and the Orchard Team whipping up some awesome modules we are now able to deploy multiple web roles with caching and deploy directly from Visual Studio.

As I said, I was upgrading from Orchard 1.6 so I followed the upgrade steps on to do so. After copying the source code on top of the existing 1.6 code I then had to modify some view templates in order to account for the new Media Picker namespaces. I created a staging cloud service, storage account, and new DB from an export of my existing SQL Azure database. This allowed me to have a trial environment to test my migration. I copied all storage data into my new storage account and updated my Settings.txt file to point to my staging database. I then updated my .cscfg file with my storage account settings. You will notice the old “DataConnection” setting was replaced by two settings, Media setting and Sites setting. Secondly, there is a variety of caching settings in the file that you can leave as default. These correspond to caches defined in your web role .csdef file and also in your web.config. Orchard 1.7.1 allows for co-role caching and a distributed cache as well. I am going to keep the defaults and utilize the co-role shared cache so my roles can share session state, output cache, and database cache. Once all this is verified and I have downloaded my publish settings file, I used the publish command by right-clicking the cloud service project to publish to Azure.

Once the publish completed, I was able to hit my site and it came back. It was all banged up, but I was able to get to the admin dashboard. After I did this, I followed the instructions to migrate existing data to 1.7.1 using the Upgrade module.Lastly, because I was in Azure I wanted to turn on my new Azure caching features to see how they worked.  I first turned off my existing SysCache and Contrib.Cache modules. Caching was now rolled into Orchard Core modules, so no need for Contrib.Cache anymore. I then turned on Azure Output Cache module and Azure Database Cache module. Both enabled successfully, and I logged out to test my site. After browsing a couple pages, the site started YSOD’ing all over the place. I had to RDP into my web role instances to turn “Off” custom errors in order to see the error. The error I was seeing was the AzureOutputCacheStorageProvider was saying “Positive value required for time-out”.

Read Part 2 of this post for solution to the caching error.

No Comments

Add a Comment