Upgrading to Windows 10

Crazy? I don’t know yet but I decided to go for the upgrade to Windows 10 on day 1 …

Most of the update motored through the process seemingly without a hitch. That is until it got to the “Configuring settings xx%” stage. It started to go through that process fairly quickly and then hit 21% … and sat there … and sat there … and … you get the picture.

It was long enough to make me get a little concerned that something was going wrong. So I started doing some searches and found that this is seemingly a common “problem” even with the technical previews.

I unplugged all the extras like external hard drives and wotnot and then it bumped up to 22% so it is actually doing stuff but it seems like this final stage might take a VERY LONG TIME indeed.

I’m going to bed and I’ll see what it’s like in the morning.

No sooner that I hit the publish as I typed the sentence above then it jumped to 26% and 81% overall update so it should be good but this is by no means a fast process and this machine has a fast SSD drive …

UPDATE 30 / 7 /2015

So the upgrade seems to have gone without a hitch.  The only problem I’m faced with at the moment is my MOTU Traveler.  MOTU haven’t yet updated their drivers to support Windows 10 so if you have mission critical use of MOTU Firewire hardware you should wait until that has been rectified.

One thing I did encounter on the first login was a notification telling me that I was using a temporary profile and that I didn’t have access to my files and folders.  A quick restart later and login and all was well again.

UPDATE 30 / 07 / 2015

Interestingly it appears that an update has been pushed out already as all my Firewire audio spontaneously started working today.  Very cool!


Missing Icon Overlays

I need to look into whether this is an issue on Windows 10.  But this is definitely an issue on Windows 7 and 8.1.

Windows only uses the first 15 entries in the shell icon overlays section of the Windows Registry which is starting to get a bit crowded as more and more applications are used as shell extensions.  Windows has it’s own set then if you have lots of shell extensions like Dropbox, OneDrive, Svn or Git and any other apps you’ll hit that limit quickly.

This can be solved really easily.

Open up regedit (Start -> Run -> regedit)

Then navigate to:


icon overlaysFrom here you can just rename things to get them into order that you want.

Ijust prepended a “z” onto the overlays I wanted to put at the bottom of the list.

Sorted …


Package Dependencies & Deploying .NET

I recently had a requirement to completely package up a .NET application so that it was extremely portable beyond it’s initial installation. By bundling all the dependencies into the main executable package you can move the application around with minimal fuss once installed.  The goal was to keep the application as independent as possible.

The application is actually fairly simple with only a handful of required library files to package.  Once all the dependencies had been packaged the entire application executable is still under 600k.  This process detailed below also enables the package to contain non .NET assemblies, like C++ components and other files.  What’s really good is by default the dependencies are never extracted onto the file system which is ideal.

Initially this might sound like a complicated process. However … all you need is one NuGet package Fody/Costura (Source).  That’s it!  Just install the package and you’re done!

The NuGet Package Solution

make sure that you have your start up project selected in the package manager console and execute this command:

Install-Package Costura.Fody

You don’t even have to configure anything.  Just build …

The only thing that might need doing in order to make sure your package only contains exactly what’s needed you can add a new set of targets to your *.csproj file.

When you install the package it will automatically add a new import:

<Import Project="packages\Fody.1.26.1\build\Fody.targets" Condition="Exists('packages\Fody.1.26.1\build\Fody.targets')" />

Then to make sure you get the package your really want you can add:

<Target AfterTargets="AfterBuild;NonWinFodyTarget" Name="CleanReferenceCopyLocalPaths">
  <Delete Files="@(ReferenceCopyLocalPaths->'$(OutDir)%(DestinationSubDirectory)%(Filename)%(Extension)')" />

Done. Very nice and a must know trick.  The only thing I want to now tackle is bundling in the base configuration file.


WPF ListBoxItem Selected Background Highlight in Windows 8

When targeting the way a ListBoxItems are styled on pre Windows 8 platforms you could easily change with style syntax like:

<SolidColorBrush x:Key="{x:Static SystemColors.HighlightBrushKey}" Color="Transparent"/>
<SolidColorBrush x:Key="{x:Static SystemColors.ControlBrushKey}" Color="Transparent"/>

This would essentially override the OS level WPF style brushes and remove the highlighting (at least in this case since the color property is set to transparent). This has all been changed in WPF post Windows 8 and requires a lot more code to achieve the same effect.

In the style below, I use the above code in the ControlTemplate to achieve this:

<Setter Property="Template">
        <ControlTemplate TargetType="{x:Type ListBoxItem}">
            <Border x:Name="Bd"
                    Background="{TemplateBinding Background}"
                    BorderBrush="{TemplateBinding BorderBrush}"
                    BorderThickness="{TemplateBinding BorderThickness}"
                    Padding="{TemplateBinding Padding}"
                <ContentPresenter HorizontalAlignment="{TemplateBinding HorizontalContentAlignment}"
                                    VerticalAlignment="{TemplateBinding VerticalContentAlignment}"
                                    Content="{TemplateBinding Content}"
                                    ContentStringFormat="{TemplateBinding ContentStringFormat}"
                                    ContentTemplate="{TemplateBinding ContentTemplate}"
                                    SnapsToDevicePixels="{TemplateBinding SnapsToDevicePixels}" />
                        <Condition Property="IsMouseOver" Value="True" />
                    <Setter TargetName="Bd" Property="Background" Value="Transparent" />
                    <Setter TargetName="Bd" Property="BorderBrush" Value="Transparent" />
                        <Condition Property="Selector.IsSelectionActive" Value="False" />
                        <Condition Property="IsSelected" Value="True" />
                    <Setter TargetName="Bd" Property="Background" Value="Transparent" />
                    <Setter TargetName="Bd" Property="BorderBrush" Value="Transparent" />
                        <Condition Property="Selector.IsSelectionActive" Value="True" />
                        <Condition Property="IsSelected" Value="True" />
                    <Setter TargetName="Bd" Property="Background" Value="Transparent" />
                    <Setter TargetName="Bd" Property="BorderBrush" Value="Transparent" />
                <Trigger Property="IsEnabled" Value="False">
                    <Setter TargetName="Bd" Property="TextElement.Foreground" Value="{DynamicResource {x:Static SystemColors.GrayTextBrushKey}}" />

Phew … thanks Microsoft!


TeamCity Backup Location Outside TeamCity Data Directory

By default TeamCity doesn’t allow you to place backup files outside the default data directory (internally known as the TeamCityData).  If you want to have these files dumped into a location that is already part of your automated backup processes you need to make some configuration changes to TeamCity.

  1. Locate your TeamCityData directory and navigate to the config directory
  2. Create a new file in here called internal.properties
  3. Open the file and paste in teamcity.maintenance.backup.allowAnyFilePath=true
  4. Save the file
  5. In the TeamCity UI Go to Administration -> Diagnostics -> Internal Properties
  6. Confirm the setting is in top section called “File properties (from G:\TeamCityData\config\internal.properties)”
  7. Navigate to Backup page and set your location as desired

Xamarin Android Automated CI Publishing Using MSBuild & JetBrains TeamCity

I love automating processes and making things consistently repeatable.  Continuous integration is your friend, yes it can take time to setup but if you take that effort hit upfront it will pay off in an immeasurable way through your development process and during the entire lifetime of the your development.

For my continuous integration I use JetBrains TeamCity.  I love this CI system, granted I’ve not used them all but comparing them to TFS and Jenkins it is like an oasis of calm in comparison and without doubt the cleanest UX design by a very long margin.  Anyway … I digress.  If you want to automate the process of producing your ready to distribute Xamarin .apk Android application packages, this is the basic process you need to follow:

Creating Your Keystore

The first step is to create your own personal keystore that will contain the information used to digitally sign your Android package files.  You can do this with the following command:

"C:\Program Files (x86)\Java\jre1.8.0_45\bin\keytool.exe" -genkey -v -keystore myandroid.keystore" -alias myaliasdroidpub -keyalg RSA -keysize 2048 -validity 30000

Before you run this command make a note a few parameters first.  I did all of this in a batch file so I can refer to it later, this does include some sensitive data so beware what you do with this file.  The 30000 at the end of the command denote the length of validity of the certificates and Google require this to be past 2033.  You’ll need the following info:

REM — Password – <yourpassword>
REM — name —– <yourname>
REM — OU ——- <organisationunit> eg: JamSoft
REM — Orgname — <organisationame> eg: JamSoft
REM — Local —- <locality> eg: Frome
REM — State —- <state> eg: Somerset
REM — Country — <2lettercountrycode> eg: UK

Visual Studio Android Project

Now that we have our Java keystore ready and prepped for use we can look at the Visual Studio project.  In order to make this automated in the build system we need to configure the project to use our keystore credentials.  This is spreading sensitive information around but since our keystore is probably going to be checked into our repository it’s most likely going to spend it’s life being treated in a sensitive fashion anyway, so no real concerns.  I personally make lots of backups of things in large .RAR files and store these in various places but these are also password protected and treated as confidential.

In Visual Studio edit the Android application .csproj file and add another PropertyGroup element as per the code below:

  <PropertyGroup Condition="'$(Configuration)' == 'Release'">

Now our .csproj file knows how to use our keystore unattended. We can tie into the Xamarin build process from within our automated builds and produce the base Android package.

You can test that this is working using the following command:

msbuild.exe HelloWorld.csproj /p:Configuration=Release /t:PackageForAndroid

This will execute MSBuild against your Android project file and you’ll now find your .apk file in your bin\Release directory.

Signing The Package

Now that we have our packaged application we can apply the signing processes.  To sign the package created in the previous step we need to execute the following command:

"C:\Program Files (x86)\Java\jdk1.7.0_71\bin\jarsigner.exe" -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore myandroid.keystore -storepass yourpassword -keypass yourpassword -signedjar \bin\Release\packagename-signed.apk \bin\Release\packagename.apk myaliasdroidpub

This package is now digitally signed using your certificate from the keystore we made earlier. Personally I still have a couple of questions around why this needs to be done again considering that the details for this keystore are in the csproj file but I’m still waiting on a response from Xamarin on this.

ZipAligning the Signed Android Package

Now that we have a signed package we can zip align this package and then publish this as an artifact of our TeamCity build process.  This command makes use of the Android SDK zipalign.exe program.  You’ll have to find where this is on your machine as there are many potential locations.  The command you need will look something like this:

“C:\Users\<name>\AppData\Local\Android\android-sdk\build-tools\<version>\zipalign.exe” -f -v 4 packagename-signed.apk packagename-zipaligned.apk

You don’t need to follow this naming convention used here this is just for illustration purposes.

You can now set this as a published artifact of your TeamCity build configuration.  Yay!

MSBuild Project

To kick off the process in your MSBuild project you can add TeamCity Step that executes an additional Target in your build script like this:

  <Target Name="PackageAndroidApk">
    <MSBuild Projects="$(MSBuildProjectDirectory)\..\src\path\MyProject.Droid.csproj" Targets="PackageForAndroid" Properties="Configuration=Release">

This target will create the base APK package that you can sign and zipalign.

Once you have all these commands working you can add all the required build steps.


And voila!  Automated.  Nice 🙂


Xamarin iOS Build Server is Too Old

This is silly message really.

If you’re getting this error (or something similar) but you also know that you’re running the latest version of the iOS build host:

Build server with address is too old to be used with this version of Xamarin.iOS extension. Double click here to select a new server.    Xamarin.iOS Extension

It’s most likely that you have a manual proxy configured in your Windows development machine

The Solution

Go to your Manual Proxy configuration settings and turn off your manual proxy.  Once you’ve done this just double click on the message in Visual Studio and it should connect to your iOS build machine and run fine.


Learning MvvmCross

Learning a new technology can sometimes be a very time consuming and error prone process.  The more complex the technology the longer this process can go on for.  When I was first getting my head wrapped around WPF and using the MVVM pattern this was a long process.  WPF is massive and very complex.  MvvmCross whilst not nearly as large is a very complex framework in itself.

Having said that I’m literally amazed at just how much Stuart Lodge manages to produce in terms of tutorials, write-ups, videos and code.  For that reason alone it’s worth your time to investigate.  Below I’m starting to compile a list of resources that I find useful along my own journey of using this framework.


MvvmCross Source



This is a series of really good videos produced that demos how to achieve a very large number of basic and advanced scenarios using Xamarin and the MvvmCross libraries.  Stuart has put a lot of time and effort into producing this and it’s well worth your time to dive in from time to time to learn about the various features and options available on how to structure your code and applications.

MvvmCross NPlus1DaysofMvvmCross Tutorial Videos

Blog Posts

This is a partner to the code and videos and contains a lot of very good examples and tutorials.

NPlug1 Blogs Table of Contents


Xamarin Android Player in VirtualBox with Fiddler as Proxy to IISExpress API

So today was another learning experience indeed.  I decided to try Xamarins own Android Emulator today.  I’ve had so many odd problems with the Google Android Emulator that I was getting a bit fed up with using it to be honest.  It seems to have a lot of small issues that make it a pain to use and it has some major issues that under certain circumstances means it won’t work at all.

Anyway, the installation went without a hitch, needed to reboot to get the Host-Only network driver working.  Then I hit a road-block.

I was trying to configure the emulator to use Fiddler as a proxy on the development machine.  In the Google emulators you can configure a proxy using the APN settings for the cellular provider but this isn;t present in the Xamarin emulator so I’ve spent far longer than I should have trying to figure this one out.

By default all the emulators sit behind a virtual router, meaning if you have several emulators running they won’t be able to see your development box nor each other.  They are running in a kind of virtual network environment and each instance is completely isolated on the network.  Add into that the additional abstraction of VirtualBox and you have a pretty complex environment to deal with.

Anyway, I have added in additional bindings to make my IISExpress web sites available over the network and I could contact the API using the IP address but this makes Fiddler ignore the traffic.

The Solution

So, in the Xamarin Emulator you need to setup the proxy settings in the WiFi configuration.

If you’re having lots of issues getting this to work it’s worth checking that VirtualBox has been configured properly during the installation.  For instance when I first installed it, it was configured to use a SubNet mask of so there was no hope of ever getting it to work properly on my development box.  Unless you have a custom setup (which is highly unlikely) this should in fact be

Check VirtualBox Network Settings

Open the VirtualBox application and check the network settings for VirtualBox (not your VM) go to File -> Preferences:


This will show you the adapters created for VirtualBox during the installation.  My particular system needs to be available on #2 so double click the adapter to check/change:


When my system was initially set-up the IPv4 Network Mask was set to meaning it couldn’t see my development box.  It very likely that if you are trying to connect things to your host development box you may need to check what your configuration is (most likely and then set VirtualBox to use the same mask (ipconfig is your friend).

Configuring the Xamarin Android Player

  1. Swipe down from the top of the screen and tap the Settings icon.
  2. Tap Wi-Fi.
  3. Tap and hold your current Wi-Fi network. Select Modify Network.ModifyNetwork
  4. Tap the Show advanced options box.ShowAdvancedOptions
  5. Tap the Proxy settings dropdown and select Manual.IPAddress
  6. Type the IP address and port (usually 8888) of the Fiddler server.IP Address
  7. Tap Save.

To verify this configuration, go to http://ipv4.fiddler:8888/. You should see the Fiddler Echo Service webpage, and the traffic should appear in Fiddler.

This is all tested and working as expected now.


View IISEXpress Hosted Sites On Your Local Network

This is a useful little tidbit of knowledge to have.  Suppose you can browse to your new spanky site using IISExpress at http://localhost:54275/ … now you want to look at it on your phone?  Or your laptop? Or your … you get the picture …

Pre Visual Studio 2015

  1. Open up C:\Users\<yourname>\Documents\IISExpress\config\applicationhost.config
  2. Find your site definition and add in a new binding <binding protocol=”http” bindingInformation=”*:54275:<your-ip-address>” />
  3. Open Command Prompt (as admin) netsh http add urlacl url=http://<your-ip-address>:54275/ user=everyone
  4. Then execute netsh advfirewall firewall add rule name=”IISExpressWeb” dir=in protocol=tcp localport=54275 profile=private remoteip=localsubnet action=allow
  5. Then point your remote machines to http://<your-ip-address>:54275
  6. Voila!

That wasn’t so hard eh!

Visual Studio 2015

You need to complete steps 2 to 5 above, but Visual Studio 2015 by default doesn’t use the global configuration file for these IISExpress bindings.  In order to configure this you know have a couple of options.

The first option is to configure your project to use the global configuration files by added this to your *.csproj file:


Or you can add your addition bindings to the solution specific configuration file Visual Studio 2015 generates here:


Now running your solution under Visual Studio 2015 will behave as required.

Potential Errors

There are obviously too many potential errors to keep track of on a single blog post but I thought I’d detail a few fixes to issues I’ve personally experienced.

Access Denied

sometimes you may see this message when trying to launch your solution in Visual Studio.  To get around this close everything down and re-launch Visual Studio “as admin”.  This should fix the issue and then subsequent launches should work without running Visual Studio as an admin.

Failed to register URL "" for site "<name>" application "/"
Error Description: The Network location cannot be reached.

This was a particularly annoying issue and took quite some time to track down.  It seems that the Threshold 2 update to Windows 10 removed all my listening IP address entries!  You can check that by executing this command in a Command Window:

netsh http show iplisten

If your own IP address isn’t listed here you need to add it.  You can do that by using this command (use your own IP address obviously):

netsh http add iplisten

You can see more information about netsh here.