---

April 2010

Volume 25 Number 05

Microsoft Azure - Developing and Deploying Azure Apps in Visual Studio 2010

By Jim Nakashima | April 2010

There are many reasons to deploy an application or services onto Azure, the Microsoft cloud services platform. These include reducing operation and hardware costs by paying for just what you use, building applications that are able to scale almost infinitely, enormous storage capacity, geo-location ... the list goes on and on.

Yet a platform is intellectually interesting only when developers can actually use it. Developers are the heart and soul of any platform release—the very definition of a successful release is the large number of developers deploying applications and services on it. Microsoft has always focused on providing the best development experience for a range of platforms—whether established or emerging—with Visual Studio, and that continues for cloud computing. Microsoft added direct support for building Azure applications to Visual Studio 2010 and Visual Web Developer 2010 Express.

This article will walk you through using Visual Studio 2010 for the entirety of the Azure application development lifecycle. Note that even if you aren’t a Visual Studio user today, you can still evaluate Azure development for free, using the Azure support in Visual Web Developer 2010 Express.

Creating a Cloud Service

Start Visual Studio 2010, click on the File menu and choose New | Project to bring up the New Project dialog. Under Installed Templates | Visual C# (or Visual Basic), select the Cloud node. This displays an Enable Azure Tools project template that, when clicked, will show you a page with a button to install the Azure Tools for Visual Studio.

Before installing the Azure Tools, be sure to install IIS on your machine. IIS is used by the local development simulation of the cloud. The easiest way to install IIS is by using the Web Platform Installer available at microsoft.com/web. Select the Platform tab and click to include the recommended products in the Web server.

Download and install the Azure Tools and restart Visual Studio. As you’ll see, the Enable Azure Tools project template has been replaced by a Azure Cloud Service project template. Select this template to bring up the New Cloud Service Project dialog shown in Figure 1. This dialog enables you to add roles to a cloud service.

Figure 1 Adding Roles to a New Cloud Service Project

A Azure role is an individually scalable component running in the cloud where each instance of a role corresponds to a virtual machine (VM) instance.

There are two types of role:

• A Web role is a Web application running on IIS. It is accessible via an HTTP or HTTPS endpoint.
• A Worker role is a background processing application that runs arbitrary .NET code. It also has the ability to expose Internet-facing and internal endpoints.

As a practical example, I can have a Web role in my cloud service that implements a Web site my users can reach via a URL such as https://[somename].cloudapp.net. I can also have a Worker role that processes a set of data used by that Web role.

I can set the number of instances of each role independently, such as three Web role instances and two Worker role instances, and this corresponds to having three VMs in the cloud running my Web role and two VMs in the cloud running my Worker role.

You can use the New Cloud Service Project dialog to create a cloud service with any number of Web and Worker roles and use a different template for each role. You can choose which template to use to create each role. For example, you can create a Web role using the ASP.NET Web Role template, WCF Service Role template, or the ASP.NET MVC Role template.

After adding roles to the cloud service and clicking OK, Visual Studio will create a solution that includes the cloud service project and a project corresponding to each role you added. Figure 2 shows an example cloud service that contains two Web roles and a Worker role.

Figure 2 Projects Created for Roles in the Cloud Service

The Web roles are ASP.NET Web application projects with only a couple of differences. WebRole1 contains references to the following assemblies that are not referenced with a standard ASP.NET Web application:

• Microsoft.WindowsAzure.Diagnostics (diagnostics and logging APIs)
• Microsoft.WindowsAzure.ServiceRuntime (environment and runtime APIs)
• Microsoft.WindowsAzure.StorageClient (.NET API to access the Azure storage services for blobs, tables and queues)

The file WebRole.cs contains code to set up logging and diagnostics and a trace listener in the web.config/app.config that allows you to use the standard .NET logging API.

The cloud service project acts as a deployment project, listing which roles are included in the cloud service, along with the definition and configuration files. It provides Azure-specific run, debug and publish functionality.

It is easy to add or remove roles in the cloud service after project creation has completed. To add other roles to this cloud service, right-click on the Roles node in the cloud service and select Add | New Web Role Project or Add | New Worker Role Project. Selecting either of these options brings up the Add New Role dialog where you can choose which project template to use when adding the role.

You can add any ASP.NET Web Role project to the solution by right-clicking on the Roles node, selecting Add | Web Role Project in the solution, and selecting the project to associate as a Web role.

To delete, simply select the role to delete and hit the Delete key. The project can then be removed.

You can also right-click on the roles under the Roles node and select Properties to bring up a Configuration tab for that role (see Figure 3). This Configuration tab makes it easy to add or modify the values in both the ServiceConfiguration.cscfg and ServiceDefinition.csdef files.

Figure 3 Configuring a Role

When developing for Azure, the cloud service project in your solution must be the StartUp project for debugging to work correctly. A project is the StartUp project when it is shown in bold in the Solution Explorer. To set the active project, right-click on the project and select Set as StartUp project.

Data in the Cloud

Now that you have your solution set up for Azure, you can leverage your ASP.NET skills to develop your application.

As you are coding, you’ll want to consider the Azure model for making your application scalable. To handle additional traffic to your application, you increase the number of instances for each role. This means requests will be load-balanced across your roles, and that will affect how you design and implement your application.

In particular, it dictates how you access and store your data. Many familiar data storage and retrieval methods are not scalable, and therefore are not cloud-friendly. For example, storing data on the local file system shouldn’t be used in the cloud because it doesn’t scale.

To take advantage of the scaling nature of the cloud, you need to be aware of the new storage services. Azure Storage provides scalable blob, queue, and table storage services, and Microsoft SQL Azure provides a cloud-based relational database service built on SQL Server technologies. Blobs are used for storage of named files along with metadata. The queue service provides reliable storage and delivery of messages. The table service gives you structured storage, where a table is a set of entities that each contain a set of properties.

To help developers use these services, the Azure SDK ships with a Development Storage service that simulates the way these storage services run in the cloud. That is, developers can write their applications targeting the Development Storage services using the same APIs that target the cloud storage services.

Debugging

To demonstrate running and debugging on Azure locally, let’s use one of the samples from code.msdn.microsoft.com/windowsazuresamples. This MSDN Code Gallery page contains a number of code samples to help you get started with building scalable Web application and services that run on Azure. Download the samples for Visual Studio 2010, then extract all the files to an accessible location like your Documents folder.

The Development Fabric requires running in elevated mode, so start Visual Studio 2010 as an administrator. Then, navigate to where you extracted the samples and open the Thumbnails solution, a sample service that demonstrates the use of a Web role and a Worker role, as well as the use of the StorageClient library to interact with both the Queue and Blob services.

When you open the solution, you’ll notice three different projects. Thumbnails is the cloud service that associates two roles, Thumbnails_WebRole and Thumbnails_WorkerRole. Thumbnails_WebRole is the Web role project that provides a front-end application to the user to upload photos and adds a work item to the queue. Thumbnails_WorkerRole is the Worker role project that fetches the work item from the queue and creates thumbnails in the designated directory.

Add a breakpoint to the submitButton_Click method in the Default.aspx.cs file. This breakpoint will get hit when the user selects an image and clicks Submit on the page.

protected void submitButton_Click(
  object sender, EventArgs e) {
  if (upload.HasFile) {
    var name = string.Format("{0:10}", DateTime.Now.Ticks, 
      Guid.NewGuid());
    GetPhotoGalleryContainer().GetBlockBlob(name).UploadFromStream(upload.FileContent);

Now add a breakpoint in the Run method of the worker file, WorkerRole.cs, right after the code that tries to retrieve a message from the queue and checks if one actually exists. This breakpoint will get hit when the Web role puts a message in the queue that is retrieved by the worker.

while (true) {
  try {
    CloudQueueMessage msg = queue.GetMessage();
    if (msg != null) {
      string path = msg.AsString

To debug the application, go to the Debug menu and select Start Debugging. Visual Studio will build your project, start the Development Fabric, initialize the Development Storage (if run for the first time), package the deployment, attach to all role instances, and then launch the browser pointing to the Web role (see Figure 4).

Figure 4 Running the Thumbnails Sample

At this point, you’ll see that the browser points to your Web role and that the notifications area of the taskbar shows the Development Fabric has started. The Development Fabric is a simulation environment that runs role instances on your machine in much the way they run in the real cloud.

Right-click on the Azure notification icon in the taskbar and click on Show Development Fabric UI. This will launch the Development Fabric application itself, which allows you to perform various operations on your deployments, such as viewing logs and restarting and deleting deployments (see Figure 5). Notice that the Development Fabric contains a new deployment that hosts one Web role instance and one Worker role instance.

Figure 5 The Development Fabric

Look at the processes that Visual Studio attached to (Debug/Windows/Processes); you’ll notice there are three: WaWebHost.exe, WaWorkerHost.exe and iexplore.exe.

WaWebHost (Azure Web instance Host) and WaWorkerHost (Azure Worker instance Host) host your Web role and Worker role instances, respectively. In the cloud, each instance is hosted in its own VM, whereas on the local development simulation each role instance is hosted in a separate process and Visual Studio attaches to all of them.

By default, Visual Studio attaches using the managed debugger. If you want to use another one, like the native debugger, pick it from the Properties of the corresponding role project. For Web role projects, the debugger option is located under the project properties Web tab. For Worker role projects, the option is under the project properties Debug tab.

By default, Visual Studio uses the script engine to attach to Internet Explorer. To debug Silverlight applications, you need to enable the Silverlight debugger from the Web role project Properties.

Browse to an image you’d like to upload and click Submit. Visual Studio stops at the breakpoint you set inside the submitButton_Click method, giving you all of the debugging features you’d expect from Visual Studio. Hit F5 to continue; the submitButton_Click method generates a unique name for the file, uploads the image stream to Blob storage, and adds a message on the queue that contains the file name.

Now you will see Visual Studio pause at the breakpoint set in the Worker role, which means the worker received a message from the queue and it is ready to process the image. Again, you have all of the debugging features you would expect.

Hit F5 to continue, the worker will get the file name from the message queue, retrieve the image stream from the Blob service, create a thumbnail image, and upload the new thumbnail image to the Blob service’s thumbnails directory, which will be shown by the Web role.

Deployment

Now that you’ve created, edited and debugged your application locally, you’re ready to deploy it to the cloud. Here’s a good process to follow when deploying an application to Azure:

• Get your application running locally in the Azure Development Fabric using local storage.
• Run your application locally in the Development Fabric using a Azure Storage Account.
• Run your application on Azure using a Azure Storage Account.

In the first stage, you can do all your development on your local machine using the Development Fabric and Development Storage as surrogates for the Azure cloud infrastructure. You don’t even need a network connection—you can develop and debug your Azure application or service completely offline. You’ll probably do 70 percent of your project development in this first stage.

In the second stage, you replace the local storage surrogate with the real deal, Azure Storage, but retain the debugging and diagnostic advantages of executing your Azure application code in the local Development Fabric. You can set breakpoints in source code, step through source code line by line, evaluate expressions, and examine call stacks while your Azure app interacts with cloud storage. You’ll probably spend 20 percent to 25 percent of your project cycle in this stage, refining your code and testing against real-world asynchronous operations.

By the time you get to the third stage, your Azure application should be all but finished. You should be feature-complete and code-complete except for bug fixes. Your main focus in this stage is testing and performance tuning. With your Azure application executing in the cloud, you won’t have the luxury of source code debugging so you’ll have to fall back to diagnostic logging.

You probably don’t want your brand-new Azure application to be seen by the whole wide world on your target URL the instant you upload it to the Azure cloud. The Azure Hosted Service has the notion of multiple deployments within the same hosted service. Each Azure Hosted Service has a private staging deployment area where you can quietly test your code in the cloud, and a public production deployment area where you release your tested code for your customers to use.

Staging deployments can only be accessed via a unique URL that is prefixed by a GUID assigned by the system. Production deployments can be the target of custom domain name mappings for easy access.

Moving to Azure Storage

Now that the Thumbnails service is running on a local machine in the Developer Fabric, let’s upgrade it to work against a Azure Storage account in the cloud. This involves getting a storage account and making the configuration changes to run the Thumbnails service against your storage account. Executing locally but using cloud storage for data is a great way to ensure that your code will run when hosted on Azure.

Start by navigating to the Azure Developer Portal (azure.microsoft.com) and sign in with your Live ID. From the page, select New Service and click on Storage Account. In the Create a Service page (see Figure 6), fill in a friendly name for the storage account (this is not the service/domain name; you will be prompted for that on the next page). Optionally enter a project description. Then fill in the service/domain name on the next page (see Figure 7). This domain name is global so you may need to fiddle with it a bit to get a name that is not already in use by another service. Be sure to click on Check Availability to test for uniqueness.

Figure 6 Configuring a Storage Service

 

Figure 7 Configuring a Storage Domain

It’s a good idea to create an affinity group to ensure that your storage and the hosted services that use it are located in the same datacenter whenever possible. Affinity groups can also specify a preference for a geographical region so that service and storage are as close to your target audience as possible to minimize network transit time.

Click Create and you’ll see a summary page for your new storage account.

Now you need to tell your Thumbnails service to use your new storage account to store its thumbnails and images. Double-click on the Thumbnails_WebRole node under Roles in the Visual Studio Solution Explorer to open its properties page. Select the Settings tab, select DataConnectionString, and click on the edit button on the far right of the grid row. This brings up the Storage Connection String dialog, shown in Figure 8.

Figure 8 Storage Connection String Properties

 “Use development storage” is the default for new Azure projects. Click on “Enter storage credentials” and then enter your storage service details. In the Account name field, type the service/domain name you entered when creating your storage service. This is the first part of your domain, thumbnails1138 (all lower case) in the example.

In the Account key field, enter the Primary Access Key displayed on your storage service summary Web page. You can select the key text in the browser, copy it, and paste it into the AccountSharedKey edit box.

Note that the Secondary Access Key provides the same access to your storage account as the Primary Access Key and is generated as a backup should your Primary Access Key be compromised. Regenerating a key invalidates the old key, shutting down storage access to anyone still using the old key.

Leave the connection endpoints set to use the default HTTPS endpoints and click OK.

Repeat these steps for the Thumbnails_WorkerRole under Roles as well, so that the Web role will be talking to the same storage service as the Worker role. When you have multiple roles to update, you can copy the connection string value to the clipboard and just paste it into the DataConnectionString value cell in each of the other role properties pages to save a little time.

Once you have switched the Web and Worker roles to use Azure storage, hit F5 in Visual Studio to debug your cloud service and ensure that everything works correctly.

You’ll see that the Web page URL you’re debugging is still locally hosted, but the URLs of the thumbnails (visible in their Properties dialogs) now point to Azure Storage.

Note that this stage of development—local services with cloud storage—will most likely have the worst performance of the three stages of deployment. Stage 1 (local/local) will be pretty snappy because everything is in the same box and has a total audience of one (you!). Stage 3 (cloud/cloud) will have the benefit of cloud scale hardware and datacenter affinity. Stage 2 (local/cloud), however, will be executing code that reasonably assumes its storage is nearby, but in fact the data is probably many network hops away from the local execution environment.

Don’t evaluate the performance of your app in the local/cloud configuration. You can turn that network lag to your advantage, though: use this stage as a stress test to see how your code handles exaggerated response times from its storage service. If you have handled something with a synchronous call that should really be asynchronous, you’ll probably notice it pretty quickly.

Once you have everything working in the local/cloud configuration, you are ready to deploy your code to a Azure hosted service.

Creating a Hosted Service

To create the fully hosted service, go back to the Azure Developer Portal and sign in with your Live ID. Click on New Service, then on Hosted Services. This takes you to a page where you can specify the project-friendly name and description used by the developer portal. Enter a service label and optionally a service description. Click Next. Now you can enter a domain name for your hosted service project (see Figure 9). Set the affinity group to match the Thumbnails affinity group created earlier with the storage service. After the project is created, you will see a summary page for your project.

Figure 9 Configuring a Hosted Service

To deploy the project from Visual Studio, right-click on the Thumbnails project node in Solution Explorer and select Publish. This command builds a package of your Azure application binaries and related files, opens Windows Explorer to show the local directory where the package was built, and launches your default Web browser to browse to the developer portal.

From the developer portal Web page, navigate to the Thumbnails Hosted Service summary page and click Deploy from under Staging to bring up the Staging Deployment page (see Figure 10). This is where you specify the package and the configuration file to upload.

Figure 10 Choosing the Package to Deploy

You can copy the path from the Windows Explorer window that Visual Studio opened into this File Open dialog, which makes it easy for you to select the Service Package (.cspkg) and Service Configuration files.

The portal will then upload the package and deploy your cloud service to staging, which puts your roles in the Allocated state. This means your Azure application has been provisioned with datacenter hardware, but it is not yet scheduled to run.

To test your Cloud Service in the Staging area, you need to run it. Click Run. This will put your Web role in the Initializing state. When the Web role is ready, the state will change to Started.

Note that there are plans to make deploying straight to the cloud from Visual Studio even simpler in future updates, but this procedure will remain valid even when those features are in place.

Once your roles have been started, you can test by navigating to the staging URL (the cloudapp.net URL that begins with a GUID).

Provisioning an application in the datacenter involves a lot of heavy lifting behind the scenes. Allow at least 10 minutes for your app to transition from Initializing to Started. Now aren’t you glad you have the Developer Fabric on your local machine?

After you’re happy with your cloud service on staging, you can promote it to production by clicking on the button shown in Figure 11.

Figure 11 Promotion Button

When the details of your deployment show up on the Production side of the page, your service will be up and running at its final URL.

If you need to test a hotfix for your app, or just want to continue development in parallel to the running production deployment, you can upload a new package to staging and test it via the staging URL. Promoting to production is actually a swap: staging moves to production and what was in production goes into staging.

While you can directly upload to production, it is highly recommended to always deploy first to staging and perform some degree of acceptance testing before pushing it to production.

Note that multiple deployments will default to using the same storage service—if you need data isolation between production and staging (for example, so staging can wipe its database without affecting production data), you will need to modify your storage bindings for each deployment before you deploy them. This is typically done by using two sets of storage and migrating production data to staging before promoting staging to production.

Updating the Service Configuration

If you want to spin up additional instances of your service in anticipation of additional load, or shut down unused instances, you can do that by modifying the deployment configuration on the fly. You don’t have to redeploy the entire package, just the service configuration file. In the portal, click Configure to update the service configuration (cscfg), either by uploading a new service configuration file created by Visual Studio or by using the editor provided by the developer portal.

Let’s now add an HTTPS endpoint to the Thumbnails application. This is a three-step process. You need to configure the endpoint, configure the certificate and upload the certificate.

To configure the endpoint, open up the configuration UI on the Web role by right-clicking on the Thumbnails_WebRole node under the Roles node in Solution Explorer and selecting Properties. Switch to the Endpoints tab and click the checkbox to select HTTPS. This adds the HTTPS endpoint, but doesn’t specify the certificate.

Switch to the Configuration page and uncheck the “Launch browser for: HTTP endpoint” option. By unselecting this option, on run or debug of the cloud service, the default browser will be launched only for the HTTPS endpoint.

In Visual Studio, click Debug | Start Debugging to package and run the cloud service on the local development simulation. The development simulation always uses a self-signed certificate issued to and issued by 127.0.0.1, which corresponds to the local host. Because the certificate is not trusted, the Web browser will come up with a certificate error. This is expected. Click “Continue to this website (not recommended)” to browse to the Web site.

To make the certificate trusted and therefore not see the certificate errors, you can install the certificate to the Trusted Root Certification Authorities certificate store. Do so only if you have an appropriate understanding of the security implications.

To configure a certificate for use in the cloud, you need a certificate that will be uploaded to the cloud and to configure that certificate for the role. For the purpose of this article, we’ll create and use a self-signed certificate. Create a self-signed certificate by opening the IIS Manager, selecting Server Certificates, and clicking Create Self-Signed Certificate under the Actions heading on the far right of the dialog. After creating the certificate, click Export to export the certificate to a .pfx file.

Navigate to the Azure Developer Portal and select the Hosted Service component to deploy to. Under the Certificates heading, select Manage. Upload the certificate by entering the name of the .pfx file and the corresponding password you entered during the export step. Copy the thumbprint of the certificate after it is installed to your hosted service component.

To configure the certificate, go back to Visual Studio, open the Thumbnails_WebRole configuration UI, click the Certificates tab and click Add Certificate. Give the certificate a name (for example, sslCert), paste in the thumbprint, and leave the store location and name at the default of LocalMachine and My.

The certificates configuration page allows you to specify for a given role what certificates should be installed to the VM instances for that role and in which stores to install those certificates. In other words, this same process can be used for any certificates you want to have on your VMs in the cloud, and not just for SSL certificates.

Finally, switch to the Endpoints tab and select sslCert for the HTTPS certificate.

Now deploy your application. You will now be able to access your Web site via HTTP and HTTPS. Because we uploaded a self-signed certificate, the browser will display a certificate error when browsing to your HTTPS endpoint. Using a real signed certificate will solve this problem.

Wrapping Up

The Azure Tools and Visual Studio 2010 make it easy to create, edit, configure, debug and deploy applications that run on Azure. They allow you to leverage your existing skills with ASP.NET and with Visual Studio.

The Azure Tools add-in is designed for both Visual Studio 2010 and Visual Studio 2008. The easiest way to install the Azure Tools for Visual Studio 2008 is by using the Web Platform Installer available at microsoft.com/web. Be sure to add the developer tools scenarios in the options.

For the latest news and information about Azure, please see windowsazure.com and blogs.msdn.com/jnak.

---

Hani Atassi is a software engineer on the Azure Tools team. Prior to his work on cloud tools, Atassi spent time developing Windows Vista and Microsoft.com.

Danny Thorpe is a principal software engineer on the Azure Tools team. In past lives he was a contributing founder of Google Gears at Google and a Delphi Compiler Architect at Borland.

Jim Nakashima is a program manager on the Azure Tools team focusing on building end-to-end developer experiences for Azure. Nakashima spent a number of years working on the Windows Presentation Foundation and Silverlight Designer and tools before being attracted to the infinite possibilities of the cloud.

Thanks to the following technical experts for reviewing this article: Anson Horton and Gus Perez