Experimenting with Windows Azure and understanding its runtime environment better


I recently learned how to develop, test and deploy a Windows Azure application. This post describes how created and deployed a sample application.
Please note that I am not a member of the Windows Azure team and this post covers my own personal experience with the service.


My experimentation was made easier by the fact that I have developed ASP.NET applications before.
I had already installed the final version of Visual Studio 2010 in my Windows 7 computer and had also added Internet Information Server as an optional Windows 7 component.
In additional to Visual Studio 2010 and IIS, I also downloaded the Windows Azure tools, which added additional templates for Azure development.


I was interested in understanding more about the environment where Azure Applications run, so I decided to write an application that would report information about the file system of the virtual machine where it runs.
That included simple things like what drives exist and what are their characteristics (Type, File System, Total Size and Available Space). I also added the ability to query folders and files, so I could understand what existed where.
Here’s a little screenshot of what I ended up with:


Nothing fancy, as you can tell. Just enough to understand the development experience, go through the deployment process and have the tools to understand the Windows Azure runtime environment.


Creating the application was fairly straightforward. I create a new project using C# and selected the cloud project.


To keep it simple, I used a single ASP.NET Web Role for my Cloud Service Project.


Then I dragged some controls, added some code and started testing it. The whole development process runs locally, so there’s no need to even have an Azure account at that point. I was also not using any Azure Storage, so it was simply one web role that had no external dependencies. Not typically a very useful application, but I my goal was to create somewhat of a glorified “Hello, World” to get started.

Since I had the entire .NET Framework available, writing the code was not hard at all.
To get the drive information, for instance, I used the System.IO namespace described at http://msdn.microsoft.com/en-us/library/system.io.aspx.

protected void btnDrives_Click(object sender, EventArgs e)
   DriveInfo[] diAll = DriveInfo.GetDrives();
   string strDrive = "";
   foreach (DriveInfo diOne in diAll)
      strDrive =
"Drive " + diOne.Name + " Type:" + diOne.DriveType.ToString();
      if (diOne.IsReady)
         strDrive = strDrive +
" Volume:" + diOne.VolumeLabel + " FS:" + diOne.DriveFormat.ToString() + " Total:" + diOne.TotalSize.ToString() + " Free:" + diOne.AvailableFreeSpace.ToString();

Aside for the fact that I had to run Visual Studio as an Administrator, everything else was fairly uneventful in terms of development and local debugging of the application. It automatically started the local Windows Azure Simulation Environment.


I was able to set breakpoints, watch my code running step by step, etc. No surprises there…


Perhaps the hardest part for me, being new to Windows Azure, was understanding exactly what I needed to deploy my application.
Once you create your service in the Windows Azure Web UI, you reach a point where you can deploy the application.


When you click on the “Deploy…” You are then prompted to provide two files (an application package file and a configuration settings file) along with a Service Deployment Name.
There was little else in terms of tips on how to generate those:


After spending some time in the Visual Studio environment, I was unable to find the right way to create those files or even what the file extensions would be.
That was when I had to look up the Windows Azure documentation for the first time. Up to this point, I was just winging it.
It turns out you need to right-click the Cloud project to find the “Publish…” option to generate a package for Windows Azure.


This will create the two required files, one of type “cspkg” (Cloud Service Package) and the other of type “cscfg” (Cloud Service Configuration).
The “Publish…” option is actually nice enough to open a Windows Explorer window with the right folder (see below) and even an Internet Explorer window with the right Windows Azure URL.


Once I provided the files and all, the service was publish within seconds. After that, clicking on “Run” deployed the application.
That is when the virtual machine containing the running application is actually provisioned/started and that took a few minutes to complete.


Running the service

The status of the service went from “Initializing” to “Busy” to “Ready”.
After that, the deployment was completed and running the service meant simply hitting the web site URL at http://servicename.cloudapp.net

I was finally ready to inspect some of the characteristics of the Windows Azure VM running my service.
First, I listed the drives on the system. It turns out that the VM had three drives (C:, D: and E:) as I showed in the first screenshot of the blog post.
I then used the application to look into specific folders and files on each drive, as shown below for the E:\approot folder:


After further investigation, I concluded the following about the three different drives:



Total Size







Pagefile (4,294,967,296 bytes), machine configuration info, temp files, web service logs, "local storage resources"





Windows operating system, including Windows and Program Files folders





Application root, including ASPX files and DLLs

I did find documentation of the amount of storage per VM at http://msdn.microsoft.com/en-us/library/ee814754.aspx
The default size (small) gives you 250GB of local storage. That was the size of my VM. You can choose bigger ones with 500GB, 1000GB and 2000GB of local storage.

However, I did not find documentation of this breakdown between the three drives (or even about the three drives themselves).
I can only tell you that the numbers above were true for my specific application deployment at that time.

If you are planning to use local temporary storage in your application, you should look into the documentation for Local Storage Resources.
You can read more about it at http://msdn.microsoft.com/en-us/library/ee758708(v=MSDN.10).aspx.
These local storage resources apparently live on the C: drive, but you should use the API to find the exact local path to use.

If you need permanent storage, you should look into the many options Azure offers, including Blobs, Tables, Queues, Drives and SQL Azure Databases.
These are accessed via APIs and are not stored as part of your Azure virtual machine local storage.


One last thing I found interesting was the process to deploy additional versions of the application.
Windows Azure allows you to allow the new version in a separate “Staging” area.
This makes it possible to run and test the staged new version with a temporary URL while the older version is still running with the main URL.

When you are confident that the version is fine, you can simply switch the production and staged environments.
This is done very quickly, since both environments are fully deployed at that point and you’re effecting just switching the two URLs.


If your new version turns out to have any issues, you can also quickly switch back to the old version.
As you can tell, I did have the change to deploy a few new versions and experiment with the Staging process. Very convenient.


If you are familiar with the ASP.NET, creating Windows Azure applications is not a big stretch, once you grasp a few extra concepts.
I was happy with my experiment, having deployed my first Windows Azure application and learned more about the Azure runtime in the process.

Comments (2)

  1. Anonymous says:

    I have spent my last few weekends building an ASP.NET web application that sends multiple queries to

  2. Anonymous says:

    I have spent my last few weekends building an ASP.NET web application that sends multiple queries to

Skip to main content