C# Multithreading: Blocking Similar Requests

It's an abuse of Moore's Law: as computers get faster, software will get slower.  And while there are many reasons why software feeds on additional resources, whether it's providing a more intuitive user interface, coding for security or simple feature bloat – it’s largely the fault of software developer's assumption that disk, memory and CPU will continue to increase in capacity and power while the cost decreases.

With the advent of multi-core processors, it's evident that software cannot afford to assume that execution will occur on a single thread.  We need to embrace multi-threaded techniques to allow our software to scale with the platform.  Developing for multi-threaded applications requires special consideration.

I want to share a simple code snippet that I've frequently used to block individual threads from executing the same code twice.  It's especially handy in dealing with process intensive or time-sensitive requests where race-conditions can occur. For example, a recent project needed to dynamically generate an image and cache as a file – if requests were allowed to overwrite the file as it was being served by another thread, the results would be disastrous.

The concept uses the "double-checked locking" pattern, which is commonly used for synchronized lazy-initialization, such as creating singletons.  Unlike the singleton pattern, this example assumes there are multiple requests for different objects, so the technique is modified slightly.

A “Double-Checked Lock” Singleton

For those that aren't familiar with the "double-checked locking" pattern, I'll outline here using a Singleton example.  In short, double-checked locking is "Check twice before doing any work, with a lock in the middle."

Note: Some may claim that the thread-safety of the double-checked lock pattern simply cannot be guaranteed.  This is true for environments where the processor or application runtime model can vary (Java, C++, etc).  However the CLR does guarantee thread synchronization.

This example outlines the double-checked lock being used to guarantee that only one singleton is created:

public class MySingleton
{
    private static volatile MySingleton _instance;
    private static readonly _lock = new object();

    public static MySingleton Instance
    {
        get 
        {
            // 1: first check
            if (_instance == null)
            {
                // 2: lock a common object
                //      all other threads must wait until the lock is released
                lock(_lock)
                {
                    // 3: second check
                    if (_instance == null)
                    {
                        // 4: thread-sensitive work
                        _instance = new MySingleton();
                    }
                } // 5: release the lock
            }
            return _instance;
        }
    }
    // other methods
} 

If you've never seen this type of pattern before, it may at first seem awkward (“why are you checking for null so much?”).  Here's a quick run down of how this plays out in a multi-threaded environment:

1. Thread #1 enters the MySingleton Instance_get method
2. Thread #2 enters the MySingleton Instance_get method at the exact same time as Thread #1.
3. Thread #1 determines that the instance is null and proceeds to the next statement which puts a lock on a common object that is available to all threads.  This lock will block all other requests until the lock is removed.
4. Thread #2 attempts to access the _lock object but cannot because it is currently locked. Execution pauses at this statement.
5. Thread #1 which is now in a sensitive code region that can only be executed by a single thread, determines that the instance is still null and proceeds to the next statement which performs the thread-sensitive work of creating the singleton.
6. Thread #1 releases the lock.
7. Thread #2 is no longer blocked and can access the lock.  It puts a lock on the _lock object to ensure that no other object can access this region.
8. Thread #2 determines that the thread is not null.  No additional work is performed and it releases the lock.
9. Thread #1 returns the instance.
10. Thread #2 returns the instance that thread #1 created.

Using Synchronized-Keys for Similar Requests

As mentioned previously, the pattern above ensures that only a single instance of our object is created.  However, this technique doesn't work well for methods that vary their response based on input because we're locking a single object to create sensitive regions.  By locking only a single object, we create a nasty side-effect that synchronizes all requests to a single thread.

To solve this problem, we need to put our lock on a different object so that we are only blocking similar requests.  We need a key that is synchronized for requests with the same input.

This is where the “SyncKey” comes in:

public sealed class SyncKey : IDisposable 
{ 
    private static Dictionary<string,SyncKey> _inner = new Dictionary<string,SyncKey>(); 

    public static SyncKey Get(string key) 
    { 
        // lock the table to ensure that only one thread can access 
        //    the dictionary at a time 
        lock(_inner) 
        { 
            // if this is the first request for this key, it will not be present 
            //    in the dictionary.  create and store it. 
            if (!_inner.ContainsKey(key)) 
            { 
                SyncKey item = new SyncKey(key); 
                _inner.Add(key, item); 
            } 
            // return the synchronized key 
            return _inner[key]; 
        } 
    }
 
    private static void Remove(SyncKey item) 
    { 
        // lock the table to ensure that only one thread can access 
        //    the dictionary at a time 
        lock(_inner) 
        { 
            // for the request that first instantiated the key, 
            //    the sensitive work is complete and the key can be safely 
            //    removed from the dictionary 
            // for subsequent requests, although the key was used to prevent 
            //    a duplicate request, it no longer exists in the table 
            //    and can be safely ignored. 
            if (_inner.ContainsKey(item.Key)) 
            { 
                _inner.Remove(item.Key); 
            } 
        } 
    } 

    private string _key; 

    SyncKey(string key) 
    { 
        _key = key; 
    } 

    public string Key 
    { 
        get { return _key; } 
    }

    public void Dispose() 
    { 
        Remove(this); 
    } 
}

An example using this strategy:

public class MyObject 
{ 
    public string SensitiveMethod(string inputParameter) 
    { 
        string key = GetKey(inputParameter); 
        // 1: first check 
        string result = GetItemFromCache(key); 
        if (result == null) 
        { 
            // create a sync key for this request 
            using(SyncKey sync = SyncKey.Get(key)) 
            { 
                // 2: lock request-specific object 
                lock(sync.Key) 
                { 
                    // 3: second check 
                    result = GetItemFromCache(key); 
                    if (result == null) 
                    { 
                        // 4: thread sensitive work 
                        result = BuildResult(key); 
                        CacheResult(key,result); 
                    } 
                } // 5: release lock 
            } // dispose sync key 
        } 

        return result; 
    } 
} 

Results

I built a small contrived example that pushes 1000 threads through a fixed set of input using the following three strategies:

• No locking – all requests are executed without blocking.
• Lock – Locking on a shared lock object.
• Sync Lock – Locking occurs on a request specific key.

Some notes on the findings:

• No locking —The example doesn’t reflect CPU and resource-starvation that would occur by flooding the system with multiple requests.  If it did, it’s likely that the execution time would be several magnitudes longer.
• Lock – duplicate requests are avoided, but the total execution time is longer since the requests are pinned to a single thread when the shared object is locked.
• Sync Lock – duplicate requests are avoided, but execution time is shorter because only similar requests are blocked, allowing other requests to be processed.

CSS for C# Developers: You should learn CSS

When I read Rob Conery's post about I suppose I'll just say it: You should learn ASP.NET MVC, it resonated strongly with me: the bloated abstraction of WebForms has placated developers into thinking they don't need to know HTML to build web applications.  We've spent the better half of this decade blissfully ignorant using server-side technology to "shoehorn" client-side concepts, and we (the asp.net developer) have been negligent on staying on top of the revolution that has been quietly happening client-side.

Thankfully, Microsoft's recent formal inclusion of jQuery for the ASP.NET MVC project has got developers discovering how powerful jQuery and client-side development can be, and that excitement is changing the way developers think about developing for the web.  I believe there's a new renaissance coming, one that isn't based on the bloated server-centric model of WebForms, but rather a new breed of sites with lean, semantic markup and rich client-side interactivity using JavaScript fuelled AJAX. Or at least, one can hope.

With all the attention client-side scripting is getting, there's never been a better time to learn CSS.  (If you're going to develop for the web, why not go all in?)  Until recently, I never did much user-interface development, but after a few short UI-centric projects I'm personally climbing onto the soapbox to challenge backend developers to drop their "I don't do pretty" attitude and learn this important skill.

So if you’ve secretly wanted to learn CSS but didn’t have a good reference point, this is my attempt at providing a crash course:

The basics

If you’re generally familiar with the basic concepts behind CSS, you can skip ahead, but no harm will come to you read it.

CSS Selectors

As developers, we love to think of the browser’s Document Object Model (DOM) as an object graph with pretty collections of childNodes and attributes that we can programmatically manipulate using imperative code instructions.  While this concept translates really well into technologies like XPath, it doesn’t fit CSS selectors so literally.  The syntax (is exactly the same syntax jQuery uses) is actually very straight-forward, and focuses primarily on all nodes of a specific criteria rather than targeting specific child nodes.

Type Selectors

Styles can be applied to all elements of a particular Type (or TagName):

/* single type (all h1 tags) */
h1 {
   color: blue;
}

/* multiple types (all h1, h2, and h3 tags) */
h1, h2, h3 {
   color: blue;
}

Id Selectors

The hash/pound/number symbol (#) is used as a selector to elements with a specific “id” attribute.  Note: This approach should only be applied to controls without the “runat=server” attribute since ASP.NET server-controls dynamically generate their IDs.

<style>
#title {
   color: blue;
}
</style>
<h1 id="title">Foo Heading</h1>

Class Selectors

Obviously, the more appropriate technique would be to assign the element a “class”, which in ASP.NET translates to our CssClass for most WebControls (otherwise you have to access this value through the Attribute collection under the appropriately named “class” key).  Note that the “class” is not tied to a specific type, and can be reused on other elements:

<style>
.title {
    color: blue;
}
</style>
<h1 class="title">Blue Heading</h1>
<p class="title">Blue paragraph</p>

Combine selectors to be specific

You can also get specific and limit the scope of a selector to a particular tag, by prefacing the selector with the tag name.  Note there is no space between the tag and class:

<style>
h1.title {
   color: blue;
}
p#description {
   color: green;
}
</style>
<h1 class="title">Blue Heading</h1>
<p id="description">Green Paragraph</p>

Child Selectors

You can also refer to child elements, which affords us the ability to provide additional formatting without having to modify our markup.

<style>
// all li elements under a ul with a "menu" class
ul.menu li {
   list-style-type: none;
   display: inline;
}
</style>
<ul class="menu">
   <li>inline 1</li>
   <li>inline 2</li>
   <li>inline 3</li>
</ul>

Applying multiple class selectors

Another important (and not well known) thing to point out is that you can have multiple class names for a single element, which can reduce duplication:

<style>
a.navLink {
   text-decoration: underline;
   color: red;
}
.selected {
   font-weight: bold;
}
</style>
<ul>
   <li><a class="navLink" href="#">one</a></li>
   <li><a class="navLink selected" href="#">two</a></li>
   <li><a class="navLink href="#">three</a></li>
</ul>

There are a few more selectors I haven’t covered here, but you can more details and tutorials here:

• http://w3schools.com/css
• http://www.w3.org/TR/CSS2/

Inheritance in CSS

From a pure developer perspective, inheritance in CSS is similar to inheriting classes:

• all tags derive from a common ancestor
• each Type (tag) has their own set of default properties.  (Each browser has a default style sheet that is loaded automatically)
• each node inherits properties defined from its parent

However, CSS inheritance deviates from this analogy as properties are merged in combination from multiple sources (wildcard, class, id and type selectors), somewhat like multiple inheritance:

• a node’s properties are overridden as selectors are matched, from least specific to exact matches.
• style sheet documents are processed from top to bottom, and in order of appearance in the source HTML

While this sounds complicated and difficult to troubleshoot, tools like FireBug and Internet Explorer Developer Toolbar have made this a trivial task.  My deepest respect goes to the user-interface developers who painfully slugged this stuff out manually only a few years ago.

A simple inheritance example:

<style>
body {
   background: #fefef2; /* eggshell */
}
h1 {
   text-decoration: underline;
   background: #ffffff; /* white */
}
.title {
   color: #0000ff; /* blue */
}
</style>

<!-- titleeffective style applied after inheritance:
{
   text-decoration: underline; /* from h1 */
   background: #ffffff; /* from h1 */
   color: #0000ff; /* from .title */
}
-->
<h1 class="title">Underlined blue title with white background</h1>

Note that the only way to prevent inheriting settings from a parent node is to explicitly supply a value for the property.

<style>
body {
   background: #fefef2;
}
h1 {
  text-decoration: underline;
  background: #ffffff;
}
.title {
  text-decoration: none;
  background: #fef2f2;
  color: #0000ff;
}
</style>
<!-- effective style applied after inheritance:
{
   text-decoration: none; /* back to the default */
   background: #fef2f2; /* back to the default */
   color: #0000ff; /* new value */
}
-->
<h1 class="title">Blue title with eggshell color</h1>

DocType matters

Much like setting the content-type of a Response in ASP.NET so that the browser will understand what the content is, the DocType is a crude processing instruction at the top of the document that instructs the browser how they should process the markup.  Without this instruction, most browsers will assume the content is ancient and they will use the oldest rendering engine available.

As to which doctype you should use, it largely depends on the markup you have, but you should strive for the most compliant possible.

A List Apart has one of the best references on this topic.

The Box Model

The Box Model is another core concept of CSS.  All elements are contained in their own box and have margins, borders and padding.

Commit to memory: Margin, Border, Padding, Content.

• The margin is the amount of space reserved as buffer between elements.  The margin is always transparent.
• The border appears between the margin and the padding.  It has many different styling options.
• Padding separates your border from your content.  It takes up visual space and is the color specified by the background – if you want your element to be larger or have more color, padding is what you want.

Commit to memory: Top, Right, Bottom, Left

When specifying values for padding, margins or border widths CSS provides two approaches.  Either declare each value separately (border-top: 0px; border-right: 0px; border-bottom: 0px; border-left: 0px) or inline as one statement in clockwise order starting at top (border: 0px 0px 0px 0px;).  This comes up frequently, so memorize now and thank me later.

Also note that there’s a shortcut for the shorthand, where top & bottom and left & right are the same values (border: 0px 0px;).

Fonts

Fonts can be tricky, and I tend to lean on the graphic designer to pick the typography for the site.  From a development perspective, although you can choose any font it must be available on the user’s machine, and only a few fonts are truly available across operating systems.  A great reference of browser surveys can be found here: http://www.codestyle.org/css/font-family/index.shtml

From a CSS perspective, you can supply a number of different fonts in comma-delimited format, and the browser will apply the first match from left to right.  Outside of actual Fonts, there are five generic fonts which all browsers implement.

Keep in mind that there is much debate on whether you should specify fonts in “em”, “pt”, “px” or “%” for font-sizes.  I won’t settle that debate here.

Digging Deeper

Congrats on reading thus far, if you skipped ahead, no cookie for you.

Pseudo Selectors

While pseudo selectors are bordering on advanced topics, a crash course in CSS would be incomplete without mention of some pretty important CSS selectors:  a:link, a:visited, a:active, a:hover.  These are special selectors that can be applied to anchor tags for their various states.  The first two (“:link” and “:visited”) allow you to specify the style of the anchor tag based on the user’s history; the latter refer to user actions with the hyperlinks.  The “:active” selector is applied the user is clicking on the hyperlink; the “:hover” selector is applied when the user moves the mouse over the anchor.

Astute developers pick up that “:hover” allows you to define styles that would normally be applied using “onmouseover” and “onmouseout” events using JavaScript.  One of my favorite applications of the “:hover” tag is to change the background image of an element when the user hovers over it.  With some extra effort, you can change the relative position of the background image to achieve a “sprite” effect.

Some trivia: there is no equivalent of these selectors as an inline style attribute, they can only be defined in a style block or style sheet.  Also, the “:hover” tag can be applied to other tags, but only anchor tags are supported in IE 6.

Background Images on Elements

CSS provides the ability to set the background property of an element to point to an image, which is major shift from standard HTML.  By moving our images from the markup into the CSS, we not only reduce the amount of markup required, but we separate presentation from content.  This technique is essential for creating impressive effects, such as drop shadows and nifty borders.

The syntax:

/*
element {
   background: color url(path) repeat attachment position
} */

div {
   background: transparent url(../images/bg.png) repeat-y fixed 0 0
}

By specifying the repeat value of an image, your image only needs to be a few pixels in size.  In addition, you can specify an offset in pixels to have the image indented.

Few key takeaways:

• The path of the image is resolved from the location of the css file, not the requested page.
• Remember to set “no-repeat” if you only want the image to appear once.
• When adding background image to an element, the image size is not taken into consideration.  If you want more of the image to be displayed, adjust the padding of the element to suit.

Not everything is a div, dummy

The div tag is one of the most popular tags in XHTML/CSS as it's used to create logical sections for your layout.  While divs are preferred over tables, using divs exclusively to represent content isn't necessarily a good thing.  If you've fallen into this trap or have trouble knowing when you should use a div versus a span, I'm going to break you out of a bad habit by demystifying what the div tag is by looking at the how it's described by most browser's default style sheet:

div { 
    display: block; 
} 

That's it!  So maybe it would help us to understand what "display" does?

There are a bunch of settings for "display", but the short list is: "none", "block", and "inline".  Setting display to "none" basically means that the content won't take up any layout space and is thus invisible.  Elements with display set to "block" are considered a chunk of content that has a line break before and after, whereas "inline" means it's part of the content.  It's best described by looking at the default's for some tags:

Tag	Display Default
body	block
h1,h2,h3,h4	block
p	block
div	block
ul, li	block
bold, strong	inline
italic, em	inline
a	inline
span	inline

A great breakdown of “display” and how it’s used, including support for all modern browsers, is available here.

If what you really need is a container for some content, P and UL are great substitutes.  You’ll be surprised at how quickly your content begins to look less like div-soup and more like xml.

<!-- before -->
<div id="contacts">
  <div class="person">
     <div class="details">
          <b>Person Name</b><br/>
          <i>555-1234</i>
     </div>
  </div>
</div>

<!-- after -->
<ul id="contacts">
   <li class="person">
        <h3>Person Name</h3>
        <ul class="details">
             <li class="phone">555-1234</li>
        </ul>
   </li>
</ul>

Start with a clean slate

Working with CSS can get tricky, especially managing the complexity of your style sheets to support multiple browsers.  One of the best approaches to minimize this complexity is to override the default settings for all elements to a minimalist state, and then slowly build up your styles to suit your needs.  This approach reduces duplication and helps ensure that your settings aren't inconsistent between browsers.

Here's a quick example that removes the padding and margin for all elements, and turns off the legacy blue-border around the image tag:

// remove all margins and padding from all elements
* { 
margin: 0; 
padding: 0; 
} 

// remove legacy border around images
img { 
    border: none; 
} 

Here are a few great starting points for a clean slate:

• http://developer.yahoo.com/yui/reset/
• http://960.gs/
• http://particletree.com/features/quick-start-your-design-with-xhtml-templates/

Floating

Using "floating" to position elements can be tricky, and there are certainly a few tricks to make it work for all browsers (I'm looking at you Internet Explorer 6), but mastering it means you'll never need to use tables to layout your content again.  Or at least, only use tables when representing data.

At a very high level, when an element has a float applied to it, it is no longer part of the normal flow of the document.  An element with a “float:left;” will float to the left until it meets the left edge of it’s containing block; likewise a “float:right;” implies the element will nestle up to the right of it’s container.  Floating can be turned off by setting a “float:none;” to the next element.

The secret to getting floating to work is ensuring that the element being floated has a width explicitly defined.  Likewise, setting a width to the parent element that contains the floating element solves many problems.

Still, as developers, we know from experience that this is a major cross-browser problem and it’s likely the principle reason why we leave CSS to the experts.  Truth is, every browser except Internet Explorer got the Box Model right, and the fix is shockingly simple: floating problems in Internet Explorer 6 are generally solved by ensuring that the floated element (in IE’s terms) “has a layout specified”.  In most cases, specifying “display:inline;” works:

.container
{
      float: left;
      display: inline;
}

A great reference on float theory can be found here: http://www.smashingmagazine.com/2007/05/01/css-float-theory-things-you-should-know/

Static, Relative and Absolute Positioning

A close relative to floating is the concept of “absolute and relative positioning”.  Personally, I’ve always felt that absolute position was a last resort when compared to using floats, but in concept may be easier to understand.

Since “static” is the default behavior for content, the real work is understanding that “absolute” and “relative” provide meaning to the css properties “top”, “left”, “right” and “bottom”.

When an element uses “absolute” for it’s positioning, the “top” and “left” properties can be used to position the element anywhere in the document, where (0,0) represents the top, left-hand corner of the document.

When an element uses “relative” positioning, the “top” and “left” properties indicate where the element appears in relation to the element that came before it.

And here’s the magic: if an element inside a “relative” positioned element specifies an “absolute” position, the “top” and “left” properties can be used to position the element anywhere within the containing element where (0,0) represents the top, left-hand corner of the relatively positioned element.

A great tutorial on positioning can be found here:  http://www.barelyfitz.com/screencast/html-training/css/positioning/

Don't trust your eyes

While the Internet Explorer 8 Developer Toolbar is considerably better than previous versions, FireBug, the popular addin for FireFox, is still the king.  Aside from being able to hack the CSS values in real time, one of the most useful features that FireBug provides is that it can highlight the contents of an element as you move your mouse over them.  The highlighted area, which uses different colours to represent padding versus margins, shows how the browser has reserved space for the visual element.  I've discovered there are times where FireFox renders the content correctly, but the overlaid highlight for margins and padding doesn't exactly match the visual appearance.  From my own experience, I've discovered that these discrepancies are often more apparent in other browsers.  If you can get FireBug's visual overlay to match the desired visual, you're less likely to have issues in other browsers.

The following example shows how FireBug highlights a paragraph with a width greater than it’s parent.

<style>
div {
  float: left;
  width: 300px;
}
p {
  width: 350px; /* bigger than parent! */
}
</style>

Learn Paint.NET

Lastly, while not a CSS tip, it would be an injustice to think that you as the developer are not capable of cutting and resizing images.  Let the graphic designer be responsible for producing the content, but as a developer you need to learn be independent and cut up the image yourself if needed.

Paint.NET is awesome, and when compared to Photoshop or GIMP, it's as easy to use as ms paint.  There are lots of tutorials online that hold your hand from start to finish on creating some impressive graphics.

Conclusion

Thanks for reading.  If you’re a backend developer who’s never spent any time in the user-interface, I hope this has help shine a light for you, please send me some feedback.  If you’re a front-end developer and I’m completely off my rocker, feedback is also appreciated.

Cheers.

Creating a better Wrapper using AOP

Recently, I was working on a system that had to use several third-party data sources with different object models.  Since changing their code was out of the question, the obvious workaround was to wrap the third-party objects into a common interface in my codebase.  The resulting code was dead simple, but the monotonous repetition of creating property accessors for several dozen fields left me with a sinking feeling that there ought to be a better way.

public class PersonWrapper : IPerson // REPEAT for each 3rd party object...
{
     public PersonWrapper(CompanyA.Person person) 
     {
          _person = person;
     }

     public string EmailAddress
     {
          get { return _person.Email; }
          set { _person.Email = value; }
     }

    // REPEAT for each Property we want to expose...

     CompanyA.Person _person;     
}

The better way snuck into my head when a colleague found an interface in the third-party library that was similar to our needs.  We only needed a small handful of properties of their interface, so he asked, "Can we inherit only half of an interface, somehow?"  This odd question with a seemingly obvious answer (there isn't a CLR keyword to break interface definitions) pushed me to think about the problem differently.  We can't choose what parts of an interface we want to inherit, but we can choose a different interface and inherit from it dynamically.  Not a trivial task but certainly possible as many frameworks have been dynamically generating classes from interfaces for years.  This technique only solved half of the problem, so I discarded the notion.

Later that night, the solution to the other half seemed obvious: decorate the interface with attributes that describe the relationship to the the third-party types, and use an aspect oriented concept known as call-interception to forward calls on the interface to the mapped fields of the third-party type.  If it sounds complicated, it is -- but fortunately, the tools make it easy to do, and I'll try my best to walk you through it.

AOP 101

For starters, it helps to understand that typically AOP is used to augment the behavior of existing classes by creating a special proxy around objects at runtime.  For the existing code that will use those augmented types, the proxy is identical to the original -- the key difference is that each call to your object passes through a special middleman (known as an interceptor) that can perform additional operations before and after each call.  The most commonly used example is logging the parameters that were passed in or the time that the method took to execute.  This diagram attempts to describe what's happening:

However, a dynamic proxy for an interface is different because there's no existing class, so our interceptor is responsible for doing all the work:

Mapping Interfaces to Third Party Types

So rather than creating a concrete wrapper for each vendor's type, we annotate our interface with the mapping information. The advantage is that we can manage our interface definition and mappings in a single place, making it easy to extend to new fields and other vendors without incurring class explosion.

public interface IPerson
{
    [MappedField("First", typeof(CompanyA.Person))]
    [MappedField("FName", typeof(CompanyB.Contact))]
    string FirstName { get; set; }
    
    [MappedField("Last", typeof(CompanyA.Person))]
    [MappedField("LName", typeof(CompanyB.Contact))]
    string LastName { get; set; }
}

[AttributeUsage(AttributeTargets.Property, AllowMultiple=true, Inherited=true)]
public sealed class MappedFieldAttribute : Attribute
{
    public MappedFieldAttribute(string fieldName, Type targetType)
    {
        FieldName = fieldName;
        TargetType = targetType;
    }
    
    public string FieldName
    {
        get;
        private set;
    }
    
    public Type TargetType
    {
        get;
        private set;
    }
}

Intercepting Calls

Now that our interface contains the information to map to properties in our third-party class, we need to dynamically generate a derived class that implements this interface.  I'm using Castle projects' DynamicProxy, though there are several other ways to do this.  We'll configure the derived class (Proxy) with a custom interceptor that will read information about the method being called, and using some Reflection goodness, it will redirect the incoming call to the third-party object. 

DynamicProxy's interceptor interface is simple. The IInvocation object contains all the information about the incoming call:

public interface IInterceptor 
{ 
    void Intercept(IInvocation invocation); 
} 

If we were creating a proxy for a concrete Type, we'd likely want to pass the call from the proxy onto the target object using the invocation.Proceed() method, but because we're using an interface with no target implementation, we'll have to write the implementation within the Interceptor.  We can implement anything we want though the only constraint is that we must set the invocation.ReturnValue if the method has a return value.

The details of the method being called are represented in the invocation.Method.  When the call is for a property, the Method is the actual accessor method, ie get_<PropertyName> and set_<PropertyName>.  This represents a bit of a gotcha because our attribute definition isn't on the accessor Method, it's on the PropertyInfo, so we have a bit of work to get our custom attributes.

The FieldMapperInterceptor implementation looks like this:

public class FieldMapperInterceptor : IInterceptor
{
    public FieldMapperInterceptor(object target)
    {
        _targetObject = target;
        _targetType = target.GetType();
    }
    
    public void Intercept(IInvocation invocation)
    {
        if (!InterceptProperty(invocation))
        {
            throw new NotSupportedException("This method/property is not mapped.");
        }
    }

    protected bool InterceptProperty(IInvocation invocation)
    {
        MethodInfo method = invocation.Method;
        string methodName = method.Name;

        if (!IsPropertyAccessor(method)) return false;

        string propertyName = methodName.Substring(4);
        bool writeOperation = methodName.StartsWith("set_");

        // get attribute from the Property (not the get_/set_ method)
        PropertyInfo property = method.DeclaringType.GetProperty(propertyName);
        MappedFieldAttribute attribute =
				property.GetCustomAttributes(typeof(MappedFieldAttribute), true)
                                               .OfType<MappedFieldAttribute>
                                               .SingleOrDefault(mf => mf.TargetType == _targetType);
        if (attribute == null) return false;

        // locate the property on the target object
        PropertyInfo targetProperty = _targetType.GetProperty(attribute.FieldName);
        if (targetProperty == null)
        {
            throw new NotSupportedException("Field not found on the target Type.");
        }

        if (writeOperation)
        {
            object propertyValue = invocation.Arguments.Last();
            object[] index = invocation.Arguments.Take(invocation.Arguments.Length -1 ).ToArray(); 
            targetProperty.SetValue(_targetObject, propertyValue, index);
        }
        else
        {
            invocation.ReturnValue = targetProperty.GetValue(_targetObject, invocation.Arguments);
        }

        return true;
    }

    public bool IsPropertyAccessor(MethodInfo method)
    {
        string methodName = method.Name;
        return (methodName.StartsWith("get_") | methodName.StartsWith("set_"));
    }
    
    private object _targetObject;
    private Type _targetType;
}

Caveats

The FieldMapperInterceptor will work with any interface using the MappedFieldAttribute and any third-party object, but there are a few caveats:

• The implementation is only dealing with Properties, though the approach for methods would be similar (and probably easier).  Maybe I'll post a follow up if there's interest.
• There's definitely room for performance and memory improvements via caching and RuntimeTypeHandles.
• Does not support generic parameters.
• While Castle's DynamicProxy2 is very light weight, there is a cost to instantiating objects. Albeit very minor.

Putting it All Together

With this in place, dynamically graphing our custom interface to our third-party types is a snap:

[Test] 
public void Demo() 
{ 
    ProxyGenerator generator = new ProxyGenerator(); 
    CompanyA.Person actualObject = new CompanyA.Person(); 
    FieldMapperInterceptor interceptor = new FieldMapperInterceptor(actualObject); 
    IPerson person = proxyGenerator.CreateInterfaceWithoutTarget<IPerson>(interceptor); 

    person.FirstName = "Bryan"; 

    Assert.AreEqual(actualObject.FName,person.FirstName); 
}

Comments welcome.

Selenium Field Notes

My last few projects have leveraged both Selenium-RC and Selenium-Core.  Here's a few notes from the field:

FireFox 3 doesn't work with Selenium 1.0.0 beta 1

When working with Selenium RC out of the box, Selenium stalls when trying to launch an instance of FireFox 3.  The Selenium-RC application works as a browser extension that is marked to only certain versions of the browser, this patch fixes the meta-data for the firefox plugin.

Instructions on how to fix the issue yourself can be found here, and within the comments there's a downloadable selenium-server.jar with the patch already applied.

Use Selenium-RC Judiciously

When you're working with Selenium Remote Control, every selenese command is sent over the network to the java application (even when working locally), so beware of redundant calls.  For example, I wrote several helper methods in my NUnit tests to group common selenese functions together:

public void SetText(string locator, string value) 
{ 
    selenium.Click(locator); 
    selenium.Type(locator,value); 
} 

Since the "Click" event is only needed for a few commands, trimming down the selenese can improve execution speed:

public void SetText(string locator, string value) 
{ 
    SetText(locator, value, false) 
} 
public void SetText(string locator, string value, bool clickBeforeType) 
{ 
    if (clickBeforeType) 
    { 
        selenium.Click(locator,value); 
    } 
    selenium.Type(locator,value); 
} 

Avoid XPath when possible

Using XPath as a location strategy for your elements can be dangerous for long term maintenance for your tests as changes to the markup will undoubtedly break your tests.  Likewise, certain browsers (cough cough IE) have poor XPath engines and are considerably slower (IE is about 16x slower).

Strangely enough, following accessibility guidelines also makes for better functional UI testing.  So instead of XPath locators, consider:

• Use "id" whenever feasible.

  <a id="close" href="#" onclick="javascript:foo();"><img src="close.gif"/></a> 

  selenium.Click("close");

• Use "alt" tags for images.

  <img src="close.gif" alt="close window" onclick="javascript:foo();" />

  selenium.Click("alt=close window");

• Use text inside anchor tags when ids or images are not used.

<a href="/">Home</a> 

selenium.Click("link=Home"); 

Avoid timing code

When working with AJAX or Postback events, page load speed can vary per machine or request.  Rather than putting timing code in your NUnit code (ie Thread.Sleep), take advantage of one of the selenium built-in WaitFor... selenese commands.

To use, you place javascript code in the condition where the last statement is treated as a return value.

// wait 30 seconds until an element is in the DOM
selenium.WaitForCondition("var element = document.getElementById('element'); element;", "3000");

This approach allows your code to be as fast as the browser rather than set to a fixed speed.

Use Experimental Browsers

When testing, I found several cases where I hit security limits, such as uploading a file.  In those cases, you have to use *chrome for Firefox and *iehta for Internet Explorer.  These browser profiles are just like *firefox and *iexplore, except that they run with elevated privileges.

Got a tip?  Leave a comment

Producing readable log4net output

As a follow up to log4net configuration made easy, a common question people ask is what tool to use for reading log4net output.

Unless you're using an AdoNetAppender, there aren't many popular choices for combing through log4net file output.  This really should be as simple as setting fixed width columns or column delimiters into our FileAppender's layout pattern, but unfortunately it isn't that simple: log4net's base appender (AppenderSkeleton) outputs Exceptions over multiple lines making it unsuitable for delimited output.

Here are a few options for producing friendly log4net output that can be easily imported or understood by common tools, such as Excel, LogParser, etc.

Format Exceptions using an IObjectRenderer

log4net is just so darn extensible!  Object renderers are one of those great hidden gems in log4net that allow you to log an object and leave the formatting to log4net configuration.  Any object reference pushed through log4net (including derived classes) will use the supplied object render to customize the output. 

public class ExceptionRenderer : IObjectRenderer
{
        public void RenderObject(RendererMap rendererMap, object obj, TextWriter writer)
        {
            Exception ex = obj as Exception;
            if (ex != null)
            {
                // format exception to taste
                writer.Write(ex.StackTrace);
            }
        }
}

The object renderer appears in your config thusly:

<log4net>
    <!-- appenders -->
    <appender ... />
    <root ... />
    <renderer 
	renderingClass="MyNamespace.ExceptionRenderer,MyAssembly"
	renderedClass= "System.Exception" />
</log4net>

This option can be combined with the other approaches defined below, or on it's own.

try
{
    // perform work
}
catch(Exception ex)
{
    // format using IObjectRenderer
    log.Warn(ex);
}

By logging just the Exception object, the IObjectRenderer will do its formatting. Coincidentally, because the exception is the message it isn't subject to the same delimited friendly problems, though this may not be a suitable solution for you if it means having to rewrite all of your exception blocks.

Redirect Exceptions using a Custom Appender

As previously mentioned, the culprit behind our messy exceptions is the AppenderSkeleton.  Technically, it's how the RollingFileAppender leverages the AppenderSkeleton RenderLoggingEvent method: it appends content to the log based on our LayoutPattern, and then dumps the Exception stack trace as its own line.  We can correct this behaviour by creating a new appender that handles our exception details before it gets rendered into the logger as an exception.

public class CustomRollingFileAppender : RollingFileAppender
{
    public override Append(LoggingEvent loggingEvent)
    {
        string exceptionString = loggingEvent.GetExceptionString();
            
        if (String.IsNullOrEmpty(exceptionString))
        {
            // business as usual
            base.Append(loggingEvent);
        }
        else
        {
            // move our formatted exception details into the message
            LoggingEventData data = loggingEvent.GetLoggingEventData(FixFlags.All);
            data.ExceptionString = null;
            data.Message = String.Format("{0}:{1}", data.Message, exceptionString);

            LoggingEvent newLoggingEvent = new LoggingEvent(data);

            base.Append(newLoggingEvent);
        }
    }
}

The key advantage to this approach is that you won't have to change your existing logging code.

Move Exception details to a Custom Property

Though the previous approach solves our problem, we're coupling our message to our exception.  There may be some cases where you would want to separate exception details, such as importing into a database where the message is limited and the stack trace is a blob.  To accommodate, we can write our exceptionString to a custom property, which can be further customized using our layout configuration.

This code example shows the exception being logged to a custom property:

   LoggingEventData data = loggingEvent.GetLoggingEventData(FixFlags.All);
   data.ExceptionString = null;
   data.Properties["exception"] = exceptionString;

And our configuration:

<appender name="RollingLogFileAppender" type="log4net.Appender.CustomAppender">
  <file value="..\logs\log.txt" />
  <layout type="log4net.Layout.PatternLayout">
    <conversionPattern value="%date %-5level [%t] - %message %property{exception} %newline" />
  </layout>
</appender>

Putting it all together

The final piece is defining our layout of file so that it can be consumed by Excel or Log Parser. In the example below, I've customized my Header and Conversion pattern to use a pipe-delimited format, perfect for importing into Excel or a database table.

<log4net>
    <appender type="Example.CustomAppender,Example" name="CustomAppender">
        <!-- derived from Rolling File Appender -->
        <file value="..\logs\log.txt" />
        <appendtofile value="false" />
              <layout type="log4net.Layout.PatternLayout">
                <header value="Date|Level|Thread|Logger|Message|Exception&#13;&#10;" />
                <conversionpattern value="%date|%-5level|%t|%logger|%message|%property{exception}%newline" />
              </layout>
    </appender>
    <renderer renderedclass="System.Exception" renderingclass="Example.ExceptionRenderer,Example" />
    </appender>
        <root>
        <level value="DEBUG" />
        <appender-ref ref="CustomAppender" />
    </root>
</log4net>

Here's a Log Parser query that uses pipe-delimited format (we use a Tab delimited format with a pipe as the delimiter):

logparser.exe -i:TSV -iSeparator:"|" "select Level, count(*) as Count from log.txt group by Level"

Legacy Projects: Planning for Refactoring

Over the last few posts, my legacy monolithic project with no unit tests has: configured a build server with statistics reports, empty coverage data, and a set of unit tests for the user interface.  We're now in a really healthy position to introduce some healthy change into our project.  Well... not quite: applying refactoring to an existing project requires a plan with some creative thinking that integrates change into the daily work cycle.

Have a Plan

I can't stress this enough: without a plan, you're just recklessly introducing chaos into your project.  Though it would help to do deep technical audit, the trick is to keep the plan at a really high level.  Your main goal should be to provide management some deliverable, such as a set of diagrams and a list of recommendations.  Each set of recommendations will likely need their own estimation and planning cycle.  Here's an approach you can use to help start your plan:

• Whiteboard all the components of your solution.  You might want to take several tries to get it right: grouping related components together, etc.  Ask a team member to validate that all parts of the solution are represented.  When you've got a good handle on it, draw it out in Visio.  (I find a whiteboard to be less restrictive at this phase...)
• Gather feedback on the current design from as many different sources as possible.  Team members may be able to provide pain points about the current architecture and how it has failed in the past; other solution architects may have different approaches or experiences that may lead to a more informed strategy.  Use this feedback to compile a list of faults and code smells that are present in the current code.
• Set goals for a new architecture.  The pain points outlined by your developers may inspire you; but ideally your new architecture is clean, performs well, requires less code, secure, loosely coupled, easily testable, flexible to change and more maintainable -- piece of cake, right?
• Redraw the components of your solution under your ideal solution architecture. It can be difficult to look past the limitations of the current design, but don't let that influence your thinking.  When you're done, compare this diagram to the current solution.   Question everything: How are they different?  What are the major obstacles to obtaining this design and how can they be overcome?  What represents the least/most effort?  What are the short versus long term changes?  What must be done together versus independently?  How does your packaging / deployment / build script / configuration / infrastructure need to change?

After this short exercise, you should have a better sense for the amount of changes and the order that they should be done.  The next step is finding a way to introduce these changes into the your release schedule. 

Introducing Change

While documenting your findings and producing a deliverable is key, perhaps the best way to introduce change into the release schedule is the direct route: tell the decision makers your plans.  An informed client/management is your best ally, but you need to speak their language. 

For example, in a project where the user-interface code is tied to service-objects which are tied directly to web-services, it's not enough to state this is an inflexible design.  However, by outlining a cost savings, reduced bugs and quicker time to market by removing a pain point (the direct coupling between UI and Web-Services prevents third parties or remote developers from properly testing their code) they're much more agreeable to scheduling some time to fix things.

For an existing project, it's very unlikely that the client will agree to a massive refactoring such as changing all of the underlying architecture for the UI at the same time.  However, if a business request touches a component that suffers a pain point, you might be able to make a case to fix things while introducing the change.  This is the general theme of refactoring: each step in the plan should be small and isolated so that the impact is minimal.  I like to think of it as a sliding-puzzle.

Introducing change to a project typically gets easier as you demonstrate results.  However, since the first steps to introduce a new design typically requires a lot of plumbing and simultaneous changes, it can be a very difficult sell for the client if these plumbing changes are padded into a simple request.  To ease the transition it might help if you alleviate the bite by taking some of the first steps on your own: either as a proof of concept, or as an isolated example that can be used to set direction for other team members.

Here are a few things you can take on with relatively minor effort that will ease your transition.

Rethink your Packaging

A common problem with legacy projects is the confusion within the code caused by organic growth: classes are littered with multiple disjointed responsibilities, namespaces lose their meaning, inconsistent or complex relationships between assemblies, etc.  Before you start any major refactoring, now is a really good time to establish how your application will be composed in terms of namespaces and assemblies (packages).

Packaging is normally a side effect of solution design and isn't something you consider first when building an application from scratch.  However, for a legacy project where the code already exists, we can look at using packaging as the vehicle for delivering our new solution.  Some Types within your code base may move to new locations, or adopt new namespaces.  I highly recommend using assemblies as an organizational practice: instruct team members where new code should reside and guide (enforce) the development of new code within these locations.  (Just don't blindly move things around: have a plan!)

Recently, Jeffrey Palermo coined the term Onion architecture to describe a layered architecture where the domain model is centered in the "core", service layers are built upon the core, and physical dependencies (such as databases) are pushed to the outer layers.  I've seen a fair amount of designs follow this approach, and a name for it is highly welcomed -- anyone considering a new architecture should take a look at this design.  Following this principle, it's easy to think of the layers or services residing in different packages.

Introduce a Service Locator

A service locator is an effective approach to breaking down dependencies between implementations, making your code more contract-based and intrinsically more testable.  There are lots of different service locator or dependency injection frameworks out there; a common approach is to write your own Locator and have it wrap around your framework of choice. The implementation doesn't need to be too complicated, even just a hashtable of objects will do; the implementation can be upgraded to other technologies, such as Spring.net, Unity, etc.

Perhaps the greatest advantage that a Service Locator can bring to your legacy project is the ability to unhook the User Interface code from the Business Logic (Service) implementations.  This opens the door to refactoring inline user-interface code and user controls.  The fruits of this labor are clearly demonstrated in your code coverage statistics.

Not all your business objects will fit into your service locator right away, mainly because of strong coupling between UI and BL layers (static methods, etc).  Compile a list of services that will need to be refactored, provide a high-level estimate for each one and add them to a backlog of technical debt to be worked on a later date. 

You can move Business Layer objects into the Service Locator by following the following steps:

• Extract an interface for the Service objects.  If your business logic is exposed as static methods, you'll have some work to convert these to instance methods.  I'll likely have a follow-up post that shows how to perform these types of refactoring using TDD as a safety net -- more later...
• Register the service with the service locator.  This work will depend on how your Service Locator works, either through configuration settings or through some initiation sequence.
• Replace the references to the Service object with the newly extracted interface.  If your business logic is exposed using static methods, you can convert the references to the Service object in the calling code to a property.
• Obtain a reference to the Service object from the Service Locator.  You can either obtain a reference to the object by making an inline request to the Service Locator, or as the point above encapsulate the call in a property.  The latter approach allows you to cache a reference to the service object.

Next steps

Now that you have continuous integration, reports that demonstrate results, unit tests for the presentation layer, the initial ground-work for your new architecture and a plan of attack -- you are well on your way to start the refactoring process of changing your architecture from the inside out.  Remember to keep your backlog and plan current (it will change), write tests for the components you refactor, and don't bite off more than you can chew.

Good luck with the technical debt!

Automate Visual Studio from external tools

While cleaning up a code monster, a colleague and I were looking for ways to dynamically rebuild all of our web-services as part of build script or utility as we have dozens of them and they change somewhat frequently.  In the end, we decided that we didn't necessarily need support for modifying them within the IDE and we could just generate them using the WSDL tool.

However, while I was researching the problem I stumbled upon an easy method to drive Visual Studio without having to write an addin or macro; useful for one-off utilities and hair-brain schemes.

Here's some ugly code, just to give you a sense for it.

You'll need references to:

• EnvDTE - 8.0.0.0
• VSLangProj - 7.0.3300.0
• VSLangProj80 - 8.0.0.0

namespace AutomateVisualStudio
{
  using System;
  using EnvDTE;
  using VSLangProj80;

  public class Utility
  {
      public static void Main()
      {
          string projectPath = @"C:\Demo\Empty.csproj";
          Type type = Type.GetTypeFromProgID("VisualStudio.DTE.8.0");
          DTE dte = (DTE) Activator.CreateInstance(type);
          dte.MainWindow.Visible = false;

          dte.Solution.Create(@"C:\Temp\","tmp.sln");
          Project project = dte.Solution.AddFromFile(projectPath, true);

          VSProject2 projectV8 = (VSProject2) project.Object;
          if (projectV8.WebReferencesFolder == null)
          {
              projectV8.CreateWebReferencesFolder();
          }

          ProjectItem item = projectV8.AddWebReference("http://localhost/services/DemoWS?WSDL");
          item.Name = "DemoWS";
            
          project.Save(projectPath);
          dte.Quit();
      }
  }
}

Note that Visual Studio doesn't allow you to manipulate projects directly; you must load your project into a solution.  If you don't want to mess with your existing solution file, you can create a temporary solution and add your existing project to it.  And if you don't want to clutter up your disk with temporary solution files, just don't call the the Save method on the Solution object.

If you had to build a Visual Studio utility, what would you build?

Catching server errors with WatiN: redux

Stumbled upon this post about how to catch server errors for your WatiN tests.  The approach outlined provides a decent mechanism for detecting server errors by sub-classing the WatiN IE object.  While I do appreciate the ability to subclass, it bothers me a bit that I have to write the logic in my subclass to detect server errors.  After poking around a bit, I think there's a more generic approach that can be achieved by tapping into the NavigateError event of the native browser:

public class MyIE : IE
{
    private InternetExplorerClass ieInstance;
    private NavigateError error;

    public MyIE()
    {
        ieInstance = (InternetExplorerClass) InternetExplorer;
        ieInstance.BeforeNavigate += BeforeNavigate;
        ieInstance.NavigateError += NavigateError;
    }

    public override void WaitForComplete()
    {
        base.WaitForComplete();
        if (error != null)
        {
            throw new ServerErrorException(Text);
        }
    }

    void BeforeNavigate(string URL, int Flags, string TargetFrameName, ref object PostData, string Headers, ref bool Cancel)
    {
        error = null;
    }

    void NavigateError(object pDisp, ref object URL, ref object Frame, ref object StatusCode, ref bool Cancel)
    {
        error = new NavigateError(URL,StatusCode);
    }

    private class NavigateError
    {
        public NavigateError(object url, object statusCode)
        {
            _url = url;
            _statusCode = statusCode;
        }

        private object _url;
        private object _statusCode;
    }
}
public class ServerErrorException : Exception 
{
    public ServerErrorException(string message) : base(String.Format("A server error occurred: {0}",message))
    { } 
}

Few caveats:

• Constructor of MyIE needs to be updated to reflect the other constructor overloads.
• Need to ensure that URL of NavigateError is the same URL of BeforeNavigate
• Test library needs to reference the Interop.SHDocVw wrapper for Internet Explorer
• Only tested with IE7

While I wouldn't consider COM Interop to be a "clean" solution, it is more bit more portable between solutions.  And if it was this easy, why isn't it part of WatiN anyway?

Legacy Projects: Test the User Interface with Selenium or WatiN

Following up on the series of posts on Legacy Projects, my legacy project with no tests now has a build server with empty coverage data.  At this point, it's really quite tempting to start refactoring my code, adding in tests as I go, but that approach is slightly ahead of the cart.

Although Tests for the backend code would help, they can't necessarily guarantee that everything will work correctly.  To be fair, the only real guarantee for the backend code would be to write Tests for the existing code and then begin to refactor both Tests and code.  This turns out to be a very time consuming endeavour as you'll end up writing the Tests twice.  In addition, I'm working with the assumption that my code is filled with static methods with tight-coupling which doesn't lend itself well to testing.  I'm going to need a crowbar to fix that, and that'll come later.

It helps to approach the problem by looking at the current manual process as a form of unit testing.  It's worked well up to this point, but because it's done by hand it's a very time consuming process that is prone to error and subjective of the user performing the tests.  The biggest downfall of the current process is that when the going get's tough, we are more likely to miss details.  In his book, Test Driven Development by Example, Kent Beck refers to manual testing as "test as a verb", where we test by evaluating aspects of the system.  What we need to do is turn this into "test as a noun" where the test is a "procedure to evaluate" in an automated fashion.  By automating the process, we eliminate most of the human related problems and save a bundle of time. 

For legacy projects, the best place automation starting point is to test the user interface, which isn't the norm for TDD projects.  In a typical TDD project, user interface testing tends to appear casually late in the project (if it appears at all), often because the site is incomplete and the user interface is a very volatile place;  UI tests are often seen as too brittle.  However, for a legacy project the opposite is true: the site is already up and running and the user interface is relatively stable; it's more likely that any change we make to the backend systems will break the user interface.

There is some debate on the topic of where this testing should take place.  Some organizations, especially those where the Quality Assurance team is separated from the development teams, rely on automated testing suites such as Empirix (recently acquired by Oracle) to perform functional and performance tests.  These are powerful (and expensive) tools, but in my opinion are too late in the development cycle --  you want to catch minor bugs before they are released to QA, otherwise you'll incur an additional bug-fix development cycle.  Ideally, you should integrate UI testing into your build cycle using tools that your development team is familiar with.  And if you can incorporate your QA team into the development cycle to help write the tests, you're more likely to have a successful automated UI testing practice.

Of the user interface testing frameworks that integrate nicely with our build scripts, two favourites come to mind:  Selenium and WaitN.

Using Selenium

Selenium is a java-based powerhouse whose key strengths are platform and browser diversity, and it's extremely scalable.  Like most java-based solutions, it's a hodge-podge of individual components that you cobble together to suit your needs; it may seem really complex, but it's a really smart design.  At its core, Selenium Core is a set of JavaScript files that manipulate the DOM.  The most common element is known as Selenium Remote-Control, which is a server-component that can act as a message-broker/proxy-server/browser-hook that can magically insert the Selenium JavaScript into any site --  it's an insanely-wicked-evil-genius solution to overcoming cross-domain scripting issues.  Because Selenium RC is written in Java, it can live on any machine, which allows you to target Linux, Mac and PC browsers.  The scalability feature is accomplished using Selenium Grid, which is a server-component that can proxy requests to multiple Selenium RC machines -- you simply change your tests to target the URL of the grid server.  Selenium's only Achilles' heel is that SSL support requires some additional effort.

A Selenium test that targets the Selenium RC looks something like this:

[Test]
public void CanPerformSeleniumSearch()
{
    ISelenium browser = new DefaultSelenium("localhost",4444, "*iexplore", "http://www.google.com");
    browser.Start();
    browser.Open("/"); 
    browser.Type("q", "Selenium RC"); 
    browser.Click("btnG");

    string body = browser.GetBodyText();

    Assert.IsTrue(body.Contains("Selenium"));

    browser.Stop(); 
}

The above code instantiates a new session against the Selenium RC service running on port 4444.  You'll have to launch the service from a command prompt, or configure it to run as a service.  There are lots of options.  The best way to get up to speed is to simply follow their tutorial...

Selenium has a FireFox extension, Selenium IDE, that can be used to record browser actions into Selenese.

Using WatiN

WatiN is a .NET port of the java equivalent WatiR.  Although it's currently limited to Internet Explorer on Windows (version 2.0 will target FireFox), it has an easy entry-path and a simple API.

The following WatiN sample is a rehash of the Selenium example.  Confession: both samples are directly from the provided documentation...

[Test]
public void CanPerformWatiNSearch()
{
    using (IE ie = new IE("http://www.google.com"))
    {
        ie.TextField(Find.ByName("q")).TypeText("WatiN");
        ie.Button(Find.ByName("btnG")).Click();

        Assert.IsTrue(ie.ContainsText("WaitN");
    }
}

As WatiN is a browser hook, its API contains exposes the option to tap directly into the browser through Interop.  You may find it considerably more responsive than Selenium because the requests are marshaled via windows calls instead of HTTP commands.  Though there is a caveat to performance: WatiN expects a Single Threaded Apartment model in order to operate, so you may have to adjust your runtime configuration.

WatiN also has a standalone application, WatiN Recorder, that can capture browser activity in C# code.

UI Testing Strategy Tips

Rather than writing an exhaustive set of regression tests, here's my approach:

• Start Small: Begin by writing coarse UI tests that demonstrate simple functionality.  For example, a test that hits the homepage and validates that there aren't any 500 errors.  Writing complex tests that validate specific HTML markup take longer to produce and often tend to be brittle and less maintainable in the long run.
• Map out and test functional areas:  Identify the key functional elements of the site that QA would normally regression test for a build: login, update a profile, add items to a shopping cart, checkout, search, etc.  Some of these will be definite road-blockers that you'll have to work around -- you'll quickly realize you can't guarantee profile-ids and passwords between environments, or maybe your product catalog changes too frequently.  Some will require creative thinking, others may inspire custom testing tools that can perform test-specific queries or functions.  You may even find a missing need in the backend systems that you could build and leverage as part of your tests. 
• Write tests for functional changes:  You don't need to sit down an write an exhaustive site wide regression fixture -- focus on the areas that you touch.  If you write tests before you make any changes you can use these tests to help automate the debugging process.  The development effort is relatively small -- you have to test it anyway a dozen times by hand.
• Write tests for testing bugs!!!:  What better motivation could you have?  This is what regression testing is all about!
• Design for different environments:  The code examples above have URLs hard-coded.  Consider using a tool that uses configuration settings to retrieve or help construct URLs so that you can run your UI tests against your local instance, dev, build-server, QA, integration, etc.  UI Tests make great build-validation utilities!