This blog post is about creating a Windows Azure Web Role project in Visual Studio and adding EPiServer CMS to it. It’s the third installment in the series “Running EPiServer on the Windows Azure Platform”. We’re going to be using the sample public templates project that ships with EPiServer CMS 6 and the database we created in the previous blost post.
Creating the Windows Azure services
First log on to the Azure Developer portal. Start off by creating a hosted service. The service label is the friendly name of the service, on the next view we’ll give it the public service name which will be the subdomain to cloudapp.net. This is essentially your website. If, like me, you’re in Sweden, then select region as North Europe.
Click New Service again and this time create a storage account. Just like before give it a friendly name. A tip is to set the public service name to the same as your hosted service but by sufix it with storage. E.g. epiazurestorage. Once created you’ll arrive at a view with URLs and access keys. Copy the primary access key into notepad, we’ll use it later.
Create the Windows Azure Cloud Service project in Visual Studio
Start Visual Studio and select File –> New Project. Create a Windows Azure Cloud Service project. I chose to name mine DBLOG.azure.cloud since this project will only contain information about the roles we’re going to deploy to the cloud. Next you must define which roles you wish to deploy to the cloud. We’re just going to add the ASP.NET Web Role since we’re deploying an EPiServer website. I call mine DBLOG.azure.episerver.
Delete the folders that Visual Studio adds by de default.
Right click the role in the cloud project and select properties. We’ll leave it as full trust since we’re going to be referencing EPiServer assemblies that require full trust.
Change the DiagnosticsConnectionString in Settings. Use the storage account we just created in the Azure Developer portal. The account name is the public service name (in my case epiazurestorage).
Set the target framework to .NET Framework 4 in the property settings of the project.
Copy sample EPiServer CMS 6 public templates website
Navigate to your sample EPiServer public templates website and copy the files and folders except for the project file and bin folder. Next create an [assemblies]-folder in your web role project and copy the files from the sample EPiServer website except for EPiServer.Templates.public.dll.
Now add references in your project to these assemblies.
Referencing assemblies
We’re missing a specific version of the System.ComponentModel.Composition assembly which is in the GAC. We need to help it escape. Start the command line tool and run the commands as shown in the image below.
Move the assembly into the [assemblies]-folder of the project and reference it. Make sure it’s the correct version as shown below.
Set copy local to true for all referenced assemblies. This is because on the Azure platform only .NET 3.5 and .NET 4 framework assemblies are available. We need to ship everything else as we publish the project.
Copy the CMS as well
Since we have no control over the cloud environment we need to move the files that were traditionally stored in program files and made accessible through virtual path providers into the project structure. Begin by creating a CMS folder and a Shell folder.
Copy the files and folders from program files –> EPiServer –> CMS –> 6.0.530.0 –> UI –> CMS as well as program files –> EPiServer –> CMS –> 6.0.530.0 –> UI –> EPiServer –> CMS into the CMS-folder in our project.
Next copy the folders App_Themes and Util from program files –> EPiServer –> CMS –> 6.0.530.0 –> Application into the root of our project.
Your final folder structure should look something like this.
Modifying EPiServer.config
Start by setting the site id to “*”. This is because on Windows Azure the account running our application does not have write access to the website folder. The EPiServer framework likes to modify web.config based on the ID of our website (it’s a license thing). So we’re going to “trick” it into leaving web.config alone, hence the asterisk.
Next set the uiUrl to “~/CMS” since this is were we put all our CMS-files earlier.
Remove all the virtual path providers except for “Page Files” since this is the only virtual path provider required by EPiServer. Set the physical path to “/PageFiles” or else EPiServer will attempt to create the missing file path and we’ll up with an UnauthorizedAccessException.
Modify EPiServerFramework.config
Set the site ID in EPiServerFramework.config to an asterisk.
Modify connectionStrings.config
We’re going to use the EPiServer-database we created in the previous blog post. Set the credentials as shown in the image below. My database is called molni – yours is probably not. :)
Modify web.config
You need to either remove all references to anything that is .NET 2.0 or specify the version as .NET 3.5 or .NET 4.
Let’s start by uncommenting wftools in the configsections-element and use version 3.5 of workflowRuntime and microsoft.web.services3.
Remove the assembly redirect since we do not need to redirect our EPiServer-assemblies. Add one for System.Web.Mvc to version 2.0.0.0.
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" culture="neutral"/>
<bindingRedirect oldVersion="1.0.0.0-1.65535.65535.65535" newVersion="2.0.0.0"/>
</dependentAssembly>
</assemblyBinding>
Set the membership- and role providers to use the .NET 3.5 framework instead.
Do the same for the sql profile provider.
Use version 2.0.0.0 of system.web.mvc instead of 1.0.0.0.
Set the roothPath-attribute of the protectedModules-element to “~/”.
Disable the remote events binding. Be aware that this could incur weird behavior and cause performance issues since we’re in a load-balanced environment.
Publish the project
Now we’re ready to publish the project into the cloud! Right click the cloud-project and select publish.
Select Deploy your Cloud Service to Windows Azure and in credentials select Add….
I won’t go into detail on how to set up the credentials – the dialogue box is very easy to follow. :)
We’re feeling quite daring so select Production right off the bat and click OK.
Now deploying can take quite a while – usually around 10 to 15 minutes, be patient. Also, once you’ve deployed your application it will begin to incur cost. So once you’re done make sure you delete it. It’s not enough to just suspend it.
Click the link and you should be good!
So what’s next?
I hope the database VPP from EPiCode will play nice in Windows Azure – this will hopefully fix the VPP issue. I’m also itching to create a virtual path provider using the Windows Azure storage API.
Run into problems? Since Windows Azure is more or less Windows Server 2008 running .NET Framework 3.5 and .NET Framework 4 you can set up a virtual test environment with just these frameworks installed. Deploy your application here and you’ll soon find out what’s causing the issues. Remember to only allow the application pool account read access though!
I hope you enjoyed the blog posts so far – I’ll see you in the cloud! Cheers!