Sharing the Strong Name Key File

Pedantry in motion: even though you shouldn't ever change your public key (see log4net versions 1.2.9 - 1.2.10 for an excellent reason) I still like to share a single strong name key file (.SNK) between all projects in a solution. Using Visual Studio 2005, this can be accomplished thusly:
1) Store the key in a parent folder of the project, so it can be accessed by all projects in the solution.
2) Add it as a link (use the add existing file menu)
3) In the signing tab of the project properties window, check the "sign the assembly" check box and choose the path from the drop down list. You will notice this is the path to the actual .snk file - not a local copy of that file.

Anonymous Methods

It looks like I've fallen off the bleeding edge again; this time I'm talking about anonymous methods: C#'s answer to the Java concept of anonymous inner classes. They've been available since C# 2.0 came out nearly two years ago. See this guy's blog for some cool stuff you can do with them. I've especially taken to sorting lists this way. :)

SQL Server 2005 Connections

So, you can see your local database server using SSMSEE, but when you fire up Visual Studio you can't find it anymore. First, you need to set up the surface area configuration to allow remote TCP/IP connections, then you need to configuration manager to choose a TCP port. If you choose 1433 then Hey, Presto! and everything should start working magically. If you intend to connect to the database server from another machine, don't forget to allow traffic over port 1433 using Windows Firewall.

Multi-stage deployments

I was recently foxed, I'll have to admit. Even when you don't think your own code's behaviour will impact another application, distributed shared environments seem to make it a likely event. For instance, you deploy a component upgrade onto one application server only... but you are unaware of the fact that references to your component are cached by clients, each of which can switch application servers at the drop of a hat. The result: thousands of errors an hour and irate support teams! :-)

Anyway, the lesson learned is that deployments - like code - should be thoroughly planned and all assumptions should be documented and passed over by someone who knows the target environment really well.

The other lesson learned is: don't change anything that you don't NEED to change. If you are required to alter the behaviour of one method, that's all you should do. Don't be clever and think that you can now refactor the code too; you'll get another opportunity to do that if it's really necessary. I guess it boils down to the fact that if your code was tightly coupled to start with - which, let's face it, a lot of code is - then you're more likely to break something. Something as silly as a client caching the method ID from an IDL definition instead of late binding using the method name can cause hours of anguish. Don't say I never warned you.

MSF Nostalgia

I'm determined not to make the same mistake again. A keen follower of process methodologies like RUP and MSF (and ACA.NET), I threw caution to the wind in developing a quote-unquote "prototype" recently. There wasn't much in the way of requirements, and it seemed like a cinch. Soon it became apparent that the business owners' visions weren't aligned and nobody could agree what the system should do. And I kept quiet because I had no idea what it should do; I'm the technology guy who would put it together from a requirements document. WRONG! What I should have done is forced them to agree on the vision ... then on the behaviour ... then on the look and feel. Lesson #1: to have their sign-off on these documents would have made my life a lot easier in the final stages where we quibbled over the system's behaviour (my interpretation of their ever-changing minds). Lesson #1.5: to get the sign-off of more senior people than those I dealt with every day would have more impact than the easily vetoed sign-off of not-so-high-up-management. Lesson #2: most importantly, have a signed-off requirements document. This you can use as a test plan, and you can use to check the boxes that everything you promised has been delivered. In summary, I think I delivered far too much functionality for free - but that's not necessarily good for the business because there was never a 100% clear and auditable understanding between myself and them. Lesson #3: never underestimate the importance of "I'd like that in writing".

IExecutionStep

Why write a blog entry about the ASP.NET HTTP pipeline when someone else has already done it better? I'm talking about Rick Strahl's Low level look at ASP.NET architecture. Note to self: as soon as you have a box running IIS 7, see if you can't reverse-engineer everything down so far as to understand even the IExecutionStep interface.

Hidden Face of NTFS Permission Issues

How can everyone be so naïve about NTFS permissions? Just yesterday I had an Associate Director bring a web site to its knees by cut-and-pasting a configuration file from somewhere else on the system. Today's problem was far more obfuscated though, and we would have saved six hours of 3 devs' (and countless users') time if the same (recently promoted) Associate Director had looked in the event log as suggested to him. As it turns out, when the IUSR_MACHINENAME user account is locked out - and IIS is configured to only allow anonymous access - IIS will not serve any static content. If you allow Integrated Windows Authentication as well, then IIS will fall back to that mechanism (a corollary: if your service delivery guy is an administrator, everything will appear fine to him). In the first instance, a Filemon trace won't show failures of w3wp.exe trying to access the files, because it's the logon that's failing - and this can be very confusing! In the second instance, it will clearly display the NT username (of the token that w3wp.exe's associated with the current request) next to the file open failure.

So, next time you see the error: access denied, and you've ruled out the fact that a Muppet has messed up the permissions on a critical file... look in the Event Viewer and save yourself a bunch of time. It's there for a reason. Use it. Take a step further even, and write to it yourself!

HTML, JavaScript and Background-Color

Well this had me confused for an hour or so. Consider the HTML element below:

<div style="background-color:red">

First, I tried to set the color programmatically using JavaScript. I knew that layer.style.background-color wouldn't work so I typed in layer.style["background-color"] = "green"; No luck. Eventually, I noticed that layer.style["background"] worked, and I went on my merry way. For about 30 seconds. Now I needed to read the background-color value from a layer, and my previous two attempts were turning up empty strings.

With a bit of Googling, I discovered that background-color should be accessed as layer.style.backgroundColor (or layer.style["backgroundColor"]).

Google saves the day.

(A couple of weeks later, and programmatically setting the css class of an HTML element has tripped me up. It seems the property is called "className" in JavaScript.)

???

It's pretty irritating to have someone else's XML document object model - on a remote server with little in the way of a debugging tool kit - screw up your document by replacing all non-ASCII characters with the ? (Question Mark) character. It's especially annoying if your application is used globally by important clients and their data contains lots of accented characters. But it's better to spit out loads of question marks than to completely F&*^ things up by just chewing off the most significant bit each time a non-ASCII character comes along (ASCII characters are all encoded using the 7 least significant bits of each byte). The first issue is a display problem that will usually only be caught by the human eye. The second one affects other law-abiding XML parsers because they are being fed invalid XML documents. A client is more likely to forgive a couple of question marks on the screen - at least they can see the rest of the data - than they are to forgive an error page because their document couldn't even be parsed.

CallContext

Today, I discovered CallContext, and it is good. I will probably use it lots instead of being tied to HttpContext. Sure, there's a downside in that we won't be able to switch threads freely, but hey, at least it works in non-Web environments, so I don't have to reference System.Web.dll from all my core and application logic classes.

2 days later: I have torn out most of the remaining hairs from my scalp. It turns out that ASP.NET doesn't - in fact - guarantee that your entire request will be executed on the same thread (see here for more details). At least the HttpContext class still works; even though it depends on an underlying CallContext (when an HttpApplicationFactory initialises an HttpApplication, the new HttpContext ...blahblahblah I'm tired) the HttpContext is moved from thread to thread whenever one of this switches occurs.

What I have learned: don't trust simple Google searches that tell you each ASP.NET request will only run on a single thread.

System.OutOfMemoryException

So you've run out of memory. The question is: what kind of memory don't you have enough of? The answer - it seems - isn't "physical", it's actually "virtual". Most 32-bit Windows processes are limited to 2GB of user-mode virtual address space (you can increase this to 3GB if you know what you're doing), and this is what you've just exhausted. If the CLR cannot find a contiguous section of free virtual memory to allocate for a new object - BANG! - the exception gets thrown.

Update: http://msdn.microsoft.com/msdnmag/issues/06/11/CLRInsideOut/default.aspx describes a second reason: "or there is not enough physical memory available in order to commit."

NUnit and Visual Studio 2003

In any typical application that I'm asked to develop, there is an assembly of business objects I'm compelled to unit test. So I create a new project to the solution with ".Test" appended to the name (e.g to unit test the CDMA.Business assembly, I'd create a new CDMA.Business.Test class library project that references both the CDMA.Business and nunit.framework assemblies). Frequently, the subject of unit tests depends on application configuration settings, so I'll create a new file called CDMA.Business.Test.dll.config (note that this is the name of the assembly, with ".config" appended) within the test project and then I'll add a new Post-build event to copy the file to the target directory. Project Properties -> Common Properties -> Build Events -> Post-build Event Command Line:

xcopy /y "$(ProjectDir)$(TargetFileName).config" "$(TargetDir)"

To enable debugging via the F5 key, I'll use the following settings in Project Properties -> Configuration Properties -> Debugging:

Debug Mode: Program
Start Application: C:\Program Files\NUnit 2.2.8\bin\nunit-gui.exe
Command Line Arguments: CDMA.Business.Test.dll

If you then set your unit test project as the start up project you can just press the F5 key and Visual Studio will automagically build the project, copy the configuration file, run the nunit-gui executable and attach the debugger to it. To skip the last step, just press CTRL-F5 instead.

C# 3.0

Ted Neward explains how the new features are nothing more than syntactic sugar that makes programmers' lives a little easier. For example, all the IL code produced by the C# 3.0 compiler can be reverse engineered by Lutz Roeder's .NET Reflector to show you how the feature's actually been implemented. Brilliant.

Extension Methods to the Rescue

Today I added some caching to a prototype application I'm developing at work. Microsoft Enterprise Library was my implementation library of choice, but I was frustrated by the choice of available overloads for CacheManager.Add(). Rather than add my own overload, spoil the clean interface and recompile the assembly, I ended up writing a single method on a static class that took an instance of the CacheManager, key, value and expiration as parameters, adding in the default values in a call to the CacheManager object. Now this may not be object-oriented, but it's very similar to how extension methods work in C# 3.0 (in my opinion, they exist solely to _fake_ the object-orientedness in calling code). In fact, when you declare a class like this:

public static class CacheManagerExtension
{
public static readonly TimeSpan DefaultAbsoluteExpiration = TimeSpan.FromMinutes(5);
public static void Add(this CacheManager cacheManager, string key, object value, TimeSpan absoluteExpiration)
{
cacheManager.Add(key, value, ..., new AbsoluteExpiration(absoluteExpiration), ...);
}
}

the new C# 3.0 compiler (figuratively speaking) recognises the "this" keyword in the parameter list, and marks the method, class and assembly with the ExtensionAttribute custom attribute. Now, you can call the Add method like this:

cacheManager.Add(key, value, CacheManagerExtension.DefaultAbsoluteExpiration);

and the compiler (and hopefully Intellisense) - upon realising that no method with that signature exists on the CacheManager class - will translate it into a call on the static class marked with the ExtensionAttribute attribute.

Oh yeah, and my other gripe with Microsoft Enterprise Library is the fact it's caching is not aspect-oriented, but that's the topic of another post...

Post-script: Don't blindly assume that your service delivery team are happy to install EntLib on the production server. :-)

Using log4net

log4net is my recommended lightweight tool for emitting log statements from .NET code. I'm a firm believer that application users shouldn't see exception messages or stack traces - that information is for system administrators and developers only. I like storing log information in a database or in a text file on the server and allowing developers to view it when things start to go pear shaped.

Here's how I typically set up log4net on a project:

- Create a sub directory within your solution - called 3rdParty - and copy the log4net assembly there. This allows meto store one copy of the assembly, and reference it from all projects in the solution.
- Create a separate configuration file that I call log4net.config (I don't use Web.config or App.config)
- Use the XmlConfigurator custom attribute on the assembly that will be loaded first
(Don't forget to set the Watch property to true)
- Start appreciating the benefits of logging!

NOTE 1: If you do choose to use Web.config or App.config, the only reason you have to declare the IgnoreSectionHandler is for .NET to ignore the log4net section!

NOTE 2: No, I don't know what line of code causes the XmlConfiguratorAttribute to be reflected and subsequently configured.

C# 3.0 is not dotnetfx3; repeat;

I am a little behind the times, it seems, as Microsoft released .NET Framework 3.0 just a few days ago. Luckily, the release is true to it's name - it's just another version of the framework with the recent additions WCF, WWF, WPF and CardSpace(collectively and formerly known as WinFX). It contains neither C# 3.0 nor LINQ, both of which will be released with "Orcas". Phew. That means I have time to brush up on my knowledge of automatic type inference before a random client starts asking tough questions!

Technical Forum

If I could offer you only one tip for the future, ______ would be it. I've tentatively accepted a spot to speak on a technical subject at a forum of consultants, but I haven't yet chosen the topic. It's my first foray into the world of presentations; I don't expect it to go swimmingly but if I can judge the level of my audience and give them something useful then my job will have been done. Actually, I will judge it a success if the audience can go away and apply some practise they learned from me (or were inspired to learn by the topic).

To meet this goal, the focus needs to be on both the content and its delivery. I hope I can do it!

Exception Handling

OMF! My blood reached boiling point this week when I overheard a colleague whining when his poorly structured error handling and logging mish-mash was removed from the codebase. Similarly, it boiled a couple of months ago when a group of fellow consultants were encouraging a user interface element that would generically display stack trace information to users. Please, people, follow these guidelines:
a) Stack trace (or even exception type information) should NEVER be shown to users because you don't know what kind of sensitive (perhaps proprietary) information is contained within.
b) DON'T append long dynamic SQL statements (or any other information used solely for diagnostic purposes) to your Exception's Message property so that it can be displayed on the screen, unencrypted, rather log it separately.
c) DO use a framework like Microsoft's Enterprise Library, or a component like log4net to trace information rather than displaying it in the end user's UI.

Inertia Xenon

I released the first alpha version of Inertia Xenon - my lightweight .NET grid framework - this afternoon. Now that it's out, I need to focus my attention on the parts that require it the most. Initially, I feel that the proxy between the client and service broker could be made a lot better if I baked in a whole lot of multi-threading goodness. Next, I bet my job will be focused on improving the administrator API. Anyway, that's all just speculation. Try it out today and let me know what you think..

Defining Architecture

I'm recently attended one of a series of sessions aimed at developers who are aspiring technical architects. From previous experience, I'd decided that the IEEE definition of architecture (presented below) is spot on; now I just wish that others would subscribe to the same idea.

Architecture is the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution. [IEEE 1471]

It bothers me when junior developers use the word to buff up their resumes. It bothers me more when experienced developers are called Technical Architects by their consultancy; they should know better. Architects, by my definition, are those people who specialize in architecture as a profession. They are not the people who can recite a few patterns and have skimmed through a couple of Martin Fowler's books (although both of these traits might be present in a real architect). Hmmm. Let's see if the next session is any better.