I suppose part of it is the potentially unfamiliar syntax, so let’s start there. You will usually find SetConfigurationPublisher called in code that looks similar to the following:

CloudStorageAccount.SetConfigurationSettingPublisher((configName,
                                                      configSettingPublisher) =>
{
    string configValue = RoleEnvironment.GetConfigurationSettingValue(configName);
    configSettingPublisher(configValue);
});

In a nutshell, you’re invoking a method that expects a method that takes a method as a parameter. Confused? No worries – it becomes clearer once you unravel the lambda expression.

First, note that the SetConfigurationSettingPublisher method expects a single parameter, of type Action<string,Func<string,bool>>. Instead of using the lambda expression, we could simply define a matching method as follows:

private void MySettingPublisher(string configName,
                                Func<string, bool> configSettingPublisher) {
}

Then the call to SetConfigurationSettingPublisher becomes the following:

CloudStorageAccount.SetConfigurationSettingPublisher(MySettingPublisher);

Now, when a call is made to retrieve settings from configuration, Azure will invoke our MySettingPublisher method. So far so good, but it won’t work yet because our method doesn’t actually do anything. If you look at the parameters that are passed to our method, you will notice that we receive a string (called configName) and a Func<string,bool> called configSettingPublisher. In other words, Azure will give us the name of the configuration setting that is being retrieved as well as a method that expects a string and returns a Boolean. We just need to call that method once we’ve figured out what the value for the setting should be. So, a few lines of implementation are all it takes to complete our code:

private void MySettingPublisher (string configName,
                                 Func<string, bool> configSettingPublisher)
{
   string configValue = RoleEnvironment.GetConfigurationSettingValue(configName);
   configSettingPublisher(configValue);
}

When you use a method such as CloudStorageAccount.FromConfigurationSetting, Azure looks for a setting publisher. Thanks to an earlier call to SetConfigurationSettingPublisher, it finds your MySettingPublisher method which it dutifully invokes. Your code gets the actual value from configuration (using RoleEnvironment.GetConfigurationSettingValue) and invokes the method Azure provided with the Func<string, bool> parameter.

But why all this back-and-forth between Azure and your code? Shouldn’t CloudStorageAccount.FromConfigurationSetting know that you want to grab the setting out of ServiceConfiguration.cscfg and just take care of it for you?

It turns out that being able to set your own “setting publisher” has code reusability benefits. The most likely scenario is building a Web application that may or may not run in Azure. No Azure, no Service Configuration.cscfg file so you might place the setting in the <appSettings> section of Web.config:

<configuration>
  <appSettings>
    <add key="MyConnectionString" value="UseDevelopmentStorage=true" />
  </appSettings>
</configuration>

Now, let’s modify our MySettingPublisher method as follows:

private void MySettingPublisher(string configName,
                                Func<string, bool> configSettingPublisher)
{
  var configValue = RoleEnvironment.IsAvailable ?
       RoleEnvironment.GetConfigurationSettingValue(configName) :
       System.Web.Configuration.WebConfigurationManager.AppSettings[configName];
  configSettingPublisher(configValue);

}

With this in place we can run our Web application outside Azure and it still works, it just uses Web.config instead of ServiceConfiguration.cscfg.

By the way, as Steve Marx points out, if you are building an Azure-specific solution and would rather not worry about all this “setting publisher” business, you could simply use the following to initialize your storage account:

string configValue = RoleEnvironment.GetConfigurationSettingValue("MyConnectionString");
CloudStorageAccount account = CloudStorageAccount.Parse(configValue);

Sample code here!

I’ll be updating a number of these videos, starting with the following which have recently been posted to the msdev site:

• Windows Azure How To Guide: Getting Started Developing on Windows Azure
• Windows Azure How To Guide: Storing Blobs in Windows Azure Storage

The video on BlobStorage includes a demonstration app – you can download the source code here.

Cheers!

http://www.msdev.com/Directory/Description.aspx?eventId=1665

This is actually the first in an eight-part series on WM6.5 that IT Mentors is doing for msdev. Oh, and you can download the demo that I used here (note that in order for this demo to work you’ll need to grab the managed code wrapper for Windows Mobile Gestures!)

• AppFabric Overview
• AppFabric Fundamentals
• AppFabric Service Bus
• AppFabric Access Control Service

Source code for the “AppFabric Fundamentals” session can be downloaded here. The source code I used in the Service Bus and ACS sessions is from the AppFabric SDK, which you can get here.

Cheers!

At any rate, the changes mean that the Azure Virtual Lab at msdev.com no longer works as is. I’ll be working on updated content that reflects the latest changes, but in the meantime you should be able to proceed with the help of the following file (luckily, I encapsulated all storage client code into a single class, so this should be a relatively easy fix.)

AzureStorageClient.cs

UPDATED: The Windows Azure Virtual Lab has now been updated to reflect the November API changes – you can check it out here.

In a Windows Azure application, the “startup project” is set to the Cloud Service by default. So when you hit F5, the development fabric spins up, the service is packaged and deployed, a browser window opens to host your start page and the Visual Studio debugger attaches to the dev fabric process. But if you right-click your Web role, select “Set as StartUp Project” and then hit F5, Visual Studio will start a debugging session attached to the ASP.NET Web Development Server – in other words, outside of the development fabric. It’s a great way to test the dual-configuration approach I mentioned in my last post!

In this post I’d like to address configuration. If you’re an ASP.NET Web developer, you already know all about web.config, and you probably use it all the time to store configuration settings for your application. Let’s assume you want to store a simple message in configuration; your web.config file would contain the following:

<appSettings>
   <add key="messageText" value="Hello, ASP.NET!"/>
</appSettings>

Then you could write some application code that retrieves the value (in this case, displaying it on the Web page using an ASP.NET Label control):

message.Text = WebConfigurationManager.AppSettings["messageText"];

The good news is that Web applications running in Windows Azure support web.config so this code will work without any modifications whatsoever. The bad news is that when you deploy an Azure application, the web.config file gets packaged up along with the rest of the Web application components in a .csx file. This sort of defeats the purpose of putting your message in a configuration file, yes? If you didn’t need the ability to change the message without recompiling your application you could have just placed the message text directly into your code. So web.config is a great place for application settings unless you’re app is in the cloud…

Ah, but Windows Azure does support the idea of a configuration file – it goes by the name ServiceConfiguration.cscfg and it gets deployed separately from the .csx package. And, you can add your own custom settings to it, just like web.config. It takes a bit more effort, since you must first define the setting in ServiceDefinition.csdef:

<ConfigurationSettings>
   <Setting name="messageText"/>
</ConfigurationSettings>

…and then set the actual value in ServiceConfiguration.cscfg:

<ConfigurationSettings>
   <Setting name="messageText" value="Hello, Azure!"/>
</ConfigurationSettings>

Once you’ve done that, you can retrieve the value quite easily:

message.Text = RoleManager.GetConfigurationSetting("messageText");

If you’re moving your application into the cloud and you’re “not looking back,” it may make sense to move your settings into the .cscfg file and use that exclusive of web.config. But what about building an application that can be deployed in AND out of the cloud?

Fortunately, it is not difficult to determine at runtime whether you are running in or out of the cloud and retrieve configuration settings as appropriate. In the following code, note how we can check the RoleManager.IsRoleManagerRunning property:

if (RoleManager.IsRoleManagerRunning)
{
   // we're in the cloud
   message.Text = RoleManager.GetConfigurationSetting("messageText");
}
else if (System.Web.HttpContext.Current != null)
{
   // we're NOT in the cloud, but we're still in a Web application
   message.Text = WebConfigurationManager.AppSettings["messageText"];
}
else
{
   // not in the cloud, not in the web... desktop app maybe?
   message.Text = ConfigurationManager.AppSettings["messageText"];
}

As you can see, we’ll get the value stored in .cscfg if we’re running in the fabric (the cloud), we get the one from web.config if we’re a “regular” ASP.NET Web application and we can even fall back to the standard .NET Configuration manager.

One more thing – checking RoleManager.IsRoleManagerRunning all the time will surely get tedious if you have a lot of settings to retrieve. You may want to encapsulate the settings retrieval into a reusable component, perhaps similar to the following:

public class SettingsManager
{
   private static Settings _settings = new Settings();
   public static Settings Settings
   {
      get
      {
         return _settings;
      }
   }
}

public class Settings
{
   public string this[string key]
   {
      get
      {
         if (RoleManager.IsRoleManagerRunning)
         {
            return RoleManager.GetConfigurationSetting(key);
         }
         else if (System.Web.HttpContext.Current != null)
         {
            return WebConfigurationManager.AppSettings[key];
         }
         return string.Empty;
      }
   }
}

You can find a much more comprehensive example (one that also deals with logging) in the HelloFabric sample that ships with the Windows Azure SDK.

Really, a Web Role project and a Web Application project are identical, with one very minor exception: by default, Web Role projects contain a reference to the Microsoft.ServiceHosting.ServiceRuntime assembly and Web Application projects do not:

The ONLY difference between a Web Role project and a Web Application project

Because Web Roles and Web Applications are architecturally identical, you can easily add an existing Web application to a Windows Azure application… It’s a two step process; first, add the Web Application project to your cloud solution:

Adding a new Web Application project to an existing Cloud Service

Second, add the project as a Web Role by right-clicking “Roles” in Solution Explorer and selecting Add > Web Role Project in solution…

Adding an existing Web Role project in solutions

Your original Web Application project is now part of your Windows Azure application! To make it identical to a Web Role created “from scratch,” simply add a reference to Microsoft.ServiceHosting.ServiceRuntime, which you can find in the Windows Azure SDK (the default location in most cases will be C:\Program Files\Windows Azure SDK\v1.0\ref\Microsoft.ServiceHosting.ServiceRuntime.dll.)

One more thing – when you add an existing application to a Visual Studio solution, it just creates a pointer to the original .csproj/.vbproj file from your solution – in other words, make sure you create a backup copy of your original Web Application before you move it into the cloud!

That’s the easy part of migration – however, it can get more complicated and more challenging if your application relies on data storage, services, client-side code or 3rd party libraries. I’ll be posting some short articles on how to deal with these various scenarios in the coming days and weeks.

In previous versions of Visual Studio the “Add Reference” dialog was always very slow to appear the first time you accessed it each session. Turns out this was because the dialog defaults to the “.NET” tab and results in a synchronous scan of the global assembly cache (blocking the UI thread). Simply by changing the scan to an asynchronous operation and having the dialog default to the “Projects” tab, the dialog will load much faster. More details in Scott’s post.

Anyway, this is the type of “feature” that is likely to get buried amongst more “exciting”, new features but it shows the type of thinking going into Visual Studio that has me exciting about this upcoming release. Sure, waiting for the “Add Reference” dialog to load may only take a few seconds but multiply that by the number of .NET developers out there and this one little tweak will save countless hours every day.

Minor tweak == Major impact

http://www.msdev.com/Directory/Description.aspx?eventId=1499

If you are interested in the sample code, there are actually two Visual Studio projects you’ll need… The first is a little WPF app that hosts a WCF service. This acts as the SMS “server”, and as the name (PsuedoSMS) suggests, there is no actual SMS involved… I just needed to be able to simulate a service I could invoke from the Worker role.

PsuedoSMS.zip

The second is the cloud service that contains the actual demonstration code from the session. This is a Visual Studio 2008 solution, but you should be able to easily convert it if you want to use it with Visual Studio 2010.

SmsCloudApp.zip

Cheers!

Oh, and I need to include some credits as far as the PsuedoSMS app – the embedded font is called Sveningsson and it was created by Derek Gomez. You can download it from dafont.com. The app also uses a great little library by Philipp Sumi called WPF NotifyIcon – it provides an easy way to use WPF for system tray popups.

Also, if you get an “HTTP could not register URL” error when you try to run the PsuedoSMS app, you can either run the app as administrator or you can create a reservation for the app… Start a command prompt with administrator privileges and then execute the following (with appropriate domain/username of course):

netsh http add urlacl url=http://+:9999/PsuedoSMS/SmsService/ user=DOMAIN\username

Thanks to Anirban Chakladar’s blog posting for helping me sort this out quickly…