Yeah, finally the information you’ve been waiting for. 
Sorry its late. I’d like to say it was due to the 22hr outage Windows Azure suffered over the weekend, but that would be a bit of a fib. So lets just say I have a busy social life. At least that is a lie big enough to be worth telling. For this walkthrough, I’m assuming you already have the SDK and project templates installed. If you don’t, then stop reading and go get them.
Back? ok, here we go.
Fire up VS08 and go to the file –> new –> project menu to open the “New Project” dialog box. Next select the Could Service category. You should see the following projects listed…
The one we’re going to talk about today is the Web Cloud Service. As you may recall, an Azure Web Role application allows for inbound as well as outbound connections whereas a Worker Role only allows for outbound. I want to start with the Web role since this one will be most like traditional .NET web development. Select the “Web Cloud Service” template, give it a name, and click “OK” to create a sample project.
The image to the left shows the solution explorer for the newly created project. Notice that there are two projects in the solution. The bottom project, WebNotepad1_WebRole looks much like a typical web application. We have references, properties, a default page, and a Web.config file. The list of references is the only quickly noticeable difference.
The top project however, is a different story. WebNotePad1 is a Cloud Service Project (extension ccproj). Unlike the previous project which was a straight up web project, this is a new Azure specific project. This project is required if we want to debug, run, or publish our project. If you don’t see this project, you may have created a web role project by mistake. If that’s the case, you can create a new Blank Cloud Service project and simply add your web role to it. Easily mended.
There’s a considerable amount that can be done with the configuration files in this project, enough to fill a chapter in a book someone, somewhere is already writing. So I’m just going to touch on a couple things here. There’s two configuration files in here. ServiceConfiguration, and ServiceDefintion. These files are just what they say they are. The definition file describes the contents of the configuration file. The configuration file tells the Azure fabric how your application runs (for example,the number of instances of each role to run). It can be updated on the fly once the application has been deployed. The definition on the other hand cannot be updated without restarting your application. I’ll try to get more into these and managing your published application at a later date.
That aside, lets open up the Default.aspx file of the WebNotepad1_WebRole project and put some custom text into it. “Hello world” has been done to death so I prefer something more likely to engender world peace. You can put in whatever you like and press F5 to start debugging your new cloud application. Now the magic starts to happen. The Development Fabric starts up and using the cscfg file mentioned earlier, a instance of our web app is powered up and deployed. If this is the first time you’ve started the development fabric, you’re also going to be prompted to configure Development Storage. I’ll touch on storage another day, so just take the defaults so that our page starts running.
After a few moments/minutes, a web browser should appear and display our page. Things may look similar to this screen shot.
The URL of the displayed web page makes it pretty clear that this is running locally. As I previously mentioned, its running in the local instance of the Windows Azure Fabric, the Development Fabric. If you look down the task bar, you’ll even find the running instance of the Dev Fabric as an icon (see the notes on the above screen shot). Double-click on that icon to open up the Development Fabric console. The Dev Fabric console allows us to manage what is going on with each instance of our Azure applications. Using this, we can see each instance of the app (if we had more than one running), as well as any messages being output by that process to the console. We can start/stop those instances, and even make manual changes to the configuration.
So we’ve started a new project, and gotten it running locally. Yeah us! Now buckaroos, its time to take it to the next level and unleash this little monster on an unsuspecting populace. We’re going to publish our application to the cloud. We’ll start by logging into the Windows Azure portal and creating a hosted services project (go to lx.azure.microsoft.com and after logging in, click on the “new project” link). What we need from this, is the Application ID and Return URL.
Now we associate our application with the assigned ID by right clicking on the Cloud Services project (this is the one that contains our csdef and cscfg files), and selecting properties. In the properties area, select the Portal tab and enter in the assigned Application ID. Now save 
the project, then right click it again and select “Publish”. This will “build” our Cloud Services project, creating a deployment package and associated configuration file. These artifacts can then be uploaded to Windows Azure for deployment by the fabric.
There’s a considerable amount of automation magic going on here. But the important thing is to see that the pieces are starting to come together. Our Web Role project is compiled, then a Windows Azure specific deployment package is created for it via the Cloud Service project (this results in a copy of our cscfg and a cspkg (cloud service package) deployment package). When this build is complete, two windows will open, an explorer window to the location of our files on disc, and a web browser so we can log into the Azure portal and deploy our application into the cloud. Log into the portal and click on the “Deploy” button. We can now select our two files, give this deployment a name, and upload… er DEPLOY!
This is where the Azure Fabric really starts doing its work. It brings in my package and its configuration file. It then looks for a VM instance it can use for my application, configures it appropriately, and installs the application (and any dependent bits into the cloud for me). Depending on the size/complexity, this can take several minutes. Once that’s done, we’re ready to start the application and preview it. So click on the “Run” button and when its complete (watch the status of the WebRole, make sure its “Started” and not “Initializing”), click on the provided Web Site URL to preview the application. Starting the application can take longer then deployment did. Its during this startup that the VM instance is actually spun up and made ready for use.
At this point, the application is live, and ready to be used. However, its not in the final production location. Its always important to test an application in an environment that matches its final production environment as closely as possible. And while the Development Fabric does its best, there’s just no substitute for running in the cloud. To that end, Windows Azure allows for a two stage deployment, staging and production. After our first deployment, the application sits in the Staging Environment and is given a URL that uses a randomly assigned GUID. This GUID helps hide it from anyone else on the internet and gives us an opportunity to test the application privately. Once we’re certain the application is working, we can then click on the promote icon (its a yin/yang symbol between our environments) to promote it to production.
And there you have, it, your first Windows Azure web cloud service. If you are truely bored, you can check out this sample application at: http://brentnotepad.cloudapp.net/
In my next post, I’m going to test the waters with the Windows Azure’s local storage. In preparation, I’ve started forgetting everything I’ve ever learned about relational databases.
