Wednesday, 16 September 2015

Windows 10 upgrade experience

Microsoft have really upped their upgrade game.

Pre-Windows 8, there was no point even bothering with an upgrade. Even if it completed without bricking your machine, the end result would be so unstable you'd just pave it and start again anyway.

The upgrade from 7 to 8 was relatively painless, I only needed to reinstall a handful of applications afterwards, not a big deal.

8 to 8.1 was seamless, as you'd expect given that 8.1 was essentially a service pack.

I've now upgraded 8.1 to 10 on 2 machines and the process has been almost perfect. On my home machine, I actually have one less bug than I had before!

About the only criticism I have is that you lose your start screen layout, but in reality this isn't a big deal and has encouraged me to do a little spring cleaning of my start screen apps.

I never thought the day would come when I'd start a Windows upgrade and not be already digging out my installer archive in preparation for a clean install.

Well done Microsoft, keep it up.

Friday, 11 September 2015

UniqueIdentifier as a primary key, that will solve all of our problems!

No, no it won't.

In evolving a single-instance website to multi-instance one, one of the many problems I have faced is how to deal with database access when your website instances are on the opposite side of the world.
My solution to this was to use SQL Azure Data Sync, makes sense as my databases are already in SQL Azure anyway.
Facilitating this involved changing all of the integer primar keys of every table to a different type with a lower possibility of collisions when syncing between databases.

I thought a Guid in the .Net side and a UNIQUEIDENTIFIER in the database would be the perfect fit for this. I was very, very wrong.

While using uniqueidentifiers as PKs has virtually eliminated any possibility of a sync collision, there is a very undesirable side effect of very high index fragmentation, bringing my site crashing to it's knees as soon as the indexes reach a critical level of fragmentation.

As is customary, I decided to run some tests. Below are the results of inserting 10k records in to an empty table:

Ouch! 96% fragmentation vs 18% on 10k records. Now in reality I rarely insert 10k records at the same time, but certain operations involve hundreds and this level of fragmentation will occur over the course of time.

Regardless of what data type your PKs are, fragmentation will happen. But the massive downside of using uniqueidentifier is that this not only happens a lot faster, but also a simple defrag or rebuild indexes is not going to save you as the data is inherently, due to it's random nature, impossible to efficiently index.

My first idea was to use an identity column (in my case called clusterkey) for the clustered index and keep the PK as a Guid with the PK constraint being non-clustered. This would sort out the fragmentation problem. But unfortunately, SQL Azure Data Sync didn't like my clusterkey, I suspect because it is a non-PK identity column. Regardless of the reason, it's not viable, so I looked further.

A contact at Microsoft suggested using the SequentialId() function in SQL Azure (available as of the latest V12 release), but all of my Guids are generated in code, so this was too big a change for me. My colleague Dave came to the rescue by tracking down this article, which describes how to generate reasonably sequential guids in C# that should keep the clustered index happy.

I'll not repeat the contents of the article, which is a really informative read, but it seems to work. This is how my tests look now:
I'll take that, much better fragmentation and approximately the same cost for inserts.

Note: The insert time includes the time taken to generate the Guid/SequentialGuid in code. Also, don't take the fact that SequentialGuid is smaller here as an indication that it is consistently faster. During testing, the number was generally the same as Guids and ints, but was consistently faster as soon as I came to actually measuring it for this blog post!

As these kinds of distributed environments become more common, I suspect more and more people will hit similar issues so hopefully this will help someone avoid making the same mistakes I have.

Friday, 5 June 2015

Windows Phone 10 - First Impressions

After running the Windows 10 Technical Preview on my laptop for the last few months and being generally happy with it, bar the obvious problems you get running a Technical Preview, I've been itching to get my hands on Windows Phone 10 (officially referred to as Windows 10 Mobile, but I'm going to refer to it as WP10). As a very happy owner of a Lumia 1020, I'll be getting it eventually so thought it was worth taking a look at. Fortunately, a colleague has recently switched from WP to Apple, so he kindly leant me his Lumia 635 to use as a sacrifice to the Technical Preview gods.

If you want to run the Technical Preview, details are here. But seriously, heed Microsoft's warning. You don't want to apply this to your main phone. I haven't hit any bugs yet, but the many interaction problems mean I'd be really annoyed if I had installed this on my main phone.

The Good

The settings app is vastly improved over the one on WP8.1, which is essentially a load of very narrowly scoped categories in a really long list on the page. The new app is well thought out, and the categorisations seem to broadly match those on Windows 10 on the desktop, which means you experience with one should transfer pretty well to the other.

The quick access to commonly used settings that has appeared in the notifications flyout on Windows 10 is also present here. It's a welcome addition that should reduce the need to venture in to the Settings app.

The Bad

Yes, that good section whizzed by rather fast didn't it? While I generally like Windows 10, even though it does remove some of the minor features of Windows 8.1 that I quite like, WP10 takes this a step further and removes pretty much everything I like about WP in one fell swoop. Let's go through the list shall we?

Command placement

WP was very predictable, all commands were at the bottom of the screen, easily reached by your thumb to summon them up. They were large and full width, so you could easily trigger them with the hand that is holding the phone without too much stretching. The overall one-handed experience with WP8.1 is very comfortable.
A great deal of the commands seem to have moved to the new "hamburger" menus in WP10, which are situated in the top-left, about as far away from your phone-holding hand as you can get (unless you're left handed of course).

Top, bottom, ellipsis,
where do I go?


As part of their march to look like everyone else, MS have removed the pivot control from their apps. This means that instead of just swiping, again with your phone-holding hand, to move between screens, you now have to stretch
to either the hamburger menu or, in the case of the dialer, to the buttons situated in the middle-top of the screen OR the buttons situated in the middle-bottom of the screen. Add to that, the dialer still has the older ellipsis menu from WP8.1, this one app has about every interaction model available, except for the one that suited it the most. Now I'm sure the ellipsis will go before release, but MS seem to have lost sight of the fact that the Pivot control was one of the greatest things about WP8.1 and I can't help but think that they could've got away with just making it a little smaller to make things more familiar to Android/iOS users while still retaining the superior interaction.

Schizophrenic navigation in the UWP mail app.

I've noted this separately from the above as I genuinely don't know whether this is just because this is a TP or if this is how this is actually intended to work, but the interaction with the mail app is incredibly painful and I sincerely hope this is not a sign of what we can expect from the UWP platform. I generally don't like doing 1-to-1 comparisons against a preview build, but in this case it's necessary to show how much of backward step this is.

To look at account settings in WP 8 is: Swipe up (or tap ellipsis) to bring up command bar (at the bottom of the screen), tap settings in the resulting menu which appears from the bottom of the screen.

In WP10: Tap hamburger (top-left), cog icon (bottom-right), tap options (in menu that appears from top of screen). My finger is going all over the phone here. It's quite a stretch and it's not even a big phone. On my Lumia 1020, I suspect this would be a 2-handed operation.

Ready to dropdown and
nowhere to go.

Desktop input controls on a phone

Most of the criticism aimed at Windows 8 is that it uses a phone UI on the desktop. It would appear misplaced UI elements is a two-way street. In the calendar app, and presumably all UWP apps, the dropdowns, rather than being full screen as they have been previously, are dropdowns just as they would be on the desktop. Except now they've got to contend with fat fingers and an on-screen keyboard that giv
es them no vertical height to occupy.

Slow animation on apps view

Now I'm nitpicking a bit, but WP at the moment is a very snappy, fast OS. You can get things done pretty quickly and there are no slow animations getting in your way, everything happens almost instantaneously. Long pressing on the back button to bring up the running apps view triggers in what feels like about 100-200ms and the animation is quick.
On WP10, it feels more like 700-800ms and the animation is slow. I don't think this is down to the hardware as there is no visible lag, it just seems that they've slowed it down to make it smoother. Smooth === slow in this case.


Not good. WP has always been a very different beast to other mobile operating systems, maybe this is part of the reason it hasn't taken off. But, in my view, the interaction with WP is faster, easier, and more natural than interacting with Android or iOS. I haven't had a great deal of contact with iOS and even less with BlackBerry, but I had Android phones for about 6 years before my current Lumia and while I didn't hate using them, WP was the first mobile operating system that I can actually describe as being pleasant to use.
 While there are a lot less WP users, those who stick with it tend to be much more satisfied with it than users of other operating systems. This survey, while admittedly a couple of years old, proves the point (at least among the users Reader's Choice surveyed).

 In their attempts to try and appeal to Android and iOS users, MS seem to have forgotten the things that make WP so pleasant to use. While I do not blame them at all for trying to make the experience more familiar to users of other OSes so the move doesn't seem quite so scary to those used to Android or iOS, you've got to think of your existing users while trying to appeal to new ones.

I suspect that, if the current preview is anything to go by, WP10 is just going to look like a pale imitation of Android or iOS, and that's a damn shame.

Thursday, 21 May 2015

Getting started with Azure Application Insights

Now that pricing information has been released for Application Insights, I decided to take the dive and deploy it on a few of the web applications I work on. The documentation is pretty good for your basic scenarios, but it glosses over what I think are probably common use cases.
  • The instrumentation key (commonly referred to as the iKey) is located in an applicationinsights.config file, which is not very helpful if you want to change it when deploying to Live or Staging environments.
  • If you use any monitoring system, such as Traffic Manager, Web Apps AlwaysOn, or any Web Testing application, this all gets included as "real traffic", which is fair enough as AppInsights has no way of knowing that it isn't real traffic. You may want to see it, but I personally do not so I wanted a way to filter it out.
There is a really great blog post by Victor Mushkatin which covers changing where AppInsights looks for the instrumentation key, adding your version number and your own tags to the telemetry so you can filter by version number or any tag you provide. I've added a siteIdentifier tag which contains an id for the particular instance of the application, identifying where in the world it is hosted.
My particular variation of his code adds the SiteIdentifier and the assembly version to the telemetry.
    public class AppInfoApplicationInsightsConfigInitializer : IContextInitializer
        public void Initialize(TelemetryContext context)
            context.Properties["SiteIdentifier"] = System.Configuration.ConfigurationManager.AppSettings["SiteIdentifier"];

                var verAtt = (AssemblyInformationalVersionAttribute)Assembly.GetExecutingAssembly().GetCustomAttributes(typeof(AssemblyInformationalVersionAttribute), false)[0];
                context.Component.Version = verAtt.InformationalVersion;
            catch (Exception)
                context.Component.Version = "Application Version Unknown";
I also have a TelemetryInitializer that finds traffic from load balancers and web testers as explained at the top of this post, and reclassifies it as synthetic traffic, making it easier to exclude from charts and reports. I found that this traffic shows up as a different user every time, making my user count orders of magnitude higher than it should be.
    public class SyntheticSourceInitializer : ITelemetryInitializer
        public void Initialize(Microsoft.ApplicationInsights.Channel.ITelemetry telemetry)
            if (HttpContext.Current == null)

            //Set traffic manager check and web test request to synthetic.
            if (HttpContext.Current.Request.Url.ToString().EndsWith("/monitoring"))
                telemetry.Context.Operation.SyntheticSource = "AzureAliveCheck";

            //Set Azure Web Apps AlwaysOn pings to synthetic.
            if (HttpContext.Current.Request.UserAgent == "AlwaysOn")
                telemetry.Context.Operation.SyntheticSource = "AzureAliveCheck";
You've got full access to the current request so you can identify the traffic however you need to (referrer, headers, request url, etc)
I then tell AppInsights to use these classes with the below entries in Application_Start() in global.asax.cs
            //Configure application insights.
            TelemetryConfiguration.Active.InstrumentationKey = System.Configuration.ConfigurationManager.AppSettings["iKey"];

            TelemetryConfiguration.Active.ContextInitializers.Add(new AppInfoApplicationInsightsConfigInitializer());
            TelemetryConfiguration.Active.TelemetryInitializers.Add(new SyntheticSourceInitializer());

As I dig further in to Application Insights, if I find more examples of useful overrides for default behaviour, I will add additional blog posts detailing these.

Wednesday, 15 April 2015

Close a window by title in C#

When you're developing for embedded systems that don't have a mouse or keyboard attached, a misbehaving program that decides to pop up windows at random is suddenly a lot more inconvenient.

Cue the below code snippet, which takes in a window title and sets it's state to minimised, maximised, or normal depending on the parameters you pass in. As usual, this is a Linqpad script. You just need to add a reference to System.Runtime.InteropServices, which is part of .net 4 and above.

void Main()
 var windowTitle = "Untitled - Notepad";

  IntPtr hWnd = FindWindow(null, windowTitle);
    if (!hWnd.Equals(IntPtr.Zero))
        ShowWindowAsync(hWnd, SW_SHOWMINIMIZED);

// Define other methods and classes here
private const int SW_SHOWNORMAL = 1;
private const int SW_SHOWMINIMIZED = 2;
private const int SW_SHOWMAXIMIZED = 3;

private static extern bool ShowWindowAsync(IntPtr hWnd, int nCmdShow);

[DllImport("user32.dll", EntryPoint = "FindWindow")]
private static extern IntPtr FindWindow(string lp1, string lp2);

This just imports the FindWindow and ShowWindowAsync methods from the user32 assembly. FindWindow is used to find the window we want to close. This return a pointer to the window handle, which we then pass to ShowWindowAsync along with an int indicating what we want to do to the window.

In the above example, I already know the window title, but this is unlikely to be the case in the real world. You can get this with the below snippet which will select out the window title and the process name. You can obviously add a where clause and modify the results based on your needs.

Process.GetProcesses().Select (p => new{p.ProcessName, p.MainWindowTitle})

Friday, 16 January 2015

ProTip: Open Powershell as admin from Powershell

Just a quick one as I find I have been using this trick a lot lately.
If I am in a standard Powershell prompt and need to get an admin one open, I used to search for Powershell, right-click, run as admin. I'd do this even if I was already in a Powershell prompt as I can never remember the syntax for runas.exe.
A much easier way, especially if you are already in a Powershell prompt is:

Start-Process powershell -verb runas

This works for any executable and will pop up UAC appropriately to allow you to enter credentials if you need to, or just run as admin if you are already an Administrator.

Hope this helps some one.


This can be further shortened to

start powershell -verb runas

Thanks anonymous user!

Thursday, 9 October 2014

Copying records between tables in different Azure accounts : The Next Generation

A few months back I posted a small piece of code for copying objects between Azure Table Storage Accounts. I have 2 bug-bears with the code I previously posted.

  1.  It's all very custom, you need to give it the type that is in the table and add lambdas to make sure it doesn't try to select the wrong object. 
  2. Due to a change in the Azure Storage Library, it no longer works. 

 I hadn't used this script in a while but now I have an impending need for something like it but better that will allow me to copy the contents of all the tables or a defined subset of tables in a given account, enter the DynamicTableEntity which allows you to get an entry from a table as a dynamic object.
To run the code, open up Linqpad and add a reference to the Windows Azure Storage library, best way to do this is using Nuget.

void Main()
  var srcClient = CreateClient("source account connection string");
  var destClient = CreateClient("destination account connection string");
  var mappings = new List<Tuple<string,string>>();
  //Manually setup mappings.
  //mappings.Add(new Tuple<string,string>("table1","table1copy"));
  //mappings.Add(new Tuple<string,string>("table2","table2copy"));
  //Copy all tables from the src account in to identically named tables in the destination account.
  var tables = srcClient.ListTables(null, new TableRequestOptions(){PayloadFormat = TablePayloadFormat.JsonNoMetadata});
  mappings = tables.Select (t => new Tuple<string,string>(t.Name,t.Name)).ToList();


public void Copy(CloudTableClient src, CloudTableClient dest, List<Tuple<string,string>> mappings) {

    var st = src.GetTableReference(x.Item1);
    var dt = dest.GetTableReference(x.Item2);
    var query = new TableQuery<DynamicTableEntity>();

    foreach (var entity in st.ExecuteQuery(query))

public CloudTableClient CreateClient(string connString){
  var account = CloudStorageAccount.Parse(connString);
  return account.CreateCloudTableClient();

In the above code, we create CloudTableClients to represent the source and destination accounts, then we build a mapping of source and destination tables.
We can do this manually if we only want to copy some tables and/or we want the destination tables to have different names to the source tables.
Alternatively, we can get a list of all the tables from the source and use that to build a 1:1 map, this will have the result of copying all items in all tables from the source account to the destination.
The Copy method simply takes the clients and mapping and does some iteration to get the items from each table from the source account and save them to the destination account.

Note: The code above is horribly inefficient for copying large amounts of data as it inserts each request individually. In a follow up post, I'll make this more efficient by making use of the TableBatchOperation.