No, there’s no flying pigs, and Satan isn’t wearing a woolly hat, but this is a post about WebAPI (boooo!) I hit an “interesting” issue today, and felt a blog post was in order in case anyone else is bitten by this rather annoying “feature”.

I added a very simple route definition:

config.Routes.MapHttpRoute(
  name: "foo",
  routeTemplate: "{controller}/{name}",
  defaults: new { name = RouteParameter.Optional },
  constraints: new { controller = "foos" });

And a very simple controller:

namespace Bar
{
    using System.Web.Http;

    using Bar.Hypermedia;

    public class FoosController : ApiController
    {
        private readonly IFooService fooService;

        public FoosController(IFooService fooService)
        {
            this.fooService = fooService;
        }

        [HttpGet]
        public IEnumerable Root()
        {
            return this.fooService.GetFoos();
        }

        [HttpGet]
        public Foo Root(string name)
        {
            return this.fooService.GetFoo(name);
        }
    }
}

It couldn’t get much more simple – just a controller that returns a collection of Foos, or a single Foo, depending on whether the name of the Foo was specified. I fired up curl and getting a single Foo was fine, but browsing to /foos/ came back with:

HTTP Error 403.14 – Forbidden
The Web server is configured to not list the contents of this directory.

Err.. what?!

The Solution

The solution was easy – just ask a friendly neighbourhood ASP.Net WebAPI MVP to fix it for me Filip stepped up and confirmed all my code was fine, but after some head scratching noticed that I had my FoosController.cs inside a folder called Foos, and renaming that folder made the route work fine. It seems that if IIS/Asp.Net sees a folder that exactly matches the URL you’re asking for (/foos in this case) then it takes over and ignores any routes you have setup. Renaming folders would be a major pain in the backside, but luckily you can disable this behaviour by adding one line to the global.asax:

public class WebApiApplication : HttpApplication
{
    protected void Application_Start()
    {
        // Stop IIS/Asp.Net breaking our routes
        RouteTable.Routes.RouteExistingFiles = true;

        WebApiConfig.Register(GlobalConfiguration.Configuration);
    }
}

So many thanks to Filip for helping me solve this one – I’m sure I’d have lost time, and hair, trying to figure it out on my own. I’d consider this behaviour to be a bug, but I’m sure it’s actually a feature in someone’s mind. If only there was a better way to write HTTP APIs in .net….

We are big fans of Mono on the Nancy project – we have Continuous Integration builds that run on both Mono 2.x, and Mono 3.x (in addition to Microsoft’s .net), and we have TravisCI also performing Mono builds of all pull requests as they come in.

As good as Mono is though, there are still times where we have issues with compatibility. Sometimes these are down to Mono itself, other times it’s a casing issue when running on Linux (which generally has a case sensitive file system, so /Images isn’t the same as /images). Plenty of our contributors are au fait with Mono and Linux, so fixing issues on pull requests isn’t an issue, but for those that aren’t, getting Mono and Linux set, even in a virtual environment can be daunting – and that’s before you even attempt to edit any files!

Introducing Nancy.Vagrant

I’ve discussed Vagrant in a previous post – it’s an excellent tool for automatically spinning up and configuring virtual machines, and we’ve used it to create two scripts that make creating a Linux/Mono test environment for Nancy as simple as typing:

vagrant up
vagrant ssh

And because Vagrant is capable of sharing folders between the host machine and the virtual machine, you can continue to edit the files in Visual Studio (or whatever editor of choice you use locally), and run the build in the Linux / Mono environment. Once you’re all done you can either stop the virtual machine, or delete it completely, using another single command.

Trying It Out

The scripts themselves, as well as instructions on getting up and running and some simple Linux help, can be found over on the Github repository:

https://github.com/NancyFx/Nancy.Vagrant

We hope this helps people get up and running easily with Linux and Mono, whether they’re contributing to Nancy or not.

I’ve recently been playing around with Vagrant to allow Nancy contributors to easily test their changes on Mono, even if they don’t have much (or any) experience with Linux or Mono itself (more on this soon). Vagrant allows scripts to be created to quickly and easily spin up virtuals with a certain configuration, and just as easily tear them down and destroy them when you’re done (which is just as important if you’re using a machine with limited SSD space).

Vagrant sits on top of actual Virtualisation software such as VirtualBox or VMWare (but no Hyper-V support), but it defaults to VirtualBox, and that’s the only provider out there that doesn’t involve spending money as both VMWare, and the Vagrant plugin for it, are commercial.

The Problem

Vagrant installed fine, VirtualBox installed fine, everything appeared to be working and could spin up VMs just dandy, but when I rebooted the machine I was stuck with the “spinning dots of doom”, and the only way to get the computer back was restoring from system restore and ditching VirtualBox

I tried 3 different machines, two failed the same way and the third worked fine; the only difference being the working machine didn’t have Hyper-V enabled in Win8, but I couldn’t remove it from the other two as it’s required for Windows Phone 8 development, and I use it for several other virtuals as the performance is excellent. Stuck between a rock and a hard place

The Solution

After trying multiple old versions of VirtualBox, and blind alleys that suggested disabling the hypervisor on startup would fix it (it didn’t), I finally tracked down the problem to be the networking drivers it installs. VirtualBox has three networking modes: NAT (the default), Bridged and HostOnly – with the latter two requiring separate drivers. Unchecking both sets of drivers in the installer and everything works fine:

Vagrant uses NAT by default anyway, and that gives you internet access from the VMs, so there shouldn’t be too many situations where you need to use the other two options anyway. It even works side-by-side with Hyper-V too, so I can have my normal Hyper-V virtuals running while firing up Vagrant scripts on VirtualBox. It’s obviously a bit slower this way, as it can’t use it’s own HyperVisor, but it seems fast enough, and less hassle than having to disable Hyper-V and reboot every time I wanted to use Vagrant (or vice versa when I wanted to use Hyper-V).

Now, back to those Nancy scripts..

With today’s release of the RTM versions of Win8 and Visual Studio 2012 I, like many others no doubt, have formatted one of my machines, thrown the new bits on, and kicked the tyres with some code. Unfortunately, when I tried Nancy, everything build just fine, but running any tests involving NDjango (F# based) blew up with:

Could not load file or assembly ‘FSharp.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a’ or one of its dependencies. The system cannot find the file specified.

Or:

Could not load file or assembly ‘FSharp.Core, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a’ or one of its dependencies. The system cannot find the file specified.

All this works perfectly fine with .net 4, and .net 4.5 is supposed to be backwards compatible, but in this case it seems not. I haven’t done much digging, but if a strongly named assembly changes version between .net 4 and .net 4.5 I would expect an assembly binding to be in place to stop this kind of thing from happening – it’s possible that NDjango is doing something odd, but still, if it works in 4, it should work in 4.5.

This may or may not be an issue on Win7 if you’ve had .net 4 installed previously.

The Solution

Luckily, it’s very simple to add your own binding redirects to get things up and running again. These can either go in the app.config/web.config of your application, or you can put it in the machine.config – I wouldn’t recommend the latter though, as you may end up with an “it works on my machine” situation a few months down the line.

Either way, this is the section you need to add, it maps both 2.0.0.0 and 4.0.0.0 to the version that ships with .net 4.5/Win8 :

<assemblyBinding  xmlns="urn:schemas-microsoft-com:asm.v1">
    <dependentAssembly>
        <assemblyIdentity name="FSharp.Core" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
        <bindingRedirect oldVersion="2.0.0.0" newVersion="4.3.0.0"/>
        <bindingRedirect oldVersion="4.0.0.0" newVersion="4.3.0.0"/>
    </dependentAssembly>
</assemblyBinding>

A simple solution, and maybe this will just affect me, but this blog post will at least stop me from pulling my own hair out if this happens again

Nancy v0.8.0 is out, loads of cool new features such as static content (so you *finally* don’t have to do it yourself :-P), basic authentication support, and CSRF protection, and enhancements to things like error handling (with fancy pants error pages) and the test framework. We also have a fantastic new logo by Nicolas Garfinkiel (codetothepeople.blogspot.com), and a new website – so go check out the Nancy site now

The plan..

Once v0.7.1 was out of the way the plan was simple – work on diagnostics, hopefully interfacing with the guys from Glimpse, and get v0.8.0 – the “diagnostics release” out within 6 weeks or so. But things didn’t go entirely to plan…

A very nice problem to have..

We knew Nancy was getting a bit of a following, but we didn’t anticipate the level, and the quality, of the community contributions. We received lots of feedback, lots of great suggestions, and lots and lots of pull requests – before we knew it v0.8.0 was already looking pretty feature rich, without the diagnostics work we intended to be the core part of it, and time was tick tick ticking by. So, after a certain Mark Rendle started referring to this release as our “Duke Nukem Forever” release, we decided people had waiting long enough for an update and we “re-scoped” v0.8.0 so we could release the growing list of improvements sooner rather than later.

Taking a look at a GitHub comparison it shows v0.8.0 consisting of:

• 186 commits
• 226 files changed / updated
• 19 different contributors

So, what *is* in v0.8.0?

You can see the commits that went into v0.8.0 in the GitHub comparison, or take a look at the issue list for a list of features / bug fixes, but some of the highlights are:

•  Static content conventions – now static content is supported out of the box with pluggable conventions for which files are server from where.
• CSRF protection – currently only supported in Razor, Spark and SSVE, but it’s now possible to validate  “tokens” (with or without a timeout) to protect your site against CSRF vulnerabilities. There’s a sample of this in the main ASPNet demo project.
• The view cache should now be disabled in debug mode properly (yay!)
• A new exception handling pipeline and built in error pages.
• Basic authentication (as a new Nuget)
• Protocol Buffers de/serialization support (as a new Nuget)
• An awesome new logo (see below)

Logo and website

Thanks to the efforts of Nicolas Garfinkiel (codetothepeople.blogspot.com) Nancy now has an awesome new logo – many thanks to Nicolas for the speed he put this together, and for putting up with Andreas and myself nitpicking so much You can see the new logo in “action” in the updated favicon, and on our newly launched Nancy site – go check it out!

Please note that we did have a redirect on that site, so if you get redirected to github you might have to press ctrl+enter (seems to work in Chrome) or clear your cache or restart your browser or something .. sorry

Thanks

So, a big thank you to everyone who contributed to this release – comments/suggestions, bug reports, fixes, features and even just giving kudos on Twitter – it’s all very much appreciated.

Now.. onwards and upwards to v0.9.0!

P.S. Andreas and I have recently recorded a Herding Code episode – so keep an eye (or ear) out for that.

After several months of neglect, we are currently working on getting the Nancy project ship shape on Mono. We’ve gotten to the point now where everything builds and runs just fine, but we have a few tests that fail when running on Linux/Mono. The failures we are seeing are obviously bugs in the tests/stubs/mocks themselves, and we need to debug them to see exactly what’s going on. MonoDevelop has some decent test runner features, but they appear to be heavily tied to NUnit which is a problem if you happen to use xUnit

Debugging With xUnit

Luckily the solution is relatively simple, if a little clunky:

1. Download the latest xUnit release and unzip it somewhere.
2. Set whatever breakpoint you need in MonoDevelop and build the test project (in debug mode, obviously).
3. In MonoDevelop, go to Run, Debug Application, browse to where you extracted the ZIP from step 1 and choose the appropriate xunit.gui.*.exe depending on your target framework/architecture (xunit.gui.clr4.exe in our case).
4. The gui xUnit runner will popup – click Assembly, Open, browse to the output of your test project, select the assembly and press OK.
5. Click Run All in the bottom left.

The runner will run the tests and you should break out into MonoDevelop whenever you hit a breakpoint.

Pretty simple, if a bit of a ballache – but hey, you shouldn’t need to debug your tests very often anyway

I’ve been dabbling with git lately, contributing to the Nancy project, and I’ve been happily working away using Cygwin, which I already had installed, and all was fine and dandy. Things went slightly awry, however, when I decided to give MSysGit a whirl. Typing “git status” on my (unmodified) repository, that I’d previously used with Cygwin, showed every single file as modified.. argh!

Faking FileModes

A quick “git diff” showed this output for every file:

old mode 100755
new mode 100644

A brief Google later and it turns out that MSysGit “fakes” filemodes (unix permissions – the 755/644 part of the log above), whereas Cygwin, which is a more “complete” Linux implementation on Windows, does them “properly”. Now, by default, git tracks the filemode and considers it a change whenever it’s modified, so the “fake” modes coming back from MSysGit were making everything appear modified.

Solution

Luckily, the solution is very simple – tell git to stop tracking filemodes! I set this as a global option, but also had to set it on the repository too as it has a default value set in there. The following two commands sorted it out:

git config --global core.filemode false
git config core.filemode false

Conclusion

A simple fix to a, potentially, obscure problem; but I think if you’re using msysgit to work on non-Windows projects, that may have filemodes set for executable scripts, then this workaround may be required too. Apparently MSysGit does attempt to fake the filemode based on file extension, so things that *look* like they should be executable are faked to have +x, but it’s not going to be perfect.

I mentioned this on Twitter last week, but completely failed to find it again today, so thought it was worth blogging for future reference  

As I have blogged about in the past, the Add Reference dialog in Visual Studio is still pretty terrible in VS2010. Various extensions have made it more bearable by providing search support and other enhancements, but now you can avoid it completely (most of the time) with an excellent extension from Clarius Consulting:

http://visualstudiogallery.msdn.microsoft.com/en-us/dc06b54c-b6c4-4cf5-8203-a09c6979e881

Anyone that’s used ReSharper will instantly recognise the approach – just hit Ctrl+. for the VS2010 Smart Tag on something you don’t currently have referenced, and voila – an option to automatically add the reference and the corresponding using statement:

Simple and effective – I haven’t had any problems with it since I installed it last week – go and give it a whirl

Introduction

Shawn Wildermuth’s “Silverlight Tour” is coming to the UK, in the guise of the Silverlight Masterclass, and NxtGenUG members can receive £50 off the course price (in addition to the current “early bird” offer if you qualify for that).

The 3 day developer course looks quite comprehensive, starting with Silverlight, XAML and Blend basics on day one, working with data on day two, and finishing off with more advanced topics like MVVM, MEF and PRISM on day three. It’s great to see some patterns and practices coverage in a Silverlight course, especially given my recent experience trying to recruit Silverlight developers!

In addition to the discounts you can also win a free ticket to one of the courses by blogging about it yourself using the text from the “pitch” below. For more details on the competition take a look at Ian Blackburn’s blog entry.

The Pitch

The Silverlight Tour comes to the UK – and it’s called the Masterclass!

This 3 day hands-on training with both designer and developer tracks looks awesome and (uniquely) has two expert trainers per course.

Currently scheduled in London, Manchester, and the Midlands for June, all courses also come with the chance to win an xbox 360, and Silverlight Spy licences!

Early bird discount of £100 if you book in May, and if you are a member of #SLUGUK or #nxtgenug there are additional discounts to be had.

Full Details are here: http://silverlightmasterclass.net

In addition bbits are holding a raffle for a free ticket for the masterclass. To be eligible to win the ticket (worth £1095!) you MUST paste this text, including all links, into your blog and email Ian@bbits.co.uk with the url to the blog entry.  The draw will be made on June 1st and the winner informed by email and on http://silverlightmasterclass.net

One of the features C# has gained in it’s latest V4 incarnation is the ability to work with optional parameters. Now VB.Net (and the underlying IL) has had this ability for sometime, but as it’s new to C# folks, and causing a little confusion; I’m going to attempt to explain how it works, when it works and the potential gotchas. I’ll also cover a strange inconsistency between the the VB and C# compilers when it comes to named parameters.

Warning: This post contains IL, but don’t let that put you off – you don’t actually need to understand it to get the point of the post!

So It’s C#4 Only, Right?

Sort of Just to confuse things, optional parameters, from both a definition and consumption perspective, are really the concern of the compiler. As other posts have correctly pointed out, as long as you’re using Visual Studio 2010 you can define and consume optional parameters while targeting an older framework version:

public void DoThings(int intParameter = 22, string stringParameter = "Default")
{
    // Do things
}

// ...

DoThings(); // Uses the default values

This will work whether you’re in the same assembly, or consuming a library that already exposes methods with optional parameters.

You can also happily consume C# libraries containing optional parameters with VB.Net; even if the VB.Net project is still running under VS2008. The reason this works it that the IL that the new C# compiler is emitting is nothing new, and VB.Net has been able to define and consume optional parameters for some time. You can see the IL that is generated for the above method in the ILDASM output below (interesting parts highlighted in yellow):

The one thing you *cannot* do is consume optional parameters using C# in Visual Studio 2008; even if you’ve built the library in VS2010 and targeted the older framework. The C#3 compiler just doesn’t understand (or more to the point doesn’t care about) optional parameters. If you try and build the code above using Visual Studio 2008 you will get the following error:

Definitely something for library authors to consider – we’re not quite out of “overload hell” yet unfortunately.

Gotchas?

Now you may well think that when you consume an optional parameter, the compiler is emitting code that pulls the default value from the method information at runtime – but that isn’t the case. In a similar fashion to the way the compiler handles consuming consts, the default values are “baked into” the calling code. This is true whether the calling code is in the same assembly as the definition, or a separate assembly . The following ILDASM screenshot shows the IL generated for the DoThings() call above (interesting parts highlighted in yellow again):

Even if you don’t fully understand the IL you can clearly see the constant values in the code are “baked into” the TestStuff() method.

The issue this can cause is the same for exposing public consts – if you change the default values in a library, but don’t recompile the calling code, then the calling code will still call your method(s) with the old default values. This is definitely something you need to consider when designing APIs using optional parameters.

One potential way to “work around” this issue and avoid “locking yourself in” to a particular set of defaults would be to follow the following pattern:

public void DoThings(int? intParameter = null, string stringParameter = null)
{
    if (intParameter == null)
        intParameter = 22;

    if (stringParameter == null)
        stringParameter = "Default";

    // Do Stuff
}

In the code above we still get the benefits of having optional parameters; but because we use “marker” values for defaults (nulls in this case), and set the *real* defaults inside the method, we are free to change the real defaults at a later date. This technique does require more code, and doesn’t look quite as elegant as the previous example, but in my opinion the benefits outweigh the drawbacks, especially for public APIs.

A VB/C# Named Parameters Quirk

As I was pulling together the IL for this post I discovered a small “quirk” when comparing the IL output by the VB.Net compiler to the output of the C’# compiler when dealing with named parameters. If we call the DoThings() method above and specify just the stringParameter the IL produced by the VB.Net compiler looks as I would expect:

The default value for the intParameter is pushed onto the stack, followed by our “Nondefault” string value and the method is called. The IL produced by the C# compiler is slightly different though, as shown by the highlighted sections below:

In the C# version the “Nondefault” string is pushed onto the stack *first*, then pops it off into a local variable (stloc.3), the default value for intParameter is then pushed, followed by the contents of the local variable (ldloc.3).

Not a massive difference, and I’m sure there’s a good reason for it, but the C# version does look decidedly “odd” to me. I’m no expert in IL performance, but this may be conclusive proof that VB is faster than C# *

Update: Marc Gravell was kind enough to review this post for me and correctly pointed out that I should really be comparing IL for *optimised* builds, not debug builds (which have optimisation turned off). Marc has done this for himself and confirmed the stloc and ldloc are still present, so my point is still valid (*phew*)

* Note: This is a joke.. I got some abuse on Twitter for “VB bashing” recently, hopefully this will appease the VB heads!

For one of the little iPhone projects I’m working I need to communicate with with a server on the local network. That all sounds very simple, but what I *really* want to be able to do is detect all instances of this service on the local network, and give the user the option of which one to connect to at runtime.

In WCF land we could leverage WCF Discovery, but in the world of MonoTouch, and even in .NET 3.5, we don’t have that luxury, so it’s time to roll our own service discovery!

Ping! Pong!

To build our service discovery system we will be dropping down to the socket level; but don’t worry! We’re only using sockets to discover the services – after that you are free to use your normal HttpClient to actually access them

The basic idea is our client will send out a “ping” containing the IP and port to respond back on. Each server that picks up the ping will send a response back containing some metadata (in this instance a “service name” and a “service endpoint address”). The two classes we will use as “payload” are as follows:

[Serializable]
/// <summary>
/// Our initial ping "payload" 
/// </summary>
public class ServiceClientInfo
{
    /// <summary>
    /// IP address of the client that sent the ping 
    /// </summary>
    public string IPAddress { get; private set; }
    
    /// <summary>
    /// UDP port to send a response to 
    /// </summary>
    public int Port { get; private set; }

    public ServiceClientInfo(string iPAddress, int port)
    {
        IPAddress = iPAddress;
        Port = port;
    }
}

[Serializable]
/// <summary>
/// Server response "payload" - could be anything
/// </summary>
public class ServiceInfo
{
    /// <summary>
    /// Standard port servers listen on 
    /// </summary>
    public static readonly int UDPPort = 3512;

    /// <summary>
    /// Name of the service 
    /// </summary>
    public string ServiceName { get; private set; }
    
    /// <summary>
    /// Endpoint address 
    /// </summary>
    public string EndpointAddress { get; private set; }

    public ServiceInfo(string serviceName, string endpointAddress)
    {
        ServiceName = serviceName;
        EndpointAddress = endpointAddress;
    }
}

For our test app we will have a simple UITableView to display server responses, and a single button for sending our out ping. It looks a little something like this:

We will also verify that we have a working WiFi connection before we do anything. We do this using Miguel’s MonoTouch “reachability” sample code.

Step 1 – Firing the Ping from the iPhone

First things first, we need to fire off the initial ping from our phone by sending a UDP broadcast containing our “payload”. UDP is ideal for our application as it gives us a lightweight, connectionless transmission model which allows us to send a single message to every machine on the network using a broadcast. UDP is considered an “unreliable” protocol (i.e. it has no guarantees of delivery), but for our purposes that isn’t a problem. For more information on TCP/UDP and broadcasting you can take a look at the wikipedia pages: TCP, UDP, Broadcasting.

From a .NET code point of view this is pretty straightforward. We create an IPv4 UDP Socket, a UDP broadcast IPEndPoint, set some options and then use our Socket to send a serialised version of our “payload” to the network.

In this instance we are using the BinaryFormatter to serialise our payload (using a generic helper class in Helpers.cs), but you could serialise using any mechanism you like.

The code for this is as follows:

/// <summary>
/// Send our our server ping
/// </summary>
private void SendServerPing ()
{
    // Create a socket udp ipv4 socket
    using (Socket sock = new Socket (AddressFamily.InterNetwork, SocketType.Dgram, ProtocolType.Udp)) {
        // Create our endpoint using the IP broadcast address and our port
        IPEndPoint endPoint = new IPEndPoint (IPAddress.Broadcast, Discovery.Core.ServiceInfo.UDPPort);
        
        // Serialize our ping "payload"
        byte[] data = Discovery.Core.Helpers.SerializeObject<ServiceClientInfo> (new ServiceClientInfo (GetCurrentIPAddress ().ToString (), 8762));
        
        // Tell our socket to reuse the address so we can send and
        // receive on the same port.
        sock.SetSocketOption (SocketOptionLevel.Socket, SocketOptionName.ReuseAddress, true);
        
        // Tell the socket we want to broadcast - if we don't do this it
        // won't let us send.
        sock.SetSocketOption (SocketOptionLevel.Socket, SocketOptionName.Broadcast, true);
        
        // Send the ping and close the socket.
        sock.SendTo (data, endPoint);
        sock.Close ();
    }
}

Step 2 – Listening for Responses

Next up we need to listen for server responses. We actually start listening *before* we send the ping (to make sure we don’t miss anything), but it makes more sense to think of it as a second step.

There are two ways to listen to responses: synchronously, where we sit there and wait for a response to come back, or asynchronously, where we provide a callback method that will respond to data as it comes in. We obviously don’t want our UI to stop responding while we’re waiting, and we certainly don’t want the iPhone to kill our application for being unresponsive, so we will opt for the asynchronous model.

The steps for setting up a listener are, again, very simple. We first create an IPEndpoint, this time using the IP address and port we included in our initial ping, and create a UDPClient bound to it. Finally we call BeginReceive to tell the client we want to receive data asynchronously, providing our callback method, and start a timer to stop listening after 2 seconds. We pass in a simple “state” object to our callback, so it has access to our endpoint and client, but you could also store those as fields if you prefer.

While we are listening for responses we also disable our Ping button and re-enable it again, making sure to do so on the UI thread, once the timer has elapsed:

private void StartListeningForServerPingBacks ()
{
    // Disable our ping button
    PingButton.Enabled = false;
    
    // Listen on our IP addresses on our port
    // In a real scenario you'd probably want to make sure the port
    // was available and fallback to an alternative if not.
    var endPoint = new IPEndPoint (GetCurrentIPAddress(), 8762);
    
    // Make sure we don't grab exclusive "rights" to our address
    // so we can use the same port for send and receive.
    var udpClient = new UdpClient ();
    udpClient.Client.SetSocketOption (SocketOptionLevel.Socket, SocketOptionName.ReuseAddress, true);
    udpClient.ExclusiveAddressUse = false;
    udpClient.Client.Bind (endPoint);
    
    // Setup our "state" object so the callback has access to the client and endpoint
    UdpState state = new UdpState (endPoint, udpClient);
    
    // Setup our async receive
    // Our callback will be called if and when data comes in
    udpClient.BeginReceive (new AsyncCallback (this.ReceiveServerPingCallback), state);
    
    // Setup a timeout timer.
    // When the timer elapses we enable our ping button again and
    // close our udpclient.
    var enableTimer = new Timer (2000);
    enableTimer.AutoReset = false;
    enableTimer.Elapsed += delegate(object sender, ElapsedEventArgs e) {
        InvokeOnMainThread (delegate { PingButton.Enabled = true; });
        udpClient.Close ();
    };
    enableTimer.Enabled = true;
}

Step 3 – The Callback

Our callback method is rather simple (are you seeing a trend? :-)). We first grab the state object, call EndReceive to grab the data, deserialise it to our ServiceInfo object, add it to the UITableView, and then call BeginReceive again. That last part is the most important – every call to BeginReceive, which starts an asynchronous receive, must match a call to EndReceive, which ends the asynchronous receive. If we didn’t call BeginReceive at the end of our callback we would only ever get one server response – which obviously isn’t what we want!

As our timer may close the connection, and because we may get bad data sent to our listening port, we wrap the whole callback in a try/catch to make sure we don’t crash the app:

/// <summary>
/// Our callback that receives the pings back from the server(s)
/// </summary>
private void ReceiveServerPingCallback (IAsyncResult ar)
{
    try {
        // Grab the state object and split it up
        UdpState state = (UdpState)(ar.AsyncState);
        UdpClient client = state.client;
        IPEndPoint endPoint = state.endPoint;
        
        // Grab all the data we received
        Byte[] receiveBytes = client.EndReceive (ar, ref endPoint);
        
        // Deserialize it to our ServiceInfo object
        var data = Discovery.Core.Helpers.DeserializeObject<ServiceInfo> (receiveBytes);
        
        // Using the UI thread, update the server list
        InvokeOnMainThread (delegate { AddItemToList (String.Format ("Name: {0} Endpoint: {1}", data.ServiceName, data.EndpointAddress)); });
        
        // Start listening again
        client.BeginReceive (new AsyncCallback (this.ReceiveServerPingCallback), state);
    } catch (Exception) {
        // Just in case we have any network issues, or we've closed the socket, we catch everything.
        // Rather a horrible catch all than an app crash in this instance.
    }
}

The Code

And that’s that. The full application source is available below. The solution contains the iPhone app, a WinForms “server” that you can run multiple times on your Mac/PC, and a shared library with the common data types in.

I’ve successfully tested this code with 10 servers, spread across multiple machines, without any issues but if your app needs responses from a large amount of servers then your mileage may vary

ServiceLocation.zip

Just a small post to announce I have added, and finally documented, TinyMessenger to the TinyIoC project.

Tiny What-Now?

TinyMessenger provides an event aggregator/messenger for loosely coupled communication. Some scenarios where this may prove useful :

• Communication between Controllers/ViewModels.
• Service classes raising “events”.
• Removing responsibilities from classes that receive external events (such as the AppDelegate in an iPhone application).
• Decoupling communication between classes.

TinyMessenger uses a Publish/Subscribe model and is orderless, so you can subscribe to a message even if there’s nobody publishing, and you can publish one even if nobody is subscribed. It is also loosely coupled in that the publisher and subscriber know nothing of each other, all they both care about is the message itself. Some of the key features are:

• Simple and orderless Publish/Subscribe API.
• Messages either need to implement a simple “marker” interface, or they can build on the “base” classes that are in the box (TinyMessageBase and GenericTinyMessage<TContent>.
• Subscriptions can supply an optional filter – only message that “pass” the filter are delivered.
• Subscriptions can supply an optional “proxy”. A proxy can be used for marshalling to the ui thread, logging or many other purposes.
• Subscriptions use weak references by default, but strong references can be specified if required.

TinyMessenger is part of the TinyIoC project, but it can be used completely independently – for more information take a look at the TinyMessenger Wiki page on the main TinyIoC site.

We all know Add Reference is horribly broken in VS2008. We’ve all clicked it and had our hearts sink as we realised it was time to make a brew, grab lunch or take a weekend mini-break before even attempting to use Visual Studio again. Now VS2010 is in Release Candidate it’s obviously been fixed.. hasn’t it?!

Not All Change Is For the Better

The main issue with the VS2008 Add Reference dialog was that it took an age to load, mostly due to it enumerating all of the assemblies available to populate the .NET tab. If all  you wanted to do was add a project or file reference you still had to wait for it to finish building the .NET tab. Not good. In an attempt to fix the problem Microsoft has made two major changes to the dialog for VS2010:

• The dialog now defaults to the Projects tab.
• The .NET tab is now multi-threaded i.e. it loads types in the background.

The first of the two fixes is an excellent idea. If you want to use the Projects, Browse or Recent tabs then you don’t even need to look at that snail-paced .NET tab.

The second of the two fixes is horrible. Truly horrible. I’d even go as far as to say that if you actually want to use the .NET tab to add a reference then it’s actually *more broken than Visual Studio 2008*. Yes, I did say that. And I’ll say it again:

“If you actually want to use the .NET tab to add a reference then it’s actually more broken than Visual Studio 2008.”

To illustrate the point, lets say we want to add MEF, which sits in System.ComponentModel.Composition to our application, we’d probably do something similar to the following:

1. Click Add Reference.
2. Marvel at how quickly Add Reference Loaded.
3. Click the .NET tab.
4. Watch the first few items start to load up.
5. Type “Sys” to jump down to System in the list.
6. Go to select System.ComponentModel.Compo..oh no.. it’s moved.
7. Scroll down, go to select Sys.. nope.. it’s moved again.
8. Scroll down a bit more, click on.. nope, gone again.
9. Swear.
10. Wait until the thing has fully finished loading and then select what we want.

So what we have there is the same delay as it would have taken with VS2008, but with the added “fun” of playing a game of “chase the reference down the listbox” in a vain attempt to save yourself a few seconds.

Could It Be Done Better?

Now I’m no User Experience expert, or an Interface Designer with a fancy job title, but couldn’t this be improved immeasurably with a simple filter box?

Perhaps I work in a strange way, but I never start searching for a reference using the mouse – I *always* type the first few letters to skip to roughly where I want to go. If we had a simple filter box at the top of the dialog then the “chase the reference” game would be massively reduced, and probably eliminated all together if you’d typed in enough of the namespace name:

Now we could get super fancy and support CamelCaseSearching like the QuickNav dialog in CodeRush, but I’d be quite happy with a basic filter.

Maybe I’m just picky.

Introduction

I’m currently using TinyIoC in my first forays into MonoTouch development, and my initialisation code was throwing a resolution error on starup:

var container = TinyIoCContainer.Current();
var mainView = new MainView();
container.Register<IViewManager>(mainView);
container.Register<IView, MainView>(mainView, "MainView");
container.Register<IView, SplashView>("SplashView").UsingConstructor(() => new SplashView());
container.Resolve<IView>("MainView");
container.Register<IStateManager, StateManager>();
// Code was blowing up here..
var stateManager = container.Resolve<IStateManager>();
stateManager.Init();

The Exception that was given was that IStateManager could not be resolved, which was odd given that the StateManager was registered against IStateManager, and everything in its constructor was also registered:

public StateManager(IViewManager viewManager, Func<string, IView> viewFactory)

To The Debugger.. Right?!

So at this point your immediate reaction may be to fire up the debugger, trace into the code and start hacking around, debugging and hacking around some more until it works. Sure, that’s an approach, and one I’m sure we’ve all used in the past; but as I was pretty sure the issue was in TinyIoC itself I took a slightly different tack.

To The Test Runner!

With the approach above I would have to build and run my app every time I wanted to check if my “fix” had actually worked – and even if it had, how would I know it hadn’t broken something else? The solution is quite simple – recreate the conditions of the bug in a unit test, using stubs/mocks to replace your real classes, and make sure it fails in the same way:

[TestMethod]
public void Dependency_Hierarchy_With_Named_Factories_Resolves_All_Correctly()
{
    var container = UtilityMethods.GetContainer();
    var mainView = new MainView();
    container.Register<IViewManager>(mainView);
    container.Register<IView, MainView>(mainView, "MainView");
    container.Register<IView, SplashView>("SplashView").UsingConstructor(() => new SplashView());
    container.Resolve<IView>("MainView");
    container.Register<IStateManager, StateManager>();
    var stateManager = container.Resolve<IStateManager>();
    stateManager.Init();

    Assert.IsInstanceOfType(mainView.LoadedView, typeof(SplashView));
}

I’ve added an Assert to show what behaviour I think it *should* have. It’s a pretty horrible looking test, but it accurately represents what my failing code was doing, and the test fails as I expected it to. Now I can attach the debugger and find out what’s going on, safe in the knowledge I have a fast executing test available to verify my fix, and the rest of my test suite there to ensure I haven’t broken anything else.

After a very brief investigation it turned out that there was a bug in registration when *just* an Interface type was registered with an concrete instance (the IViewManager registration above). The “InstanceFactory” it was using hadn’t set the “AssumeResolves” flag, so TinyIoC was actually trying to find a valid constructor for IViewManager – which obviously wasn’t going to succeed. It’s a scenario I probably should have factored into my Unit Tests, but hey, nobody is perfect

Conclusion

This post is aimed at covering two points:

1. Test aren’t just for TDD. If you find a bug, isolate it with a test and you have a quick and easy way to verify a fix, and verify you haven’t broken anything else.
2. Code Coverage isn’t everything. Apart from a few “defensive coding” null checks, the core of TinyIoC has pretty much 100% code coverage with its tests, but it didn’t help me with this issue. Although the code path was covered, the exact input (Interface type, concrete instance) wasn’t in my unit tests, so don’t assume 100% code coverage means 0 bugs in the code, there may well be a scenario you missed!

Whenever I start a new “pet” project I usually *want* to use IoC, but I don’t really want the hassle of taking a dependency on a container, or adding another binary to my project. Usually this leaves me using “poor man’s IoC”, whereby I define dependencies in my constructors, but I pass them in manually or construct them using constructor chaining.

I’ve thought for some time that it would be useful to put together a container that fits the bill for that scenario, but also attempts to “lower the barrier of entry” for developers that are new to IoC, and may be scared off by the “big boys”. A couple of weeks ago @DotNetWill posted his simplified container, and that gave me the kick up the backside I needed to create my own

Introducing TinyIoC

Now you might ask “do we really need *another* IoC container?” – and it’s a reasonable question. We already have Unity, Ninject, StructureMap, AutoFac.. the list goes on. TinyIoC makes no attempt to go “head to head” with any of these other containers, instead TinyIoC has been designed to fulfil a single key requirement:

To lower the “level of entry” for using an IoC container; both for small projects, and developers who are new to IoC.

To that end, TinyIoC attempts to stick the following core principals:

• Simplified Inclusion. No assembly to reference, no binary to worry about, just a single cs file you can include in your project and you’re good to go. It also works on Mono, and on MonoTouch for the iPhone / iPad.
• Simplified Setup. With auto-resolving of concrete types and an “auto registration” option for interfaces, setup is a piece of cake. It can be reduced to 0 lines for concrete types, or 1 line if you have any interface dependencies.
• Simple, “Fluent” API. Just because it’s Tiny, doesn’t mean it has no features. A simple “fluent” API gives you access to the more advanced features, like specifying singleton/multi-instance, strong or weak references or forcing a particular constructor.

The following snippet gives an example of the simplified setup:

// TinyIoC provides a lazyily constructed singleton
// version of itself if you want to use it.
var container = TinyIoCContainer.Current;

// By default we can resolve concrete types without
// registration
var instance = container.Resolve<MyConcreteType>();

// We can automatically register all concrete types
// and interfaces with a single call.
container.AutoRegister();
var implementation = container.Resolve<IMyInterface>();

So Where Now?

If you want to grab the source, read the tests, or take a look at some more complex examples of the API, wander on over to the homepage on bitbucket. I’m happy to take comments and suggestions – just grab me on Twitter or ping me an email from the contact form.

Over the next few weeks I will be posting a series of “beginners” articles on the hows and whys of IoC. I will be using TinyIoC specifically, but the majority of concepts and content can equally apply to other containers. I may even do a “File, New” screencast to show how “un-scary” this stuff is, and how it doesn’t really add any extra development effort,

Let me start with a disclaimer. I’ve only been using Mercurial for 2 days so my nomenclature may be completely wide of the mark. Hopefully this post will help other hgnewbies with what is probably a common requirement.

Introduction

I keep all of my pet projects in my own Subversion repository but I’ve recently decided to give this distributed version control shenanigans a whirl. I ummed and arred about Git or Mercurial, but in the end I plumped for Mercurial, with a bitbucket account, as it seems to have more ubiquitous support. I’m about to release a project I’ve been working on for the last week or so and thought it would be nice to release it via bitbucket – complete with the version history I’d build up in Subversion.

Turns out, it’s really rather easy!

I’m Converted!

I’m assuming at this point you have the commandline version of Mercurial (hg) installed and working. If you don’t then you should probably go and do that first I’ve also assumed you’ve already created a mercurial repository (bitbucket or elsewhere) called “myproject”.

In my scenario I was converting a single project with no trunk, branch or tag directories. The convert command is capable of handling much more advanced scenarios – take a look at the documentation for more infomation.

First things first you need to edit your Mercurial settings (.hgrc for *nix, Mercurial.ini in your user dir for Windows) and add the following lines:

[extensions]
hgext.convert=

This will add the “convert” command extension to our client. Next up we clone our repository and use the new convert command to add the SVN changesets into it:

hg clone https://bitbucket.org/myuser/myproject

hg convert http://mysvn.server.com/svn/myproject/ myproject

The convert command will now start counting down the revisions and adding each one to our local hg repository. This may well take some time

Potential gotcha: it appears that the convert extension doesn’t work properly with Subversion repositories over http that require authentication. If you get multiple “http authorization required” messages and prompts for your username/password then you have a problem. The only solution I found was to temporarily disable authentication while I did the conversion

Once the conversion had finished we push our changes back:

cd myproject

hg push

Now at this point for me the push worked fine but my local repository had no files in it – despite insisting it was up to date. This may be my lack of knowledge on Mercurial, or it might be a bug, but deleting the myproject directory locally and cloning the remote repo again sorted things out.

Conclusion

All in all a pretty trivial task, albeit one that takes a while with a large repository. The only big issue is the authentication one I mention above – this may well be a showstopper for you if you can’t control the ACL on your Subversion repository.

Following on from my previous post about a “Thread Safe” Dictionary, and the subsequent comment from Rajeesh, made me think that perhaps a general post on “thread safety” was in order.

Stop With the Quotes Already!

The astute amongst you may notice I always try and put the phrase “thread safe” in quotes; and there is a good reason for that! “Thread safe” is a pretty horrible term (although I can’t think of a better one) that doesn’t really give enough detail for what exactly we mean when we express that a class is “thread safe”. As far as I’m concerned, my “library” classes are thread safe if:

“All public static and instance methods and properties on the class are safe to be called concurrently from multiple threads.”

What this certainly does *not* mean is:

“You do not have to consider thread safety or concurrency issues in your own code that uses this class.”

So in the instance of our dictionary if you get/set a value and then in subsequent lines of code you *assume that the value you got or set hasn’t changed* then you have a concurrency issue in *your* code and you will *need to address it, likely using the same synchronisation primitives we used internally in our SafeDictionary class.*

Some Examples

As an example we can take similar code to the snippet that Rajeesh posted:

// Check the item exists and process
// if it does
if (mySafeDictionary["Testing"] != null)
{
    // Process element
    ProcessElement(mySafeDictionary["Testing"]);
}

Although each of those calls to the SafeDictionary are themselves threadsafe, we are making an assumption in *our code* that those value won’t change between the “if” statement and our call to ProcessElement. This particular scenario is one reason why we should always try to use TryGetValue, rather than the “if it exists do this with it” approach above. To this end we should probably alter our SafeDictionary to explicitly deny gets:

public class SafeDictionary<TKey, TValue>
{
    private readonly object _Padlock = new object();
    private readonly Dictionary<TKey, TValue> _Dictionary = new Dictionary<TKey, TValue>();

    public TValue this[TKey key]
    {
        set
        {
            lock (_Padlock)
            {
                _Dictionary[key] = value;
            }
        }
    }

    public bool TryGetValue(TKey key, out TValue value)
    {
        lock (_Padlock)
        {
            return _Dictionary.TryGetValue(key, out value);
        }
    }
}

If you now try and access a member using the array syntax, rather than through TryGetValue you will get a compile time error like:

The property or indexer ‘Variabler.this[string]’ cannot be used in this context because it lacks the get accessor.

From that simple example you may think that TryGetValue solves all our problems; but unfortunately it still isn’t able to save your from yourself! To reiterate what I said earlier, you need to consider concurrency yourself if you *assume that the value you got or set hasn’t changed*. Assuming we expand our SafeDictionary to include all of the options that the normal Dictionary supports, take the following horribly contrived example:

public List<String> GetKeysToProcess()
{
    object myObject;
    List<String> keysToProcess = new List<String>();

    // Check to see if the type is valid for
    // processing
    foreach (var currentKey in myDictionary.Keys)
    {
        if (myDictionary.TryGetValue(currentKey, out myObject))
        {
            if (myObject.GetType() == typeof(ProcessorClass))
                keysToProcess.Add(currentKey);
        }
    }

    return keysToProcess;
}

Now there’s a chance that a key might have been removed between the start of the foreach and us actually using it; but as we use TryGetValue that doesn’t matter – the value just won’t resolve. The key here (pardon the pun) is that we are building and returning a list that *makes assumptions about the contents of the dictionary*. Even if in our consuming code we stick to TryGetValue to handle items being deleted, there’s nothing in this example preventing another thread changing any of the items to be a different type – effectively rendering our List of “Keys to process” completely invalid.

Conclusion

The examples above are very contrived, and I’d hope nobody would ever write those exact pieces of code; but hopefully it illustrates the point that *just because you are working with a “Thread safe” object doesn’t mean you can ignore thread safety concerns in your own code*.

Introduction

A pet project I’m currently working on requires the use of an internal Dictionary to store “registered” data, which is a pretty common requirement. For this particular project I’d like to at least *attempt* to make it “thread safe” on .NET 3.5, with an eye to moving it to the ConcurrentDictionary in .NET 4 which promises not only thread safety, but more granular locking to increase multi-threaded performance.

A simple enough task, but one that I’ve seen many people make mistakes implementing.

Just Locking Writes?

It’s obvious we need to do some kind of syncronisation primitive around our writes, but first impressions might make you think that read should be ok – especially if we stick to the preferred TryGetValue pattern instead of “if it exists then get the value”:

object myValue;

// This is obviously not thread safe.
// Something else can alter the collection
// between ContainsKey and reading the
// value.
if (dictionary.ContainsKey("Testing"))
{     myValue = dictionary["Testing"];
}

// Using TryGetValue looks safe though?
// Doesn't it?!
if (!dictionary.TryGetValue("Testing", out myValue))     throw new KeyNotFoundException();

Unfortunately if we fire up Reflector, and take a look at how TryGetValue is implemented, it’s pretty obvious it has exactly the same concurrency problem as the first method above:

public bool TryGetValue(TKey key, out TValue value)
{
    int index = this.FindEntry(key);
    if (index >= 0)
    {
        value = this.entries[index].value;
        return true;
    }
    value = default(TValue);
    return false;
}

Ok, So I Will Lock Reads and Writes?

The next obvious approach would be to find everywhere in our code where we access the Dictionary, for either reading or writing, and use a syncronisation primitive, such as lock, to ensure we’re only accessing it from a single thread at any one time:

private readonly object padlock = new object();
private readonly Dictionary<string, object> dictionary = new Dictionary<string, object>();

private void Test()
{
    object myValue;

    // Now we lock before we do anything
    lock (padlock)
    {
        if (dictionary.ContainsKey("Testing"))
        {
            myValue = dictionary["Testing"];
        }
    }

    lock (padlock)
    {
        if (!dictionary.TryGetValue("Testing", out myValue))
            throw new KeyNotFoundException();
    }
}

Simple enough, but you’re relying on locking around every access, which is not only ugly, but also potentially prone to errors if you miss one. Also, once we move our code to .NET 4, and the new ConcurrentDictionary, we will have to go through the code and remove each lock in turn – pretty laborious!

Composition, Composition, Composition!

In this approach we wrap our nasty non-thread safe dictionary in our own class, expose the methods we want to use, and take any locks accordingly. This class only implements “array” access and TryGetValue, but is sufficient to show the approach:

public class SafeDictionary<TKey, TValue>
{
    private readonly object _Padlock = new object();
    private readonly Dictionary<TKey, TValue> _Dictionary = new Dictionary<TKey, TValue>();

    public TValue this[TKey key]
    {
        get
        {
            lock (_Padlock)
            {
                return _Dictionary[key];
            }
        }
        set
        {
            lock (_Padlock)
            {
                _Dictionary[key] = value;
            }
        }
    }

    public bool TryGetValue(TKey key, out TValue value)
    {
        lock (_Padlock)
        {
            return _Dictionary.TryGetValue(key, out value);
        }
    }
}

As we prevent any direct access to the Dictionary, and use our lock internally whenever we need to access it, we can now use our SafeDictionary in code without worrying about concurrency issues – both for reading and for writing!

To .Net 4 ?

As I mentioned earlier .Net 4 will be shipping with several “thread safe” collections, including a dictionary, in the new System.Collections.Concurrent namespace. As we have our own SafeDictionary implementation we have a few options here:

• We could go through our code and replace all references to SafeDictionary with ConcurrentDictionary. We don’t have any locks in our main code so we could do this with a direct replacement.
• We could alter our SafeDictionary to use a ConcurrentDictionary internally, and remove all of our internal locks.
• If we don’t mind exposing extra methods we can remove all of the implementation from SafeDictionary and just derive it from ConcurrentDictionary:

public class SafeDictionary<Tkey, TValue> : ConcurrentDictionary<Tkey, TValue>
{
}

Conclusion

Quite a long blog post for quite a simple issue, but even simple concurrency can be the source of mistakes and headaches. Once .NET 4 arrives with its concurrent collections, parallel extensions and parallel debugging options hopefully at least *some* of this headache will go away.

Introduction

Hotwire is a project I started some time ago but never completed. It was designed to be a “quick launch” utility for remote controlling machines using the excellent LogMeIn service. While the better half was “enjoying” the Boxing Day sales I took it upon myself to finish the project. And by finish, I obviously mean a complete rewrite

What does it do?

I’ve used LogMeIn for quite a while now, and it’s an excellent service, but 99% of the time I just want to get straight to the desktop of the machine I’m connecting to and Hotwire is designed to let me do just that.

The application itself is written using WPF and consists of two parts; the launcher, which sits in the task tray, and the main application. The launcher provides machine configuration and quick launch options for connecting to remote machines. The main application is just a single window (containing a WPF WebBrowser control) that connects to LogMeIn and does some jiggery pokery to get you directly to your machine desktop.

More Information

The project is up on Google Code at http://code.google.com/p/hotwire/ – I normally prefer to use CodePlex, but the Hotwire name was already taken The Google code site contains a downloadable installer, and the source code should anyone be interested.

Screenshots

One of the most bizarre limitation of the WPF RichTextBox is its hit and miss support for subscript and superscript in text. Although you can set the style quite easily using appropriate command, in order for this property to actually alter the appearance of the text the font needs to be OpenType, and come with a Subscript/Superscript variant, which the vast majority of fonts do not. Obviously in a control that’s designed for user input, restricting what fonts can be used in this way is far from ideal.

An Alternative Approach

Having spent some time poking around inside RichTextBox I would strongly recommend that you don’t. Seriously. The code may well make you physically sick. In the past I have tried to use TextRange.ApplyPropertyValue, which takes a normal DependencyProperty, to attach my own property to a piece of text. You’d imagine this would be pretty straightforward, especially as attaching properties to other types is a fairly fundamental part of WPF, but unfortunately there’s a particularly lovely piece of code that checks to see if the DependencyProperty is on a predefined “allowed” list, and thows an exception if it isn’t. While this chunk of code scuppered my ideas in the past, it did provide a useful place to look for an alternative way to create Subscript and Superscript text.

One of the properties that we are “allowed” to apply to text is Inline.BaselineAlignmentProperty which takes its values from the BaselineAlignment enumeration which includes the following values:

• Top
  A baseline that is aligned to the upper edge of the containing box.
• Center
  A baseline that is aligned to the center of the containing box.
• Bottom
  A baseline that is aligned at the lower edge of the containing box.
• Baseline
  A baseline that is aligned at the actual baseline of the containing box.
• TextTop
  A baseline that is aligned at the upper edge of the text baseline.
• TextBottom
  A baseline that is aligned at the lower edge of the text baseline.
• Subscript
  A baseline that is aligned at the subscript position of the containing box.
• Superscript
  A baseline that is aligned at the superscript position of the containing box.

Subscript and Superscript look exactly like what we want, and amazingly, they actually work To demonstrate the technique I’ve created two simple extension methods that toggle either Sub or Superscript on the selected text:

/// <summary>
/// Toggle Superscript for the currently selected text in a RichTextBox. Does not require the font to be OpenType or have a Superscript font style.
/// 
/// Doesn't attempt to change/restore the size of the font, just moves the baseline.
/// </summary>
/// <param name="richTextBox">RichTextBox with selected text</param>
public static void ToggleSelectionSuperscript(this RichTextBox richTextBox)
{
    var currentAlignment = richTextBox.Selection.GetPropertyValue(Inline.BaselineAlignmentProperty);

    BaselineAlignment newAlignment = ((BaselineAlignment)currentAlignment == BaselineAlignment.Superscript) ? BaselineAlignment.Baseline : BaselineAlignment.Superscript;
    richTextBox.Selection.ApplyPropertyValue(Inline.BaselineAlignmentProperty, newAlignment);
}

The code checks the current value of the BaselineAlignmentProperty and toggles the value as appropriate. I’ve made no attempt to adjust font size, or do anything clever, so it does look a little goofy, but it proves the concept. The demo application also includes the XAML content of the RichTextBox document so you can see exactly what content it’s producing:

And that’s that, hope it helps someone out You can grab the sample demo from the link below:

RichTextBoxSubSuperscript.zip

Localisation is something everyone should really care about. Creating your applications, or websites, in a manner that can be easily localised for different languages and cultures is not only “good practice”, but it may also provide additional opportunities.

Luckily the .NET framework, and WPF, has rich support for localisation, with WPF even having “baked in” support for switching flow direction for right to left languages. On top of that Rick Strahl and Michele Leroux Bustamante compiled an excellent guidance document detailing several technique for localising WPF applications. The documentation, along with sample code, can be found in the WPF Localisation Guidance project on CodePlex.

The document discusses several techniques for localising applications using RESX (resource) files, which is my preferred approach; but each of the techniques has its drawbacks:

• Static Binding. Simple and easy, but lacks support for dynamically switching culture.
• Attached Properties. Look powerful, but lacks support for value convertors and it’s a bit inefficient.
• Markup Extension. A new instance of the helper (complete with event wireup for locale switching) is created for every control, which doesn’t sound ideal and may lead to memory leaks.

All of the techniques are perfectly workable solutions, but with Binding and INotifyPropertyChanged WPF already contains a powerful mechanism for mapping and automatically updating UI elements with data; surely there’s some way we can leverage those? My goal was to attempt to find a way to localise an application with the following criteria:

• Use the standard Binding syntax so we can support value convertors.
• No complicated markup extensions.
• Provide a mechanism for code to “register” resources that can be consumed anywhere in the application, even from other PRISM modules.
• Be able to cleanly switch locales, without restarting the application or closing/reopening screens.
• Support the design experience with a minimum of fall back values when in design mode.

The Result – Localisation Using Binding

If you just want to see the code, there’s a basic implementation, and a PRISM demonstration, at the end of the article. Both implementations use the same basic “moving parts”:

LocalisationHelper

In essence this is our ViewModel. There are two key pieces of code here, first being:

public string this[string Key]
{
    get
    {
        if (!validKey(Key))
            throw new ArgumentException(@"Key is not in the valid [ManagerName].[ResourceKey] format");

        if (DesignHelpers.IsInDesignModeStatic)
            throw new Exception("Design mode is not supported");

        return _resourceManager.GetResourceString(GetManagerKey(Key), GetResourceKey(Key));
    }
}

This allows us to bind elements to the LocalisationHelper and provide a “key” which will be used to lookup the correct resource manager and resource string. Our binding uses a little known syntax that looks like this (take note of the initial “.”):

{Binding Path=.[MyResourceManager.MyResourceString]}

To provide design support we throw an exception if we detect design mode (using code from Laurent Bugnion’s MVVM Light Toolkit) so the FallbackValue can be used instead. I’m not too keep on throwing an exception, but I couldn’t see a cleaner way to “fail” the binding.

The other important code hooks an event that fires when the locale changes, and fires a NotifyPropertyChangedEvent with an empty property string. This triggers a refresh for all controls that have bindings to the LocalisationHelper.

ResourceManagerService

The ResourceManagerService provides several functions:

• The ability to register ResourceManagers – these are automatically generated by Visual Studio when you create RESX files and are used to load the locale specific strings.
• Retrieve a resource string from a given ResourceManager.
• Get and set the current locale. A locale consists of an IETF language tag (such as en-GB) and a boolean to indicate whether the locale uses a right to left flow direction.
• A event that is fired when the locale changes. This is hooked by the LocalisationHelper, for firing PropertyChanged events, and also by the main Window which uses the right to left flag to set the flow direction.

Give Me The Code Already!

There are two samples attached. The first is a simple application that uses a static ResourceManagerService that shows the basic implementation. The second is a PRISM based application that uses the container/service locator, EventAggregator, weak references, and several different modules to give a more “advanced” example.

ResourceTest.zip

PRISMResourceTest.zip

Conclusion

I haven’t yet used this solution in anger, but it certainly seems to “tick all the boxes” from my initial requirements. Comments, suggestions, criticisms and flames are welcomed

Consider the following simple class for managing storage and retrieval of custom classes in the Windows Clipboard using WPF:

using System;
using System.Windows;

namespace ClipboardTest.Services
{
    public class ClipboardService : IClipboardService
    {
        public bool ContainsData<T>() where T:class
        {
            return Clipboard.ContainsData(typeof(T).ToString());
        }

        public void SetData<T>(T data) where T:class
        {
            Clipboard.SetData(typeof(T).ToString(), data);
        }

        public T GetData<T>() where T : class
        {
            return Clipboard.GetData(typeof(T).ToString()) as T;
        }
    }
}

Simple stuff, but it lets me abstract the clipboard away and remove the usual “magic string” approach for clipboard types.

Now consider the following basic tests:

using ClipboardTest.Services;
using Microsoft.VisualStudio.TestTools.UnitTesting;

namespace ClipboardTest.Test.Services
{
    public class TestPayload
    {
        public string Data { get; set; }
    }

    [TestClass]
    public class ClipboardServiceTests
    {
        [TestMethod]
        public void SetData_CustomClass_ClipboardContainsInstanceOfClass()
        {
            string data = @"More Cowbell";
            var clipboardService = new ClipboardService();

            clipboardService.SetData<TestPayload>(new TestPayload() { Data = data });

            Assert.IsTrue(clipboardService.ContainsData<TestPayload>());
        }

        [TestMethod]
        public void SetDataGetData_CustomClass_ReturnsEquivilantClass()
        {
            string data = @"More Cowbell";
            var clipboardService = new ClipboardService();

            clipboardService.SetData<TestPayload>(new TestPayload() { Data = data });
            var output = clipboardService.GetData<TestPayload>();

            Assert.IsNotNull(output);
            Assert.AreEqual(data, output.Data);
        }
    }
}

Again, all very simple. The first test checks to make sure that the class gets stored onto the clipboard, and the second checks to see if the class we get back off the clipboard is the same as the one we put in.

The more astute among you have probably spotted the problem in the test code already, but the resultant symptoms are a little confusing.

System.OutOfMemoryException?

When we run the tests the first test runs absolutely fine, but the second test crashes out with a System.OutOfMemoryException. A bit more digging showed that storing and retrieving standard types such as strings, ints etc all worked fine, but my own class was throwing an exception.

Checking good old MSDN threw up the following statement:

An object must be serializable for it to be put on the Clipboard.

Seeing as I had stupidly forgotten to add the SerializableAttribute to the TestPayload class that definitely explained why things weren’t working as I expected; but it didn’t really explain the actual behaviour I was seeing. Another quote from MSDN, but from the WinForms documentation, stated:

If you pass a non-serializable object to a Clipboard method, the method will fail without throwing an exception.

So from that I would expect SetData to silently fail, and for nothing to be on the clipboard. However the first test above clearly shows that the clipboard at least thinks that something of our specified type has been added to the clipboard – it just throws an exception when we try and retrieve it again. Marking the payload class as serializable did fix the issue, but the behaviour I was seeing certainly didn’t make that obvious!

Just out of interest I tested the same code using the WinForms Clipboard class, which looks to all intents and purposes exactly the same as the WPF one, and that did fail silently and returned null from GetData.

Conclusion

So, after all that rambling, the conclusion is that if you are working with the Clipboard in WPF and you are getting System.OutOfMemoryExceptions that don’t seem to make any sense, then you’ve probably forgotten to add the SerializableAttribute to whatever class you placed on the Clipboard.

Yesterday I was working on a small prototype, which I will be blogging about shortly, and ran across the common problem of my bindings not updating. A very common problem, and one that’s usually a very simple fix once you’ve tracked it down.

Yes, I’m an Idiot!

Normally my ViewModels inherit from my ViewModelBase base class, which provides a RaisePropertyChanged method and, when in debug mode, uses reflection to check if the property name is valid. Now I’d recently refactored the code so this particular ViewModel wasn’t using the base class, so my first instinct was that I’d simply mistyped the property name magic string in the event – but that was all fine.

I threw in a few breakpoints and I could see my ViewModel was changing, I could see the OnPropertyChanged method being hit, but there didn’t seem to be any listeners and as a result my UI was just ignoring the changes.

After a few minutes of head scratching I noticed that although my class was firing the PropertyChanged event correctly, I hadn’t added INotifyPropertyChanged to my class declaration when I removed the base class! So although I was firing an event that looked like INotifyPropertyChanged.PropertyChanged, I was actually just firing my own event with the same name

Conclusion

So there you have it, I’m an idiot The moral of the story is, when your bindings aren’t working check the obvious:

1. The property name is correct. A base class that checks this in debug mode can be useful, or failing that, watch the Output window.
2. Check you are actually implementing INotifyPropertyChanged and not just firing events that happen to have the same name

This morning I was taking a look at the new (ish) meta stackoverflow site, and noticed a thread asking “Can we get flare as an image?”. It seemed like a good idea, especially for forum signatures and the like, so I thought that seeing as I’d recently updated the WordPress widget, that I’d try and put something together.

Pretty as a Picture (or not)

As C# is generally my weapon of choice these days, I was originally going to knock something together in ASP.Net. I was thinking something along the lines of rending a WPF control to a bitmap, and emitting that as an image. I decided against that approach because:

1. ASP.Net hosting is generally more expensive – most people I know seem to stick to *nix hosting.
2. Rendering WPF to a bitmap doesn’t work in partial trust scenarios; so it might not even work on ASP.Net hosting anyway.

So, feeling in a masochistic mood, I thought I’d knock something together in lovely old PHP; the results of which look something like this:

Or, by passing in a userid on the querystring:

You can test  it with your own details by changing the userid on the following url:

https://www.grumpydev.com/imageFlair/imageFlair.php?userid=1

Images are cached (for 30minutes by default) and all of the StackOverflow data is taken from the JSON feed, so the strain on SO should be fairly minimal.

The Code

You can use the script hosted on here if you want (although I might have to change my mind on that if the load gets too high), or you can download the code and run it on your own box:

https://www.grumpydev.com/imageFlair.zip

Although it will run just fine “out of the box”, the code is pretty flexible; with plenty of configurable options for fonts, colours, positioning, background images, caching time etc. Take a look in config.php and you’ll hopefully find you can change everything you want to without having to delve into the main code.

Bear in mind that I am far from a PHP expert, and this was put together in a few hours, so please don’t laugh too much if you do take a peek at the source

Font Support / Licensing

The text is rendered to the bitmap using a TrueType font of your choosing, which gives us some nice flexibility. Unfortunately though, none of the fonts that we generally take for granted, such as Arial, Verdana etc. come with any distribution rights; so I can’t include any in the source archive. This might not be a problem if you already have your favourite TrueType fonts installed; but if you don’t you can get a “free” version of several core fonts from http://sourceforge.net/projects/corefonts. You just need to extract the archives using WinRAR, or 7zip, or something of that ilk; then just drop the TTF file into the source code directory.

That’s it – hope someone finds it useful

Update – Bug Fixes and Pretty URLs

After some feedback from the meta question I’ve fixed a stupid bug in the gravatar code, so now it should work for people who have a 1 in their gravatar hash (don’t ask! :-)).

I’ve also enabled “pretty urls” on the hosted version, so now you can go to a url like:

https://www.grumpydev.com/imageFlair/658.png

And you’ll get the PNG for the corresponding userid. I do intend to expand it to include Flair for the other sites in the “Stack Overflow” family, but I haven’t had chance yet.

For those that are interested, this is the .htaccess file that enables the pretty urls, and also reduces the cache time on pngs to 1 second:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^(.*)\.png$ imageFlair.php?userid=$1 [L]
</IfModule>

<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/png "access plus 1 seconds"
</IfModule>

Update 2 – Supporting the Whole Family

I’ve added an optional parameter to specify which site’s information to display. The “pretty” url format now looks like this:

http://[ur]/[mode]/[id].png

Where [mode] is one of:

• so – Stack Overflow
• meta – Meta Stack Overflow
• sf – Server Fault
• su – Super User (although this isn’t live yet)

So for Jeff (id number 1 everywhere is easy :-)) we end up with:

The htaccess file now looks like this:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^(.*)/(.*)\.png imageFlair.php?mode=$1&userid=$2 [L]
RewriteRule ^(.*)\.png$ imageFlair.php?userid=$1 [L]
</IfModule>

<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/png "access plus 1 seconds"
</IfModule>

Source ZIP is updated with all the latest changes. Hopefully that will be it for the time being!

Just a quick post to say I’ve updated my Stack Overflow WordPress Widget to implement some basic caching. I’m still in the process of converting it to the new JSON service that SO have provided; but in the meantime this should cut down on the amount of traffic it uses.

You should be able to upgrade straight from the admin section of your blog; but you can also grab it from the WordPress Plugin Directory.

The cache time is configurable in the widget settings, and defaults to 30minutes. It attempts to locate your temp directory, then creates a unique filename cache in there; so there’s no need to chmod a cache file to get it to work.

I’ll hopefully get a JSON version working in the next few days, but if anyone has any problems feel free to give me a shout from the contact page.

Update: It seems the JSON version was easier than I thought I’ve uploaded v2.0.0 that still includes the caching changes, but also uses the “official” JSON feed. If you have already used the cached version you might might need to delete the cache file to make it re-download the raw data.

The only “downside” to the JSON version is it requires json_decode, so you must have PHP 5.2.0 or above. If you can’t satisfy this requirement then you’ll be better off with the previous version.