Month: September 2015

Azure, PowerShell and DLL hell

It’s great that Azure is supported so extensively within Windows PowerShell – it really helps with automating builds and adopting a continual delivery / DevOps approach however eventually, in my experience, you’ll find yourself wanting to supplement what’s available from Microsoft with some Cmdlets of your own. Sure you can access .Net from PowerShell but sometimes C# is just more expressive and maintainable.

Of course this is simple enough to do and an example of implementing Cmdlets that use the Storage and Service Bus SDKs to create and configure resources can be found in the Application Support framework (here’s a direct link to the relevant project).

However I guarantee you that given the pace of change in the Azure space then at some point you’ll hit a DLL binding issue. Your Cmdlet will reference a different version of the Storage DLL or you’ll be using NewtonSoft.Json v7 while the Storage SDK is using v6 or vice versa and you’ll get one of those delightful can’t find DLL issues. And here I was thinking that at one point .Net was supposed to solve DLL hell!

Fortunately there’s a fairly simple solution to this: the PowerShell executable is a .Net application like any other and you can add binding redirects to a powershell.exe.config file. On a clean Windows machine this file doesn’t exist but you can create it easily enough using notepad or your text editor of choice. If you’re using a 32-bit operating system then PowerShell can be found in the folder:


Or on a 64-bit operating system in:


In that folder either create a new file or edit the existing one – you’ll probably need to run your text editor with Administrator privileges. As an example my current powershell.exe.config file looks like this:

<?xml version="1.0" encoding="utf-8"?>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
        <assemblyIdentity name="Microsoft.Data.OData" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="" newVersion="" />
        <assemblyIdentity name="Microsoft.Data.Edm" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="" newVersion="" />
        <assemblyIdentity name="Microsoft.Data.Services.Client" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="" newVersion="" />
        <assemblyIdentity name="System.Spatial" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="" newVersion="" />
        <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" />
        <bindingRedirect oldVersion="" newVersion="" />

Hope that helps with any PowerShell binding issues.

AccidentalFish.ApplicationSupport v2.1.0 Released

I’ve just pushed to Nuget the latest version of this framework. Full release notes are available here. The main addition is the support for IoC containers other than Unity – I’ve added support for Ninject and Autofac with this release however I’ve also improved the component host with a default restart handler and made a set of bug fixes.

I’ve also been working on tutorial / getting started documentation and you can find the first part of this here.

As ever I’d love to hear any feedback you might have either here or over on the GitHub Issues page.

AccidentalFish.Application Support v2.0.0 Release

This is now available in both GitHub and NuGet. There have been a large number of changes mostly to make the naming consistent throughout the framework and also documentation has been added to all public interfaces in the AccidentalFish.ApplicationSupport.Core assembly / package.

Release notes are available, the API reference, and documentation site updated.

Any issues please let me know here or on GitHub.


  • If you're looking for help with C#, .NET, Azure, Architecture, or would simply value an independent opinion then please get in touch here or over on Twitter.

Recent Posts

Recent Tweets

Recent Comments




GiottoPress by Enrique Chavez