0 Comments

The stories you hear about working at Microsoft and how we send and receive lots of email is true. It is more true than you could imagine. I’ve been an addicted avid user of Outlook since I’ve had a job but there are some features I’ve not explored with any depth. Even with software, I sometimes strive to live a more Buddhist lifestyle and deny myself the investigation for features that I fear I will not find. That whole expecting it to be there and being disappointed when it isn’t thing is too depressing for me to go through, so I choose to minimize my expectations and not go hunting for features my life would benefit from having. No, really. I’m just lazy. No but seriously, I have this obsessive rule about not seeing a scrollbar in my Inbox. Each day when the little scrollbar icon appears, shortening the width of my Inbox by 20 (or so) pixels, I cringe. I hate having more-than-a-scroll emails in my Inbox.

The feature I’ve wanted (ever since I got the feature of not having to refresh my inbox) is to tell my inbox to stop auto-refreshing. I’d never gone hunting for it. Tonight, I did, and I found it in 5 minutes. I like this feature so much I’m going to show it off. You’ve probably seen this already, but get this – you can leave Outlook open and prevent it from checking your mail. That way, you can clean out your Inbox while simultaneously preventing it from refilling itself as you try to clean it out.

Here’s the trick. On your Outlook ribbon in any of the modes – email, calendar, tasks, whatever – click the Send/Receive ribbon. Then, toggle the Work Offline feature. I’ve highlighted my favorite part of the feature – the “if you do not want to receive new mail” message.

image

As soon as you do this, Outlook will stop checking your email for you. The status bar reflects my newfound joy, knowing I can keep my old friend open but quiet as I prune away towards inbox-zero Nirvana. In the status bar, I can see that I’m working offline. That way, once I get jittery in 15 minutes after not having received any new email, I can just look down and see why no one’s emailing me. I’ve temporarily put the incoming world on hold.

image

Whenever I’m ready to stop being anti-social, I can go back to the Send/Receive tab and see that I’m hiding via the greyed-out Work Offline toggle button.

image

Once I click that, Outlook connects and starts updating my folders…

image

After a few seconds everything is updated and I’m back online, with new fresh email to read…

image

You probably already knew about this feature, but I’m so excited I had to share it. Thanks, Outlook team, for being awesome.

8 Comments

The Windows Azure SDK team has been working hard to finish up more of the Windows Azure Management Libraries so you can use .NET code to manage your Windows Azure resources, and today’s blog will highlight one of the newest additions to the WAML stack. Today I’ll introduce you to the Windows Azure SQL Database Management Library. We released the SQL Management Library this week, and it’s loaded with features for managing your Windows Azure SQL Databases. Like the rest of the management libraries, the SQL library provides most of the functionality you’d previously only been able to do using the Windows Azure portal, so you’ll be able to write .NET code to do pretty much any level of automation against your SQL databases and servers.

Here’s a list of some of the features supported by the new SQL library:

  • Create, update, delete, and list your Windows Azure SQL Servers
  • Create, update, delete, and list your Windows Azure SQL Databases
  • Create, update, delete, and list your Windows Azure SQL Servers’ Firewall Rules
  • Import and Export SQL databases to & from Windows Azure Blob Storage

Let’s dive in to some of these features by exploring their usage in the sample code I’ve written to demonstrate all these cool new WAML features. I’ve put this code up in GitHub so you can fork it, add your own functionality and test cases, and [please, feel free] spruce up the UX if you’re so inclined. The code for this demonstration includes the demonstrations from my previous blog posts on WAML, so if you’ve been wanting to see that code, you can dive in as of this latest installment in the blog series.

The WPF app shown below sums up today’s code demonstration for using the SQL management library. Once I select my publish settings file and select the subscription in which I want to work WAML makes a REST call out to Windows Azure to retrieve the list of database servers in my subscription. I data-bind a list view in the WPF app with the list of servers. Next to each you’ll find buttons to allow for convenient access to the databases residing on the servers, as well as a button giving you access to the servers’ firewall rules.

SNAGHTML1a48f73

Creating the SQL Management Client

As with the other demonstrations, the first step is to create an instance of the SqlManagementClient class using a subscription ID and an X509 Certificate, both of which are available in my publish settings file. The code below is similar to the manner in which the other management clients (Compute, Infrastructure, Storage, and so on) are created.

image

SQL Server Operations

The code below shows how, in two lines of code, I can get back the list of servers from my subscription. Once I’ve got the list, I set a property that’s data-bound in the WPF app equal to the list of servers the REST API returned for my subscription.

image

Database Operations

Once a user clicks the “Databases” button in one of the server lines in the WPF app a subsequent call is made out to the Windows Azure REST API to pull back the list of databases running on the selected server. 

image

You can do more than just list databases using the SQL management library – you have full control over the creation and deletion of databases, too, using the easily-discoverable syntax. Below, you’ll see how easy it is to figure out using nothing more than the Intellisense features of Visual Studio to figure out how to create a new database.

image

Firewall Rules

You no longer need to load up a server in the portal to manage your firewall rules – you can do that using the SQL management library, too. The code below demonstrates how easy it is to retrieve the list of firewall rules for a particular SQL Servers. When the user hits the “Firewall Rules” button in the WPF app, this code runs and loads up the rules in the UX.

image

In addition to the SQL library, we’ve also released the preview libraries for Media Services and Service Bus, too. We’re continuing to improve the landscape of WAML every day, and have some convenience features we’re adding into the overall WAML functionality set, too. Keep watching this blog for more announcements and tutorials on the Windows Azure Management Libraries. As always, if you have any suggestions or ideas you’d like to see bubble up in the management libraries, feel free to post a comment below.

Happy Coding!

2 Comments

I am not very good at cryptography, even the most fundamental basic aspects of it. I’m humble enough to be willing to admit this (or smart enough to put it out there so folks don’t ask me questions about it, take your pick). That said, the idea of working with X509 Certificates in my code is something I obviously don’t relish doing. It’s a necessary thing, however, when working with various authentication paradigms, like the traditional method of attaching certificates to individual requests I’d like to make to the Windows Azure API. Since the first implementation of the credential-passing logic with the Management Libraries use X509 certificates, I needed to come up with an easy way of testing my code with management certificates. Luckily, the *.publishsettings files one can download from Windows Azure via techniques like the PowerShell cmdlets’ Get-AzurePublishSettingsFile command provides a Base-64 encoded representation of an X509 Certificate. This post will walk through how I use the information in a publish settings file to authenticate my requests with the management libraries.

You won’t want to put your publish settings files onto a web server, store the information in these files in your code, or anything like that. This is just for demonstration purposes, and makes the assumption you’re working on your own machine, controlled by you, while you’re logged into it in a nice and secure fashion. If some nefarious villain gets ahold of your publish settings file they could theoretically authenticate as you. Point is, be careful with these files and with the strings embedded into them. Keep them somewhere safe and secure when you’re not using them.

Once you’ve downloaded a publish settings file to your computer, you can write code that will open the files up and parse them. Don’t worry, this is pretty easy, as the files are just normal XML files. So, you can use XLinq or any other XML-parsing techniques to read the values out of the file. In my example code for this and the other posts I’m writing on the topic, you’ll notice that I’ve provided a menu you can use to open up a publish settings file. A screen shot of this application running is below:

Selecting the publish settings file

When the user clicks this menu, I simply throw open a new Open File Dialog object and allow the user to select a *.publishsettings file from their machine. The screen shot below demonstrates this.

Opening the file

When the user selects the file the code does just what you’d expect – it opens the file up, parses out the XML, and builds an array of subscription models the rest of my code will use when it needs to make calls out the API via the management libraries. The section of the code below that’s highlighted is doing something pretty simple – just building a list of a model type known as PublishSettingsSubscriptionItem to which I’ll data-bind a list of child menu items in my form.

Loading up the subscriptions

The XAML code that does this data-binding logic is below. This sample code (which will soon be available for your viewing pleasure) shown below does the data-binding magic.

Data-binding the list of subscriptions

Once this code is in place and I select a publish settings file, the menu will be augmented with the list of subscriptions found in that publish settings file.

The data-bound list

Since I’ve got my XAML wired up in a nice command-like manner, selecting any of those items will fire the SelectSubscriptionCommand method in my form’s view model class. That method in turn sets the current selected subscription so that it can be used later on by management library client classes that need the information. The code below, which is the handler method for that command, does this magic.

Setting the selected subscription

Now, whenever I need to run any management library code that reaches out to the Windows Azure REST API, I can use the properties of my selected subscription to set up the two elements of data each client needs – the subscription ID and the Base-64 encoded management certificate. The code below does exactly this to make a call out to the REST API to get the list of supported regions in the Windows Azure fabric.

Using the selected subscription

Thanks to my good buddy and evil coding genius Mike Lorbetske for MVVM-ifying this code so the demos can be easily added to support the upcoming blog posts in this series. I was mixing MVVM techniques and nasty, old-fashioned codebehind brutality together, and Mike came in just in time and helped me make this code a little more robust using MEF and some other tricks.

0 Comments

When we built out the Windows Azure Management Libraries, one of the things we knew we needed to do was to make it easy for developers to trace API conversations however they want or need, to whatever medium they’d like to save the trace logs. The deeper the trace information available during conversations with the Windows Azure REST API, the easier it is to figure out what’s going on. To make tracing easier and more flexible, we added an interface to the SDK common package called the ICloudTracingInterceptor. You can implement this method however you want to drop the trace messages from the API conversations. This post will walk through a simple example of using the tracing interception functionality in the management libraries in a WPF application.

Building a Custom Interceptor

First, a quick inspection of the tracing interceptor interface is in order. The object browser window below shows the interface and all of the methods it offers.

Object Browser

An obvious implementation of the interceptor logic would be to dump trace messages to a Console window or to a debug log. Given I’m building a desktop application I’d like to see that trace output dropped into a multi-line textbox. Rather than pass the constructor of my implementation a reference to a WPF TextBox control I’ll take a reference to an Action<string>, as I may need to be proactive in handling threading issues associated with the API calls running in an asynchronous manner. Better safe than sorry, right? Below is the beginning of the code for my custom tracing interceptor.

Custom tracing interceptor implementation

With the custom implementation built, I’m ready to use it in an application.

Hooking the Interceptor to the Cloud Context

Also provided within our common package is another helpful object that abstracts the very idea of the cloud’s context and the conversations occurring with the REST API. This abstraction, appropriately named CloudContext, is visible in the object browser below.

Object Browser

The Cloud Context abstraction makes it simple to dial in a custom tracing interceptor. In my WPF application code, shown below, I simply use the Configuration.Tracing.AddTracingInterceptor method to add a new instance of my interceptor to the context.

Hooking in the tracing interceptor

Now, each call I make to the Windows Azure API via the management libraries will be dumped to the multi-line text box in my WPF form. The screen shot below is the WPF application running. In this example, I’ve made a call to the management API’s list locations method, which returns a listing of all of the regions supported by the Windows Azure fabric.

Example code running

Since the tracing interceptor is bound to the cloud context, any calls made through the management libraries will be traced and dropped into the text box (or whatever you specify in your own implementation). We think this adds a nice, one-stop method of tracing your API conversations. Keep watching this space for more blog posts about the management libraries. My next post, which will be released this week, will cover the code in this WPF application responsible for loading up a list of subscriptions from a publish settings file, and how the information in the publish settings file can be used to hydrate an X509 Certificate at run-time (note the “Select Publish Settings File” UX elements in this example).

34 Comments
   

The first thing I had the opportunity to work on when I joined the Windows Azure team was something that I’m excited to show off today. I demonstrated the early bits of the Windows Azure Management Libraries at the TechEd Australia Developer kick-off session, and now that they’re out I’m really excited to walk you through getting started with their use. This post will sum up what the Windows Azure Management Libraries are and why you should care to take a peek at them, and then I’ll dive into some code to show you how to get started.

What are these libraries you speak of?

With this release, a broad surface area of the Windows Azure cloud infrastructure can be accessed and automated using the same technology that was previously available only from the Windows Azure PowerShell Cmdlets or directly from the REST API. Today’s initial preview includes support for hosted Cloud Services, Virtual Machines, Virtual Networks, Web Sites, Storage Accounts, as well as infrastructure components such as affinity groups.

We’ve spent a lot of time designing natural .NET Framework APIs that map cleanly to their underlying REST endpoints. It was very important to expose these services using a modern .NET approach that developers will find familiar and easy to use:

  • Supports Portable Class Library (PCL), which targets apps that are built for .NET Framework 4.5, Windows Phone 8, Windows Store, and Silverlight
  • Ships as a set of focused NuGet packages with minimal dependencies to simplify versioning
  • Supports async/await-based task asynchrony (with easy synchronous overloads)
  • Has a shared infrastructure for common error handling, tracing, configuration, and HTTP pipeline manipulation
  • Is factored for easy testability and mocking
  • Is built on top of popular libraries such as HttpClient and Json.NET

These packages open up a rich surface area of Windows Azure services, giving you the power to automate, deploy, and test cloud infrastructure with ease. These services support Windows Azure Virtual Machines, Hosted Services, Storage, Virtual Networks, Web Sites and core data center infrastructure management.

Getting Started

As with any good SDK, it helps to know how you could get started using it by taking a look at some code. No code should ever be written to solve a problem that doesn’t exist, so let’s start with a decent, but simple, problem statement:

I have this process I run as in Windows Azure as a Worker Role. It runs great, but the process it deals with really only needs to be run a few times a week. It’d be great if I could set up a new service, deploy my code to it, then have it run. Once the process finishes it’d be even better if the service could “phone home” so it could be deleted automatically. I sometimes forget to turn it off when I’m not using it, and that can be expensive. It’d be great if I could automate the creation of what I need, then let it run, then have it self-destruct.

Until this preview release of the Windows Azure Management Libraries (WAML for short hereafter, though this is not an official acronym, I’m just being lazy), this wasn’t very easy. There’ve been some great open-source contributions to answering the .NET layer in managing Windows Azure services and their automation, but nothing comprehensive that delivers C# wrappers for nearly all of the Windows Azure Management REST APIs. If you needed to use these API to generate your own “stuff” in Windows Azure, you pretty much had to write your own HTTP/XML code to communicate with the REST API. Not fun. Repetitive. Boring, maybe, after you do a few dozen out of hundreds of API methods.

Getting the Management Libraries

I decided to do this work in a simple WPF application I’ll run on my desktop for the time being. I’ll want to run it as long-running app or service later, but for now this will work just fine. Since I’ve got a Windows Azure Cloud Service with a Worker Role I’ll want to run in the cloud, I’ve just added all three projects to a single solution, which you’ll see below.

You probably noticed that I’m preparing to add some NuGet packages to the WPF application. That’s because all of the Windows Azure Management Libraries are available as individual NuGet packages. I’m going to select the Microsoft.WindowsAzure.Management.Libraries package, as that one will pull everything in the Management Libraries into my project. If I wanted to manage one aspect of Windows Azure rather than all of it, I’d reference one of the more specific packages, like Microsoft.WindowsAzure.Management.WebSites, which provides management functionality specific only to the Windows Azure Web Sites component.

Once I’ve referenced the NuGet packages, I’m ready to set up client authentication between my WPF application and the Windows Azure REST APIs.

Authenticating

The first implementation we’ve built out for authenticating users who are using WAML and Windows Azure is a familiar one – using X509 Certificates. Integrated sign-in was added recently in SDK 2.2 to Visual Studio and to PowerShell, and we’re working on a solution for this in WAML, too. With this first preview release we’re shipping certificate authentication, but stay tuned, we’re doing our best to add in additional functionality.

Don’t panic. We’ve made this so easy even I can do it.

I’m not going to go deep into a discussion of using certificate-based authentication in this post. In fact, I’m going to be as brute-force as possible just to move into the functional areas of this tutorial. I’ll need two pieces of information to be able to log into the Windows Azure API:

  • A subscription ID
  • A management certificate

I obtained these values from one of my publish settings files. The XML for this file is below.

With the key and the subscription ID in my code later on, I can call the GetCredentials method below that returns an instance of the abstract class, SubscriptionCloudCredentials, we’re using to represent a credential instance in the Management Library code. That way, if I add single-sign on later it’ll be easy for me to replace the certificate authentication with something else. The code the the CertificateAuthenticationHelper class from my sample code is below:

Now I’ll write a controller class that’ll do the work between my WPF application and the Management Libraries – a convenience layer, in a sense.

Management Convenience Layer

To map out all the various parameters I’ll have in my workflow I’ve created the ManagementControllerParameters class shown below. This class will summarize all of the pieces of data I’ll need to create my services and deploy my code.

Then, I’ll create a class that will provide convenience functionality between the UX code and the Management Library layer. This code will make for cleaner code in the UX layer later on. Note the constructor of the code below. In it, two clients are being created. One, the StorageManagementClient, will provide the ability for me to manage storage accounts. The other, the ComputeManagementClient, provides the ability for me to work with most of the Windows Azure compute landscape – hosted services, locations, virtual machines, and so on.

For the purposes of explaining these steps individually, I've created a partial class named ManagementController that's spread across multiple files. This just breaks up the code into functional units to make it easier to explain in this post, and to provide for you as a public Gist so that you can clone all the files and use them in your own code.

Now, let’s wire up some management clients and do some work.

Create a New Storage Account using the Storage Management Client

The first thing I’ll need in my deployment strategy is a storage account. I’ll be uploading the .cspkg file I packaged up from a Cloud project in Visual Studio into a Windows Azure blob. Before I can do that, I’ll need to create an account into which that package file can be uploaded. The code below will create a new storage account in a specified region.

Once the storage account has finished creating, I'm ready to use it. Given that I'll need a connection string to connect my application (and my soon-to-be-created cloud service) to the storage account, I'll create a method that will reach out to the Windows Azure REST APIs to get the storage account's connection keys. Then, I'll build the connection string and hand it back to the calling code.

Now that the storage account has been created I'll create my cloud service and publish my package up to Windows Azure.

Create and Deploy a new Cloud Service using the Compute Management Client

The call to create a cloud service is surprisingly simple. All I need to do is to provide the name of the cloud service I intend on creating and the region in which I'd like it to be created.

Finally, all I need to do to deploy the cloud service is to upload the cloud service package file I created in Visual Studio to a blob, then call the REST API. That call will consist of the blob URI of the package I uploaded to my storage account, and the XML data from the cloud project's configuration file. This code will make use of the Windows Azure Storage SDK, which is also available as a NuGet package.

Now that all the code's written to create my Windows Azure application, I'll write some code to destroy it once it wraps up all of the work it was designed to do.

Deleting Assets from Windows Azure

Deleting assets using the Windows Azure Management Libraries is as easy as creating the assets. The code below cleans up the storage account I created. Then, it deletes the cloud service deployment and the cloud service altogether.

With all the convenience code written at this point, the user experience code should be relatively painless to write next.

The User Experience

The UX for this application is relatively simplistic. I'm just providing a pair of buttons on a WPF form. One will create the assets I need in Windows Azure and perform the deployment. The other will delete the assets from Windows Azure. XAML code for this UX is below. It isn't much to look at but the idea here is to keep this simple.

The codebehind for the UX is also just as easy. In the Create button-click event, I create a new ManagementController instance, providing it all of the parameters I'll need to create the application's components in the Windows Azure fabric. Then I call all of the methods to created everything.

I also handle the Delete button-click by cleaning up everything I just created.