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

Technorati Tags: competition, masterclass, NxtGenUG, Silverlight, silverlight tour, training

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!

Technorati Tags: c#, c#4, csharp, csharp4, il, ildasm, named parameters, optional parameters, quirks, vs2010

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

Technorati Tags: iPhone, MonoTouch, service location, sockets, udp

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.

Technorati Tags: csharp, event aggregator, TinyIoC, TinyMessenger

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.

Technorati Tags: add reference dialog, rant, Visual Studio, vs2010

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!

Technorati Tags: csharp, debugging, MonoTouch, testing, TinyIoC, unit testing

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,

Technorati Tags: csharp, dependency injection, di, inversion of control, ioc, TinyIoC

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.

Technorati Tags: convert, hg, history, Mercurial, subversion, svn

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*.

Technorati Tags: concurrency, concurrentdictionary, csharp, dictionary, locks

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.

Technorati Tags: concurrency, concurrentdictionary, csharp, dictionary, locks

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

Technorati Tags: googlecode, Hotwire, logmein, WPF

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

Technorati Tags: opentype, richtextbox, workaround, WPF

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

Technorati Tags: localisation, localization, resourcemanager, resx, WPF

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.

Technorati Tags: clipboard, OutOfMemoryException, System.OutOfMemoryException, WPF

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

Technorati Tags: binding, inotifypropertychanged, Silverlight, WPF

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:

http://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:

http://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:

http://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!

Technorati Tags: flair, php, stack overflow

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.

Technorati Tags: stack overflow, widget, wordpress

PRISM, or Composite Application Guidance/Library for WPF/Silverlight, is a library and a corresponding guidance document that helps you to build loosely coupled “composite” WPF and Silverlight applications.

The library itself “sits on top” of an Inversion of Control Container (Unity by default), and provides facilities for modularising your application, composing your UI from components, loosely coupling events and, in Silverlight’s case, only downloading parts of your application as and when they’re required.

Sounds great doesn’t it?

So, There Must Be Something Wrong With It.. Right?

Plenty has been written about PRISM, its benefits, and how to get started; but very little on why you wouldn’t use it on your next WPF/Silverlight project. I’ve put together some concerns, based both on criticisms I’ve read, and supposition on my part; and some commentary about whether I believe those concerns are well founded or not.

“I’m Only Doing a Small Project!”

Granted, PRISM is rather overkill for “toy” applications; but are you sure your application is always going to stay that small and simple? One of the big advantages of the modular nature of a PRISM app is being able to add and test new features with relative ease. I’m sure we’ve all started projects that started off as a simple little toy app, but have since grown organically into something rather more complex – possibly ending up with some pretty kludgey code at the end of it.

“It’s Complicated!”

No; it’s not. Really. There’s nothing particularly complex in PRISM, either conceptually or in the code you have to write. Once you understand the structure of a PRISM project, you’ll probably find that your code is actually easier to follow, as it is separated into clearly defined parts.

If you want an easy to follow tutorial that takes you from File.. New, through to a working application, then take a look at the excellent screencasts from Blaine Wastell’s blog.

“It Takes Too Long To Use! There’s Too Much Overhead!”

If you’ve watched some of the initial screencasts about PRISM, or had a peak at some sample code, you might be thinking that the overhead of creating all these “extra” classes and projects is just too much. While it certainly is more work than just File.. New and throwing controls on a page; once your initial project structure and bootstrapper is setup, adding new modules is no more time consuming than adding a normal User Control.

Separating your view from it’s logic; whether it be with ViewModels, the Presentation Model, or any other pattern, is going to be slightly more work; but the testability and data binding benefits far outweigh any slight increase in typing!

“It Will Add Bloat to My Silverlight App!”

The PRISM binaries, including Unity, weigh in at around 270k; and squeeze down to approximately 100k when zipped. Not exactly tiny, but not exactly Bloaty McBloater. In fact, if you take advantage of PRISM’s ability to bundle parts of your Silverlight application into different XAP files, and only load them when needed, you may find your initial payload is actually smaller than it would be without PRISM.

“You Have To Use Unity! I Don’t Want That Dependency!”

I’ve seen this repeated several times, but it’s simply not true. Although PRISM “out of the box” uses Unity, and comes with a Unity Bootstrapper; you can plug in your own IoC container without too much trouble. At the time of writing I believe there are alternatives for Spring.Net, Castle Windsor and StructureMap already written for you.

“I Want Control Over *ALL* My Damn Code!”

Firstly, if you’re writing a .Net application then chances are you are calling at least one library that you didn’t write Secondly, PRISM is very “lightweight”. It’s a helping hand at your disposal, rather than a monolithic framework that takes over your whole application and forces you to work in a certain way. Thirdly, you can just pick and choose which parts of PRISM you want to use, it’s not an “all or nothing” proposition. Don’t like the view composition? Then don’t use it! And finally, it’s all open source, so if you don’t like the way something works – change it!

“It’s From MS – So It Sucks!”

Unfortunately if someone holds this view, then there’s probably nothing anyone can say to change their mind. While everything that comes out of Microsoft isn’t perfect, far from it, it most certainly doesn’t all suck

With PRISM, the exceedingly smart guys from the Patterns and Practices team have created an excellent set of tools and guidance to help solve some very common problems; without producing a heavy, complicated framework in the process (CAB anyone? )

“I Can’t Frikkin’ Find It!”

Ok, I admit it, you’ve got me on this one! Is it on MSDN? Is it on CodePlex? Both?! Is it called PRISM? The Composite Application Library (CAL)? Or maybe Composite Application Guidance for WPF and Silverlight (CAG)?

Now CAL obviously refers to the library, CAG to the guidance, and I believe PRISM is an umbrella term for the whole project, but the naming is certainly confusing, and searching for PRISM takes you to CodePlex then MSDN and back again, so it’s very easy to get confused! In fact, finding, downloading and building the library is actually MORE confusing than using the damn thing! There is actually a whole article on Sparking Client on How to Find, Download and Build Prism for Silverlight, which speaks volumes

I really don’t see what’s wrong with calling the whole thing PRISM and leaving it at that. If I say  “.Net Framework”, then most developers would know what I mean. There’s certainly no need for me to call it the “Microsoft Framework for Building Managed Applications Targeting the Windows Platform (MFBMATWP)”

Tell Me More!

If you want to know more about PRISM, or if you want some walkthroughs and examples of how to use it, then here’s some links that should float your boat:

• The MSDN section covers the goals and architecture of PRISM, along with some hands on examples and labs.
• Shawn Wildermuth’s recent article from MSDN Magazine, entitled Composite Web Apps With Prism, contains a good intro to Prism, and a walkthrough on putting together a Composite Silverlight app.
• Blaine Wastell has plenty of PRISM resources on his blog, including links to the excellent “getting started” screencasts from Channel 9.
• Ward Bell did an excellent video introduction to PRISM at Tech-Ed and it’s available from IdeaBlade.
• Brian Noyes did some DNRTV episodes showing PRISM basics, and PRISM Events and Commands
• There’s some good introductory information on the Sparkling Client blog, including how to download and install it
• There are some interesting additions to PRISM on the contrib Codeplex site.
• Ward Bell has an interesting article on his blog, in a similar vein to this one, where he asks Are We Overselling Prism?
• There’s a list of 10 Things To Know About Silverlight Prism on the Sparkling Client blog.

Technorati Tags: Composite Application Guidance, Composite Application Library, PRISM, Silverlight, WPF

Although you’ve been able to sync your Google Calendar with your iPhone for some time using ActiveSync, there is a limitation whereby you can only add a single ActiveSync account at one time. This isn’t a problem for most people, but if you happen to use ActiveSync for your work email, then it becomes a bit of an issue.

Enter CalDAV

One of the new features of the 3.0 firmware is the ability to add a CalDAV calendar, which it just so happens that Google Calendar also supports.

Adding your calendar to the phone is very simple:

1. Go into “Settings”, “Mail, Contacts, Calendars”
2. Choose “Add Account…”
3. Select “Other” for the account type
4. Under “Calendars” choose “Add CalDAV Account”
5. For “Server” you need to put “https://www.google.com/calendar/dav/YOUREMAIL@DOMAIN.COM/user” (obviously replacing the YOUREMAIL@DOMAIN.COM!)
6. “Username” and “Password” are your normal Google account details and “Description” is whatever you want it to be.
7. Press Next, you will see an error stating that the CalDAV account could not be verified, but this doesn’t appear to actually be a problem.
8. All done!

Now you should see your Google calendar in the Calendar app on the iPhone, and you should see it as an option when creating a new appointment. If you go back into “Settings”, “Mail, Contacts, Calendars” you can also set the Google calendar to be your default.

Technorati Tags: caldav, google calendar, iPhone, sync

This is a follow up post to Surface SDK on Vista x64 where we got the original Surface SDK working on the unsupported Vista X64. Last week Microsoft released Service Pack 1 of the SDK and there is an additional tweak that we need to get it going.

The original post was split into 3 sections:

1. Patch the MSI and install
2. Patch the Simulator and other files
3. Configure our projects

Steps 2 and 3 haven’t changed with SP1 (we don’t need to “corflags” the new “stress” tool as it connects to the simulator rather than launching it), so jump over to the original post when you’ve got the SDK installed.

Prerequisites

• Surface SDK SP1 (duh!)
• Visual Studio 2008 (for corflags)
• Orca (part of the Windows SDK or just search for it)
• Administrator access to the Vista or Win7 box you’re installing onto.

Step 1 – The MSI

Firstly we need to use Orca to tweak the launch conditions of the MSI. Make sure you’ve installed all of the SDK pre-requisites first, then walk through the following:

1. Install Orca (link above, or just search for it).
2. Copy the SurfaceSDKWE.msi to somewhere on your hard disk, and make sure that it’s not Read Only.
3. Right click on the MSI and choose Edit with Orca. This will trigger a UAC, but it’s software from Microsoft, so you should be ok to trust it
4. Select “LaunchCondition” in the left hand list, then select “Install OR NOT VersionNT64″ in the right hand list (see below).
   
5. Press delete and click OK when asked to confirm the row delete.

This is where we got to with the original SDK, but the SP1 install will still fail if we leave it like that. As part of SP1 Microsoft has added automatic updates and automatic error reporting. Unfortunately the exe they call as a custom action doesn’t work on x64 (it looks like it puts registry entries in the wrong place), which causes the install to fail. We could extract the MSI, patch the custom exe with corflags and then run setup, but we won’t do that because:

a) We don’t want automatic updates as they will overwrite our nicely patched exes, and
b) x64 is not a supported platform, so I’m sure Microsoft aren’t particularly interested in error reports!

Instead of that we can just continue with Orca to remove those commands from the installer:

1. From Orca, select “InstallExecuteSequence” in the list on the left and remove SetCreateSqmMachineGuid and CreateSqmMachineGuid as before:
2. Click Save on the toolbar

Now you can quit Orca and run the msi, which should install just fine. Make sure you also switch off automatic updates and error reporting as follows:

Now the SDK is installed, head over to the original post and follow steps 2 and 3 and you’re all done.

Thanks to JamesK for his workaround comment on the original post.

Update: thanks to Michael Zervos for letting me know that the academic version of the SDK comes in EXE, rather than MSI form. As he points out on his blog, if you keep an eye on your %temp% directory when you run the EXE it will extract the MSI for you to copy and patch.

Update again: Thanks to Robin Sanner for providing details on getting the samples to work:

To get the samples to build and install correctly do the following:

- Edit the configuration properties for the sample solution and create an x86 platform for all projects.
- Edit InstallSamples.bat
- Comment out the lines on either side of the set as follows:

::FOR /F “eol=H tokens=2*” %%A IN (‘REG QUERY HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Surface\v1.0 /v IsLogicalSurfaceUnit’) DO SET LogicalTableValue=%%B
SET InstallingOnTable=false
::IF %LogicalTableValue%==0×1 SET InstallingOnTable=true

- Change the MSBuildParameters to reference the x86 PlatformName as follows:

SET MSBuildParameters=/p:Configuration=Release;PlatformName=x86 /noconsolelogger /fl /fileLoggerParameters:LogFile=%LogFile%;Append /nologo

Technorati Tags: sdk, Surface, vista, Win7, Windows 7, workaround, x64

Anyone that blogs should be using Live Writer, end of discussion. It’s brilliant in its own right (and surprisingly doesn’t just support Windows Live blogs!) and its various plugins just make life so much better for bloggers.

One of the features it has, which I’ve always found a little limiting, is the ability to save local drafts. These drafts are saved into your local Documents folder, which is fine if you blog from a single machine, but if you chop and change machines as often as you change your socks like I do, then it’s not a whole lot of use. Admittedly it does give you the option of saving drafts to your blog (with WordPress at least), but I don’t particularly want ALL my inane nonsense cluttering my blog drafts

Asking The Question

I asked Joe Cheng, one of the Live Writer developers, on Twitter about whether changing the default location was possible. Unfortunately it’s one of those features that’s “on the list” for the next major version, but not implemented this release. Jason Burns was kind enough to point out a solution using Live Mesh, which works a treat; but DropBox is my “cloud storage of choice”, and one of the first things I install on any machine, so I hacked together my own solution.

The Solution / Workaround / Bodge

One of features of NTFS, which isn’t widely used, is the ability to create “junction points”. Junction Points are very similar to symbolic links in the UNIX world – they create a file or folder that “maps” to another file or folder; so when I go to c:\myfakefolder I can actually be looking at files in c:\myrealfolder. They’re not used all that often because Shortcuts generally do a good enough job for linking one place to another; but in this scenario Shortcuts don’t cut the mustard (Live Writer will just ignore it and create its folder again), so a junction point it is!

First things first we need to copy or create the “My Weblog Posts” directory in our Dropbox, which you can just do with Explorer, then delete the original from our Document folder. You might want to back it up in case this goes horribly wrong

Next we need to create our junction point, which is easy in Vista and Win7, as they both come with utilities to manage them, but for XP or Windows 2000 you will have to download a SysInternals utility called Junction from Technet. The syntax for the two methods is slightly different, but the basic concept is the same. We tell the utility the location of the link we want to create (which will be <your documents directory>\My Weblog Posts) and where to point it to (which will be <your dropbox directory>\My Weblog Posts). E.g.:

Vista / Win7

mklink /D "%UserProfile%\Documents\My Weblog Posts" "%UserProfile%\Documents\My Dropbox\My Weblog Posts"

WinXP / Win2k

junction "%UserProfile%\My Documents\My Weblog Posts" "%UserProfile%\My Documents\My Dropbox\My Weblog Posts"

And that should be that. If you copied existing drafts to your Dropbox you should be able to see them from the Open dialog. There does appear to be a small bug in Live Writer whereby it doesn’t show you the drafts in the shortcut list on the right hand side until you’ve actually saved a draft; but you can access them just fine from the Open menu, and they’ll magically appear once you’ve saved a draft for the first time.

I worked on this post using this workaround on two different machines, so it does seem to work nicely; but as with all workarounds, please make sure you back everything up just in case!

*Update*

If you don’t want to type these commands in manually then Will Charles has created a useful little GUI utility to take some of the pain away. You can grab it over on his blog.

Technorati Tags: drafts, dropbox, live writer, sync

I’ve been chatting to the guys that run the NxtGenUG .Net user group for a few months about the possibility of giving some “NxtGen love” to “us northerners”, and as of this morning Manchester is now officially the 7th region!

In the words of El Presidente Richard Costall:

“NxtGenUG is about bridging the gap between Microsoft and the developer. The waves of technology emerging from Microsoft is relentless, developers are under more pressure to deliver software and also understand these new technologies.”

We’ll be kicking off in May with a main speaker still to be confirmed, so if you’re in the area then please feel free to sign up, or spread the word to anyone you think might be interested. There will be an event running on the 3rd Wednesday of each month, diaries permitting, keep an eye on the main NxtGenUG page for more news.

Big thanks to Dave McMahon, Richard Costall and John Price for their invaluable help in getting this off the ground, and no, despite the date, this isn’t an April Fool!

Technorati Tags: manchester, NxtGenUG, user group

While we were putting together Finguistics down at Microsoft in Reading, Nick Page was filming mini-interviews about the project, the process and Surface development in general; the result of which has just been released on YouTube.

The Video

The video has a definite “design” slant, so isn’t very technical, which is understandable given the nature of Surface development (designing the apps and the user interaction is FAR harder than actually coding them). Myself, Marc and the other techies do try to throw some technical jibber jabber in there to counter act all the design speak though, so it’s not all crayons and paintbrushes!

I’d like to also point out that I wasn’t told we were going to be filmed, so I didn’t get chance to do my hair OR my makeup, and I had been eating on expenses for 3 weeks at this point, and the camera adds a least half a stone.. and.. and..

Technorati Tags: Finguistics, Surface, video, youtube

At Lightbox we use an excellent program called FinalBuilder for automating all of our builds, and managing the configuration for the various environments we build to (system test, user acceptance testing, production etc.) It’s a very powerful tool and our “scripts” allow us to produce and deploy a build from a particular branch/tag in Subversion, targeting a particular configuration, with the touch of a button.

Once you get used to putting the projects together, using FinalBuilder is a huge time saver. One of the features it gives you is the ability to substitute “tags” in a file with the corresponding value from a project variable; so for example you could substitute %ServerName% for the variable called ServerName in the project. While this is very useful, it does require several steps to set it up each variable:

• Create the configuration file (or template) containing the %VARIABLE% tag.
• Add the corresponding variable name to an INI file (FinalBuilder had native support for INI files).
• Add the variable to the project.
• Configure the project to load that variable from the INI file.
• Add the build command to do the substitution (obviously you will usually do this once for all the variables).

While none of those tasks are particularly onerous, it is quite error prone when you are relying on your developers to perform each task, and does make writing “generic” scripts quite tricky. You may not even want your developers meddling with your build process in the first place!

Substitute Utility

As an attempt to get the same level of functionality as the FinalBuilder substitution, but without the extra steps, I put together a small utility that takes an input file, a “substitute” file to be processed and a series of “sections” to use to perform the replacement. So for example, if you had the following INI file:

[MAIN]
SVNServer=MySvnServer
SVNPort=80

[INT]
Server=IntServer
Username=IntUser
Password=Password

[SYS]
Server=SysServer
Username=SysUser
Password=Password

And a “substitute” file as follows (this obviously isn’t a configuration file, it’s purely a very basic sample ):

Subversion Server: %SVNServer%:%SVNPort%

Server: %Server%
Details : %Username% / %Password%

Running it through the utility and specifying the MAIN and INT sections (I generally use a “global” section, then configuration specific sections) would give us:

Subversion Server: MySvnServer:80

Server: IntServer
Details : IntUser / Password

More Information

So there you go, it’s a very, very simple utility, and indeed very little code; but I thought it might be of use to people who might be using FinalBuilder, or even people doing “manual” configuration management. It currently only supports INI files, but adding support for other file format is just a case of creating a new VariableReader implementation and decorating it with a ReaderHandles attribute to signify what “mode” you want it to handle.

I’ve uploaded it onto CodePlex at http://substitute.codeplex.com/, so feel free to grab it, play with it, edit it or criticise it to your hearts content.

Technorati Tags: codeplex, configuration management, finalbuilder, subtitute, utility

This problem appeared out of the blue in Visual Studio 2005 on my work laptop. Google didn’t help with a solution, so I thought a brief blog post was in order.

The Issue

Trying to launch any ASP.Net application on my local machine, either in debug mode or starting without debugging, started the Cassini ASP.Net Webserver just fine, but the browser just threw up an “unable to connect” error. Google seemed to suggest it might be a corrupt webserver exe, but it seemed to be running fine so I ignored that option. I tried manually specifying a port in the project settings, and even using telnet to try access the port on localhost from the command prompt, but even though the webserver was running, nobody was listening!

The Fix

After clutching at random straws for a while I did a “ping localhost” from the command prompt and noticed it was returning replies from ::1 (the IPv6 “loopback” address). I popped open my hosts file (c:\windows\system32\drivers\etc\hosts) and noticed that localhost was mapped to ::1, but not to 127.0.0.1. I have no need for IPv6 on my machine so I commented out that line and added:

127.0.0.1       localhost

Fired up Visual Studio, pressed F5 and voila – all fixed! I’m not sure why this was suddenly a problem, it just appears that Cassini just doesn’t like being accessed via IPv6, but this seems to be the solution if this issues bites you

Technorati Tags: cassini, localhost, troubleshooting, Visual Studio, webserver