How to publish your Windows Azure application right from Visual Studio 2010

Windows Azure is an emerging technology that will be gaining bigger share of our life as software developers or IT Pros. Using earlier releases of Windows Azure Tools for Visual Studio there was an almost painful process of deploying application into the Azure environment. The standard Publish process was creating Azure package and opens the Windows Azure portal for us to publish our package manually. This option still exists in Visual Studio 2010, and is the only option in Visual Studio 2008. However, there is a new, slick option that allows us to publish / deploy our azure package right from within Visual Studio. This post is around that particular option.

Before we begin, let’s make sure we have installed the most recent version of Windows Azure Tools for Visual Studio.

For the purpose of the demo I will create very simple CloudDemo application. Just select “File” –> “New” –> “Project”, and then choose “Cloud” from “Installed Templates”. The only available template is “Windows Azure Cloud Service C#”:

A new window will pop up, which is a wizard for initial configuring Roles for our service. Just add one ASP.NET Web Role:

Assuming this is our cloud project we want to deploy, let’s first pass the Windows Azure Web Role deployment checklist, before we continue (it is a common mistake to miss configuring of DiagnosticsConnectionString setting of our WebRole).

Now is time to publish our Windows Azure service with that single ASP.NET WebRole. There is initial configuration, that must be performed once. Then every time we go to publish a new version, it will be just a single click away!

Right click on the Windows Azure Service project from our solution and choose “Publish” from the context menu:

This will popup a new window, that will help publish our project:

There are two options to choose from: Create Service Package Only and Deploy your Cloud Service to Windows Azure. We are interested in the second one – Deploy your Cloud Service to Windows Azure. Now we have to configure our credentials for deploying onto Windows Azure. The deployment process uses the Windows Azure managed API that works with client certificate authentication, and there is a neat option for generating client certificates for use with Windows Azure. From that window that is still open (Publish Cloud Service) open the drop down, which is right below “Credentials” and choose “Add …”:

Another window “Cloud Service Management Authentication” will open:

Within this window we will have to Create a certificate for authentication. Open the drop down and choose “<Create…>”:

This option will automatically create certificate for us (we have to name it). Once the certificate is created, we select it from the drop down menu and proceed to step (2) of the wizard, which is uploading our certificate to the Windows Azure Portal. For this task, the wizard offers us an easy way of doing this by copying the certificate to a temp folder. By clicking on the “Copy the full path” link it (the full path) is automatically copied onto our clipboard:

Now we have to log-in to the Windows Azure portal (http://windows.azure.com/) (but don’t close any Visual Studio 2010 Window, as we will be coming back to it) and upload certificate to the appropriate project. First we must the project for which we will assign the certificate:

Then we click on the “Account” tab and navigate to the “Manage my API certificates” link:

Here, we simply click browse and just paste the copied path to the certificate, then click Upload:

Please note, that there is a small chance of encountering an error of type “The certificate is not yet valid” during the upload process. If it happens you have wait for a minute or two and try to upload it again. The reason for this error is that your computer time might not me as accurate and synchronized, as Windows Azure server’s. Thus, your clock may be a minute or more ahead of actual time and your generated certificate is valid from point of time, which has not yet occurred on Windows Azure servers. When you upload the certificate you will see it in the list of installed certificates:

After you upload the certificate successfully to the Windows Azure server, you have to go back to the “Account” tab and copy the Subscription ID to your clipboard:

Going back to Visual Studio’s “Cloud Service Management Authentication” window, you have to paste your subscription ID onto the field for it:

At the last step of configuring our account, we have to define a meaningful name for it, so when we see in the drop down list of installed Credentials, we will know what service is this account for. For this project I chose the name “WindowsAzureCloudDemoCert”. When we are ready and hit OK button, we will go back to the “Publish Cloud Service” window, we will select “WindowsAzureCloudDemoCert” from Credentials drop down. An authentication attempt will be made to the Azure service to validate Credentials. If everything is fine we will see details for our account, such as Account name, Slots for deployment (production & stating), Storage accounts associated with that service account:

 

When you hit OK a publish process will start. A successfull publish process finishes for about 10 minutes. A friendly window within Visual Studio “Windows Azure Activity Log” will show the process steps and history:

Well, as I said there is initial process of configuring credentials. Once you set up everything all right, the publish process will be just choosing the credentials and Hosted Service Slot for deployment (production or staging).

Have a great time developing for Windows Azure!

How to debug your application (http protocol) using Fiddler

Fiddler has been out there for a while, but recently I discovered that it is either unknown, or not used, so I decided to write a short post on what it is, and how we can easily debug HTTP traffic (for example WCF Service calls) using it.

Before diving into essentials I would like to mention what it is. Fiddler is a debugging HTTP proxy(you can read more on what proxy server is here). Being so, when started it automatically configures user’s system to use it.

So, here is a “Welcome” screen of Fiddler:

Where, you can see a Web Sessions list (1), Working area (2,3) which is split over Action tabs (2) and Information window part (3). From the Action tabs, you would spent most of the time inside “Inspectors” while you debug your http traffic.

Once you download, install and run it, you can check the Internet Connection settings, and you will notice that it has automatically configured the system to use a HTTP Proxy on address 127.0.0.1 (which is local machine) and port 8888:

Please note, that although the shortest way to go to “Internet options” if from the “Tools” –> “Options” menu from Internet Explorer, these options are not just “Internet Explorer Options”. These are system-wide internet connectivity options, and all windows based programs are reading them. So when this proxy is set, any program that relies on windows settings (and not its own settings) will use that proxy for HTTP connections.

So let’s see how to inspect a single HTTP request. Just install and run Fiddler. You can run fiddler either from Windows’ Start Menu, or from Internet Explorer’s “Tools” menu. Once you run it, just leave it open and navigate to a website of your choice. You will be surprised how many HTTP requests are issued for a single web page to load. Every single image you see, every single style loaded, every JavaScript load initiates a HTTP request. So pick up one of the requests (preferable some of the first requests, that will load the HTML) and go to Inspectors from Action tabs:

So, you see the selected web session (1), and you click on Inspectors (2). Well, the Inspectors information area is split horizontally on two parts. First part (3,4) is inspecting HTTP request issued by the client application, while the second (bottom) part (5,6) is inspecting the server response. On the image 3 and 5 are the different types of inspectors, while 4 & 6 are the information parts that shows information structured by the way of showing it (using 3 & 5). You will easily see that you can inspect the request by viewing it in:

• Headers – showing only headers
• TextView – showing plain text view of the request
• WebForms – showing only variable names & values sent with the request (if you have some forms submitting some data)
• HexView – shows hexadecimal representation of the request
• Auth – showing just the Authentication headers (if present), so you can inspect issues with authentication
• Raw – showing the Raw HTTP request (headers + body as sent by the client application)
• XML – showing the request in XML tree navigation structure. It is very useful for visualizing XML RPC communication or SOAP communication, as it displays the XML in tree structure.

For the Response part of the screen you will see 3 additional types of displaying information:

• Transformer – showing general information on the response, as well as response size
• Caching – showing whether the response sent is cached
• Privacy – showing any information, if present, regarding PGP privacy
• Image View – showing the actual image, if the request was returning image

During development process we are more likely to run your application at “localhost”. What is localhost? Long explanation you can find here: http://en.wikipedia.org/wiki/Localhost. In basics, this your computer. And localhost is always resolved as IPv4 address 127.0.0.1 or IPv6 address ::1. Here comes the tricky part. You can read the FAQ Section on Debugging localhost. As explained, if your application launches on http://localhost:45960/WebSite1/Default.aspx, you can change the “localhost” to “ipv4.fiddler” (http://ipv4.fiddler:45960/WebSite1/Default.aspx) and you will see the same page, but the traffic will go through fiddler.

The issue comes from the way localhost is interpreted by applications. Although a system proxy is configured, the applications (especially .NET based) automatically bypass proxy for this address. And you have no means (in .NET) to instruct application to use proxy server when connecting to localhost. So you have to use any other name to access your application. The tricky moment is that Cassini Web Server (Visual Studio development server) binds only to IPv4 address of 127.0.0.1. And you must somehow add another hostname that resolves to 127.0.0.1. The easiest, the smoothest way to do that without writing any code, without altering any configuration setting of your project, without changing the registry, is relying on the way windows DNS resolver works. On every windows machine (well at least since Windows XP & 2000 and later) there is one single plain text file, located on same place on all windows platforms (x86, x64) regardless of windows version:

c:\windows\system32\drivers\etc\hosts

It is a file without extension. In more recent versions of windows you have to be administrator (run notepad as administrator) in order to save changes to that file. It is very simple and its first lines are following:

# Copyright (c) 1993-2009 Microsoft Corp.
#
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
#
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# space.
#
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a '#' symbol.
#
# For example:
#
#      102.54.94.97     rhino.acme.com          # source server
#       38.25.63.10     x.acme.com              # x client host

# localhost name resolution is handled within DNS itself.
#    127.0.0.1       localhost
#    ::1             localhost

I open that file, and add a single line at the bottom:

127.0.0.1 developdemo

Now I know that whenever I type http://developdemo/ I will open the localhost (127.0.0.1). And whatever windows application makes a HTTP request to “developdemo” – it will be requesting information from localhost. And if Fiddler is running, it will log all and any HTTP requests that are going to and from developdemo host.

Well, I gave you the basics, and I hope that you now know that there is a way to debug your HTTP based application.

Windows Azure Web Role Deployment Checklist

When you develop for Windows Azure for the first time, there are a couple of things that you have to be careful about, in order to deploy your application successfully.

For this checklist (to be more complete) I will use a Silverlight Application with WCF RIA Services and Entity Framework 4.0. It is great and Windows Azure already supports .NET 4.0 along with all the goodies that come along with it. I will show the application in another post, now it is more important what we have to do in order to successfully deploy our application. I will not put them in ordered list, because if you fail in any, your application will cycle through “initializing – busy – stopping – initializing – busy – stopping”.

You can download the source solution from here.

· Diagnostics connection string

Whenever you choose to create a new Web Role, a WebRole.cs file is added to your web application. It is very important part of your Windows Azure Web Role. It gives you the possibility to intercept the Start and Stop events of your Web Role and do some initializing or cleaning up. It also starts the Diagnostics Monitor, which is something you can’t live in Azure without! The Diagnostics Monitor uses Azure Storage to save diagnostics logs, that’s why it needs a connection string. This connection string, however is set to use development storage by default:

It is very easy to change that connection string – just right click on your Web Role from the Cloud Service project choose Properties, then select Settings from the left navigation tabs. Now click on the […] button which is located right next to the Value string and new window will appear:

You have to enter storage credentials. A good practice is to always use HTTPS endpoints. The Account name and Account key, you can get from the Azure Developer portal. Once you create an Azure Storage service, you can give the account name, and the keys are generated from the portal:

You will have to go to Windows Azure (1) and then select your Storage Service (2). Your account name (4) and account keys (5, 6) are located within main Cloud Storage settings area (3). You can use either of the keys – Primary (5) or Secondary (6) as configuration.

You are done. Of course the Windows Azure Storage service can be accessed from any place with internet connection, so now you can start and run your application to check out if it will run smoothly on local development fabric.

· References in Web Role

Dealing with References can be really annoying in Web Roles & Worker Roles! You have to be very careful – you have to select Copy Local = True, for each and every assembly that you refer and that is not part of Core .NET Framework 4.0. This of course includes any third party assemblies (such as NetAdvantage for .NET). More interesting for you to find out, that you have to set Copy Local to True even for the following assemblies:

Microsoft.WindowsAzure.Diagnostics

Microsoft.WindowsAzure.StorageClient

The WindowsAzure part of the names of these assemblies would make you think that they must exists on the Azure VM, but they don’t! However the Microsoft.WindowsAzure.ServiceRuntime is part of Azure VM deployment, and you can safely leave it as Copy Local = False.

Working with WCF RIA Services, you will also have to set this attribute (Copy Local) for all RIA assemblies:

System.ServiceModel.DomainServices.EntityFramework

System.ServiceModel.DomainServices.Hosting

System.ServiceModel.DomainServices.Hosting.OData

System.ServiceModel.DomainServices.Server

· Target CPU Architecture

Windows Azure uses 64 bit CPUs and the operating system (Windows Server 2008 based) is x64. So your assemblies – any and all assemblies that run as part of your Web Role should be compiled as either “Any CPU” or “x64”. In very rare situations, when you use Worker Role, you can use x86 assemblies, but you can only execute them in separate process, that is not part of the Role! The target CPU architecture is managed from "Configuration Manager". You can launch the configuration manager by right clicking on the Solution in Solution Explorer and selecting "Configuration Manager". You will see the following dialog:

Most probably you've never seen this dialog, but it is something that you have to pay attention when developing for Azure!

· Web.config issues

As you may already know – Windows Azure Guest OS is Windows 2008 based. That means your web roles are run on IIS 7. So any configuration that is not compatible will cause your web role to not start and begin cycling.

Well, this is first, not fully complete, but the very first checklist you have to check even before you are going to deploy your WebRole!

Display PHP error messages on IIS 7.0 / 7.5

Have you ever tried running PHP on IIS with FastCGI? Yes, it runs, and it does it smoothly. However regardless of php.ini settings for “display_errors” and “error_reporting”, starting with IIS 7.0, you will most probably see only “Internal Server Error 500.XX” for any error generated by PHP (even if it is just a warning or even notice). And yes, the hard workaround is to turn on Failed Request Tracing on the site, and examine FRT log files. Which I’m sure you don’t want!

The solution is here: http://serverfault.com/questions/69839/show-php-error-message-on-iis-7

The reason:

With IIS7, it doesn't pass the errors through by default. It's "existingResponse" that needs to be set.

The solution (run this line with elevated command prompt):

c:\windows\system32\inetsrv\appcmd.exe set config "{sitename}" -section:system.webServer/httpErrors /existingResponse:"PassThrough" /commit:apphost

and do not forget to replace {sitename} with the real site name.

New features in SQL Azure

An amazing set of new features has been announced recently. These features include:

• 50 GB Database SKU, available upon request
• MARS (Multiple Active Result Sets) This is very useful feature, since lots of developers are having issues with connection when using Entity Framework. The EF connection string enables MARS by default and developers are having though times to identify connection errors.
• Alter rename process for symmetry in renaming databases

You can read more details at SQL Azure team blog:
http://blogs.msdn.com/sqlazure/archive/2010/04/16/9997517.aspx