NuGet « Wade Wegner

Yes, that title is a mouthful. But this title is as cryptic as the error that can get generated when trying to install a NuGet package:

    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:

NuGetErrorMessage

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:

OldNuGet

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:

NewNuGet

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

NuGetWorking

I hope this helps!

A couple days ago I wrote a post on outsourcing user authentication in a Windows Phone application, demonstrating how easy it is to leverage the Windows Azure Access Control service in your Windows Phone application. The solution is built using a set of NuGet packages that our team has built for Windows Phone + Windows Azure – they provide a similar development experience by allowing you to better manage dependencies and compose great application experiences on the Windows Phone.

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:

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.
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.
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.
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:

Architecture

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.

Create a new Windows Phone OS 7.1 application.
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.
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.
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.

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}"/>

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.";
        }
    }

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.
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.
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.
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.
In the Windows Phone emulator, click to Enable push notifications. Wait until you receive confirmation that the channel has successfully registered.
Reload the notifications page and you’ll see that you now have a registered channel.
Click the Send Notification. Select the Raw notification type, type a message, and click send.
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.
On the device emulator, click the Windows button, pan to the right, and pin the PushNotifications application to start.
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.
Notice how the title, tile background, and count have now updated on the device!
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.
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!

Yesterday I shared all the NuGet packages we’re building to make it easy to build Windows Phone and Windows Azure applications. Today I wanted to share how easy it is to build a Windows Phone application that leverages the Windows Azure Access Control service.

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:

Create a new Windows Phone OS 7.1 application.
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

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>

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.
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));
```

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>

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;

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!

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:

Build brand new applications that quickly can get some advanced capabilities
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]

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!

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:

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!

Wade Wegner

From the whiteboard to the keyboard

Category Archives: NuGet

Unable to find assembly references that are compatible with the target framework ‘Silverlight,Version=v4.0, Profile=WindowsPhone71′

Adding Push Notification Support to Your Windows Phone Application

Outsourcing User Authentication in a Windows Phone Application

NuGet Packages for Windows Azure and Windows Phone Developers

Using ELMAH in Windows Azure with Table Storage