Getting Started Developing on Azure: Creating the Hosted Service and Storage Account

This is the next post on Getting Started developing on Azure with Visual Studio 2010 and Installing the Azure Management Certificates.

Starting to develop on Azure with Visual Studio can be a lot to eat the first time. Getting Visual Studio ready, including installing the Management Certificates and so on is not a simple task (the first time anyway). So that is why I made this little walk-through series on starting to develop on Azure… In the first part you’ll build and run your first project on the Azure Compute Emulator, which is the local test version of the cloud. In the second part you’ll get Visual Studio ready to directly publish your solution in the cloud by installing the management certificates and in this part you will create the Hosted Service and storage account to actually deploy from Visual Studio.

1.3 Creating the Hosted Service

Go back to the Azure Management Portal (windows.azure.com), and now click on the Hosted Services tab. To deploy we also need a hosted service, so click the New Hosted Service button to create one. This opens the Create a New Hosted Service dialog:

image

Enter a name for your service and URL prefix. The prefix should be world-wide unique, so try adding your company name or something unique to you in it.

If the chosen name is already taken you will be notified like this:

image

Now we need to choose in which data-center the service should be deployed. We can also do this using an affinity group. An affinity group is an easy way to keep everything together (services can communicate with one another more efficiently (and less cost) if they are running in the same data center) so choose affinity group and select Create a new affinity group… from the dropdown list.

Enter a name and datacenter; best take one near to your expected customers:

image

North Europe is the datacenter in Amsterdam, which is closest to where I live, so I took that one. Feel free to take another…

Click OK.

We’ll deploy using Visual Studio, so before you click OK, select Do not deploy. Now click OK.

1.1.5 Creating the Storage Account

Finally, before we can deploy we also need to create a Storage Account. Visual Studio will upload the package to storage and then instruct Azure to deploy it from storage.

Go back to the Management Portal (windows.azure.com)l. Now go the the Storage Accounts tab. Click on the New Storage Account button. This will open the Create a New Storage Account dialog:

image

Enter a unique (lowercase only) URL and use the same affinity group you used in the previous step. Hit OK.

1.1.6 Ready to deploy the web site

Now we are ready to deploy!

First we need to remove the local development trace listener from web.config configuration because it is not available in the cloud, but leave the diagnostic monitor listener:

Code Snippet
  1. <listeners>
  2.   <add type="Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener, Microsoft.WindowsAzure.Diagnostics, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
  3.     name="AzureDiagnostics">
  4.     <filter type="" />
  5.   </add>
  6. </listeners>

 

Go back to Visual Studio, right click your azure project, and select Publish… Now select your hosted service and storage account, and hit OK (you might need to cancel and re-open this window to refresh it).

image

Deployment should start and after a little while you should see the Windows Azure Activity Log:

image

Wait until this is complete, it may take several minutes or longer depending on bandwidth…

image

Click on the WebSite URL, the site should open.

1.1.7 Using Server Explorer

Open Server Explorer. With the Azure SDK tools installed, you can look here at Azure Compute and Azure Storage. Click on the Windows Azure Compute tree item, then select Add Deployment Environment…

image

Select your management certificate to list all hosted services there. Open the tree item and select Staging or Production. Click OK. From now on you can look at this environment from Visual Studio Server Explorer:

image

You can try the same for storage.

Later we will look at how we can use this to debug applications with Intelli-Trace.

The end. My Next post (next Wednesday) is going to be on remote debugging worker roles running in the cloud…

Installing the Azure Management Certificates

This is the next post on Getting Started developing on Azure with Visual Studio 2010.

Starting to develop on Azure with Visual Studio can be a lot to eat the first time. Getting Visual Studio ready, including installing the Management Certificates and so on is not a simple task (the first time anyway). So that is why I made this little walk-through series on starting to develop on Azure… In the first part you’ll build and run your first project on the Azure Compute Emulator, which is the local test version of the cloud. In this part you’ll get Visual Studio ready to directly publish your solution in the cloud by installing the management certificates and in part 3 you will create the Hosted Service and storage account to actually deploy from Visual Studio.

1.2 Deploying your solution to the cloud

Now we’re ready to deploy to the actual cloud environment. Start by logging on to the Azure Management Portal, which is at http://windows.azure.com . Open the Hosted Services tab, and select Management Certificates:

image

If you just started with Azure development you will not have any certificate here. To make Visual Studio integrate better with the management portal (actually with the management API’s) we need to upload a certificate here so your Visual Studio can publish projects to the cloud. This is easily done with Visual Studio.

1.1.3 Installing the Management Certificate:

Go back to Visual Studio with the cloud project open. Right-click the cloud project and select Publish

image

The Deploy Windows Azure project dialog should open:

With this dialog you can publish your project. The first option will create the package, but then you have to deploy it using the Management Portal. The second option will do this for you. In the first drop-down you need to select a Management Certificate, or create a new one.

Select Add… from the Credentials drop-down. The Windows Azure Project Management Authentication dialog opens:

image

Select <Create…> from the first drop-down. Enter a friendly name for your certificate. I call mine AzureManagment.

image

Now click the View button. This will allow use to export the certificate’s public key using the Details… tab:

image

Click on the Copy to File button. This opens the Certificate Export wizard. Click next. Choose “Do not export the private key”:

image

Click Next> twice, then choose a filename for the certificate. Hit Next> then Finish. Your certificate should be exported now.

Go back to the management portal (windows.azure.com), to the Management Certificates. Click on the Add Certificate button and select your previously exported file. Click Ok and wait for the import to complete. Your certificate should be added, and now you need to copy the subscription-id back to Visual Studio. It is right there in the properties window of the certificate:

image

So copy it, go to Visual Studio to where the Windows Azure Project Management Authentication is waiting. Copy the subscription-id and name it:

image

Click OK.

In the next blog post we will add a hosted service and storage account and deploy the solution…

Getting started developing on Azure with Visual Studio 2010

Starting to develop on Azure with Visual Studio can be a lot to eat the first time. Getting Visual Studio ready, including installing the Management Certificates and so on is not a simple task (the first time anyway). So that is why I made this little walk-through series on starting to develop on Azure… In this part you’ll build and run your first project on the Azure Compute Emulator, which is the local test version of the cloud. In part 2 you’ll get Visual Studio ready to directly publish your solution in the cloud by installing the management certificates and in part 3 you will create the Hosted Service and storage account to actually deploy from Visual Studio.

1.1 Azure Lab – Getting started developing

In this walk-through you will learn how to develop with Visual Studio 2010 on Azure. To be able to do this you need to have the latest Azure SDK with Visual Studio tools installed (SDK 1.4 at time of writing), and you should also have a valid Azure account.

1.1.1 Creating the Azure project

Start Visual Studio 2010 and create a new cloud project, calling it MyFirstCloudProject:

image

Click on Ok. The New Windows Azure Project dialog should open:

image

Click on the ASP.NET Web Role and click the > button. Then rename the project by clicking on the rename button:

image

Call it MyFirstWebRole:

image

Click OK.

Add a button to the web form:

image

Implement its click event as follows:

Code Snippet
  1. System.Diagnostics.Trace.WriteLine("Hello from Azure!");

To enable Tracing to the Windows Compute Emulator, add following configuration to your web.config (line 6 to 9 should be added):

Code Snippet
  1. <listeners>
  2. <add type="Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener, Microsoft.WindowsAzure.Diagnostics, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
  3. name="AzureDiagnostics">
  4. <filter type="" />
  5. </add>
  6. <add type="Microsoft.ServiceHosting.Tools.DevelopmentFabric.Runtime.DevelopmentFabricTraceListener, Microsoft.ServiceHosting.Tools.DevelopmentFabric.Runtime, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" name="DevFabricListener">
  7. <filter type="" >
  8. </filter>
  9. </add>
  10. </listeners>

Open the Solution Explorer and make sure that the Azure project is the start project. Run your solution by pressing F5. Note that Visual Studio will package your code and upload it to the Compute Emulator.

image

If not already running, the compute emulator (the little Azure icon in the system tray) will also be started. Right-click the Azure icon in the system tray and choose “Show Compute Emulator UI”.

After a while your browser will display the web site and the emulator will display loggings:

image

This window shows you output as your web role gets started, etc…

You can add some more by clicking the button. This should write something to the emulator:

image

Try placing a breakpoint on the button’s event handler. Click the button. Visual Studio should stop on the breakpoint. If your code was a little more complicated this would allow you to debug it.

In the next blog we will look at installing the management certificates to run this same code in the cloud, deploying it with Visual Studio 2010.

Creating and Using Custom Performance Counters in Windows Azure

Building software, especially software running on servers, requires some way to look “inside” the running application. Using the debugger is one way, but you cannot use a debugger on production applications. A better way is to use performance counters. These give you a way to see things, like how hard the CPU working, but also how many orders have been processed by your system. The first performance counter is provided by the system, the latter you can build yourself.

Before Azure SDK 1.3 you couldn’t create your own performance counters because your code doesn’t get write access to the region of the registry where you register your custom performance counters. But with elevated startup tasks this is easy. In the blog post I will show you how you can create a startup task to create custom performance counters, and how to use them in your role.

Commence by creating a new Visual Studio Cloud project. Add a single worker role. We’ll use this role to illustrate using a performance counter.

Add another project, now a Console project (call it InstallPerfCounters). We’ll use this console application as the startup task.

Implement the InstallPerfCounters console project as follows:

Code Snippet
  1. class Program
  2. {
  3.   static void Main(string[] args)
  4.   {
  5.     const string categoryName = "U2U";
  6.     const string categoryHelp = "U2U demo counters";
  7.  
  8.     if (!PerformanceCounterCategory.Exists(categoryName))
  9.     {
  10.       var counters = new System.Diagnostics.CounterCreationDataCollection();
  11.       counters.Add(new CounterCreationData
  12.       {
  13.         CounterName = "# secs/running",
  14.         CounterHelp = "How long has this been running",
  15.         CounterType = PerformanceCounterType.NumberOfItems32
  16.       });
  17.  
  18.       var category = PerformanceCounterCategory.Create(categoryName,
  19.         categoryHelp, PerformanceCounterCategoryType.MultiInstance, counters);
  20.     }
  21.   }
  22. }

This uses the same kind of code you would use anywhere else to create new performance counters.

Now we need to install this as a startup task. Add a folder to the worker role project, calling it startup. We need to add two files here, one the console project we just made, and a command file.

To copy the executable, let’s make first sure we’re using the release version at all time. Open the configuration manager:

image

Select Release as the configuration:

image

Build your project, ensuring everything compiles nicely.

Now right-click the startup folder from the worker role project and select Add Existing Item… Browse to the release folder of the console project, select the executable and choose Add As Link from the drop-down:

image

This should add the executable to the startup folder. Select it, and select Copy Always in the properties folder:

image

Now we are ready to add the command file. Don’t use Visual Studio for this, because it will add the Byte Order Mark which is not supported by Azure. The easiest way to do this is by right-clicking the startup folder, and select “Open Folder in Windows Explorer”. Then right-click the folder’s contents, and add a new text document:

image

Rename it to installcmd.cmd. Go back to Visual Studio. In Solution Explorer select “Show All Files”:

image

The installcmd.cmd should appear, you can now right-click it and select “Include in project”. Edit it to the following contents:

Code Snippet
  1. %~dp0InstallPerfCounters.exe /q /log %~dp0pc_install.htm
  2. exit /b 0

 

Now open the ServiceDefinition.csdef file from your cloud project and add a startup task:

Code Snippet
  1. <Startup>
  2.   <Task commandLine="startup\installCmd.cmd" executionContext="elevated" taskType="simple" />
  3. </Startup>

 

This should take care of installing the performance counter. Now let’s use it in our worker role. First we need to create the performance counter instance, and then update it. In this simple example we’ll make the counter increment once each second. So implement the worker role’s run as follows:

Code Snippet
  1. public override void Run()
  2. {
  3.   // This is a sample worker implementation. Replace with your logic.
  4.   Trace.TraceInformation("UsingPerfCounters entry point called");
  5.  
  6.   const string categoryName = "U2U";
  7.  
  8.   PerformanceCounter secsRunning = new PerformanceCounter()
  9.   {
  10.     CategoryName = categoryName,
  11.     CounterName = "# secs/running",
  12.     MachineName = "." /* current machine */,
  13.     InstanceName = Environment.MachineName,
  14.     ReadOnly = false
  15.   };
  16.   var counterExists = PerformanceCounterCategory.Exists(categoryName);
  17.  
  18.   while (true)
  19.   {
  20.     Thread.Sleep(TimeSpan.FromSeconds(1));
  21.     if (counterExists)
  22.     {
  23.       secsRunning.Increment();
  24.     }
  25.     Trace.WriteLine("Working", "Information");
  26.   }
  27. }

 

Publish this solution in Azure, not forgetting to turn on Remove desktop.

imageimage

Also note that I turn in IntelliTrace, whichh is great for debugging those nasty deployment problems…

When you complete publishing you can now remote desktop to the instance and use PerfMon to look at your custom performance counter. Or you can use Azure Diagnostics….

Silverlight and the Windows Azure AppFabric Service Bus

This blog post will show you how to allow a Silverlight application to call a service over the Windows Azure AppFabric Service Bus. The problem you need to solve is that Silverlight will look for a “clientaccesspolicy.xml” at the root uri of the service. When I tried it myself I couldn’t find any “how to” on this topic so I decided to turn this into a blog post. If anyone else has this blogged, sorry I am such a bad internet searcher Smile.

So, you’ve just build a nice Silverlight application that uses some WCF service you’re hosting locally. You’ve done all the steps to make it work on your machine, including the “clientaccesspolicy.xml” to enable cross-domain communication. The only thing is that you want to keep hosting the service locally and/or move it to another machine without updating the Silverlight client.

You’ve heard that the Windows Azure Service Bus allows you to do this more easily so you decide to use it. This is your current service configuration (notice the localhost address!).

Code Snippet
  1. <service name="SilverlightAndAppFabric.TheService" >
  2.   <endpoint name="HELLO"
  3.             address="http://localhost:1234/rest"
  4.             behaviorConfiguration="REST"
  5.             binding="webHttpBinding"
  6.             bindingConfiguration="default"
  7.             contract="SilverlightAndAppFabric.IHello" />
  8. </service>

What you now need to do is to move it to the AppFabric Service bus. This is easy. Of course you need to get a subscription for Windows Azure and set up the AppFabric service bus… Look for somewhere else on this, there’s lots of this around.

Then you change the address, binding and behavior like this:

You need an endpoint behavior, because your service needs to authenticate to the service bus (so they can send you the bill):

Code Snippet
  1. <endpointBehaviors>
  2.   <behavior name="REST">
  3.     <webHttp />
  4.     <transportClientEndpointBehavior>
  5.       <clientCredentials>
  6.         <sharedSecret
  7.           issuerName="owner"
  8.           issuerSecret="---your secret key here please---" />
  9.       </clientCredentials>
  10.     </transportClientEndpointBehavior>
  11.   </behavior>
  12. </endpointBehaviors>

You (might) need a binding configuration to allow clients to access your service anonymously:

Code Snippet
  1. <webHttpRelayBinding>
  2.   <binding name="default" >
  3.     <security relayClientAuthenticationType="None">
  4.     </security>
  5.   </binding>
  6. </webHttpRelayBinding>

 

And of course you need to change the endpoint to use the WebHttpRelayBinding:

Code Snippet
  1. <endpoint name="HELLO"
  2.           address="https://u2utraining.servicebus.windows.net/rest"
  3.           behaviorConfiguration="REST"
  4.           binding="webHttpRelayBinding"
  5.           bindingConfiguration="default"
  6.           contract="SilverlightAndAppFabric.IHello" />

 

This should to the trick. Yes, when you try the REST service using Internet Explorer you get back the intended result.

Now you update the address in your Silverlight application to use the service bus endpoint:

This is the old call:

Code Snippet
  1. wc.DownloadStringAsync(new Uri("http://localhost:1234/rest/hello"));

 

And you change it to:

Code Snippet
  1. wc.DownloadStringAsync(new Uri("https://u2utraining.servicebus.windows.net/rest/hello"));

 

Please note the switch to https and the service bus address.

You run your Silverlight client and it fails with some strange security error! The problem is that Silverlight will try to access the clientaccesspolicy.xml file from your new address. Since this is now the service bus this will not work. To solve it you simply add another REST endpoint that will return the clientaccesspolicy from this Uri. Start with the service contract:

Code Snippet
  1. [ServiceContract]
  2. public interface IClientAccessPolicy
  3. {
  4.   [OperationContract]
  5.   [WebGet(UriTemplate = "clientaccesspolicy.xml")]
  6.   Message GetPolicyFile();
  7. }

Implement it:

Code Snippet
  1. public Message GetPolicyFile()
  2. {
  3.   WebOperationContext.Current.OutgoingRequest.ContentType = "text/xml";
  4.  
  5.   using (FileStream stream = File.Open("clientaccesspolicy.xml", FileMode.Open))
  6.   {
  7.     using (XmlReader xmlReader = XmlReader.Create(stream))
  8.     {
  9.       Message m = Message.CreateMessage(MessageVersion.None, "", xmlReader);
  10.       using (MessageBuffer buffer = m.CreateBufferedCopy(1000))
  11.       {
  12.         return buffer.CreateMessage();
  13.       }
  14.     }
  15.   }
  16. }

 

And make sure it returns the right policy. This is what gave me a lot of headache, so here it is:

Code Snippet
  1. <?xml version="1.0" encoding="utf-8"?>
  2. <access-policy>
  3.   <cross-domain-access>
  4.     <policy>
  5.       <allow-from http-request-headers="*">
  6.         <domain uri="http://*"/>
  7.         <domain uri="https://*"/>
  8.       </allow-from>
  9.       <grant-to>
  10.         <resource path="/" include-subpaths="true"/>
  11.       </grant-to>
  12.     </policy>
  13.   </cross-domain-access>
  14. </access-policy>

 

Pay special attention to the allow-from element. By default this will allow SOAP calls, not REST calls.

For explanations read the documentation. You might want to edit it anyway.

Now add a similar REST endpoint, making sure the clientaccesspolicy is at the root level:

Code Snippet
  1. <endpoint name="CLIENTACCESSPOLICY"
  2.           address="https://u2utraining.servicebus.windows.net"
  3.           behaviorConfiguration="REST"
  4.           binding="webHttpRelayBinding"
  5.           bindingConfiguration="default"
  6.           contract="SilverlightAndAppFabric.IClientAccessPolicy" />

 

Done! A working example (you will have to change the client credentials to your own) can be downloaded from the U2U site here.

Azure Inter-role communication using callback instead of queues

I’m currently playing with Azure and the Azure training kit, and I learned something cool today. When you work with Azure you can setup multiple worker roles for your Azure application. If you want to make these roles talk to one another you can use the queuing mechanism which is part of Azure. But you can also use WCF dual interface mechanism. Imagine you want to build a chat application using Azure and WCF. In this case you define a worker role that exposes a dual interface like this:

Code Snippet
  1. [ServiceContract(
  2.     Namespace = "urn:WindowsAzurePlatformKit:Labs:AzureTalk:2009:10",
  3.     CallbackContract = typeof(IClientNotification),
  4.     SessionMode = SessionMode.Required)]
  5. public interface IChatService
  6. {
  7.   /// <summary>
  8.   /// Called by client to announce they are connected at this chat endpoint.
  9.   /// </summary>
  10.   /// <param name="userName">The user name of the client.</param>
  11.   /// <returns>The ClientInformation object for the new session.</returns>
  12.   [OperationContract(IsInitiating = true)]
  13.   ClientInformation Register(string userName);
  14.  
  15.   /// <summary>
  16.   /// Sends a message to a user.
  17.   /// </summary>
  18.   /// <param name="message">The message to send.</param>
  19.   /// <param name="sessionId">The recipient's session ID.</param>
  20.   [OperationContract(IsInitiating = false)]
  21.   void SendMessage(string message, string sessionId);
  22.  
  23.   /// <summary>
  24.   /// Returns a list of connected clients.
  25.   /// </summary>
  26.   /// <returns>The list of active sessions.</returns>
  27.   [OperationContract(IsInitiating = false)]
  28.   IEnumerable<ClientInformation> GetConnectedClients();
  29. }

The IClientNotification interface is the call-back interface which is implemented by the client of the service. The client calls the Register method on the server, which then can keep track of the client by using the callback interface:

Code Snippet
  1. IClientNotification callback =
  2.   OperationContext.Current.GetCallbackChannel<IClientNotification>();

 

If you host the service as a single instance, all clients will register to the same service, so this service can easily track each client. But if you grow and start using multiple instances of your service in Azure, each client will register to a single instance, so each instance will know only about its own clients. If two clients, registered to different instances, want to communicate, the services will have to handle the communication for this. The solution is easy, make them also expose the IClientNotification callback service interface using internal endpoints, so they can communicate to each other:

Code Snippet
  1. public class ChatService : IChatService, IClientNotification

 

Of course each service will have to be able to find the other service instances. This you can do with the RoleEnvironment class, which you can use in your worker role class:

Code Snippet
  1. var current = RoleEnvironment.CurrentRoleInstance;
  2. var endPoints = current.Role.Instances
  3.                 .Where(instance => instance != current)
  4.                 .Select(instance => instance.InstanceEndpoints["NotificationService"]);

 

This does require the worker role to define an internal endpoint. You can do this in Visual Studio 2010. Select the worker role’s properties, go to the endpoint tab and enter an internal endpoint:

image

The rest of the code is straightforward (of your comfortable with WCF that is) and can be found in the Azure Training Kit (look for the Worker Role Communication lab).