In the previous posts in the series Exposing your data using .NET WCF Data Services we’ve covered everything required from building a data driven application from scratch to making the application ready to be fully running in the cloud. The final step in this process is to publish/host the application on Windows Azure. Below are the steps required to do so.
Creating the Windows Azure cloud service
The first thing that needs to be done is that we create the service to host our application. To do this I’ve chosen the Cloud Service option and specified the required parameters as shown below.
Once the service has been successfully created the Windows Azure Portal dashboard will show the service entry as can be seen here.
When we drill into the details of that service we will see two deployment options, one into a staging environment and one for production. We can deploy the application to either of these environments but for now we’ll use the staging option as shown below.
Once we drill into this option, the following dialog will be presented which allows us to specify the packages to upload. At this stage, we do not have any files that can be uploaded so we need to first create these before uploading.
Creating and uploading the Windows Azure packages
From within visual studio we can use the IDE to create the packages we need so that we can manually upload them using the portal screen shown earlier or we can publish directly from the IDE. For the moment, we will use the portal to upload the files. To do this we need to package our solution into the required format.
1) Configure the role properties
The first thing to do before creating and uploading the packages is to configure the role properties for the instance we are uploading. From here you can configure things like the instance count and VM size. I’ve currently set these to a single instance and to use the smallest VM size as shown below.
The standard for Windows Azure is to use 2 instances – this will be apparent further in the post – but for now we’ll just use a single instance.
2) Build the packages
To build the packages, all that needs to be done is to select the package option by right-clicking the cloud service project and then choose the desired build configuration as shown below.
Once the above steps have been completed, the required Windows Azure files will be generated in the folder below – the folder will open once the build is successful.
2) Upload the packages
With our packages now ready, we can go back to the portal and select the generated files for upload as shown below. Note that the option Deploy even if one or more roles contain a single instanceis selected here. If we do not select this option the Windows Azure portal will prevent the deployment from uploading. The reason for this is that in the role configuration that was shown earlier, we chose to only create a single instance of the role. We also selected the Start deployment option so that once the upload is complete the deployment to the staging environment is accessible straight away.
3) Deployment being prepared
After we complete the upload process, the instance we uploaded will start initialising and will go through several stages, below are screenshots of what you will see while the deployment is being made ready.
4) Deployment ready
Once the deployment is complete, the dashboard will show the status of the instance as Running.
Now, given that the service is running in the staging environment, we can drill down into the details of the instance and obtain the URL to access the service as well as other properties as shown below.
Accessing the service and fixing deployment issues
With all the upload steps now completed, we can use the URL of the staging instance to access the service as shown below. However, as you can see, our initial publish has failed due to the reason mentioned below. We are able to see the error here as I’ve already set the customErrors mode to Off. This issue is due to the explicit version number reference for the Microsoft.Data.Services dll which can be seen below in the* QuotesDataService.svc *file.
1) Microsoft.Data.Services dll mismatch error
2) Fixing the Microsoft.Data.Services mismatch error
To fix the dll issue observed earlier, all that needed to be done was to remove the explicit version reference. After this has been done we are able to successfully view the service data after fully deploying to Windows Azure as shown below.
Summary
In the previous Exposing your data using WCF Data Services posts we covered everything from creating a local application and database, migrating the database to the cloud to making our code ready for cloud publishing. This post covered the final stage of the process for migrating everything to Windows Azure which involved publishing the cloud ready application code to the Windows Azure portal. The post covered doing this by manually creating the Windows Azure packages and then uploading them manually through the portal’s upload interface. Whilst this approach is fairly simple, there are other ways to publish projects to Windows Azure such as directly from Visual Studio or via the Windows Azure PowerShell.