Windows Azure is Microsoft’s cloud operating system. The
tools integrated into Visual Studio make Windows Azure quick and easy for
developers who are familiar with .NET development to adopt. The tools provide
a steamlined way to create, develop, and publish cloud projects, as well as
view storage data.
First, you must have some version of SQLServer installed –
this can be any flavor of SQLServer 2008, or SQLServer Express 2005. This is
for emulating the cloud storage when you test your application locally. If you
already have VS2010 installed, then SQLServer should`ve been installed
automatically.
Next, you will need to download and install the Windows
Azure Tools and SDK. You can find the Windows Azure Tools & SDK here: http://www.microsoft.com/windowsazure/getstarted/
Note: When you select File -> New Project below and start a cloud project, Visual Studio
will download the latest Azure tools if they’re not currently installed. See
the below screen capture as an example of what it looks like when Azure tools
are not installed.
The Tools for Visual Studio add the ability to create cloud projects
that you can test locally and publish to Windows Azure. Let’s start by running
Visual Studio in administrator mode.
Select File / New Project. Under either Visual Basic or
Visual C#, you should now see a category for Cloud as illustrated in Figure 1.
Click on it, fill in the information at the bottom and click OK.
Figure 1: Creating a cloud project in Visual Studio 2010.
Next you will be prompted for the type of role that you want
to use. This will host the actual code. There are only two types of roles – web
roles and worker roles. Web roles use IIS by default and worker roles do not. So
if you are going to create a web application or WCF service,
you will want to use a web role.
Worker roles are used more for processing. I’ve used them in
cases where I used to have a Windows service running on a server. For example,
if you are taking wav files and converting them to MP3 asynchronously, you
could submit that to a worker role and let it do it for you.
Select an ASP.NET Web Role. On the right, if you hover over
the first line, a pencil will appear on the right – click it in order to edit
the name of the Web Role. I’m going to name my web role “AwesomeWebApp”
instead of “WebRole1”, as shown in Figure 2.
Figure 2: Adding a web role.
After clicking OK, you should have something similar to Figure
3.
Figure 3: New web application in a web role.
There are two projects. AwesomeWebApp is the web role. This
is what will actually run in the instance on Windows Azure. The second one is
the cloud project. This contains the role itself and the service configuration
and service definition files. These apply to all of the instances of the role
that are running. Let’s look at the service configuration first.
In Figure 4, I have changed two things. The osFamily value
determines whether the instance runs Windows Server 2008 (osFamily = “1”) or
Windows Server 2008 R2 (osFamily = “2”). I always want to run the most recent
version, so I’ve changed this to the latter. I’ve also added some more
settings. You will probably want to move some of your settings from your
website’s web.config file to your service configuration, because you can modify
your Service Configuration file while the instance is running, but you can’t
modify the web.config file – you have to fully redeploy the application for
changes to the web.config to take effect. For example, I put settings in my
service configuration for the frequency of performance counter logging, so I
can raise and lower it without needing to re-publish the entire project.
Figure 4: Service Configuration
The Service Definition is just a definition of what
variables are in the Service Configuration file. Mine is displayed in Figure 5.
Figure 5: Service Definition.
You can also edit the values of the service configuration
through the role properties. To see the role properties displayed in Figure 6,
just double-click on the role in Solution Explorer.
Figure 6: Role Properties
Here you can set the basic properties of your role,
including the number of instances and the size of the VM that you want to use.
You can also specify a connection string for the Diagnostics, which are stored
by default in Windows Azure Storage. You can use the EndPoints tab to manage
the endpoints for the application.
The Certificates tab is for specifying the SSL certificate
used when you are using https endpoints and/or when you enable RDP access to
the role instance. Local Storage is used to configure local file system storage
resources for each instance, and whether to clear them when the role recycles.
Rather than edit the configuration settings in the XML, you can
use the grid in the settings tab, displayed in Figure 7, to edit the values of
the settings you have already defined, and to add new settings. If you add a
new setting here, it automatically adds it to the service definition as well.
Figure 7: UI for editing settings.
Hit F5 in Visual Studio to run your Windows Azure instance
just the way you would run any other application in Visual Studio. This runs
the role instance(s) in the “development fabric”, which simulates running in
production. Note that just because something works in the development fabric,
it doesn’t mean you can be 100% certain it will run when you publish it to Windows
Azure, but it will get you most of the way there and it doesn’t cost you
anything to use it.
Your browser should open, showing your running web
application.
You will see the Windows Azure icon in your system tray. If
you right-cilck on it, you can view the Windows Azure Compute Emulator (where
you can see your role running or not running, whichever the case may be). Mine
is displayed in Figure 8.
Figure 8: Windows Azure Compute Emulator
From here, you can attach a debugger to an instance, view
the logging from the startup of each instance, and manage the service in the
development fabric (restart it, stop it, start it, etc.). You can also get the
IP address for the service, in case you didn’t check the box in the role
properties to have the http page start up automatically when the service
started.
If you look at the Storage Emulator, you should see
something similar to Figure 9.
Figure 9: Storage Emulator
This gives you then endpoints for storage if you need them,
and enables you to manage the development table storage (click Reset to clear
it out).
Let’s publish the application to the cloud. First go into Settings
and set the connection string for Windows Azure Storage to point to your storage
in Windows Azure. Then right-click on the cloud project and select Publish. You
will get the dialog displayed in Figure 10.
Figure 10: Publish the project to Windows Azure
If your role targets the .NET 4 Framework and you are
running Visual Studio 2010 Ultimate, you will be able to enable Intellitrace
for your role. If you do this, you can then see the Intellitrace output and use
it to debug your role.
If you select the blue link that says “Configure Remote
Desktop connections…”, you can configure the role to allow you to use Remote
Desktop to connect and log into the instance after it has completed starting up.
You will have to create a certificate and upload it to your hosted service
before you can do this. I’m going to skip this for now and click on OK.
Visual Studio will build the solution, create a service
package, upload it, create a new VM, and deploy the package to it. You can see
it progress in the Windows Azure Activity Log in Visual Studio in Figure 11.
When it has successfully completed, it will say “Complete”.
Figure 11: Windows Azure Activity Log displayed while
publishing to the cloud.
You can also watch the progress in the Windows Azure Portal
(http://windows.azure.com) as shown in
Figure 12.
Figure 12: Viewing the status of the deployment in the portal.
The Portal can be used to manage all of your services and
your storage accounts. You can also edit the service configuration of your
deployment through the portal. If you have configured RDP, this is where you
would connect to your instance.
After your role publishes successfully, you should be able
to open the URL in the browser and see your web application running in the
cloud. You can actually click on the link in the Windows Azure Activity Log
once the role is complete, as seen in Figure 13.
Figure 13: Completed deployment.
You will also see the link that says “Open in Server
Explorer”. If you click on that link, Server Explorer will be displayed in
Visual Studio, and you will be able to see your instance running, as displayed
in Figure 14.
Figure 14: Server Explorer
You can also view your Windows Azure Storage in Server
Explorer. You will probably have to add your storage account to the list – just
right-click on Windows Azure Storage and select Add New Storage Account. You
will be prompted for your credentials, and then you can view the content. The
content is read-only. You can view the blobs and the rows in the tables.
In summary, Microsoft has provided a development environment
that makes it easy for .NET Developers to develop for Windows Azure by
integrating the tools into Visual Studio 2010. You can sign-up for a free trial today at www.microsoft.com/cloud/windowsazure.