First Cloud App Using Visual Studio Tools

Signing Up for Windows Azure

The Windows Azure Developer Portal is a one-stop shop for all your service management and Windows Azure needs. The portal contains everything from all the projects/storage accounts underneath your account, to links to billing information. To sign up, head to http://windows.azure.com. You’ll be asked to create an account by signing in with your Live ID credentials and providing billing information. The entire account creation process is quick and painless.

Getting and Installing the Tools

You can use the following two primary tools to develop for Windows Azure:

• Windows Azure Software Development Kit (SDK)

• Windows Azure Tools for Visual Studio (which is bundled with the SDK as well)

The Windows Azure SDK is a free download that contains CSPack (used for packaging your applications), the Development Fabric, and other essential tools needed for building applications for Windows Azure. (You’ll learn what these tools do later in this chapter.) The SDK typically has a new version released every few months. You can find a link to the latest SDK download at http://www.microsoft.com/azure.

Installing these prerequisites separately can be a hassle. One easy way to install all of them with one tool is through the Microsoft Web Platform installer, available from http://www.microsoft.com/web. Figure 3-1 shows the Web Platform installer with the Windows Azure tools (an early version) set to be installed. Note how the necessary dependencies are detected and installed.

Getting to Know the SDK and Tools

If everything installed correctly, you should see a variety of new items in your Start menu, as shown in Figure 3-2. (Note that this figure is reproduced from an early build of the software, and you’ll almost surely see a different icon.)

Understanding the Development Fabric

On the actual cloud, your code runs on different virtual and physical machines. Since launching a virtual machine on a normal physical (development) machine requires a lot of overhead, the Development Fabric (Dev Fabric) launches different processes instead. For every virtual machine you’ll see launched in the cloud, the Dev Fabric launches a local process called RdRoleHost.exe to host your application. Since these are just normal processes, you can attach a debugger to them, and perform typical debugging tasks (such as setting breakpoints, inspecting and changing values, stepping through code, and so on). In fact, this is how the Visual Studio extensions provide debugging support; they attach to the processes launched by the Dev Fabric.

Dev Fabric providing a simulation of the Windows Azure fabric on a local machine. In short, the Dev Fabric enables a developer to build, debug, and test code locally before deploying to the actual cloud

Development Storage

While the Dev Fabric simulates the Windows Azure fabric and is used for hosting code, the Development Storage (Dev Storage) part of the SDK is used to simulate the Windows Azure storage services—blobs, tables, and queues. It does this by using a local SQL Server instance as a backing store, and providing a local running instance of the Windows Azure blobs, tables, and queues.

Developing Your First Cloud Application

Understanding Windows Azure Roles

Windows Azure takes this informal grouping of machines that most applications do and formalizes it into something called roles. A Windows Azure role roughly corresponds to a “type” of box. However, each role is tweaked for a special purpose. 

Table 4-1. Windows Azure role and role template types

Role type Description

Web role This is analogous to an ASP.NET website hosted in IIS (which is, in fact, exactly how Windows Azure hosts your code, as you saw in Chapter 2). This is your go-to option for hosting websites,web services, and anything that needs to speak HTTP, and can run on the IIS/ASP.NET stack.

Worker role A worker role in Windows Azure fulfills the same role a long-running Windows service/cron job/console application would do in the server world. You get to write the equivalent of an int main() that Windows Azure will call for you. You can put absolutely any code you want in it. If you can’t fit your code in any of the other role types, you can probably find a way to fit it here. This is used for everything, including background jobs, asynchronous processing, hosting application servers written in non-.NET languages such as Java, or even databases such as MySQL.

CGI web role (web role) Windows Azure offers direct support to host languages and runtimes that support the FastCGI protocol. The CGI Role template makes it easier for you. Though this is offered as a first-class role type in Visual Studio, under the covers it is just a web role with the CGI option turned on.

WCF service role (web role) This is another customized version of the web role targeted at hosting WCF Services. Under the covers, this is just a web role with some Visual Studio magic to make it easier to write a WCF service.

Writing the Code for "WEB Role"

This directory will be the root of your website—the equivalent to inetpub/wwwroot in IIS, or the root of your ASP.NET application. Any content you put in here will “hang” off the root URL of your website.

Let’s now create the contents of the website. Create a new file called index.html in the htmlwebsite directory with the contents shown in Example 3-1. (Since this is just a normal HTML page, you can put any valid HTML content you want in here.)

Example 3-1. Über-complex web page

<html>

<body>

Hello World!

</body>

</html>

To get Windows Azure to run this trivial site, you must provide two pieces of metadata: the service definition and the service configuration. These are stored in two XML files called ServiceDefinition.csdef and ServiceConfiguration.cscfg, respectively.


So, let’s create two files called ServiceDefinition.csdef and ServiceConfiguration.cscfg
with the contents of Examples 3-2 and 3-3, respectively.

Example 3-2. Sample ServiceDefinition.csdef

<?xml version="1.0" encoding="utf-8"?>
<ServiceDefinition name="CloudService1"
xmlns=
"http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
<WebRole name="WebRole1" enableNativeCodeExecution="false">
<InputEndpoints>
<InputEndpoint name="HttpIn" protocol="http" port="80" />
</InputEndpoints>
<ConfigurationSettings />
</WebRole>
</ServiceDefinition>

Example 3-3. Sample ServiceConfiguration.cscfg

<?xml version="1.0"?>
<ServiceConfiguration serviceName="CloudService1"
xmlns=
"http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration">
<Role name="WebRole1">
<Instances count="1" />
<ConfigurationSettings />
</Role>
</ServiceConfiguration>

Packing the Code for the Dev Fabric

You now have all the code you need to run the service on Windows Azure. However, to run applications on Windows Azure (either the production fabric or in the Dev Fabric), you must package the applications in a special format. This lays out your application binaries in a specific folder structure, and generates some files used internally by Windows Azure.

Run the command shown in Example 3-4 from the directory above htmlwebsite (which contains the index.html web page). This will “package” your application code and service definition file into a Windows Azure-understandable format in a directory named output.

Example 3-4. Packing the sample application for the Dev Fabric

D:\>cspack htmlwebsite\ServiceDefinition.csdef

/role:WebRole1;htmlwebsite /out:output /copyonly

Windows(R) Azure(TM) Packaging Tool version 1.0.0.0

for Microsoft(R) .NET Framework 3.5

Copyright (c) Microsoft Corporation. All rights reserved.

Running the Code in the Dev Fabric

The final step in creating your first application is to run the packaged application in the Dev Fabric. To do that, run the command shown in Example 3-6. This uses another utility that ships with the SDK, CSRun, to point to the output files and to launch the Dev Fabric with your specified configuration.

Example 3-6. Launching the Dev Fabric

D:\>csrun /run:output;htmlwebsite/ServiceConfiguration.cscfg
Windows(R) Azure(TM) Desktop Execution Tool version 1.0.0.0
for Microsoft(R) .NET Framework 3.5
Copyright (c) Microsoft Corporation. All rights reserved.
Created deployment(21)
Started deployment(21)

Deployment input endpoint HttpIn of role WebRole1 at http://127.0.0.1:81/ The Dev Fabric acts not only as a simulation of the Windows Azure fabric, but also as a local web server. In this case, as the last line of the command output indicates, it has launched your site at the local URL http://127.0.0.1:81. Since your web page was called index.html, navigate to http://127.0.0.1:81/index.html in any web browser.

Creating a new hosted service project

The Developer Portal is also where you create projects, which are either hosted services (that let you run code) or storage accounts (that let you store data in Windows Azure storage).

Uploading packages

Windows Azure offers you the same two environments. They’re called deployment slots, and there are two of them: staging (where you deploy your build if you want to test it before it goes live) and production (where the build goes live). Each slot can contain its own package, and each runs separately on its own URL. The production slot runs at the servicename.cloudapp.net URL you picked out, while the staging slot runs at a randomly picked URL of the form <some-guid>.cloudapp.net.

Using the Visual Studio Tools

Just as Visual Studio wraps around the C# or Visual Basic compilers to provide an integrated experience with the IDE, the Visual Studio extensions wrap around CSPack and the Dev Fabric to provide an integrated experience with Windows Azure. This also provides an additional important feature that is difficult to reach with just the command-line tools alone: debugging support. The following discussion assumes that you’ve finished installing the SDK and the Visual Studio tools. If you haven’t, follow the instructions presented earlier in this chapter on where to get the right bits and how to install them.

Let’s start by opening Visual Studio and selecting File→New→Project. Select the Cloud
Service template on the list

A cloud service solution contains only the service definition and service configuration files for your service. It doesn’t contain (by default) the actual roles that make up your service

The WebRole1 project itself is just an ASP.NET web application project under the covers. It is identical to a typical ASP.NET project in almost all ways. However, instead of hooking up with the ASP.NET development server, Cloud Service projects are automatically run in the Dev Fabric.

Looking at Worker Roles in Depth

A worker role is the Swiss Army knife of the Windows Azure world. It is a way to package any arbitrary code—be it something as simple as creating thumbnails, to something as complex as entire database servers. The concept is simple: Windows Azure calls a well-defined entry point in your code, and runs it as long as you want.

Creating Worker Roles

Creating a worker role is simple using the Visual Studio tools. Figure 4-7 shows how to add a new worker role to your project using the new cloud service dialog (you can add one to an existing solution, too, if you prefer). This will generate a new Visual Studio project for you, along with the correct entries in ServiceDefinition.csdef.