AccidentalFish.ApplicationSupport v2.0.0

As part of my documentation push I’m also dealing with some unresolved naming issues and inconsistencies I’ve noticed since releasing v1.0.0.

As addressing some of this means breaking changes, and following the semver rules, I’ll be releasing this as v2.0.0 of the framework in due course.

I’m tracking the changes in a release note as I make them and you can already see that here if you want a view of what is coming.

Azure Notification Hub – Double Message Gotcha

I recently worked on a piece of Azure hosted software that was required to send a large volume of push notifications to mobile devices and so decided to give Azure Notification Hubs a whirl.

On the whole I found it to be pretty easy to set up and get going with and very well documented with walkthroughs for most scenarios (both server side and device) across all the major platforms.

But, and you knew there was a but coming didn’t you?, I did come across one major gotcha while building an implementation based off the tutorial on sending notifications from your server.

After implementing this and doing a bit of debugging I was finding that every time I sent a message from the server to the device my device was responding to it multiple times. Due to how devices and the registration process work you do have to be careful to ensure that your device isn’t already registered with the notification hub and Microsoft themselves show you how to do this in this code snippet:

public class DeviceRegistration
    public string Platform { get; set; }
    public string Handle { get; set; }
    public string[] Tags { get; set; }
// POST api/register
// This creates a registration id
public async Task<string> Post(string handle = null)
    string newRegistrationId = null;
    // make sure there are no existing registrations for this push handle (used for iOS and Android)
    if (handle != null)
        var registrations = await hub.GetRegistrationsByChannelAsync(handle, 100);
        foreach (RegistrationDescription registration in registrations)
            if (newRegistrationId == null)
                newRegistrationId = registration.RegistrationId;
                await hub.DeleteRegistrationAsync(registration);
    if (newRegistrationId == null) 
        newRegistrationId = await hub.CreateRegistrationIdAsync();
    return newRegistrationId;
// PUT api/register/5
// This creates or updates a registration (with provided channelURI) at the specified id
public async Task<HttpResponseMessage> Put(string id, DeviceRegistration deviceUpdate)
    RegistrationDescription registration = null;
    switch (deviceUpdate.Platform)
        case "mpns":
            registration = new MpnsRegistrationDescription(deviceUpdate.Handle);
        case "wns":
            registration = new WindowsRegistrationDescription(deviceUpdate.Handle);
        case "apns":
            registration = new AppleRegistrationDescription(deviceUpdate.Handle);
        case "gcm":
            registration = new GcmRegistrationDescription(deviceUpdate.Handle);
            throw new HttpResponseException(HttpStatusCode.BadRequest);
    registration.RegistrationId = id;
    var username = HttpContext.Current.User.Identity.Name;
    // add check if user is allowed to add these tags
    registration.Tags = new HashSet<string>(deviceUpdate.Tags);
    registration.Tags.Add("username:" + username);
        await hub.CreateOrUpdateRegistrationAsync(registration);
    catch (MessagingException e)
    return Request.CreateResponse(HttpStatusCode.OK);

You’ll notice the comment in the built of the Post action about making sure their are no existing registrations for the push handle. The handle is a token you obtain from the device and use as illustrated as part of the registration process.

The problem is – this code sample doesn’t work.

I learned the hard way that when the registration is created (in the Put action) the notification hub converts the handle to all upper case text. The handle from my device (which I obtained using the Cordova PushPlugin – I was working in Ionic) contained a mix of lower case letters and numbers.

When you subsequently search for registrations that match the handle (var registrations = await hub.GetRegistrationsByChannelAsync(handle, 100)) it performs a case sensitive search and none of your previous registrations will be found.

The result is that you can find yourself registering the same device token multiple times against different registration IDs and when you do a message send it is sent multiple times – multiple registrations == multiple sends.

If you suspect you might have a similar problem you can enumerate all registrations with the GetAllRegistrationsAsync method on the NotificationHubClient.

Other than that, and as I said earlier, my experience with the Notification Hub was really very smooth.

AccidentalFish Application Support Updates

A quick post with a few bits of news regarding my lightweight application framework.


Yesterday I pushed out a new version of the packages that contain an updated logger that will work alongside my Owin middleware for HTTP logging and correlation ID attachment.

If you use that middleware package, and an appropriate filter (Web API or MVC) in a project using the logger then everything should just work.


I’ve not been strict enough over the versioning of this framework and I’m going to tighten this up by adopting the Semver format and guidelines. I am aware of a few, minor, upcoming breaking changes as I’ve realised I’ve got some naming inconsistencies in the interfaces (particularly around the use of async) – at least by adopting Semver it will be clear when I make those changes.


The long promised documentation is now underway – something of a minor miracle as I’m always distracted by Visual Studio! I’m hosting it on GitHub Pages, go check it out. It’s early days but I’m hoping to make fairly short work of getting started guides so at least there’s a clear way into the framework.

I’m writing the documentation using Markdown and that’s getting translated into HTML on GitHub Pages via Jekyll. I’ve not used Jekyll before but it’s pretty simple to get going with and coupled with Markdown seems to be a neat solution to creating verbose documentation. I’ll be producing API reference documentation using C#s XML comments and Sandcastle.

Http Logging and Correlation IDs

I’ve recently pushed out some new open source for HTTP logging / tracing and alongside that support for adding correlation IDs to http calls and tracking them across MVC and Web API applications.

It’s fully documented and can be found in GitHub and on NuGet. The logger is independent of storage mechanism however I’ve currently only created a repository for Azure. I’ll probably add a SQL repository shortly.

The NuGet packages are entirely free standing other than the minimal Microsoft dependencies required.

I’m currently working on adding correlation ID support to the logging framework contained within the wider AccidentalFish.ApplicationSupport framework and I expect that to roll out early next week.

Alongside this I’m having a bit of a documentation push for all my open source. Other than Markdown and Sandcastle I’d be very interested in hearing how others have approached creating large amounts of technical documentation in the Microsoft space.

As ever feedback and issue reports are very welcome.

Azure Cloud Roles with .Net 4.5.2 and .Net 4.6

If, like me, you’ve been quietly tearing your hair out about the lack of support for .Net 4.5.2 in Azure Cloud Roles (and now .Net 4.6) for the last year or so then tear your hair out no longer!

I’d missed it but support for this shipped in the Azure SDK 2.6. You still have to install the .Net framework yourself as a startup task but there are some pretty clear instructions provided for doing that here that at the time of writing uses .Net 4.5.2 as an example.

According to the release notes 4.6 is also supported but I’ve not yet had an opportunity to try that.

AngularJS, IdentityServer3 and OAuth2 Plugin Sample

By popular(ish) demand I’ve published to GitHub a sample that demonstrates using my OAuth 2 Angular plugin (also hosted on GitHub) requesting tokens from IdentityServer3 and using them to access protected Web API resources.

The sample can be found on GitHub and should be pretty easy to get running as long as you have the pre-reqs (npm, git, grunt and bower primarily):

  1. Open the SLN file in Visual Studio and start both projects.
  2. Open a NodeJS command prompt and navigate to the UI folder.
  3. Type “bower install” to install the plugins.
  4. Type “grunt serve” to run the Angular app.

The identity server is prewired with a single user account details as follows:

Username: auser
Password: password

It should be noted that this is illustrative code, particularly in the C# projects, and it’s been written as such. I didn’t want to cloud the example with dependency injectors and other such components.

Thanks to everyone for their comments, questions, and feedback on the plugin both here and on GitHub.

AccidentalFish ApplicationSupport – v1.0.0

As per my previous post I’m spending some time on my application framework – I’m aware of this getting used, by myself and others, in a variety of projects and some of the flaws in the code as it stands now are starting to hurt. Since I first put it together the Azure libraries have also come on a long way and this has led to some friction.

That being the case I’m taking this oppurtunity to revisit the framework with a number of objectives:

  1. Reduce the number of dependencies. Even the core assembly had accumulated around 10 NuGet dependencies including Azure storage, Entity Framework, Unity, AWS and SendGrid.
  2. Removal of the Enterprise Library Transient Fault framework.
  3. Support for dependency injectors other than Unity.
  4. Switch to NewtonSoft Json for serialization.
  5. Documentation and samples.
  6. Move to the “new” way of restoring packages.

This does mean a bunch of breaking changes but I think they’re worth making to achieve the above.

I’ve got a compiling first stab at v1.0.0 in GitHub. I’ll be testing this in an upcoming project and dropping the packages into the NuGet prerelease channel.

AccidentalFish ApplicationSupport NuGet Packages

I just wanted to give a little bit of warning to anyone using these that an upcoming version of these packages is going to be somewhat restructured.

Over time they’ve become a bit monolithic and adding the NuGet package to a solution can result in all manner of dependency NuGet packages being added even if you’re not using those parts of the framework. And if you follow me on Twitter you’ll know I do so hate DLL hell!

To resolve this I’m going to pull them out into multiple NuGet packages. I’m not quite sure what the final shape will be yet but the best indication is probably given by the latest work I’m doing here. I’ve just started adding some wrapped cache support (Redis) and rather than just bundle it into the .Azure package I’ve added the core interface to the .Core assembly and have created a new assembly .Cache. So you can imagine that in a reworked NuGet world that might be 3 NuGet packages:


My instinct is I’ll actually end up with 6 or 7 NuGet packages as follows:


I’m not planning on significant C# level API changes so once you’ve got the packages you need things should continue to work as is.

If you’re using this NuGet package and have alternative suggestions then let me know.

Windows 8, Portable Class Libraries and ISupportIncrementalLoading

In my previous two posts (Win RT, Commanding and Cross Platform Apps Part 1 and Platform Specific Code and Portable Class Libraries) I extolled the virtues of adopting a view model approach and keeping a clean separation between your platform specific code and your view models.

For the most part it works pretty simply with a rich enough section of .Net available across most portable class library profiles however every now and then you’ll come across something that looks to be glued deeply into the platform and that isn’t immediately obvious how to best decouple.

Adopting ISupportIncrementalLoading recently caught me out like this. In Windows 8 controls such as GridView and ListView look for this interface to be defined on the collection model they are bound to. If it’s found then after the initial set of items in the collection are bound and displayed they will repeatedly call the interface (usually as you scroll towards the end) to fetch additional items asynchronously.

It’s simple to implement other than one drawback: it’s a very Windows 8 specific feature and isn’t available from a portable class library.

So how to tackle this?

I normally adopt one of two approaches: proxy classes accessed via value converters or dependency injected factories.

All of the below examples come from a side project I’ve been working on and that I’ll be releasing as open source shortly – so if you want to see this all in a real world context you will be able to soon.

The Proxy Class Approach

In this approach, and continuing to use ISupportIncrementalLoading as an example, we would implement a class within our platform specific Windows 8 UI layer that supports the necessary interfaces for ISupportIncrementalLoading (IList, INotifyCollectionChanged and ISupportIncrementalLoading itself) and routes most of the calls down to your view model in a cross-platform friendly manner.

During binding you then use a ValueConverter to wrap the underlying view model in your proxy class as in the below sample:

public class StoryCollectionValueConverter : IValueConverter
    public object Convert(object value, Type targetType, object parameter, string language)
        StoryCollection storyCollection = value as StoryCollection;
        if (storyCollection != null)
            return new IncrementalLoadingObservableCollectionProxy<StoryViewModel>(storyCollection);
        throw new InvalidCastException("Value is not of type StoryCollection");
    public object ConvertBack(object value, Type targetType, object parameter, string language)
        throw new NotImplementedException();

Using this example my view model simply declares a property of type StoryCollection and this gets replaced during binding by the proxy class IncrementalLoadingObservableCollectionProxy that implements the ISupportIncrementalLoading interface – I won’t show this latter class as it becomes quite big.

The advantage of this approach is that it keeps your view model code uncluttered. It needs to undertake no special behaviour to account for the host platform. The downside, in the case of ISupportIncrementalLoading, is that because the proxy is of a collection and an implementation of the other two interfaces it gets quite large and unwieldy.

The Factory Approach

If you remember from the post on Bait and Switch PCLs a portable class library always runs within a non-portable framework and so although you can’t access the functionality of that framework directly from the code in the library you can use techniques such as dependency injection to access it.

The factory approach to this problem takes advantage of this by declaring an IIncrementalLoadingCollectionFactory interface in a portable class library but providing the implementation for it in a Windows 8.1 assembly. My factory implementation looks like this:

internal class IncrementalLoadingCollectionFactory : IIncrementalLoadingCollectionFactory
    private readonly IUserInterfaceDispatcher _dispatcher;
    public IncrementalLoadingCollectionFactory(IUserInterfaceDispatcher dispatcher)
        _dispatcher = dispatcher;
    public ObservableCollection<T> GetCollection<T>(Func<ObservableCollection<T>, uint, Task<IncrementalLoadingResult<T>>> fetchMoreFunc)
        return new IncrementalLoadingCollection<T>(_dispatcher, fetchMoreFunc);

You can see that it returns a collection called IncrementalLoadingCollection that is constructed with a function that is responsible for adding items to the collection.

My IncrementalLoadingCollection looks like this:

public class IncrementalLoadingCollection<T> : ObservableCollection<T>, ISupportIncrementalLoading
    private readonly IUserInterfaceDispatcher _dispatcher;
    private readonly Func<ObservableCollection<T>, uint, Task<IncrementalLoadingResult<T>>> _fetchMoreFunc;
    public IncrementalLoadingCollection(IUserInterfaceDispatcher dispatcher, Func<ObservableCollection<T>, uint, Task<IncrementalLoadingResult<T>>> fetchMoreFunc)
        _dispatcher = dispatcher;
        _fetchMoreFunc = fetchMoreFunc;
        HasMoreItems = true;
    public IAsyncOperation<LoadMoreItemsResult> LoadMoreItemsAsync(uint count)
        return Task.Run(async () =>
            IncrementalLoadingResult<T> result = await _fetchMoreFunc(this, count);
            HasMoreItems = result.HasMoreItems;
            await _dispatcher.DispatchAsync(() =>
                foreach (T item in result.ItemsLoaded)
                return Task.FromResult(0);
            return new LoadMoreItemsResult {Count = (uint)result.ItemsLoaded.Count()};
    public bool HasMoreItems { get; private set; }

It’s a fairly minimal class that simply calls the supplied function and adds the items to the observable collection and I use all the above from my portable class library view model layer as follows:

model.FilteredStories = _incrementalLoadingCollectionFactory.GetCollection<StoryViewModel>(async (collection, count) =>
    IncrementalLoadingResult<StoryViewModel> result = new IncrementalLoadingResult<StoryViewModel>();
    IncrementalStories increment = await _readerCoordinator.FetchMoreStoriesAsync(model, count);
    result.ItemsLoaded = new List<StoryViewModel>();
    result.HasMoreItems = increment.HasMoreStories;
    if (increment.Stories.Any())
        await _userInterfaceDispatcher.DispatchAsync(() =>
            List<StoryViewModel> filteredNewStories = 
                    .Filter(_readerCoordinator.ReaderViewModel, increment.Stories)
                    .OrderByDescending(x => x.PostedAt)
            result.ItemsLoaded = filteredNewStories;
            return Task.FromResult(0);
        }, true);
    return result;

In the specific example of ISupportsIncrementalLoading I prefer the factory approach as the proxy boilerplate is lengthy and you then still need to deal with linking your view model to your proxy in order to actually get the incremental results.

Authenticating AngularJS against OAuth 2.0 / OpenID Connect

I’ve recently found myself doing quite a bit of work putting in place an STS (Security Token Service) based around the excellent¬†Thinktecture IdentityServer 3. I have a variety of different client types that need to authenticate including JavaScript Single Page Applications using the AngularJS framework.

IdentityServer 3 implements the Open ID Connect protocol for clients to authenticate against, Open ID Connect being an extension to OAuth 2.0.

There’s an existing open source plugin for authenticating with OAuth 2.0 called oauth-ng¬†that utilises the implicit authentication flow that I wanted to use however I wanted some different behaviour and was interested in implementing my own plugin as a learning exercise with the protocol itself and with AngularJS. Massive credit to the author of that plug-in for inspiration and readable code, this is the first non-trivial AngularJS directive I’ve developed and so it was incredibly useful to be able to look at oauth-ng and riff off it’s design. As another reference the Adal-Angular project was also really useful.

The main features of the plugin I’ve developed are:

  • Sign in / sign out button
  • Specify which routes require a token for access to protected resources and automatically handle sign in if required when they are accessed
  • Storage of the token in the browsers session storage via the ngStorage module
  • Automatic insertion of a bearer token into HTTP requests once a user has authenticated

The plug-in can be found on GitHub here. It works and I’ve tested it against both Thinktecture IdentityServer3 and Google’s OAuth2 endpoint but is still quite early code in terms of testing and so if you encounter any issues please do log them on the GitHub issues page or submit a pull request with a fix.

All the code samples given below are from the sample app which is basically the Yeoman generated scaffold and that you can find on GitHub here and which I’ve configured to authenticate directly against Google. You will need to obtain your own client ID and configure Google as per the instructions here.

Getting Started

You can either grab the scripts from GitHub or, more easily, install the plugin as a bower package which you can install as follows:

bower install angularjs-oauth2 --save

First you’ll need to add the module to your applications list of dependencies in app.js and you need to make sure that ngStorage is also included:

  .module('angularJsApp', [

The default template that is supplied for the sign in / out button expects to be placed inside a bootstrap navbar.

Typically in the above example you would select a scope appropriate to the resource you wished to access (if that terminology is confusing then I have a series of blog posts on the way as an intro to Open ID Connect and OAuth 2.0) – I’ve just picked one that we’ll have access to without additional configuration.

Now let’s modify the app.js file so that clicking the About link will require the user to be signed in:

.config(function ($routeProvider) {
      .when('/', {
        templateUrl: 'views/main.html',
        controller: 'MainCtrl'
      .when('/about', {
        templateUrl: 'views/about.html',
        controller: 'AboutCtrl',
        requireToken: true
        redirectTo: '/'

Note the addition of requireToken:true to the route for about.

Now run the app (if you’re using the yeoman builder like myself then type grunt serve). You should see something much like the following appear in your browser:


The only difference from the standard Yeoman template (at least at the time I wrote this) is the Sign In button at the top right. If you click that, or the about link, then you should be redirected to the Google sign in page that looks like this:


If you’ve not got things wired up “just so” in the Google console then you’ll see an error. Generally they are reasonably informative and normally, in my experience, the redirect URI in the console doesn’t quite match the redirect URI in the app (they’re sensitive over things like the / on the end or not).

After signing in the token will be added as an Authorization header to all http calls using the ‘Bearer my token’ format and so any calls you make to a remote resource that require authorisation will be supplied the token they need to verify the user.


The oauth2 tag has a number of attributes that can be specified as follows.

authorisation-url: The URL to request the token from.
client-id: The client ID to supply to the token provider.
redirect-url: The URL the token provider should redirect to on a successful sign in.
response-type: Optional. The required token type. Defaults to token.
scope: The resources that access is requested to.
state: A magic number to send to the token provider to protect against CSRF attacks.
template: Optional. URL of a Angular template to use for the sign in / out button in place of the built in template.
buttonClass: Optional. Defaults to “btn btn-primary”. The class to apply to the button in the standard template.
signInText: Optional. Defaults to Sign In.
signOutText: Optional. Defaults to Sign Out.
signOutUrl: Optional. The URL to call to ask the token provider to perform a sign out. See notes on sign out below.
signOutAppendToken: Optional. Defaults to “false”. If set to “true” then the access token will be appended to the signOutUrl.
signOutRedirectUrl: Optional. The URL that the token provider, if it supports redirects, should redirect to following a sign out.

Signing Out

Signing out in the OAuth world can be… complicated. When the user presses the sign out button presented by this plug in the token that is stored in session storage is cleared and as we’re using session storage as soon as the session ends (window or tab closed) then they’ll be logged out.

However they may still be logged in with the token provider depending on how the token provider behaves and the options the user has selected their.

This plugin does allow a URL to be supplied to initiate a logout at the token provider where the token provider allows for that but if the token provider is using a persistent cookie and the user shuts the window without clicking sign out then they could remain logged in.

It’s worth thinking about if / when you choose to use OAuth.