Added reservation for http://127.0.0.1:10000/ in user account COMPUTER\User.
    Added reservation for http://127.0.0.1:10001/ in user account COMPUTER\User.
    Added reservation for http://127.0.0.1:10002/ in user account COMPUTER\User.

    Creating database DevelopmentStorageDb20110816...
    Cannot create database 'DevelopmentStorageDb20110816' : CREATE DATABASE permission
    denied in database 'master'.

    One or more initialization actions have failed. Resolve these errors before attempting
    to run the storage emulator again. These errors can occur if SQL Server was installed
    by someone other than the current user. Please refer to
    http://go.microsoft.com/fwlink/?LinkID=205140 for more details.

And an image of the error:

This error can occur when running the storage emulator (or running DSINIT.exe) for the first time. The compute emulator needs to initialize itself, which includes creating a local SQL Server database that is used to store data for local Windows Azure storage. The above error indicates that there’s a permissions when trying to create the database.

There are a number of ways to resolve this issue and, like others, I have my favorite approach. I have a script that I run which will add the executing user to the SQL Server sysadmin role.

I’ve published the entire script here: https://gist.github.com/1677788. Simply download and unzip the file. Open up an elevated command prompt and execute the file (i.e. run addselftosqlsysadmin.cmd). Once the script is executed the user can successfully initialize the storage emulator.

I hope this helps!

As part of the refresh of the WindowsAzure.com we have also provided additional information about mobile scenarios – it’s worth taking a look.

We’ve built a lot of resources that you should take a look at, including: the Windows Azure Toolkit for iOS, the Windows Azure Toolkit for Android, the Windows Azure Toolkit for Windows Phone, and a host of NuGet packages for Windows Phone and Windows Azure. All of these resources include native libraries (e.g. Objective-C for iOS and .NET for Windows Phone), sample applications, documentation, and tools. We also have a lot of videos and guides available to make the process of getting started as easy as possible.

How can you help?

One of my primary goals in 2012 is to continue to find and build compelling mobile applications that benefit from Windows Azure. We already have few great stories (see T-Mobile USA, Red Badger, easyJet, and more) but that’s only scratching the surface – we can do a lot more!

So, I have a few questions of you:

• Are you building mobile applications that use services in Windows Azure?
• Are you looking for additional PR and opportunities to highlight your applications?
• Have you tried any of the toolkits or NuGet packages?
• Do you have feedback for me regarding the use of the toolkits or NuGet packages?
• What should we do that we aren’t today?
• Do you have an application released to a marketplace – either Windows Phone, Apple, or Android – that uses Windows Azure?

If you have any feedback to these questions then please contact me at wade.wegner@microsoft.com. I want to hear from you!

Let’s see what we can accomplish together!

• I needed optimal performance (i.e. TCP over HTTP).
• I wanted to reuse existing connections (rather than opening many connections).
• I didn’t want to open up ports in my firewall (inbound or outbound).

Based on these requirements, the Service Bus is almost a no brainer. The Service Bus provides both messaging and connectivity capabilities, the latter of which provide a nice way to build loosely coupled applications in hybrid scenarios (i.e. cloud + on-premises).

I dove right in and wrote the following code:

public static IEnumerable<Customer> GetCustomers()
{
    Uri serviceUri = ServiceBusEnvironment.CreateServiceUri("sb",
        "MYSERVICENAMESPACE", "Customer");
    var customersChannelFactory = new ChannelFactory<ICustomerChannel>(
        "RelayEndpoint", new EndpointAddress(serviceUri));
    var customersChannel = customersChannelFactory.CreateChannel();
    customersChannel.Open();

    return customersChannel.GetCustomers();
}

(I put much of the binding, client, and endpoint behaviors in the Web.Config.)

This code works but has problems. The channel to the Service Bus will open every time the service is called, resulting in suboptimal performance. To make this more efficient I decided to make the ChannelFactory and Channel variables statics so that I could reuse the channel if it had already been opened.

static ChannelFactory<ICustomerChannel> customersChannelFactory;
static ICustomerChannel customersChannel;

public static IEnumerable<Customer> GetCustomers()
{
    if (customersChannelFactory == null || customersChannel == null)
    {
        Uri serviceUri = ServiceBusEnvironment.CreateServiceUri("sb",
            "MYSERVICENAMESPACE", "Customer");
        customersChannelFactory = new ChannelFactory<ICustomerChannel>(
            "RelayEndpoint", new EndpointAddress(serviceUri));
        customersChannel = customersChannelFactory.CreateChannel();
        customersChannel.Open();
    }

    return customersChannel.GetCustomers();
}

This updated does a good job of improving the performance of the service call but has it’s own problems. When you create a Channel through the ChannelFactory your channel can enter a faulted state – with the Service Bus there are a number of ways that this can occur (in my testing it was because I often stopped/started the service host). When this happens the WCF communication static must be reset by recreating the client channel.

Finding an efficient – and somewhat elegant – way of handling the faulted state proved to be a fun challenge. Fortunately, I received a lot of help from folks on the Service Bus team.

In the end I went with the following code:

static ChannelFactory<ICustomerChannel> customersChannelFactory;
static ICustomerChannel customersChannel;

public static IEnumerable<Customer> GetCustomers()
{
    List<Customer> customers = null;

    if (customersChannelFactory == null)
    {
        Uri serviceUri = ServiceBusEnvironment.CreateServiceUri("sb",
            "MYSERVICENAMESPACE", "Customer");
        customersChannelFactory = new ChannelFactory<ICustomerChannel>(
            "RelayEndpoint", new EndpointAddress(serviceUri));
    }

    int tries = 0;
    while (tries++ < 3)
    {
        try
        {
            if (customersChannel == null)
            {
                customersChannel = customersChannelFactory.CreateChannel();
                customersChannel.Open();
            }

            return customersChannel.GetCustomers();
        }
        catch (CommunicationException)
        {
            customersChannel.Abort();
            customersChannel = null;
        }
    }

    return customers;
}

More verbose but much, much better.

The key is correctly handling the CommunicationException, aborting the channel, and setting the channel to null. Since we have retry logic via the while loop it will try again, determine that the channel is null, and re-open the channel.

There are certainly other ways to do this correctly. For example, you could decide to create a Faulted event handler.

I hope this helps!

    Install-Package : Unable to find assembly references that are compatible with the target
    framework 'Silverlight,Version=v4.0,Profile=WindowsPhone71'.

    At line:1 char:16
    + Install-Package <<<<  Phone.Storage
        + CategoryInfo          : NotSpecified: (:) [Install-Package], InvalidOperationException
        + FullyQualifiedErrorId : NuGetCmdletUnhandledException,
          NuGet.PowerShell.Commands.InstallPackageCommand

Here’s what you’ll see in Visual Studio:

This is the error I get when trying to install one of our NuGet packages on a freshly built machine. Long story short, the reason is that I don’t have the latest NuGet Package Manager.

Take a look at Extension Manager and observe the version number associated with the NuGet Package Manager:

See that the version is 1.2? We need to update it to version 1.5. Head to http://nuget.org and from there click to install NuGet. Once you’ve completed the installation you should confirm that you now have version 1.5:

So now, when you try to install a NuGet package such as Phone.Storage you won’t have any problems.

I hope this helps!

Today I want to show a similar way to build support for sending push notifications to Windows Phone applications.

Push notifications provide you a way to deliver information to your applications that are installed on someone’s Windows Phone. It can help provide a key way to differentiate your application from other applications – especially when you tap into tile notifications and take advantage of background tiles, deep linking, and the like. There are a lot of great blog posts on this topic:

• Push Notifications Overview for Windows Phone
• Understanding Microsoft Push Notifications for Windows Phones (somewhat old)
• Understanding How Microsoft Push Notification Works (somewhat old)
• Live Tiles (part of the 31 Days of Mango series)

One problem I’ve observed with push notifications is most people aren’t sure what to do with the channel URI’s received from the Microsoft Push Notification Service (MPNS). Developers also don’t know where or how to send messages to the device—should it be a service, and if so, where does it run? This is where Windows Azure can provide a lot of help.

Through the Windows Azure Toolkit for Windows Phone, we’ve been providing push notification services for quite a long time. It’s a great solution, and one that has helped a lot of folks. However, it was also relatively difficult to take our samples and then update them such that they worked in your applications. This is where the NuGet packages come into play. We’ve completely refactored the underlying libraries and now deliver all the capabilities as individual NuGets – you can easily create a new Windows Phone application—or update an existing one—using these NuGets.

A few comments on how these NuGets collaborate with the Windows Phone and the MPNS:

1. The Windows Phone Application registers in the MPNS: The Windows Phone application opens a notification channel to the MPNS and indicates that it wishes to receive push notification messages. The MPNS creates a subscription endpoint associated with that particular channel and forwards it to the Windows Phone device (and the specific application) using the channel it’s just opened. The MPNS sends the endpoint to the application so that the application can send it to the service from which it plans to receive notifications.
2. The Windows Phone Client registers with the Web Role: The Windows Phone application invokes a service in the Web Role to register itself with the subscription endpoint received from the MPNS. This endpoint is the URI to which the cloud application will perform the HTTP POSTs to send push notification messages to the device.
3. The Cloud Service sends a notification request to the MPNS: The cloud services sends a notification request by doing a HTTP POST in a specific XML format defined by the MPNS protocol to the subscription endpoint associated with the device it wants to notify.
4. The MPNS sends the notification to the Windows Phone device: The MPNS transforms the notification request it received to a proper Push Notification to send to the Windows Phone device associated with the endpoint where it received the notification request. The notification request can ask for a toast, a tile, or a raw notification. Once the device receives the push notification via the Push Client it will route the notification to the Shell, which will take an action according to the status of the application. If the application is not running, the shell will either update the application tile, or show a toast. If the application is running, it will send the notification to the already running application.

This architectural picture should help explain the interactions:

As with the Windows Phone and ACS example, I want to walk you through the whole process. There’s certainly more that you can do, but I think you’ll agree that the following is quite compelling.

1. Create a new Windows Phone OS 7.1 application.
   
2. From the Package Manager Console type the following to install the ACS base login page NuGet package for Windows Phone: Install-Package Phone.Notifications.BasePage.
   
3. Update the WMAppManifest.xml file so that the default page is the Push.xaml. This way the user will come to the login page before the MainPage.xaml.
   
4. Let’s create a page that we can use to demonstration deep linking with MPNS. Create a new Windows Phone Portrait Page called DeepLinkPage.xaml in the Pages folder.
5. In the ContentPanel grid, add a TextBlock control. We’ll push a message to this control when sending a notification.

       <TextBlock x:Name="QueryString" Text="Query string" Margin="9,10,0,0"
           Style="{StaticResource PhoneTextTitle2Style}"/>
   

6. We need to write the handler that will write the code to the TextBlock.

       protected override void OnNavigatedTo(NavigationEventArgs e)
       {
           if (this.NavigationContext.QueryString.ContainsKey("message"))
           {
               this.QueryString.Text = this.NavigationContext.QueryString["message"];
           }
           else
           {
               this.QueryString.Text = "no message was received.";
           }
       }

7. That’s all there is to do in the Windows Phone client. Now we have to write the services that will store the Channel URI generated by MPNS and allow us to send notifications to the device. Add a new Windows Azure Project to the solution. Select the Internet Application template using the HTML 5 semantic markup.

   

8. From the Package Manager Console, change the default project to Web (or whatever you called your MVC 3 web application), and then type the following to install the MPNS push notifications services and libraries into the web applications: Install-Package WindowsAzure.Notifications. The services installed will let clients register (and unregister) for receiving push notification messages.

   

9. At this point we don’t have any means for sending a notification. To make this easier, we’ve built a sample management UI for Windows Phone that allows you to manually send push notifications to registered devices. This registers a sample MVC Area called “Notifications” containing the UI and the MPNS Recipe for sending all the supported types of push notifications.

   

10. At this point you’re ready to roll! Hit Control-F5 to build and run. When your website starts browse to http://127.0.0.1:81/notifications and notice that you don’t have any clients currently registered.

    

11. In the Windows Phone emulator, click to Enable push notifications. Wait until you receive confirmation that the channel has successfully registered.

    

12. Reload the notifications page and you’ll see that you now have a registered channel.

    

13. Click the Send Notification. Select the Raw notification type, type a message, and click send.

    

14. In your application on the Windows Phone emulator you should receive the message. This is great – we’ve just received a push notification message in our application.

    

15. On the device emulator, click the Windows button, pan to the right, and pin the PushNotifications application to start.
16. Now, from the website, click Send Notification. This time select a Tile notification type. Change the Title, set the Count, and choose a Background Image. Click Send.

    

17. Notice how the title, tile background, and count have now updated on the device!

    

18. Lastly, from the website, click Send Notification. This time select a Toast notification type. Set a Title, Sub Title, and set the Target Page to: /Pages/DeepLinkPage.xaml?message=Hello. Click Send.

    

19. You’ll receive a toast message (i.e “Title Sub Title”) on the device. Click it. This will open up the DeepLink.xaml page and pass along the message “Hello” that was sent in the toast.

    

And that’s it! You can now quickly enrich your Windows Phone applications by leveraging push notifications.

While the Sample UI works great for development, you’ll most likely want to go a few steps further and write your own services or processes to generate notifications. Worker roles with queues work great in this space – I’ll definitely write about this in the future.

Long story short, the following three NuGet packages make it really easy to take advantage of Push Notifications on the Windows Phone using Windows Azure:

• Install-Package Phone.Notifications.BasePage
• Install-Package WindowsAzure.Notifications
• Install-Package WindowsPhone.Notifications.ManagementUI.Sample

Give it a try and tell me if you agree.

I hope this helps!

The Phone.Identity.AccessControl.BasePage NuGet package includes a control for Window Phone that allows your phone applications to outsource user authentication to the Windows Azure Access Control service (ACS). This service enables your users to login by reusing their existing accounts from identity providers such as Windows Live ID, Google, Yahoo, Facebook, and even Active Directory. If you want to know more about ACS you can take a look at the dedicated hands-on labs in the Windows Azure Platform Training Course.

Using this NuGet package and the included control for ACS in your Windows Phone applications takes care of all the runtime interactions with ACS. Additionally, this package provides a base login page that uses the control and is easy to setup in your phone application. All that is left for you to do is to configure your ACS namespace via the management portal (i.e. specifying your preferences such as the identity providers you want to enable in your application) and integrate the login page into your existing Windows Phone application.

For more information on setting up ACS take a look at the resources at http://acs.codeplex.com/

To help simplify the process below, I’m making the assumption you already have ACS setup and configured. I’ll be using the following values in the below sample (no guarantee that they’ll be available when you read this post but I’ll do my best):

• namespace: watwindowsphone
• realm: uri:watwindowsphone

Without further ado, here are the steps to build a Windows Phone application that outsources authentication to ACS:

1. Create a new Windows Phone OS 7.1 application.
   
2. From the Package Manager Console type the following to install the ACS base login page NuGet package for Windows Phone: Install-Package Phone.Identity.AccessControl.BasePage
   
3. Update the AccessControlResources.xaml resources file to use your ACS namespace and the realm you have configured.

       <system:String x:Key="acsNamespace">watwindowsphone</system:String>
       <system:String x:Key="realm">uri:watwindowsphone</system:String>
   

4. Update the WMAppManifest.xml file so that the default page is the LoginPage.xaml. This way the user will come to the login page before the MainPage.xaml.
5. Update the LoginPage.xaml.cs so that the user is navigated to the MainPage.xaml upon successfully logging into the application. Make sure to update Line 23 and Line 33.

    this.NavigationService.Navigate(new Uri("/MainPage.xaml", UriKind.Relative));

6. Let’s display some information from the Simple Web Token. Add a TextBlock control to the MainPage.xaml page. 

       <!--ContentPanel - place additional content here-->
       <Grid x:Name="ContentPanel" Grid.Row="1" Margin="12,0,12,0">
           <TextBlock Name="DisplayLoginInfo" />
       </Grid>
   

7. Add a Loaded event for the MainPage.xaml. In this event you’ll want to load the simpleWebTokenStore out of the application resources. You can then use it to grab resources like the name identifier or various other claim types (like Name). Finish by updating the DisplayLoginInfotextblock.

       using Microsoft.WindowsAzure.Samples.Phone.Identity.AccessControl;
   
       ...
   
       var simpleWebTokenStore = Application.Current.Resources["swtStore"]
           as SimpleWebTokenStore;
   
       var userNameIdentifier = simpleWebTokenStore.SimpleWebToken.NameIdentifier;
       var name = simpleWebTokenStore.SimpleWebToken.Claims[ClaimTypes.Name];
   
       this.DisplayLoginInfo.Text =
           "Identifier: " + userNameIdentifier + Environment.NewLine +
           "Name: " + name;

8. Run the application. I’d recommend using Facebook, Google, or Yahoo! for the identity providers, as Live ID does not provide the name claim type in the SWT token.

And that’s it! You can now take advantage of the Identifier claim (and others) in your phone application for many things – tracking users, displaying additional user information, and so forth. Additionally, you can use these claims to authenticate against additional services running in Windows Azure – I’ll cover this token in a future post.

The Phone.Identity.AccessControl.BasePage NuGet package makes it really easy for you to take advantage of the Windows Azure Access Control service within your applications. ACS provides a great way for you to leverage your users existing identity providers when using your application.

I hope this helps!

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!

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’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!

• Download Now: You can download the full training kit including the hands-on labs, demo scripts, and presentations from the Microsoft download center here: http://go.microsoft.com/fwlink/?LinkID=130354.
• Browse the hands-on labs: Alternatively, you can browse through the individual hands-on labs on the MSDN site here: http://bit.ly/WAPCourse

The October 2011 update of the training kit includes the following updates:

• [New Hands-On Lab] SQL Azure Data-tier Applications
• [New Hands-On Lab] SQL Azure Data Sync
• [New Hands-On Lab] SQL Azure Federations
• [New Demo] Provisioning Logical Servers using Cmdlets Demo
• [New Demo] Parallel Computing on Azure – Travelling Salesman Demo
• [Updated] SQL Azure Labs and Demos with the new portal and tooling experience
• Applied several minor fixes in content

As with the September release, we have shipped an (updated) preview of our web installer. The training kit web installer is a very small application weighing in at 2MB. The web installer enables you to select and download just the hands-on labs, demos, and presentations that you want instead of downloading the entire training kit. As new or updated hands-on labs, presentations, and demos are available they will automatically show up in the web installer – so you won’t have to download it again.

You can now download the training kit web installer preview release from here.

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.