Wade Wegner

Yesterday we released the Window Azure Platform Training Kit – September 2011 Release. You can get the content here:

• Windows Azure Platform Training Kit (offline)
• Windows Azure Platform Training Courses (online)

The September 2011 release of the training kit includes the following updates:

• [New Hands-On Lab] Service Bus Messaging
• [Updated] Labs and Demos to leverage the new Window Azure SDK & Tools 1.5
• [Updated] Labs and Demos to leverage the new Windows Azure AppFabric SDK 1.5
• [Updated] Introduction to Windows Azure Marketplace for Data
• Applied several minor fixes in content

The updates for the Windows Azure SDK & Tools 1.5 and the Windows Azure AppFabric SDK 1.5 are really quite significant – it takes a lot of work to pull this off. To give you an idea, take a look at everything we did:

• 25 of the 30 hands-on labs were updated to use the Windows Azure SDK 1.5 and/or Windows Azure AppFabric SDK 1.5.
• 15 of the 25 demos were updated to use the Windows Azure SDK 1.5 and/or Windows Azure AppFabric SDK 1.5.
• Approximately 145 projects updated.
• 86 dependency checker files updated for 25 hands-on labs and 18 demos.
• 22 hands-on labs and 7 demos updated for changes to the Windows Azure Portal experience.

We really try to make these training resources valuable to you, so please be sure to provide feedback if you find a bug, mistake, or feel as if we should including something else in the kit.

Now that we can get our hands on the Windows Developer Preview of Windows 8, I’m sure everyone is excited to start building applications! For many of us, this means that we’ll want to install all of the great Windows Azure tools on our Windows Developer Preview machine – especially if we plan to take advantage of the new Windows Azure Toolkit for Windows 8. However, there are a few things we’ll need to do in order to get things to work.

Quickly let me explain the three challenges you’ll run into:

1. The current Windows Azure Tools for Visual Studio do not yet support Dev11 – you’ll have to install Visual Studio 2010.
2. There are a few quirks getting dependencies for IIS installed on Windows 8 using the Web Platform Installer.
3. After Visual Studio 2010 and the Windows Azure Tools for Visual Studio are installed on a machine with Dev11, the Windows Azure tools will grab an environmental path variable that points to 11.0 instead of 10.0.

Fortunately, these things are pretty easy to resolve and will certainly get addressed in later builds.

Here’s what you’ll have to do to get the tools and SDK working with the Windows Developer Preview:

1. Install Microsoft .NET Framework 3.5.1. Easiest way is to type “Windows Features”, select Settings, and select Turn Windows features on or off. Then simply check the checkbox. Click OK to install.
   
2. Next we need to correctly configure IIS. Typically we’d do this through the Web Platform Installer, but this doesn’t work correctly on Windows 8. From Turn Windows features on or off you’ll need to do the following, then click OK to install.
   • Check Internet Information Services.
   • Expand Internet Information Services and World Wide Web Services.
   • Expand Application Development Features and check ASP.NET 2.0, ASP.NET 4.5, and CGI.
   • Expand Common HTTP Features and check HTTP Redirection.
   • Expand Health and Diagnostics and check Logging Tools, Request Monitor, and Tracing.
3. Install the Web Platform Installer (WebPI).
4. Install Visual Web Developer 2010 Express through WebPI. (You can use a different version of Visual Studio 2010, so long as it’s supported by the Windows Azure Tools for Visual Studio.)
5. Install Windows Azure Tools for Microsoft Visual Studio 2010 – September 2011 through WebPI.

Okay, now you have everything installed. However, before you trying running Visual Studio, you have to create a script to launch Visual Studio 2010. This is because the Windows Azure tools use an environmental variable that’s incorrectly pointing to version 11.0, and we’ll need to change it right before we launch to version 10.0 (for Visual Studio 2010).

@ECHO OFF

SET VisualStudioVersion=10.0

SET VisualStudioPath="%ProgramFiles(x86)%\Microsoft Visual Studio 10.0\Common7\IDE"
IF NOT EXIST %WINDIR%\SysWow64 SET VisualStudioPath="%ProgramFiles%\Microsoft Visual Studio 10.0\Common7\IDE"

CD /D %VisualStudioPath%

VWDExpress.exe

As you can see, the script changes the VisualStudioVersion to 10.0 then launches Visual Web Developer Express (there’s a little extra code to set the path correctly regardless of 32- or 64-bit versions of Windows).

Save the above script as a CMD file (i.e. OpenVisualStudio2010.cmd) and then make sure to right-click and Run as administrator! If you forget to run the script as administrator then Visual Studio won’t have the permissions needed to run the Windows Azure tools correctly.

Look, it’s working!

NOTE: I found myself having to reboot Windows 8 in order to resolve a problem where the debugger wouldn’t attach. Not sure if this occurs every time, but in case you have a similar issue just try rebooting.

I hope this helps!

I love building keynote applications! I had the great fortune to work with John Shewchuk – Technical Fellow at Microsoft – as he demonstrated a vision for how identity in Windows Azure can enable great experiences in Windows 8. I wanted to quickly provide some background on the components of the sample application he showed called Margie’s Travel.

Margie’s Travel is a sample travel application that demonstrates how you can track and manage your trips across multiple Windows 8 machines using a combination of technologies in Windows Azure and Windows 8.

The application is a Metro styled app built on HTML5, CSS, and JavaScript. Additionally, this application was rapidly built by using the templates and samples found in the Windows Azure Toolkit for Windows 8.

When the application is launched, the user needs to login. Rather than creating yet another identity store, or mapping directly to a specific identity provider, Margie’s Travel uses the Windows Azure Access Control Service.

When you click the login button, the application first checks the Windows PasswordVault to see if the credential (which includes the token) exists:

var vault = new Windows.Security.Credentials.PasswordVault();
var cred = vault.retrieve(url, username);

If this exists, the application will login.  If not, the the application calls out to the Access Control Service to get a list of identity providers from which the user can select.

This code is also very simple to write in JavaScript:

var request = new XMLHttpRequest();
request.open("GET", IPSFeedURL("https://ACSNAMESPACE.accesscontrol.windows.net"), false);
request.send(null);
var jsonString = request.responseText;
var jsonlist = ParseIPList(jsonString);

BindJsonToList(jsonlist);

Once the users makes the selection, the Windows Web Authentication Broker invoked. This allows us to use a consistent and secure method for handling authentication. The login page for the selected identity provider is rendered in the broker.

Once the user logs in, the Access Control Service token is return to the Web Auth Broker. The application is able to take the credential and store it into the Windows Web Vault. This gives us a consistent SSO experience so that upon subsequent launches thee user does not need to log in again.

To store the credential, we simply take the various components, create a new PasswordCredential, and add it to the vault.

var cred = new Windows.Security.Credentials.PasswordCredential(
    url,
    username,
    token);
vault.add(cred);

Furthermore, since the Web Broker can synchronize across trusted devices using Windows Live, the token is automatically synchronized to any trusted device so that you can get SSO across multiple devices.

Once logged in, the application will call out to additional Web services in Windows Azure (like the GetTravelerInfo() method) so that we can validate the users credentials before returning the results.

In addition, this token can be used to call out to additional services in Windows Azure, to get rich pictures from Bing, specific data from the Windows Azure DataMarket and Wolfram Alpha, and even weather information.

All of this is made possible by unique features and capabilities provided by Windows Azure and Windows 8.

If you want to give this a try, and learn more about how all this works, download the Windows Azure Toolkit for Windows 8. Additionally, take a look at posts by Nick Harris and Vittorio Bertocci.

I hope this helps!

I am tremendously pleased to share that today we have released the Windows Azure Toolkit for Android! We announced our intentions to build a toolkit for Android back in May, and it had always been our intention to release this summer (we only missed by a week or so).

In addition to this release of Android, we have also:

• Released the Windows Azure Toolkit for Windows Phone (v1.3.0)
• Released the Windows Azure Toolkit for iOS (v1.2.1)
• Released a new Windows Phone sample called BabelCam both as source code and to the Windows Phone Marketplace

These releases complete our coverage of the three device platforms we intended to cover earlier this year when we started our work – Windows Phone, iOS, and Android.

It’s my belief that cloud computing provides a significant opportunity for mobile device developers, as it gives you the ability to write applications that target the same services and capabilities regardless of the device platform. Furthermore, I believe that Windows Azure is the best place to host these services. Take a look at the post Microsoft Releases the Windows Azure Toolkit for Android for examples of how American Airlines and Linxter are using the toolkits and Windows Azure to build great cross-device applications!

In addition to releasing the the Android toolkit, we have released some important updates to the Windows Phone and iOS (i.e. iPhone & iPad) toolkits for Windows Azure. Since I have so many things to cover in this post, let me break it all down in various sections (click the links to jump to the section of choice):

Android

Today we released version 0.8 of the Windows Azure Toolkit for Android. This version includes native libraries that provide support for storage and authN/Z, a sample application, and unit tests. Everything is built in Eclipse and uses the Android SDK.

Here’s the project structure:

• library
  
• simple (sample application)
  
• tests
  

The library project includes the full source code to the storage client and authentication implementations.

Once you configure your workspace in Eclipse, you can run the simple sample application within the Android emulator.

From here you choose to either connect directly to Windows Azure storage using your account name and key or through your proxy services running in Windows Azure. To set your account name and key, modify the ProxySelector.java file …

… found here:

As with the Windows Azure Toolkits for Windows Phone and iOS, we recommend you do not put the storage account name and key in your application source code. Instead, use a set of secure proxy services running in Windows Azure. You can use the Cloud Ready Packages for Devices which contain a set of pre-built services ready to deploy to Windows Azure.

As you can see from it’s name, the shipping sample is designed to be simple – do not consider this a best practice from a UI perspective. However, it does should you fully how to implement the storage and authentication libraries. For another alternative at the library implementations, take a look at the unit tests.

Windows Phone

Today we released version 1.3.0 of the Windows Azure Toolkit for Windows Phone. This release includes a number of long awaited features and updates, including:

• Support for SQL Azure as a membership provider.
• Support for SQL Azure as a data source through an OData service.
• Upgraded the web applications to ASP.NET MVC 3.
• Support for the Windows Azure Tools for Visual Studio 1.4 and Windows Phone Developer Tools 7.1 RC.
• Lots of little updates and bug fixes.

I’m most excited about the support for SQL Azure.

The new project wizard now lets you choose where you want to store data in Windows Azure – you can both Windows Azure storage and SQL Azure database!

You can choose to enter your SQL Azure credentials into the wizard (which places them securely in your Windows Azure project, not the device) or use a SQL Server instance locally for development.

Once you’ve finished walking through the wizard, you may not immediately notice anything different – that’s a good thing! However, in the background all the membership information has been stored in a SQL database, and you’ll see in the application a new tab for your SQL Azure data that’s consumed through an OData service.

Moving forward we plan to only target the Windows Phone Developer Tools 7.1 releases (i.e. no more WP 7.0). However, we have archived all the 7.0 samples, and will continue to ship them as part of the toolkit as long as the Windows Phone Marketplace accepts 7.0 applications. You can find them organized in two different folders: WP7.0 and WP7.1.

iOS

Over the last few weeks, and with the help of Scott Densmore, we have made a series of important updates to the Windows Azure Toolkit for iOS – namely, bug fixes and project restructuring!

Over the last few weeks, as more and more developers used our iOS libraries, we started getting reports of memory leaks. Scott has spent a considerable amount of time tracking these down, and all these updates have been checked into the repo.  Additionally, we have spent some time refactoring our github repos, and you’ll now find everything related to the Windows Azure Toolkit for iOS in a single repository:

This gives us a lot more flexibility for releases, as well as making sure that the resources are easy to use and consume.

What’s Next?

Oh no, we’re not done! There’s still a lot we want to do. We continue to get great feedback from customers and partners using these toolkits.

Over the next few months, here are the things we’ll focus on:

• Continue to update the Windows Azure Toolkits for iOS and Android so that they are in full parity with the Windows Azure Toolkit for Windows Phone.
• Samples, samples, and more samples! We want to have a great set of samples that work across all three device platforms. We’ve got a good start with BabelCam, but we need to bring it to iOS and Android, and then build more!
• Continue to support and fix the toolkits.

Your feedback is invaluable, so please continue to send it our way!

In this week’s episode of Cloud Cover, Steve and I covered Logging, Tracing, and ELMAH in Windows Azure. Steve explored the first two topics while I looked into ELMAH in Windows Azure. You should make sure and take a look at his posts – they’re useful:

• Printf(“HERE”) in the Cloud
• Lightweight Tracing to Windows Azure Tables

ELMAH (Error Logging Modules and Handlers) itself is extremely useful, and with a few simple modifications can provide a very effective way to handle application-wide error logging for your ASP.NET web applications. If you aren’t already familiar with ELMAH, take a look at the ELMAH project page.

NuGet

Before going any further, I thought I’d let you know that I’ve created a NuGet package that makes this extremely easy to try. You can take a look at ELMAH with Windows Azure Table Storage on the NuGet gallery or immediately try this out with the following command:

       Install-Package WindowsAzure.ELMAH.Tables

By default this NuGet package is configured to use the local storage emulator. If you want to use your actual Windows Azure storage account you can uncomment the following line in the Web.Config file:

<!--
<errorLog
    type="WebRole1.TableErrorLog, WebRole1"
    connectionString="DefaultEndpointsProtocol=https;AccountName=YOURSTORAGEACCOUNT;
      AccountKey=YOURSTORAGEKEY" />
-->

Incidentally, if you like NuGet, then you should check out Cory Fowler’s post on must have NuGet packages for Windows Azure development.

Demo

For those of you unfamiliar with ELMAH, I put together a simple demo. You can try it out on http://elmahdemo.cloudapp.net/. Just enter a message (keep it clean, please!) and throw an exception.

Click the ELMAH button to then load the handler. You’ll see all the errors logged with a lot of great detail.

The great part is that these files are getting serialized into Windows Azure table storage. The benefit of this is you can read them from anywhere – in fact, you don’t have to even deploy the elmah.axd handler with your web application! You could run it locally.

Here’s what the files look like in table storage:

How Does it Work?

The nice part is you can easily grab the NuGet package to view all the source code. There are two items of interest: ErrorEntity.cs and Web.Config.

In ErrorEntity.cs we first create our ErrorEntity:

public class ErrorEntity : TableServiceEntity
{
    public string SerializedError { get; set; }

    public ErrorEntity() { }
    public ErrorEntity(Error error)
        : base(string.Empty, (DateTime.MaxValue.Ticks - DateTime.UtcNow.Ticks).ToString("d19"))
    {
        this.SerializedError = ErrorXml.EncodeString(error);
    }
}

Then we implement the ErrorLog abstract class from ELMAH to create a TableErrorLog class with all the implementation details.

public class TableErrorLog : ErrorLog
{
    private string connectionString;

    public override ErrorLogEntry GetError(string id)
    {
        return new ErrorLogEntry(this, id, ErrorXml.DecodeString(CloudStorageAccount.Parse(
            connectionString).CreateCloudTableClient().GetDataServiceContext()
            .CreateQuery<ErrorEntity>("elmaherrors").Where(e => e.PartitionKey == string.Empty
                && e.RowKey == id).Single().SerializedError));
    }

    public override int GetErrors(int pageIndex, int pageSize, IList errorEntryList)
    {
        var count = 0;
        foreach (var error in CloudStorageAccount.Parse(connectionString).
            CreateCloudTableClient().GetDataServiceContext()
            .CreateQuery<ErrorEntity>("elmaherrors")
            .Where(e => e.PartitionKey == string.Empty).AsTableServiceQuery()
            .Take((pageIndex + 1) * pageSize).ToList().Skip(pageIndex * pageSize))
        {
            errorEntryList.Add(new ErrorLogEntry(this, error.RowKey,
                ErrorXml.DecodeString(error.SerializedError)));
            count += 1;
        }
        return count;
    }

    public override string Log(Error error)
    {
        var entity = new ErrorEntity(error);
        var context = CloudStorageAccount.Parse(connectionString)
            .CreateCloudTableClient().GetDataServiceContext();
        context.AddObject("elmaherrors", entity);
        context.SaveChangesWithRetries();
        return entity.RowKey;
    }

    public TableErrorLog(IDictionary config)
    {
        connectionString = (string)config["connectionString"] ?? RoleEnvironment
            .GetConfigurationSettingValue((string)config["connectionStringName"]);
        Initialize();
    }

    public TableErrorLog(string connectionString)
    {
        this.connectionString = connectionString;
        Initialize();
    }

    void Initialize()
    {
        CloudStorageAccount.Parse(connectionString).CreateCloudTableClient()
            .CreateTableIfNotExist("elmaherrors");
    }
}

Now, to leverage these assets, we update the Web.Config file to include an <elmah> … </elmah> section that specifies our custom error log (and also allows remote access to the handler:

<elmah>
  <security allowRemoteAccess="yes" />
  <errorLog type="WebRole1.TableErrorLog, WebRole1"
            connectionString="UseDevelopmentStorage=true" />
</elmah>

That’s all there’s to it!

Of course, there are many other ways you could define your ErrorEntity and implement the TableErrorLog (i.e. you could extract more details into additional entities within your table), but this way is pretty effective.

I hope this helps!