This post is part of a series called “Windows Azure for the ASP.NET Developer” written by Rachel Appel, Adam Hoffman, and Peter Laudati. You can see the complete list of posts in the series at the US Cloud Connection site.
Whether you’re looking to build a new ASP.NET application from scratch, or migrate an existing ASP.NET application into Windows Azure, getting started is an easy process. You can even start developing locally without a Windows Azure account! However, be sure to get one, because you will need it eventually to experience all Azure has to offer.
In this post, I’ll describe the various tools & SDKs available to start you on your journey.
Get The Bits
In December 2011, a set of new Developer Centers were added to the main Windows Azure website. These developer centers are the de-facto starting place for developers looking to take advantage of Windows Azure whether you’re an ASP.NET developer or using other technologies like Node.js, Java, or PHP.
From the .NET Developer Center, you can obtain the necessary tools in one download by clicking the big green “Install” button. (or THIS link). This will launch the Microsoft Web Platform Installer to install the Windows Azure SDK for .NET (current release is November 2011). This SDK contains:
- Windows Azure SDK
- Windows Azure Tools for Visual Studio
- Windows Azure Client Libraries for .NET
Windows Azure SDK
The Windows Azure SDK contains the basic tools which are needed to run, test, debug, and package applications for Windows Azure. Chief amongst these is the Windows Azure Developer Emulator, which emulates the Windows Azure Compute environment and Windows Azure Storage services on your local workstation. These tools are used for working with all Windows Azure applications, including ones developed in other languages.
For an overview of the tools included in the Windows Azure SDK, see Overview of the Windows Azure SDK Tools on MSDN.
Windows Azure Tools for Visual Studio
The Windows Azure Tools for Visual Studio contains the necessary project templates & extensions for Windows Azure projects. It also integrates tightly with the underlying tools in the Windows Azure SDK such as the developer emulator and deployment packaging tools. This makes for a seamless experience developing, testing, and configuring ASP.NET applications for Windows Azure.
For more information on these tools, explore the content under Windows Azure Tools for Microsoft Visual Studio on MSDN.
Windows Azure Client Libraries for .NET
The Windows Azure Client Libraries for .NET contain the APIs needed to access Windows Azure services. This includes APIs for:
- Windows Azure Storage (Blobs, Tables, Queues)
- Access Control Service
- Distributed Caching
- Windows Azure Service Management
- Windows Azure Diagnostics
We will explore these APIs more throughout this series.
Note: Windows 7, Windows Vista, or Windows Server 2008 is required to develop and package applications for Windows Azure. Windows XP is not supported. The Visual Studio tools for Windows Azure require a version of Visual Studio 2010. If you do not have Visual Studio 2010 installed, the installation package referred to above will install the free Visual Studio 2010 Web Developer Express.
Note: Alternatively, you can install the Windows Azure SDK for .NET directly from within Visual Studio 2010. For details, see: (Install the Windows Azure tools)
Understanding The Windows Azure Developer Emulator
The Windows Azure Developer Emulator is one of the core tools in the Windows Azure SDK that enables development of cloud applications on your local workstation. As an ASP.NET developer, your experience with the Windows Azure Developer Emulator will be mostly through its seamless integration with Visual Studio.
The Windows Azure Developer Emulator emulates the Windows Azure Compute environment on your local workstation. This enables you to test your application in the environment it will run in up in the cloud. You can attach the Visual Studio Debugger to your application running in the emulator for the full Visual Studio debugging experience you are familiar with.
The compute emulator uses Internet Information Server (IIS) under the covers to emulate the compute environment. If your workstation does not have IIS installed or enabled, the installation process of the Windows Azure Tools for Visual Studio will do it automatically for you. Due to the emulator utilizing IIS, it is required that Visual Studio be run as an Administrator to develop and test Windows Azure applications.
Some differences exist between running an application in the compute emulator and running it as a hosted service in Windows Azure. To learn more about these, see: Differences Between the Compute Emulator and Windows Azure
The Windows Azure Developer Emulator also emulates the Windows Azure Storage services on your local workstation. This enables you to test your application’s use of the non-relational blob, table, and queue storage services.
For more information about Windows Azure Storage, see Data Storage Offerings in Windows Azure.
The emulator uses SQL Server Express under the covers to emulate the storage services. Some differences exist between using the storage emulator and using Windows Azure Storage services. To learn more about these, see: Differences Between the Storage Emulator and Windows Azure Storage Services.
Tip: By default, the storage emulator runs against the default instance of SQL Server Express 2005 or 2008. If you do not have SQL Server installed, the Windows Azure SDK for .NET will install SQL Server Express as a pre-requisite and configure the storage emulator to use it.
However, the Windows Azure SDK for .NET currently does not configure the storage emulator to use an existing SQL Server instance. If you have an existing installation of SQL Server, you will need to configure the storage emulator to use it! To do this, see How to Initialize the Storage Emulator by Using the DSInit Command-Line Tool. This has been a common issue folks run into when attempting to run the storage emulator the first time.
The Windows Azure Developer Emulator does not emulate SQL Azure. This is because it is not needed! SQL Azure functions virtually the same as SQL Server. For development and testing of SQL Azure databases, you can use SQL Server or SQL Server Express on your workstation.
For more information on the Windows Azure Developer Emulator, see Running a Windows Azure Application Locally on MSDN.
Understanding Hosted Services, Roles, and Instances
Before you dive into your first “Hello World” sample, it is important to understand some basic concepts about how the Windows Azure Compute service works. Windows Azure Compute is a “Platform-as-a-Service” offering. This means that the operating system and application platform are provided for you. There is no need to create and manage the virtual machine(s) that your application will run in.
The unit of deployment for your application is essentially your packaged application code and its associated configuration for how it should run in the cloud. Given this model, that unit of deployment is referred to as a “Windows Azure service” or a “hosted service”.
Hosted Services are like containers. You can think of them as a container in the cloud that you will deploy your application into. There are two aspects to defining a hosted service: Location and Configuration.
In the cloud, via the Windows Azure Management Portal, you choose a location for your hosted service by selecting one of the Windows Azure datacenters to physically host it. You also reserve a URL on the Internet where your hosted service will be available at.
In your application configuration, you must define how your hosted service will be configured to run.
Just like in your own datacenter, you may choose to deploy parts of your application across one or more server types. Perhaps one server type hosts your ASP.NET web application across a farm of five servers, and another server type hosts your back-end services on a single server. The difference in Windows Azure is that you will be deploying them into virtual machines instead of actual servers.
For more information on Hosted Services, see Overview of Creating a Hosted Service in Windows Azure.
Roles are defined configurations of a virtual machine. In Windows Azure, there are two role types: Web role & worker Role. Both of these represent a standard Windows Server 2008 R2 VM. The only difference is that the web role is configured to run IIS7 and handle HTTP traffic. A worker role does not have IIS enabled by default. It is typically used for running background services. ASP.NET Applications are hosted in Web Role VMs.
A hosted service can contain one or more roles, each hosting a different part of the application. For example, your ASP.NET web application runs in a web role, while a backend service runs in a worker role.
Instances are are to Roles like objects are to classes in object oriented programming languages. An “object” is an instance of a “class”, an “Instance” in Windows Azure is a instance of a virtual machine configured for a given “Role”. You can have one or many instances of a role configured to run in a Windows Azure hosted service.
For example, you may have five instances of a web role configured to run you ASP.NET web application (like a web farm), and one single instance of a worker role to run your backend services.
Get Ready To Build Your First Application
The Windows Azure Tools for Visual Studio provide a Windows Azure Service project type to define a Hosted Service. This project is essentially a “meta” project that lets Visual Studio know how to package your application for deployment to the cloud and configure Windows Azure to run your application.
The Windows Azure service project contains configuration files to configure the roles and number of instances the hosted service will use in the datacenter. It also contains links to the Visual Studio projects that contain your ASP.NET application.
The Windows Azure service project also enables you to seamlessly test and debug your application in the Windows Azure Developer Emulator using the standard “F5” debug experience you are familiar with in Visual Studio.
When it is time to deploy your application to Windows Azure, the Windows Azure service project will compile your application and package it up, providing the ‘unit of deployment’ for your application, two files:
- <yourWindowsAzureProjectName>.cspkg – A package (or zip-like) file containing the contents of your application.
- ServiceConfiguration.Cloud.cscfg – An XML configuration file containing the settings for how your hosted service will run in Windows Azure.
Time for “Hello World”
Now that you have an high-level understanding of how the tools work, it is time to get your hands dirty. There are plenty of good “How to build a Hello World ASP.NET app for Windows Azure” posts out there. Feel free to try some of these walkthroughs:
- Hosting an ASP.NET Application on Windows Azure (from MSDN Library)
- ASP.NET MVC Web Application with SQL Azure (from WindowsAzure.com)
- Multi-tier Application (from WindowsAzure.com)
Hopefully, this post has provided an overview of how the Windows Azure developer tools work. This is barely the tip of the iceberg. You can learn more about the Windows Azure Tools for Visual Studio on MSDN here: Windows Azure Tools for Microsoft Visual Studio