Flawless Code

Right To Left Google

Sean — Tue, 19 Aug 2008 07:41:00 +0100

On holiday in Dubai and saw this:

Pretty cool...

Mocking and IOC in Silverlight 2, Castle Project and Moq ports

Sean — Fri, 15 Aug 2008 08:46:00 +0100

Some time ago I started wondering about mocking and IOC in Silverlight 2. There is quite obviously a gap here that someone needs to plug, as soon as you start writing tests (thank you Jamie Cansdale!) you're going to need mocks of some sort and as soon as you have a Silverlight project of any real size, IOC becomes necessary.

Mark Monster blogged about what it would take to port Castle DynamicProxy and consequently Moq to Silverlight and so until someone comes along with a better or official solution I decided to take up the challenge. There was a fair amount of work, although in terms of actual code changes that were needed due to API changes in the Silverlight CLR there was really very little, the brunt of the work as Mark pointed out was around the lack of Remoting and also the lack of non-generic collections in Silverlight. I will just note though Mark, your list of code changes required to get these projects to compile is a MASSIVE underestimate, because the compiler shows as many errors as it can, but only when you fix these does it throw another few hundred at you!

There was a lot of code in the Castle libraries to support remoting and serialization for remoting (MarshalByRefObject, ISerializable, IDeserializationCallback, SerializableAttribute etc etc), none of this is actually required for any of the core features and aren't supported in Silverlight and so I ripped it all out! The other big chunk of work was that there were hundreds upon hundreds of references to types which are missing in Silverlight 2, generally it was non-generic collections such as ArrayList and Hashtable, but also there were some key threading classes which were absent. I solved this by creating a new assembly called FlawlessCode.MissingTypes and adding into this implementations for the missing types. No, I didn't write them all! What I did do was download the Mono source code and use their implementations! You may notice I changed the namespace of all the Mono types to start with FlawlessCode and not System, this is because some of these collections are implemented internally in the Silverlight CLR but just aren't exposed for our use and Visual Studio was complaining to me.

There were some other changes required in the Castle libraries for features which would make no sense and could never work on Silverlight, these of course were removed. Castle DynamicProxy has the ability to save generated assemblies to disk for example, and Castle Core has types like FileResource and UncResource. None of these will ever work in the way intended because Silverlight doesn't have proper access to the file system.

Moq by comparison was very very easy to port, the only real problem was the HastSet<T> class which is not available, thanks go out again to Mono for this!

In terms of IOC, I also ported the Castle MicroKernel. This should give you the basics to play around with, but I have NOT ported Castle Windsor, the reason being that there is a lot of Xml handling code contained therein and it uses XmlNode, XmlElement, XmlDocument etc... this would all need changing to XNode, XElement, XDocument and the like, to be honest I was tired and thought I'd done enough!

To cut a long story short, all the unit tests now pass! I just want to thank the people who made all this possible in the first place, Jamie Cansdale for the Silverlight NUnit work, the people behind the excellent Castle Project, the people behind Moq and of course the Mono Project. I want to be clear that I'm posting this here as a stopgap solution so that all the people working with the beta of Silverlight 2 have something to play with and to perhaps show that this is possible, but really I'm hoping this will be worthless very soon and that someone who really knows what they're doing does a real port or that we get official support from Moq and Castle.

One issue I do know about with all this, Assembly.GetName which is used by DynamicProxy is marked as SecurityCritical, and as such stops the whole thing from working at all! This would be a disaster and indeed if you were wanting to run Moq or DynamicProxy in the browser it is a disaster, however the way in which Jamie got NUnit to work was by making Visual Studio load the silverlight DLLs using the desktop CLR, and apparently when doing this, the desktop CLR takes no notice of SecurityCritical. The end result is that DynamicProxy works fine using Jamie's unit test templates, but if you reference DynamicProxy from your silverlight app and expect it to run in the browser, it won't.

DISCLAIMER: For what it's worth, I'm not a legal mind and while I don't think I'm doing anything wrong by mashing together all this different open source code, if I'm violating anyone's licenses please give me a heads up before you unleash the hounds and I will of course pull it down immediately.

DISCLAIMER 2: While this all seems to work so far and the unit tests do all pass, I did monkey around with the code quite a bit, so please take this as it comes and don't expect too much!

Download

Castle-SLandMoq-SL.zip (770.03 kb)

Silverlight 2 Navigating Between Xaml Pages

Sean — Fri, 21 Mar 2008 09:23:00 +0100

Update - 9/6/2008 : Updated for Silverlight 2 Beta 2!

One of the problems I've run across while playing around with the Beta is the lack of support for any easy way to navigate around you application by moving between Xaml pages. The problem really stems from this little piece of generated code in your App.xaml.cs file.

private void Application_Startup(object sender, StartupEventArgs e)

{

// Load the main control

this.RootVisual = new Page();

}

Looking at the docs for the RootVisual property of Application class, we're told that RootVisual can only be set once. My limited testing shows that this isn't actually true, and that it's possible to set LayoutRoot as many times as you'd like but only in the Application_Startup handler, which is obviously of very little use!

My solution is actually really very simple and can be summed up with one short snippet of code...

private void Application_Startup(object sender, StartupEventArgs e)

{

// Load the main control

Grid root = new Grid();

root.Children.Add(new Page());

this.RootVisual = root;

}

As you can see, here I am setting the RootVisual of the application as a new Grid and adding my Page usercontrol as a child of the grid. All we need to do now when we want to switch out Xaml pages is to manipulate the Children collection of our Grid! Here, check out my demo to see how it looks in action, this is a little two page application which allows you to switch back and forth between the pages in a number of different ways.

[silverlight:source=/ClientBin/FlawlessCodeNavigation.xap;width=640;height=480]

Woah! Hang on, where did all those cool transition effects come from? It just so happens that I've knocked together a few classes (I'm not going to use the word 'framework'!) that make these navigation issues and transition effects, even making your own transitions, really really easy. So... On to the code.

First up we'll take a look at the transitions. Every transition is implemented as a class deriving from the abstract TransitionBase, it's a really tiny little class which provides the implementation for a completed event, for when the transition has finished, and the contract for a single method which must be implemented by derived transitions.

public abstract class TransitionBase

{

public event EventHandler<TransitionCompletedEventArgs> TransitionCompleted;

protected void OnTransitionCompleted(UserControl newPage, UserControl oldPage)

{

if (TransitionCompleted != null)

TransitionCompleted(this, new TransitionCompletedEventArgs() { NewPage = newPage, OldPage = oldPage });

}

public abstract void PerformTranstition(UserControl newPage, UserControl oldPage);

}

We have a PerformTransition method here which takes a reference to the two pages, the current and the one we'd like to change it with. This method is obviously implemented by our derived transitions to manipulate and animate the pages in some pleasing way, one thing to note here is that when the transition has completed its shuffling of the pages around, it must fire the completed event as we will see shortly.

Next up lets look at NavigationHelper, this is a static class which contains methods which can be called to switch pages.

public static class NavigationHelper

{

private static Grid root;

static NavigationHelper()

{

root = Application.Current.RootVisual as Grid;

}

public static void Navigate(TransitionBase transition, UserControl newPage)

{

UserControl oldPage = root.Children[0] as UserControl;

root.Children.Insert(0, newPage);

transition.TransitionCompleted += transition_TransitionCompleted;

transition.PerformTranstition(newPage, oldPage);

}

public static void Navigate(UserControl newPage)

{

UserControl oldPage = root.Children[0] as UserControl;

root.Children.Add(newPage);

root.Children.Remove(oldPage);

}

private static void transition_TransitionCompleted(object sender, TransitionCompletedEventArgs e)

{

root.Children.Remove(e.OldPage);

}

Ok, so here in our static constrcutor we grab a reference to our root visual from the application object. This is cast to a Grid so we can manipulate the Children collection. Now this is not really 100% safe because our static constructor will run the first time and member of our NavigationHelper class is accessed and this could be before the application's root visual has been set as a Grid. In practice though this is very unlikely to ever happen and it would make no sense at all for someone to call our navigation methods before Application_Startup so I'm going to let it go...

We also have two methods here, one which take a TransitionBase and a UserControl and one which just takes a UserControl. The method taking just a UserControl simply switches out the Xaml pages with no other action. The method first gets a reference to the current page which should be at the top of the children collection, then it inserts our new page at the top, this will cause it to be visible and hide the previous page as we have dropped our new one on top, the final step is to pull out the old page from underneath. This is how the "Switch" button in the demo above is working...

The other Navigate overload is more interesting, first we get a reference to the old page but this time we insert the new page behind it so it isn't immediately visible. Next we subscribe to the completed event for the passed in transition object and fire it off to let it do it's thing. We can see that when the transition completes and fires it's event, we simply remove the old page.

Looks great! Now we'll check out how a transition is implemented. There are a few transitions included with the code, but it's really easy for you to write your own and pass them to the NavigationHelper.Navigate method, just by inheriting from TransitionBase. Here is my FadeTransition.

public class FadeTransition : TransitionBase

{

private UserControl newPage;

private UserControl oldPage;

private TimeSpan time;

public FadeTransition(TimeSpan duration)

{

time = duration;

}

public FadeTransition() : this(TimeSpan.FromSeconds(2))

{ }

public override void PerformTranstition(UserControl newPage, UserControl oldPage)

{

this.newPage = newPage;

this.oldPage = oldPage;

Duration duration = new Duration(time);

DoubleAnimation animation = new DoubleAnimation();

animation.Duration = duration;

animation.To = 0;

Storyboard sb = new Storyboard();

sb.Duration = duration;

sb.Children.Add(animation);

sb.Completed += sb_Completed;

Storyboard.SetTarget(animation, oldPage);

Storyboard.SetTargetProperty(animation, new PropertyPath("Opacity"));

sb.Begin();

}

void sb_Completed(object sender, EventArgs e)

{

OnTransitionCompleted(newPage, oldPage);

}

This first thing to notice is that we overload the constructor so that we can pass in timespan, this lets us lengthen or shorten the transition as we see fit. Next is the PerformTransition implementation, this method just steps through and constructs a Storyboard object in code then sets it to run. When the Storyboard has finished its work we fire the TransitionCompleted event which lets NavigationHelper clear up out old page. I won't step through how the Storyboard is created as it's well documented on MSDN and I pretty much just copied if from there anyway, so if you want to know more, go check it out.

There is one other transition I'd like to show you, which is called CompositeTransition. This is how I achieve multiple effects at once, for example fading and sliding. I create a fade transition and a wipe transition, wrap them in a CompositeTransition and pass that to the NavigationHelper.

public class CompositeTransition : TransitionBase

{

private TransitionBase transitionOne;

private TransitionBase[] transitions;

private Int32 count;

private UserControl newPage;

private UserControl oldPage;

public CompositeTransition(TransitionBase transitionOne, params TransitionBase[] transitions)

{

this.transitionOne = transitionOne;

this.transitions = transitions;

}

public override void PerformTranstition(UserControl newPage, UserControl oldPage)

{

this.newPage = newPage;

this.oldPage = oldPage;

transitionOne.TransitionCompleted += transition_TransitionCompleted;

transitionOne.PerformTranstition(newPage, oldPage);

foreach (TransitionBase transition in transitions)

{

transition.TransitionCompleted += transition_TransitionCompleted;

transition.PerformTranstition(newPage, oldPage);

}

private void transition_TransitionCompleted(object sender, TransitionCompletedEventArgs e)

{

count++;

if (count == transitions.Length + 1)

OnTransitionCompleted(newPage, oldPage);

}

There is nothing particularly clever going on here, we have a constructor which take a variable number of TransitionBase instances. When PerformTransition is called we fire off all the transitions at once. When each one of them has completed we fire the TransitionCompleted event. Nice, now we can create loads of cool stuff! One thing worth noting though when stringing transition together like this, in my implementation there is a limitation in that my transtions set the UserControl's RenderTransform property and animate on this. If you chain multiple transitions which work like this they will over write the UserControls RenderTransform and only the last transition will do anything. The fix for this I guess would be to pass a TransformGroup into each transition so they're all animating against the same instance, but I'll leave that bit of fun and games as an excercise for the reader!

Just quickly, here is a snipet showing what a call to NavigationHelper.Navigate looks like, and then I'll leave you with the code download.

TransitionBase transition = new CompositeTransition(

new FadeTransition(TimeSpan.FromSeconds(1)),

new WipeTransition(WipeTransition.WipeDirection.LeftToRight));

NavigationHelper.Navigate(transition, new AnotherPage());

Enjoy!

FlawlessCode.Navigation.zip (144.27 kb)

Blogengine.NET extension for embedding a Silverlight plugin

Sean — Fri, 07 Mar 2008 22:19:00 +0100

Update - 9/6/2008 : Updated for Silverlight 2 Beta 2, new Silverlight.js included!

Silverlight 2 is here and with it's arrival there are going to be a whole load of Blogengine.NET using developers wanting to embed their sample Silverlight apps in their blog posts.

Presented here is a Blogengine.NET extension which makes all the necessary arrangements to embed your content. It works, like most others, by using a token that you type into your posts and in the most basic form looks like this:

[ silverlight:source=/ClientBin/MySilverlightApp.xap ] (without the spaces!)

All very self explanatory... Simply enough, the extension adds the silverlight.js (the latest from the Silverlight 2 Beta 1) file to the head section of the page and then calls Silverlight.createObjectEx for each instance of the plugin on the page.

Using the extension manager you can set all of the other options that this function call takes.

As you can see from the help text though, all these values are just defaults which will be used if they are not specified with the token. The format looks as follows.

[ silverlight:source=/ClientBin/MySilverlightApp.xap;width=640;height=480 ] (without the spaces!)

The format is "key=value" and each pair seperated by ";". Any of the settings in the Extension Manager can be overriden like this, although width and height are the most commonly needed ones, the only required parameter is "source". Here is a sample from my previous post.

[silverlight:source=/ClientBin/FlawlessCodeRegexTester.xap]

Included in the download below is two things. SilverlightExtension.cs needs to be upoaded to your /App_Code/Extensions folder. There is also a folder in the zip file with one file in, script/SilverlightExtension.js. This needs to be put into the root of your website, with the final layout looking like this:

/App_Code/Extensions/SilverlightExtension.cs
/script/SilverlightExtension.js

Hope this comes in handy, enjoy!

SilverlightExtension.zip (5.25 kb)

Silverlight 2.0 Regular Expression Evaluator

Sean — Fri, 07 Mar 2008 09:26:00 +0100

Update - 9/6/2008 : Rebuilt the solution for Silverlight 2 Beta 2

I don't think I'm alone in saying that I've been waiting to get my hands on the Silverlight 2.0 bits for quite a while now. First impressions: it delivers!

I've been reading through the docs and playing around with the bits and my mind has been buzzing with loads of little samples and things to try, many of which will make it to these pages over the coming months I'm sure. I was actually reading though the API docs on MSDN before MIX08 even started and when I saw System.Text.RegularExpressions it just popped into my head I could make my first little baby steps with a Silverlight regex evaluator.

If you have read through all of Mr Guthrie's tutorials, which I highly recommend you do, then most of the code is very simple so I will only highlight a few interesting pieces, although as always the code will be available for download. The application cycles through all available matches for the suplied regular expression highlighting each in turn as you press the button. If no match is found or the last match has been reached a modal "MessageBox" type control is displayed.

Without further ado, here she is:

[silverlight:source=/ClientBin/FlawlessCodeRegexTester.xap]

How It Works

Like Scott's Digg application I wanted to have the application flow and resize nicely using the new layout controls. The trick to getting this to work is setting a DesignWidth and DesignHeight on the root element instead of just Width and Height. This is accomplished with the following Xaml:

<UserControl x:Class="FlawlessCodeRegexTester.Page"

xmlns="http://schemas.microsoft.com/client/2007"

xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

xmlns:d="http://schemas.microsoft.com/expression/blend/2008"

xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"

mc:Ignorable="d"

d:DesignWidth="640" d:DesignHeight="480"

xmlns:FlawlessCodeRegexTester="clr-namespace:FlawlessCodeRegexTester">

The part to note is that DesignWidth and DesignHeight are actually in an expression blend related namespace and as such VS08 doesn't properly respect these values. In fact the designer goes a little odd looking, this isn't really a problem though as Blend looks fine and Blend is where I do all the visual stuff anyway.

The only other part worth mentioning really is how the regex is evaluated.

match = Regex.Match(textTextBox.Text, regexTextBox.Text);

Run beforeMatchText = new Run();

beforeMatchText.Text = textTextBox.Text.Substring(0, match.Index);

Run matchText = new Run();

matchText.Text = textTextBox.Text.Substring(match.Index, match.Length);

matchText.Foreground = new SolidColorBrush(Color.FromArgb(255, 255, 0, 0));

Run afterMatchText = new Run();

afterMatchText.Text = textTextBox.Text.Substring(match.Index + match.Length);

resultTextBlock.Text = "";

resultTextBlock.Inlines.Add(beforeMatchText);

resultTextBlock.Inlines.Add(matchText);

resultTextBlock.Inlines.Add(afterMatchText);

As you can see I use the standard Regex.Match method to perform the actual search and using the value returned I build up a series of Runs which contain the text, colouring the matched part in red. These Run objects are then added to the Inlines collection of the TextBlock which displays the result. A lot more info about how this works can be found on MSDN.

This should be the first of many Silverlight 2 apps I have swimming around in my brain but I do like it, short and sweet, and I may spend some time extending it and adding features to develop this into a more useful tool. Hope you enjoyed it!

FlawlessCodeRegexTester.zip (136.68 kb)

Getting the icon for a given file extension

Sean — Sun, 24 Feb 2008 15:22:00 +0100

Background

In writing a pretty boring LOB app for my day job, I had the need to associate and store arbitrary files with records. I didn't want to just store the file in the actual database, so given that the application already sends audio and image data to an Ftp server on the network I figured I would store the files there also and just hold the file name in the database. 'm not storing the path, just the name and extension of the file and then the file is on the Ftp. Works very well and any client in the building can store pdf/doc/xls/etc files and anyone else can see and save them. The problem I had was that I wanted to make a nice UI for the workflow and display the correct icon for each file. There is a handy static method for extracting icons from files, Icon.ExtractAssociatedIcon(filePath), which works great when you actually have the path to a file you want to find the icon for. Unfortunately there is no way built into the framework to get the default icon for a given file extension.

The Solution

The solution is to P/Invoke into Shell32.dll and call SHGetFileInfo. This lets us just pass in a file extension and get back an icon, we can also use this to get folder icons. Pretty handy, here is the static method in my class which does the lifting.

SHFILEINFO shellFileInfo = new SHFILEINFO();

try

{

uint flags = SHGFI_ICON | SHGFI_USEFILEATTRIBUTES;

flags |= linkOverlay ? SHGFI_LINKOVERLAY : 0;

flags |= largeIcon ? SHGFI_LARGEICON : SHGFI_SMALLICON;

SHGetFileInfo(extension,

FILE_ATTRIBUTE_NORMAL,

ref shellFileInfo,

(uint)Marshal.SizeOf(shellFileInfo),

flags);

return (Icon)Icon.FromHandle(shellFileInfo.hIcon).Clone();

}

finally

{

DestroyIcon(shellFileInfo.hIcon);

}

The trick is in passing SHGFI_USEFILEATTRIBUTES, this tells SHGetFileInfo not to look on the disk for this file. Raymond Chen explains is better than I could in his post here.

To illustrate and test the code I knocked up a quick sample app which is included with the download, check it out.

Just tap in a file extension and select whether you want the shorcut arrow in the bottom corner and away you go.

IconUtils.zip (11.85 kb)

Compiler keywords for primitive types? Why?

Sean — Sat, 23 Feb 2008 22:28:00 +0100

Having just read a pretty interesting post by some guy who gets quite emotional about "else" blocks, the way to spot that this is an emotional reaction is the use of "Never-ever-under-any-circumstances-for-any-reason-what-so-ever", I have to admit I really liked the post. It was fascinating for me to see and have explained some other developer’s little mental twitch reflex when he sees "else" used in (what he considers to be) an inappropriate way.

The truth is I liked it because secretly I have one of my own. Actually I think its way worse than his. Why oh why did Microsoft see fit to include compiler keywords for primitive types? What purpose does it serve?

We have "string" for String, "byte" for Byte, "int" for Int32... Why? Seriously, why? "float" and "double", what's that all about, what we're talking about is single and double precision floating point numbers, if you're at least going to have compiler keywords for these they should be "single" and "double". If you're going to do this kind of thing, we already have "smalint", "int" and "bigint" from Sql Server, why not stick to that instead of "short", "int" and "long"? Has the whole world gone to madness?

Isn't it confusing for newcomers to figure out there are two ways of doing the same thing, not two different things happening? What's the point in the extra level of indirection? Isn't it better to really show that everything is an object (sorry that should be Object!) by not separating primitive types and everything else like this? It's ugly and completely redundant! Let's face it, anyone who's had a look through the String.cs file can tell you it's not exactly "primitive" in there anyway, that's no small code file!

I'll just come right out and say it, never-ever-under-any-circumstances-for-any-reason-what-so-ever use those wimpy little blue keywords when what you're really using can be much more beautifully represented as a soft calming green type name with a capital letter at the front just like every other type in the framework!

I always now write code completely using type names, and depending on just how OCD I'm feeling I have an even dirtier little secret... I actually go and change generated code, you know, when you have VS generate a method stub for you, event handlers for example which always pop out as button_Click(object sender etc etc... That's bad right? What's worse is that there is probably some way of changing how these snippets are generated so I can make the template give me the real type name but I'm afraid to go look for it in case I find it. The truth is I actually get a sick sense of satisfaction hunting down rogue compiler keywords. I think I have a problem.

Phew, the other guy was right; it does feel good to get it off my chest! That being said, I think he actually made a better case than I did. Is it just me then, does anyone else hate compiler keywords for primitive types? Can anyone even explain... No, not just explain, can anyone give me a good reason for the existence of these things? Even more interesting, does anyone else have any little emotional reactions to stuff like this? I bet some of you do...

Enforcing single instance with argument passing

Sean — Mon, 11 Feb 2008 13:06:00 +0100

There are several implementations out there already for doing this, but for one reason or another they all did something I didn't like. Some use the registry, some can't pass parameters, some use P/Invoke, some use remoting and others use the VB libraries. Not quite high treason but even so, an all C# and very light implementation has got to be worth the effort.

The class that does all the work is, imaginatively, called SingleInstance. The single public constructor takes a Guid which is used to identify out application. Like some of the other examples out there I use a Mutex object to tell whether the application is already running or not.

mutex = new Mutex(true, identifier.ToString(), out ownsMutex);

The out parameter tells us whether we were able to create and own the Mutex or whether someone else (another instance of our app) already has. Given this, we have a simple property telling us if we're the first instance or not.

public Boolean IsFirstInstance

{ get { return ownsMutex; } }

The only piece left of the single instance puzzle is making sure that we release the mutex, if we happen to own it, and for this I implemented IDisposable and did the following in the dispose method:

if (mutex != null && ownsMutex)

{

mutex.ReleaseMutex();

mutex = null;

}

Couldn't be more simple, right? Next we need to handle passing any command line arguments onto the initial instance. For this I use the new NamedPipeClientStream and NamedPipeServerStream classes here is the client end:

using (NamedPipeClientStream client = new NamedPipeClientStream(identifier.ToString()))

using (StreamWriter writer = new StreamWriter(client))

{

client.Connect(200);

foreach (String argument in arguments)

writer.WriteLine(argument);

}

On the server end it's pretty much just as simple, we read in all the arguments and the fire the ArgumentsReceived event which the class exposes.

using (NamedPipeServerStream server = new NamedPipeServerStream(identifier.ToString()))

using (StreamReader reader = new StreamReader(server))

{

server.WaitForConnection();

List<String> arguments = new List<String>();

while (server.IsConnected)

arguments.Add(reader.ReadLine());

ThreadPool.QueueUserWorkItem(new WaitCallback(CallOnArgumentsReceived), arguments.ToArray());

}

Everything works really nicely, the only odd looking bit here is that we spawn a new thread to fire the event. I did this simply because I we need to create a new NamedPipeServerStream to handle any subsequent clients and I didn't want to wait for the app to have to process the event. That's all, we leave the responsibility of giving focus to the first instance to itself, should it so wish. Here is a snippet of how it looks in action.

static void Main(String[] args)

{

Guid guid = new Guid("{6EAE2E61-E7EE-42bf-8EBE-BAB890C5410F}");

using (SingleInstance singleInstance = new SingleInstance(guid))

{

if (singleInstance.IsFirstInstance)

{

singleInstance.ArgumentsReceived += singleInstance_ArgumentsReceived;

singleInstance.ListenForArgumentsFromSuccessiveInstances();

//Do whatever your application is supposed to do here...

}

else

singleInstance.PassArgumentsToFirstInstance(args);

}

static void singleInstance_ArgumentsReceived(object sender, ArgumentsReceivedEventArgs e)

{

//Process the arguments here...

}

One thing to note, remember to make your own Guid to use, and make a new one for each application which uses this class (Tools->Create Guid->Registry Format->Copy)! Hope you like the excessively long method names, but hey, for a code sample on a blog it makes it much clearer...

Packaged with the code download is a simple Windows Forms application to demonstrate the functionality, the best way to see it work is to launch one instance in the debugger then minimise it. Next, drag and drop some jpeg files in explorer onto the exe.

And you should see the image viewer app jump to the front and open all the images you dragged!

I'm pleased with the class, hope it can help out some others. Enjoy.

SingleInstance.zip (18.77 kb)

Creating a Low Integrity named pipe in C#

Sean — Sun, 10 Feb 2008 23:05:00 +0100

Before I start, I'll give fair warning, this fits squarely into the category of post where the topic is going to be of very little interest to most readers, however it just might make one person out there a very very happy developer and save them some pain.

I'm nearing the end of my adventures (I sure as hell hope there are no more problems, put it that way) writing a Winsock LSP and I have to say, it's been a gloriously excrusiating experience.

One of the problems I had when tinkering with this was with the new Windows Integrity Control stuff in Vista, in particular, how it all applies to IE7 Protected Mode. I'm sure it's all far more secure and that's a great thing, but it does put some obstacles in the road of people writing code which runs in the IE process, such as BHO's and toolbars... and also Winsock LSPs.

I needed to perform some operations which Protected Mode wouldn't allow, and after playing with several alternatives, I decided I'd have the code which required more priveledges running in it's own process and have all instances of my LSP talk to it over named pipes. Because my LSP, when running in IE, was low integrity I needed to lower the integrity of the pipe I was creating in my medium integrity broker. This is where it got a little trickier, given there is no real built in way to do this in .Net. I ended up writing a load of P/Invoke stuff to get it all working, so without further ado, let's check out how to use it.

SafePipeHandle handle =

LowIntegrityPipeFactory.CreateLowIntegrityNamedPipe("NameOfMyPipe");

NamedPipeServerStream server =

new NamedPipeServerStream(PipeDirection.InOut, false, false, handle);

Pretty simple right? Here's a look at the insides of that factory method...

Byte[] securityDescriptor = ConvertStringSDToSD(lowIntegritySddl);

using (SECURITY_ATTRIBUTES securityAttributes =

new SECURITY_ATTRIBUTES(securityDescriptor, inheritability))

{

IntPtr handle = CreateNamedPipe(@"\\.\pipe\" + pipeName,

(Int32)direction | (Int32)options,

(Int32)mode,

maxInstances, inBufferSize, outBufferSize, 1000,

securityAttributes);

return new SafePipeHandle(handle, true);

}

So here we create our security descriptor with the low mandatory label. We use it to populate an instance of SECURITY_ATTRIBUTES and then we call the unmanaged CreateNamedPipe.

The reason this is all such a pain.. Well first of all, it doesn't seem that you can lower the integrity of a named pipe you've already created. This is frustrating because all of the samples for lowering resource integrity do so on an exisintg resource and nowhere is it suggested that you need to, with pipes, create the resource with the low label as assigning it later won't seem to work. Secondly, this should all be possible in pure managed code using the PipeSecurity class, unfortunately for some unknown reason I wasn't able to get this to work. This is how it should look though.

PipeSecurity security = new PipeSecurity();

security.SetSecurityDescriptorSddlForm(lowIntegritySddl);

NamedPipeServerStream server =

new NamedPipeServerStream("NameOfMyPipe", PipeDirection.InOut,

serverInstances, PipeTransmissionMode.Byte, PipeOptions.None,

inBuffer, outBuffer,

security);

Nevermind, I got it all working right in the end, and I hope this helps someone out.. Code file attached!

LowIntegrityPipeFactory.zip (1.45 kb)

Free copy of VS '08, SQL '08 & Server '08 for the UK too...

Sean — Wed, 23 Jan 2008 15:59:00 +0100

In addition to the post made here a few days ago, registrations were opened today for the UK launch event of all three products, and just like our friends over in the USA we also get a free copy of everything just for turning up!

You can register on the (cheesily named) Heroes Happen Here UK website, go get it while you can. See you there!

Really simple Business Rule validation using lambdas

Sean — Mon, 07 Jan 2008 20:29:00 +0100

At some time or another we all have to code all the little rules, probably most of them already enforced in the database, into our business objects. FirstName cannot be null or empty, Age must be greater than 21, StartDate must be less than EndDate, etc etc... Wouldn't it be lovely if we could just declare these rules in one place and have them decoupled yet cross cutting the whole application, in the database, in the business layer, in the UI? Yeah it would, but I don't really have a solution for that and is it really possible/practical anyway? If it's possible it's sure not clean and easy, and if it's practical we'd all be doing it already!

What I have here is a very simple and lightweight way of validating these little rules, certainly not enterprise grade but certainly of some use in small scale scenarios.

In An Ideal World

Ideally what we want to do is associate rules with properties of our objects. This way we can hook into our NotifyPropertyChanged behaviour and validate anything that goes through each property. Wouldn't it be cool if we could pass in lambdas or delegates to attributes? Something like this maybe:

[ValidationRule(x => x.SomeNumber > 5, "SomeNumber must be greater than 5.")]

public Int32 SomeNumber { get; set; }

Unfortunately we can't. Ok, how about we declare our own delegate type and then we can stick instances of it above our properties and then use reflection or some other trickery to parse the order of members in our class so we know which rule is associated with each property. Then we could decorate our rule with an attribute containing the friendly human readable error message. Something like this maybe:

delegate Boolean ValidationRule<T>(T obj);

[ValidationRuleDescription("SomeNumber must be greater than 5.")]

ValidationRule<MyClass> rule = x => x.SomeNumber > 5;

public Int32 SomeNumber { get; set; }

Unfortunately we can't do that either. At least not in any pleasant, reliable and future proof way. It was getting a little messy anyway. In fact as far as the pile of my hair which was pulled out and left under my desk seems to indicate, there is no way of associating a method with a property.

Yes, we could start passing a string containing the property's name along with our rule, but that's just a maintenance problem waiting to happen. Is it really worth the possible gains when we'd have to maintain brittle string litteral mappings in our code files? In my opinion, in most cases, it's not. We have enough of that crap in all our Xml files already, I'm not about to bring it into my code if I can avoid it.

The Answer

The answer to all this? I have no idea, I don't have one. Instead I have some code which is type safe, clean, doesn't break under refactoring and lacking a feature that's probably not that important anyway. If anyone figures out how to associate a method with a property though, please please let me know!

Here is how it looks:

class Program

{

static void Main(string[] args)

{

MyClass c = new MyClass();

c.AnotherNumber = 10;

c.SomeNumber = 3;

List<String> result = SimpleValidator.Validate(c);

result.ForEach(x => Console.WriteLine(x));

Console.ReadKey();

}

public class MyClass

{

public MyClass()

{

SimpleValidator.AddRule<MyClass>(x => x.SomeNumber > 5

, "SomeNumber must be greater than 5.");

SimpleValidator.AddRule<MyClass>(x => x.SomeNumber > x.AnotherNumber

, "SomeNumber must be greater than AnotherNumber.");

}

public Int32 SomeNumber { get; set; }

public Int32 AnotherNumber { get; set; }

}

And the output looks like so:

The Code

And the code to achieve all this? First we have the RuleItem<T> class. This class is simply used internally to hold a representation of a rule and allow it to be validated.

internal class RuleItem<T> : IRuleItem

{

public RuleItem(Predicate<T> rule, String description)

{

this.rule = rule;

this.description = description;

}

private readonly Predicate<T> rule;

private readonly String description;

public String Description { get { return description; } }

public Boolean Validate(Object obj)

{

return rule((T)obj);

}

As you can see, this class implements IRuleItem. The reason for IRuleItem is to support polymorphism and allow us to create collections of RuleItem<T> by making a List<IRuleItem>. As you should all know, generics mess with polymorphism and we wouldnt be able to put an RuleItem<MyClass> and an RuleItem<MyOtherClass> into the same collection of List<RuleItem<T>>.

internal interface IRuleItem

{

Boolean Validate(Object obj);

String Description { get; }

}

The third and final part of the puzzle is SimpleValidator itself:

public static class SimpleValidator

{

private static Dictionary<Type, List<IRuleItem>> rules = new Dictionary<Type, List<IRuleItem>>();

public static void AddRule<T>(Predicate<T> rule, String description)

{

Type type = typeof(T);

List<IRuleItem> typesRules;

if (rules.ContainsKey(type))

typesRules = rules[type];

else

{

typesRules = new List<IRuleItem>();

rules.Add(type, typesRules);

}

typesRules.Add(new RuleItem<T>(rule, description));

}

public static List<String> Validate(Object obj)

{

Type type = obj.GetType();

if (!rules.ContainsKey(type))

return new List<String>();

List<IRuleItem> typesRules = rules[type];

List<String> validationFailures = new List<String>();

foreach (IRuleItem rule in typesRules)

{

if (!rule.Validate(obj))

validationFailures.Add(rule.Description);

}

return validationFailures;

}

In this class we maintain a collection of Dictionary<Type, List<IRuleItem>>. This holds a list of rules for each type we want to validate against. In AddRule<T> we check to see if we have a list of rules for this type in the dictionary already, if not we create one, then we add the given rule. In the Validate method we simply pull out the rules for the given type, if any, and then run them all. All done.

SimpleValidator.zip (7.43 kb)

Socket Server with .NET 3.5 using pooled buffers and SocketAsyncEventArgs

Sean — Thu, 03 Jan 2008 10:15:00 +0100

In a previous post I talked about the System.Net.Sockets enhancements in .NET 3.5, and if you haven't read it I suggest you do before tucking in to this as some of that code is important to understand what's happening here. Before I start, in essence this is just a result of my experimentation and while it seems it does a pretty good job, I'm not going to claim it's bullerproof or that it's a good example of how to write a socket server all it does is demonstrate the techniques of working with the new classes and methods.

The sample solution you can see on the right there contains three projects. FlawlessCode contains all the classes we'll need to build ourselves a socket server. TestLoadGenerator is a console application which generates load for us by connecting lots of sockets to our server and sending it random data. TestSocketServer is a small socket server implementation using the classes in FlawlessCode.

TcpSocketListener

We'll begin by looking at the FlawlessCode project and in particular, the TcpSocketListener. It should be fairly obvious from the name what this class is meant to achieve, it sits in a loop listening for socket connections and lets us know when one arrives. The public interface is very simple and looks like this:

public void Start();

public void Stop();

public event EventHandler<SocketEventArgs> SocketConnected;

The only thing we'll take a closer look at here is the internal loop which accepts the client sockets. Here you can see the first usage of the new SocketAsyncEventArgs and we're calling AcceptAsync, in our callback we check the SocketError property to see if we had any errors.

private void ListenForConnection(SocketAsyncEventArgs args)

{

args.AcceptSocket = null;

listenerSocket.InvokeAsyncMethod(

new SocketAsyncMethod(listenerSocket.AcceptAsync)

, SocketAccepted, args);

}

private void SocketAccepted(object sender, SocketAsyncEventArgs e)

{

SocketError error = e.SocketError;

if (e.SocketError == SocketError.OperationAborted)

return; //Server was stopped

if (e.SocketError == SocketError.Success)

{

Socket handler = e.AcceptSocket;

OnSocketConnected(handler);

}

lock (this)

{

ListenForConnection(e);

}

ServerConnection

Next we're going to take a look at the ServerConnection class, this class encapsulates the concept of a connected client. Depending on what you wanted to do with your server you may decide to extend this class, rewrite it or maybe completely replace it with something derived from NetworkStream. For our purposes today, this class when created will begin listening for data from the network, it has two public methods, one to disconnect the client and one to send data synchronously back to the client. ServerConnection also fires two callbacks, one when data is received and one when the client is disconnected. Here is a rundown of the interesting parts:

public void Disconnect()

{

lock (this)

{

CloseConnection(eventArgs);

}

public void SendData(Byte[] data, Int32 offset, Int32 count)

{

lock (this)

{

State state = eventArgs.UserToken as State;

Socket socket = state.socket;

if (socket.Connected)

socket.Send(data, offset, count, SocketFlags.None);

}

private void ListenForData(SocketAsyncEventArgs args)

{

lock (this)

{

Socket socket = (args.UserToken as State).socket;

if (socket.Connected)

{

socket.InvokeAsyncMethod(socket.ReceiveAsync,

ReceivedCompleted, args);

}

private void ReceivedCompleted(Object sender,

SocketAsyncEventArgs args)

{

if (args.BytesTransferred == 0)

{

CloseConnection(args); //Graceful disconnect

return;

}

if (args.SocketError != SocketError.Success)

{

CloseConnection(args); //NOT graceful disconnect

return;

}

State state = args.UserToken as State;

Byte[] data = new Byte[args.BytesTransferred];

Array.Copy(args.Buffer, args.Offset, data, 0, data.Length);

OnDataReceived(data, args.RemoteEndPoint as IPEndPoint,

state.dataReceived);

ListenForData(args);

}

private void CloseConnection(SocketAsyncEventArgs args)

{

State state = args.UserToken as State;

Socket socket = state.socket;

try

{

socket.Shutdown(SocketShutdown.Both);

}

catch { } // throws if client process has already closed

socket.Close();

socket = null;

args.Completed -= ReceivedCompleted; //MUST Remember This!

OnDisconnected(args, state.disconnectedCallback);

}

Taking it from the top, we can see the public Disconnect method, this simply calls our internal CloseConnection method which shuts down the socket and fires our disconnected callback. An interesting point to note here is that when this class is instanciated we subscribe to the SocketAsyncEventArgs.Completed event, when a client disconnects we need to remember to unhook this event because when we're reusing objects and pooling resources like this it's a bad idea to leave these references hanging around. Moving down we have the public SendData method, nothing interesting here really, just a standard synchrounous call. Next we get to the internal loop which listens for data from the client, notice how we check SocketAsyncEventArgs.BytesTransferred, if this is zero, the client has closed the connection and disconnected gracefully. We check the value of SocketError here also to make sure there was no error anywhere, after that we make a copy of the bytes we received and inform any interested parties we have new data.

BufferPool and SocketArgsPool

These two classes help us with pooling our resources and are not really very interesting, they're also almost identical to the MSDN examples so you can either look there or just check out the code.

BufferPool: http://msdn2.microsoft.com/en-us/library/bb517542.aspx

SocketArgsPool: http://msdn2.microsoft.com/en-us/library/bb551675.aspx

TestSocketServer

Now that we've sen to main functionality in the FlawlessCode project we're going to look at a simple socket server implementation using these classes.

TcpSocketListener socketListener = new TcpSocketListener(IPAddress.Any, 12345, 10);

socketListener.SocketConnected += socketListener_SocketConnected;

socketListener.Start();

Fairly straight forward, we fire up out listener on port 12345 and give the listening socket an allowed connection backlog of 10.

static void socketListener_SocketConnected(object sender, SocketEventArgs e)

{

SocketAsyncEventArgs args = socketArgsPool.CheckOut();

bufferManager.CheckOut(args);

ServerConnection connection = new ServerConnection(e.Socket, args,

new DataReceivedCallback(DataReceived),

new DisconnectedCallback(Disconnected));

}

When a client connects we get an SocketAsyncEventArgs and some free buffer space for our client and then we create an instance of ServerConnection. Note that we are passing delegates into the constructor, this is because the ServerConnection begins listening for data immediately and we have to have the callbacks hooked up before hand. If we let the call to the constructor complete and the we hooked to standard events we may have already missed the first batch of data!

static void DataReceived(ServerConnection sender, DataEventArgs e)

{

//Do whatever we want here...

}

static void Disconnected(ServerConnection sender, SocketAsyncEventArgs e)

{

bufferManager.CheckIn(e);

socketArgsPool.CheckIn(e);

}

Here we do whatever processing is necessary when a client sends us data. When a client disconnects we just check our buffer space and SocketAsyncEventArgs back into their respective pools to fight another day.

TestLoadGenerator

I'm not going to go into how the load generation works for now, the code is all very straight forward if you've managed to follow the post this far I would imagine. One thing to note is that if you want to test this code and open thousands of connections you need to tweak a registry setting or windows wont give you enough ports. You will need to add the DWORD MaxUserPort to HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters and give it a high enough value that windows won't run out of ports (reboot required, sorry)! Here is a quick examaple of how the load generation classes are used:

static void Main(string[] args)

{

LoadGenerator generator = new LoadGenerator(15000);

generator.BytesPerDelivery = 2048;

generator.DeliveriesPerSecond = 2;

generator.SocketCount = 15000;

generator.SocketDelay = 5;

generator.SocketsPerDelivery = 3;

generator.Start(IPAddress.Parse("127.0.0.1"), 12345);

Console.ReadLine();

generator.Stop();

}

Pretty easy to use, right? We create an instance of the LoadGenerator class, telling it we'd like 15,000 connections maximum. Then we set some properties saying that we'd like each connected socket to deliver 2K of data twice per second. We'd like 15,000 sockets and we'd like them to connect 5ms apart and that we want on average 3% of sockets to send data in each delivery. Then we just aim and fire! Check it out:

When this was taken, the server executable was using 109MB or RAM and 1% CPU on my desktop machine so I think at 15,000 connections we've got some pretty damned good performance out of this thing! Obviously when we start implementing the server logic and actually processing each packet this will go up, but for a bare socket server, I'm pretty pleased.

Net35SocketServer.zip (24.77 kb)

Silverlight video player extension for Blogengine.NET

Sean — Sat, 29 Dec 2007 21:01:00 +0100

Anyone checking out my last post might have noticed the rather nice looking silverlight player demoing the code... Whilst I can't claim responsibility for the xaml and design of the player, I did manage to create an extension which makes adding a player like this very simple. I was thinking of adding some video to the post to demonstrate the sample app so that interested, but not that interested, people could see what was going on without downloading the code and firing up VS. Looking around I found that someone had already made an FLV player extension but hey, this is a .NET blog and Blogengine.NET is written using Microsoft technology, why not go all the way?!

My extension works almost exactly like the FLV player one, adding a token like this: [ silverlight:somevideo.wmv ] (without the spaces!) will get you a silverlight video player.

Now given that Blogengine.NET 1.3 has just landed, it's only right that we find a use for the new ExtensionManager amongst all this. It's time now that I confess why I can't claim responsibility for the lovely xaml, I stole it! There are actually 14 video player templates which come with Expression Encoder and from what I can make out from the EULA, I'm not doing anything wrong by redistributing them (someone please correct me if I'm wrong!). So to that effect we have 14 different skins and also width and height adjustments, all configurable from within the Extensions admin menu.

The attached zip file contains a file, SilverlightPlayer.cs, this must be uploaded to your ~/App_Code/Extensions folder. The zip also contains a folder, SilverlightPlayer, this must be uploaded along with it's contents (a Skins folder containing all the xaml/javascript etc..) to the root of your site. Any videos are then uploaded into your SilverlightPlayer folder before saving your post. If you want to check out what the other skins look like there are jpeg images in the SilverlightPlayer/Skins folder. Thats it!

One last note, if you haven't served silverlight content from your site before make sure you add the mime type for xaml, extension - .xaml, mime type - application/xaml+xml.

Enjoy a sample video here, curtesy of my partner who runs AlexZanDance.

[silverlight:dance.wmv]
(double click for full screen)

Update

Edited the code as per Troy Goode's suggestion in the comments to allow easy upload of files through the web interface. As Troy says below, all you need to do is go into the extension manager and change the Content Root to point to App_Data/files, which is where DotNetBlogEngine puts files you've uploaded through the web interface. Thanks Troy, like it!

SilverlightPlayer.zip (476.37 kb)

Dynamic discoverability using Udp Multicasting

Sean — Wed, 26 Dec 2007 22:27:00 +0100

Continuing with my playing with sockets, I've come up with some classes which allow instances of your application to discover eachother at runtime.

The basic idea is that we join a multicast group and listen for incoming discovery requests. When one is received we reply with the details of where to make a more reliable Tcp connection for any actual communication. Starting with the low level socket work we have two classes, UdpTransmitter and UdpMulticastListener. UdpTransmitter handles sending data to the multicast group which is accomplished fairly easily by creating a Udp socket and sending data to a multicast address:

socket = new Socket(AddressFamily.InterNetwork, SocketType.Dgram, ProtocolType.Udp);

socket.SendTo(data, endpoint);

UdpMulticastListener is more interesting and handles listening for Udp datagrams. Here we create a socket and set some options, this will join the multicast group, set the time-to-live or router hops and also disable loopback so we dont get our own transmissions getting sent back to us!

listenerSocket = new Socket(AddressFamily.InterNetwork, SocketType.Dgram, ProtocolType.Udp);

listenerSocket.Bind(new IPEndPoint(IPAddress.Any, port));

listenerSocket.SetSocketOption(SocketOptionLevel.IP,

SocketOptionName.AddMembership, new MulticastOption(multicastGroup));

listenerSocket.SetSocketOption(SocketOptionLevel.IP,

SocketOptionName.MulticastTimeToLive, timeToLive);

listenerSocket.SetSocketOption(SocketOptionLevel.IP,

SocketOptionName.MulticastLoopback, false);

Now we just start listening, remembering to leave the multicast group when we're done:

listenerSocket.SetSocketOption(SocketOptionLevel.IP,

SocketOptionName.DropMembership, new MulticastOption(multicastGroup));

listenerSocket.Close();

listenerSocket = null;

UdpMulticastListener also also fires a DatagramReceived event when the socket receives data, the EventArgs for this event holds the endpoint the data came from and also a Byte[] containing the actual data.

Wrapping both these classes is one called RendezvousClient which handles both advertising a Tcp endpoint and also sending discovery requests to other instances on the network. Named due to the tendancy for the problem of dynamic discoverability to be refered to as the Rendezvous Problem. RendezvousClient has a very simple interface but there is some magic going on under the covers. There is a single public method SearchForServices, this sends out a discovery request to the multicast group. There are two events, DiscoveryRequest which is raised when RendezvousClient receives a discovery request from the network, there is a handy CancelEventArgs here so we can decide not to reply! There is also the ServicesDiscovered event which is raised when we recieve replies to our own discovery requests. Under the covers, discovery requests are made up of a Byte[] containing a Guid which must be known to both parties, and discovery replies are prefixed with the same Guid, this allows us to filter out any Udp traffic not meant for us. Replies are implemented as the aforementioned Guid and a ServiceEndPoint serialized with the BinaryFormatter, ServiceEndPoint is a little helper class which contains a string for the display name of the service and an IPEndPoint.

One last point, valid multicast addresses are in the range 224.0.0.0-239.255.255.255, however the first 255 are reserved. My home router has a slightly dodgy implementation of IGMP, the routing protocol that makes Udp multicasting possible, and as such only works properly using multicast group 224.0.0.1 which is a reserved address for all hosts in a subnet. Because of this the sample is actually set up to work more like a broadcast however I've also tested on my company network and everything works well in proper multicast mode.

Anyway, I don't know if anyone managed to follow that whole description, but the code should speak for itself and is all available in the download. I have also included a WPF test project using the RendezvousClient. The well known Guid, multicast group, multicast port and time-to-live are all stored in a config file and can be changed without closing the application. See below for a short demonstration.

[silverlight:RendezvousClientTest.wmv]

(Double click for full screen)

RendezvousClient.zip (132.72 kb)

DotNetKicks button extension for Blogengine.NET

Sean — Tue, 18 Dec 2007 20:52:00 +0100

I was looking around for some method of easily adding an DotNetKicks button to my posts but couldn't find anything anywhere. What did I do? Good developer that I am I downloaded the Blogengine.NET source and whipped up a quick extension! I only browsed around for as long as it took for me to find what I needed but I must say that the code was really well organised and readable, there is a post on the project's wiki about creating extensions and it really was a breeze.

My extension checks the post's content for an occurance of the token "[ dotnetkicks ]" (without the spaces!) when it is saved or updated and replaces it with the friendly green button. The code really just boils down to the following:

post.Content = post.Content.Replace(dotnetkicksToken, kickItButton);

There is one class in the attached zip, DotNetKicks.cs, this needs only be uploaded to your ~/App_Code/Extensions folder and everything magically works.

Update

In response to a comment asking about generating the correct HTML for a button when the article is not yet on DotNetKicks, here is the code to do just that! DotNetKicks works in such a way that if a button is created using a URL which it doesn't know, the "kick it" button will show 0. When the button is clicked for the first time you will be taken to the DotNetKicks submission form and just have to fill in the title and description. When you hit submit and them come back to your post, "kick it 1"! Pretty smooth..

String kickItButton = String.Format(

@"<a href=""http://www.dotnetkicks.com/kick/?url={0}"">

<img src=""http://www.dotnetkicks.com/Services/Images/KickItImageGenerator.ashx?url={0}""

border=""0"" alt=""kick it on DotNetKicks.com"" />

</a>", post.AbsoluteLink);

Update 2

Changed the code as per Chris Blankenship's comment to include the title, saves you filling it in yourself...

DotNetKicks.zip (681.00 bytes)

<--- Look, it works...