Hi Guys, this week I will show you how I migrated my previous WCF service to be hosted on the Azure cloud instead of Amazon. I decided to follow a two step process: first I will migrate the service as it was previously, that is it will still rely on the AWS API to store and retrieve the data but it will be deployed on Azure, then in the next post I will migrate the code in order to replace Amazon SimpleDb and S3 by Azure Tables and Blob services.
I – Creating a new Azure project
If you haven’t done it yet, you will first need to install the Azure SDK, which is rather straightforward, so I can just skip that step. We then need to create a new “Windows Azure Cloud Service” project:
We then add a “WCF Service Web Role” to our project. That’s the instance that will host our service:
At that point my default project looks as follow:
I am going to remove that default “Service1” and replace it with the existing code I had from my previous project. After including those files in the new project and my two client app, my solution looks like below. At that point I did nothing more than suppressing and including files:
I also cut and paste the content of my old web.config file to the new one. The Azure web.config contains more sections than the one I had before, so I take care about placing the old content at the right place. Also because Azure do not support directly using Net.Tcp from a web role, we will disable the callback functionality and keep only the http and json endpoints.
The Azure config file looks as follow and I am highlighting the portion I was adding myself:
<!-- To collect diagnostic traces, uncomment the section below or merge with existing system.diagnostics section.
To persist the traces to storage, update the DiagnosticsConnectionString setting with your storage credentials.
To avoid performance degradation, remember to disable tracing on production deployments.
<add name="AzureLocalStorage" type="WCFServiceWebRole1.AzureLocalStorageTraceListener, WCFServiceWebRole1"/>
<source name="System.ServiceModel" switchValue="Verbose, ActivityTracing">
<source name="System.ServiceModel.MessageLogging" switchValue="Verbose">
Microsoft.WindowsAzure.Diagnostics, Version=220.127.116.11, Culture=neutral,
<filter type="" />
<compilation debug="true" targetFramework="4.0" />
<serviceHostingEnvironment multipleSiteBindingsEnabled="true "/>
To browse web app root directory during debugging, set the value below to true.
Set to false before deployment to avoid disclosing web app folder information.
The service is now ready to be built. if the build is successful, you should be able to debug it as you would do for a classic .Net application and it is pretty cool because Visual Studio will launch the compute and storage Azure emulators on your machine and you can test your service locally, including using breakpoints. No manual action is required for this local deployment.
II – Deploying the service on Azure
Once you are done with testing locally, it’s time to place the service on the cloud. First step is to generate the deployment package. Right click your service project
and select “Package…”. This should generate two files:
The first one is the Azure configuration file, the second contains the whole Azure package (binaries and so on…)
You then need to log on into the Azure management console (of course after having sign up for the services or take advantage of the free trial offer):
Go to the “CLOUD SERVICES”, then +NEW. You can see in my case a colleague already deployed a service on our common account:
You’ve then got to upload your package files and set a couple of options, especially the name of your service and your public base address in “ServiceName”.cloudapp.net:
If you’ve done everything ok, your service should be up and running after a few minutes… easy! You can check the attachment for a complete reference. Next week I will show you how to migrate the code to rely on Azure APIs, cheers!