Wade Wegner

Earlier this week we released the Windows Azure SDK 1.6, which includes a lot of great updates to the emulators, tools for Visual Studio, and libraries. One of my favorite additions is a new way to get a management certificate installed into Windows Azure and onto your machine. You can now browse to https://windows.azure.com/download/publishprofile.aspx and login with your Live ID; this process will do two things:

1. Generate a management certificate that is installed into Windows Azures on your behalf.
2. Prompts you to download a .publishsettings file which includes an encoded version of your certificate and all of your subscription IDs.

The new tools for Visual Studio let you easily important this file and immediately start working with your subscriptions from within Visual Studio. It’s a much simpler experience than in the past. In fact, on this weeks episode of the Cloud Cover Show (not yet published) Steve and I cover how to use this file from within your own code. While Steve beat me to it and published a great blog post showing some of the things you can do, I thought I’d take this a slightly different way and show you a couple different things:

• How to install the certificate into your personal certificate store (which is exactly what Visual Studio is doing).
• How to use the certificate from your person certificate store to make calls to the Service Management API.

The code is very similar. Take a look:

var publishSettingsFile =
    @"C:\\temp\\CORP DPE Account-11-16-2011-credentials.publishsettings";

XDocument xdoc = XDocument.Load(publishSettingsFile);

var managementCertbase64string =
    xdoc.Descendants("PublishProfile").Single().Attribute("ManagementCertificate").Value;

var importedCert = new X509Certificate2(
    Convert.FromBase64String(managementCertbase64string));

Now that we’ve imported the certificate, we can extract some information. I’ll grab the certificate thumbprint, which uniquely identifies the certificate—we’ll use it later in the post.

string thumbprint = importedCert.Thumbprint;

Additionally, I can grab my subscription ID from the .publishsettings file – this we will also use later.

string subscriptionId = xdoc.Descendants("Subscription").First().Attribute("Id").Value;

Now, we can take our X509Certificate2 and install it directly into our certificate store.

X509Store store = new X509Store(StoreName.My);
store.Open(OpenFlags.ReadWrite);
store.Add(importedCert);
store.Close();

After running this code, you can see that the certificate has been installed into my personal certificate store.

If you select the certificate you’ll see that it’s the same certificate with the same thumbprint.

Since the certificate is now loaded into the certificate store I can delete the .publishsettings file – I no longer need it. (It’s also a credential that I don’t want to let anyone else get their hands on.)

Now I have the following resources available to me:

• My X509 certificate loaded in my personal certificate store.
• The thumbprint for the certificate (which we’ll use to identify the right certificate).
• My Windows Azure subscription ID.

With this information we can do the exact same thing Steve shows in his post except without the .publishsettings file.

X509Store store = new X509Store(StoreName.My);
store.Open(OpenFlags.ReadWrite);
X509Certificate2 managementCert =
    store.Certificates.Find(X509FindType.FindByThumbprint, thumbrprint, false)[0];

var req = (HttpWebRequest)WebRequest.Create(
    string.Format("https://management.core.windows.net/{0}/services/hostedservices",
    subscriptionId));

req.Headers["x-ms-version"] = "2011-10-01";
req.ClientCertificates.Add(managementCert);

XNamespace xmlns = "http://schemas.microsoft.com/windowsazure";

Console.WriteLine(string.Join("\n",
    XDocument.Load(req.GetResponse().GetResponseStream())
    .Descendants(xmlns + "ServiceName").Select(n => n.Value).ToArray()));

Essentially, we can grab the certificate out of the certificate store using the thumbprint and then make the exact same call to the service management API.

The console output below shows that I’m able to get a list of all my hosted services:

It’s as simple as that!

I’m not sure that this post applies to everyone—in fact, most of you may find it boring or cryptic—but for those of you that are building content or tools you’ll probably find this a really simple way to automate a lot of the pieces. I know that my team plans to use these techniques in a lot of places to simply the experience of getting started with Windows Azure.

I hope this helps!

If you’ve been paying attention to the Windows Azure Toolkit for Windows Phone (or my twitter feed) the last couple weeks, you’ve probably noticed something about NuGet packages. We’ve been building a lot of Windows Phone and Windows Azure NuGet packages that, when composed together, give you the ability to quickly build some cool applications. To highlight this, here’s a short video that shows how you can enable push notification support in a brand new Windows Phone 7.1 project—and send notifications from a new ASP.NET MVC 3 Web Application running in Windows Azure—in less than two minutes!

Here’s a look at how to use the storage NuGet packages to quickly (and securely) upload a picture from the Windows Phone to Windows Azure blob storage.

All of this is made possible by delivering functional, discrete, and composable NuGet packages. I’ve gotten a lot of feedback (positive and constructive, but fortunately mostly positive) about the Windows Azure Toolkit for Windows Phone, and invariably people have said that it’s too hard to decompose the sample applications – often times people just want Push Notification support or user management, and it’s too hard to get rid of the rest.

I think the NuGet packages make it very easy to do two things:

1. Build brand new applications that quickly can get some advanced capabilities
2. Quickly update existing applications to get some desirable enhancements

This is largely possible because we can easily manage and deliver dependencies through NuGet. Let us handle the hard stuff – you focus on building out cool applications.

In this post I’d like to provide a list and description of the NuGet packages we’ve delivered so far – I imagine I’ll update this post many times to keep it accurate. I don’t plan to show exactly how to use these packages—I’ll save that for many future posts—but instead I want to use this post as a reference and guidepost moving forward.

So, without further ado, I’d like to introduce you to the two kinds of NuGet packages we have today: Client Side NuGet Packages, and Server Side NuGet Packages.

Client Side NuGet Packages

The first set of NuGet packages to be aware of are the NuGet packages for Windows Phone, designed to target Windows Phone OS 7.1 project types.

You can use these NuGets in a number of interesting ways. For example, you can quickly incorporate the Access Control Service into your phone applications using the following NuGet packages:

• Phone.Identity.AccessControl: Access Control Service Log In control for Windows Phone.
• Phone.Identity.AccessControl.BasePage: Base log in page for Windows Phone that uses the Access Control Service Log In control.

If you’re not using ACS but instead want simple username/password, you can quickly incorporate membership into your phone applications using the following NuGet packages:

• Phone.Identity.Membership: Membership Sign In control for Windows Phone.
• Phone.Identity.Membership.BasePage: Base log in and register pages for Windows Phone that use the Membership Log In control

To get full support for Push Notifications (including Mango updates like deep linking) you can easily incorporate Push Notifications using the following NuGet packages:

• Phone.Notifications: Class library for Windows Phone to communicate with the Push Notification Registration Cloud Service.
• Phone.Notifications.BasePage: Base notifications page for Windows Phone to register / unregister with the Push Notification Registration Cloud Service for receiving push notification messages.

In scenarios where you’d want to secure your notification services using the Access Control Service, you can use the following packages:

• Phone.Notifications.AccessControl: This package enables communication with the Push Notification Registration Cloud Service using Windows Azure Access Control Service (ACS) for authentication, by adding a set of base pages to the phone application.

  The dependencies and relationships between these NuGets are as follows: 
  

In scenarios where you’d want to secure your notification services using traditional membership, you can use the following packages:

• Phone.Notifications.Membership: This package enables communication with the Push Notification Registration Cloud Service using Membership for authentication, by adding a set of base pages to the phone application.

  The dependencies and relationships between these NuGets are as follows: 
  

[Updated 1/6/12]

Recently we added a set of client side NuGet packages that can communicate with the Windows Azure storage service – either directly (using the storage account information) or through proxy services running in Windows Azure. Here are the packages for the client:

• Phone.Storage: Class library for Windows Phone to communicate with Windows Azure storage services directly (using the storage account information) or through Proxy Cloud Services (using custom authentication mechanisms).
• Phone.Storage.Sample: Sample application for Windows Phone that shows how to use the Windows Azure Storage Client Library for Windows Phone.
• Phone.Storage.AccessControl: This package enables communication with the Windows Azure Storage Proxy Cloud Services using Windows Azure Access Control Service (ACS) for authentication.
  
• Phone.Storage.Membership: This package enables communication with the Windows Azure Storage Proxy Cloud Services using Membership for authentication.
  

Server Side NuGet Packages

Over the years our team has built a lot of libraries for Windows Azure that we regularly use for samples, demos, hands-on labs, and so forth. We’ve continued to refine these libraries and have started to expose some of them as discrete NuGet packages.  Here are some of them:

• WindowsAzure.Common: Class library that provides common helpers tools for Windows Azure.
• Storage.Providers: ASP.NET Providers (Membership, Roles, Profile and Session State Store) for Windows Azure Tables.
• MpnsRecipe: Class library to communicate with the Microsoft Push Notification Service (MPNS).

If you plan to manage users through ASP.NET membership, we have a NuGet package that will handle everything in your Windows Azure project:

• WindowsAzure.Identity.Membership: Class library that includes the Membership Authentication Cloud Service.

We have a set of WebAPI services that work with the Phone.Notifications NuGet packages for handling the Channel URIs and push notification registration services:

• WindowsAzure.Notifications: This package contains a class library with the Push Notification Registration Cloud Service, and a WebActivator enabled class with the default configuration.
• WindowsAzure.Notifications.Sql: Class library that provides storage in a SQL Azure or SQL Server database for the Push Notification Registration Cloud Service.
• WindowsAzure.Notifications.Client.Sql: This package contains a class library with a Table Context to access the Push Notification Registration Cloud Service’s SQL Server tables where the registered enpoints are stored. This package can be used from a worker role to query registered endpoints and send notifications.
• WindowsAzure.Notifications.Client.AzureTables: This package contains a class library with a Table Context to access the Push Notification Registration Cloud Service’s Azure Tables where the registered enpoints are stored. This package can be used from a worker role to query registered endpoints and send notifications.

If you plan to use the Phone.Notifications.AccessControl NuGet package and secure the communications channel with ACS, then you can use this NuGet package:

• WindowsAzure.Notifications.AccessControl: This package enables authentication using Windows Azure Access Control Service (ACS) for the Push Notification Registration Cloud Service. You just need to configure a Relying Party Application with Simple Web Token (SWT) in your ACS namespace, and configure its settings accordingly in the Web.config.

  The dependencies and relationships between these NuGets are as follows:  
  

If you plan to use the Phone.Notifications.Membership NuGet package and secure the communications channel with membership, then you can use this NuGet package:

• CloudServices.Notifications.Membership: This package enables authentication using the Membership provider for the Push Notification.

  The dependencies and relationships between these NuGets are as follows:  
  

When working with Push Notifications, you need some kind of client to generate and send notifications. We’ve built some simple scaffolding that you can use during development (or production?) to generate and send notifications:

• WindowsPhone.Notifications.ManagementUI.Sample: A sample MVC Area containing the Management UI for sending Push Notifications to Windows Phone Devices.

[Updated 1/6/12]

Recently we added a set of client side NuGet packages that can communicate with the Windows Azure storage service – either directly (using the storage account information) or through proxy services running in Windows Azure. Here are the packages for the services:

• WindowsAzure.Storage: This client library enables working with the Windows Azure storage services which include the blob service for storing binary and text data, the table service for storing structured non-relational data, and the queue service for storing messages that may be accessed by a client.
• WindowsAzure.Storage.Proxy: This package contains a class library with the Windows Azure Storage Proxy Cloud Services, and a WebActivator enabled class with the default configuration.
• WindowsAzure.Storage.AccessControl:This package enables authentication using Windows Azure Access Control Service (ACS) for the Windows Azure Storage Proxy Cloud Services. You just need to configure a Relying Party Application with Simple Web Token (SWT) in your ACS namespace, and configure its settings accordingly in the Web.config.
• WindowsAzure.Storage.Proxy.AccessControl: This package enables authentication using Windows Azure Access Control Service (ACS) for the Windows Azure Storage Proxy Cloud Services. You just need to configure a Relying Party Application with Simple Web Token (SWT) in your ACS namespace, and configure its settings accordingly in the Web.config.
  
• WindowsAzure.Storage.Membership: This package enables authentication using the Membership provider for the Windows Azure Storage Proxy Cloud Services. You just need to make sure to have a valid Membership provider configured in your Web.config.
• WindowsAzure.Storage.Proxy.Membership: This package enables authentication using the Membership provider for the Windows Azure Storage Proxy Cloud Services. You just need to make sure to have a valid Membership provider configured in your Web.config.
  

That’s it!

It’s a lot of resources, I know. The intent of this post isn’t to necessarily provide you with the guidance on how to use all these NuGets, but rather to explain what we have available. I plan to write a lot of blog posts that highlight real scenarios and use cases for these NuGet packages, so I’ll refer back to this post quite often. In the meantime, I hope it gives you a  feel for how we’re thinking about engineering and delivering resources for Windows Phone and Windows Azure moving forward.

I hope this helps!

I’m working on a Windows Phone project that requires me to surface up multiple RSS feeds as a single source. I needed a way to do this quickly and easily, and with a little help from friends on Twitter (particularly a suggestion from @bertcraven) I found a nice way to accomplish this using the SyndicationFeed in System.ServiceModel.Syndication.

I’ve detailed the steps below, but if you want to get to the heart of it then here’s the code to get this working:

SyndicationFeed mainFeed = new SyndicationFeed();
List<string> feeds = new List<string>();

feeds.Add("http://feeds2.feedburner.com/WadeWegner");
feeds.Add("http://www.nickharris.net/feed/");
feeds.Add("http://feeds.feedburner.com/ntotten");
feeds.Add("http://michaelwasham.com/feed/");
feeds.Add("http://blogs.msdn.com/b/hpctrekker/rss.aspx");

foreach (var feed in GetRssFeeds())
{
    Uri feedUri = new Uri(feed);
    SyndicationFeed syndicationFeed;
    using (XmlReader reader = XmlReader.Create(feedUri.AbsoluteUri))
    {
        syndicationFeed = SyndicationFeed.Load(reader);
    }

    syndicationFeed.Id = feed;

    SyndicationFeed tempFeed = new SyndicationFeed(
        mainFeed.Items.Union(syndicationFeed.Items).OrderByDescending(u => u.PublishDate));
    mainFeed = tempFeed;
}

It’s really quite simple – once you know how to do it!

As you iterate through the list of feeds we use LINQ to union the feeds together – in the end this produces a main feed that has all the contents. Along the way we sort the elements in a descending order based on the PublishDate – otherwise you’ll just get blocks from each of the feeds and nothing is sorted according to the date publish. Once this is done you end up with a main feed that you can use.

For me I wanted to create a service that published the aggregated feed – I chose to use ASP.NET MVC 3 for this new feed. Here are steps you can follow in order to get this working in ASP.NET MVC 3.

1. Create a new ASP.NET MVC 3 Web Application. I’ve called mine RssFeed. 
   
2. Choose an Internet Application using the Razor view engine and HTML5 semantic markup.
3. Add System.ServiceModel as a reference in the application. We’ll use this with SyndicationFeed.
4. Create an empty controller. I’ve called mine the RssController. 
   
5. We’re going to define our own ActionResult implementation that can emit RSS by deriving from ActionResult. Inspiration and original source comes from this post on Developer Zen.

   public class RssActionResult : ActionResult
   {
       public SyndicationFeed Feed { get; set; }
   
       public override void ExecuteResult(ControllerContext context)
       {
           context.HttpContext.Response.ContentType = "application/rss+xml";
   
           Rss20FeedFormatter rssFormatter = new Rss20FeedFormatter(Feed);
           using (XmlWriter writer = XmlWriter.Create(context.HttpContext.Response.Output))
           {
               rssFormatter.WriteTo(writer);
           }
       }
   }

6. We can now update the Index method to use the RssActionResult instead of the default ActionResult implementation.

   public RssActionResult Index()
   {
       return new RssActionResult();
   }

7. Define a method that returns all the feeds with which you want to aggregate. You can pull from many different places – I recommend SQL Azure – but for the purposes of this demo you can just use a generic list of strings.

   private static List<string> GetRssFeeds()
   {
       List<string> feeds = new List<string>();
   
       feeds.Add("http://feeds2.feedburner.com/WadeWegner");
       feeds.Add("http://www.nickharris.net/feed/");
       feeds.Add("http://feeds.feedburner.com/ntotten");
   
       return feeds;
   }

8. Now we can update our Index method to iterate through the feeds and aggregate them into a single SyndicationFeed that is sorted (descending) by the publish date.

   public RssActionResult Index()
   {
       SyndicationFeed mainFeed = new SyndicationFeed();
   
       foreach (var feed in GetRssFeeds())
       {
           Uri feedUri = new Uri(feed);
           SyndicationFeed syndicationFeed;
           using (XmlReader reader = XmlReader.Create(feedUri.AbsoluteUri))
           {
               syndicationFeed = SyndicationFeed.Load(reader);
           }
   
           syndicationFeed.Id = feed;
   
           SyndicationFeed tempFeed = new SyndicationFeed(
               mainFeed.Items.Union(syndicationFeed.Items).OrderByDescending(u => u.PublishDate));
           mainFeed = tempFeed;
       }
   
       return new RssActionResult() { Feed = mainFeed };
   }

9. Now, hit F5 and run. Browse to http://localhost:<port>/rss to see the aggregated RSS feed. 
   

And that’s it!

There’s certainly more you can do with this – in fact, given the cost it takes to aggregate a large number of feeds, I’ve started to take the aggregated feed and store it in Windows Azure blob storage attached to the Content Delivery Network (CDN). The code to do this is similar to the following:

StringBuilder builder = new StringBuilder();
using (XmlWriter writer = XmlWriter.Create(builder))
{
    mainFeed.SaveAsRss20(writer);
    string rssFeed = builder.ToString();

}
// write to Windows Azure blob storage

You might consider doing something similar.

I hope this helps!