Tag Archives: .Net

Ensuring WCF Correctly Reports Errors

This is another one of my note to my future self posts, that might be useful to somebody else, so skip past if you don’t know what WCF is…

Anyway, if you’re still here, I’ve spent the past day or so trying to track down a problem in some WCF code. Essentially the problem has been that whilst I have been out of the office over the last week, we’ve had a change propagate through to our development server which has caused problems with some of our existing services, specifically some code where one service needs to make a call to another service running on the same machine to finish it’s work. To do this it needs to pass through the Kerberos ticket that the initial service has received, and whilst up to now it has been quite happily doing this, now it has stopped and instead is getting the credentials for the underlying windows service passed.

The problem was made a lot harder to diagnose by a little WCF gotcha whereby the error that is generated is overwritten when the calling code tries to dispose of the service object. Damien McGivern has an excellent post describing the problem and giving a solution, however it didn’t quite meet our needs, as we sometimes need to specify an endpoint when creating the proxy object.

To get around the problem, I adapted Damien’s code slightly creating an extension method taking an object of type TService rather than creating the object within the method, so the method can be used as follows:

new RelationshipServiceClient().UsingService(service => ... );

Whilst it doesn’t actually solve the mystery of why our server started mishandling WCF calls, it did at least give us a bit more clue!

A Whole Load of Empty

I have a lot of respect for Jeff Atwood and his Coding Horror blog. He often has interesting and informed insights into software development, and generally knows what he is talking about.

Yesterday he posted an article under the heading “The Best Code is No Code At All” where, backed by comments from Wil Shipley he argues for the benefits of code brevity – put simply reducing the volume of code a developer has to read to understand how an application works. This is certainly something I agree with. However then he gives an example of a simple change to improve code brevity:

Instead of

if (s == String.Empty)

he suggests

if (s == "")

He backs the suggestion with the following statement:

It seems obvious to me that the latter case is better because it’s just plain smaller. And yet I’m virtually guaranteed to encounter developers who will fight me, almost literally to the death, because they’re absolutely convinced that the verbosity of String.Empty is somehow friendlier to the compiler. As if I care about that. As if anyone cared about that!

This is one occasion where I significantly disagree with Jeff on this when it comes to development in .Net.

Firstly, using “” is error prone. Put a space between the quotes, and the compiler won’t pick it up – it is still a valid string literal. It may be a minor change, but it will break your application, and is the kind of typo that is a pain to find. A typo in String.Empty will be picked up by the compiler, rather than coming up in testing, or worse still on a customer site.

Secondly, using String.Empty is more efficient (although as any .Net programmer should be able to tell you, checking the length of the string is more efficient still). To understand why String.Empty is more efficient it helps to understand how .Net handles strings. In .Net, a string is immutable – it never changes, so for example routines that concatenate strings together to build up database queries will be repeatedly creating new strings throughout the whole process. The .Net Framework helpfully provides a StringBuilder object to use in such situations. However the same is true when considering any literal, so “” has to become a string object, and yet you already have String.Empty which is exactly that.

However, .Net has another trick up it’s sleeve, in that it maintains something called the string intern pool. Every string literal is stored in this pool, and when a new literal is encountered that is already in the pool the version from the pool is used instead, saving the overhead of creating a new object. Whilst that speeds up literals somewhat, the application still has to do slight more than if it is just handed a suitable object straight off. Using String.Empty is slightly more efficient than “” – and it’s nothing to do with being friendlier to the compiler.

It’s entirely fair to argue that the performance differences are negligible in most situations, a point with which I’d agree, however the differences magnify if you are producing code with a lot of literals, and a lot of string comparisons. As an aside check out this posting from a former member of the CLR team at Microsoft where he ponders whether automatically interning the entire pool when an assembly is loaded is a good or bad idea.

Put simply, if you know you’re going to be repeatedly comparing to a string value, and performance is an issue, don’t use a string literal, as every comparison you’ll get the overhead of it looking up in the string intern pool – and if the string value is an empty string, don’t bother with either and use String.Length, or better still String.IsNullOrEmpty if there is the possibility that the string is null (or Nothing in VB.Net), both of which are faster than a string comparison in that situation.

So sorry Jeff – I see your point about brevity, but I’m sticking with String.Empty!

Great Support from MZTools

I’m a great fan of MZTools. On paper the features it offers don’t really seem spectacular, offering templates and assistants for commonly used constructs and tasks, an improved find and replace and so on. However, whilst on their own, each seems a fairly trivial addition or change, together they make a big difference.

I had the freeware VB6 and VBA version installed at SSE pretty well since I arrived, but until recently I hadn’t really looked at the newer .Net versions, not thinking I really needed them.

Anyway, recently I decided to give an evaluation of the .Net version a go, and, as with any good evaluation, found that I missed the features when the evaluation expired, so I decided to put my money down, and purchase a copy for myself.

I went for the VS2005 licence – although I primarily still work with VS2003, as Carlos Quintero, the developer kindly throws in a free copy of the 2003 version too. The 2003 version installed fine, however I hit a bit of a problem with the 2005. Part way through the install it came up with a pretty odd looking error message.

I e-mailed a copy of the message off to Carlos, who asked what platform I was using. I replied telling him that I had VS2005 installed onto an XP64 partition – and Carlos confirmed that he wasn’t able to support XP64, as he is still developing using a 32-bit system. He kindly offered me a refund, however since I could use it on a 32-bit install, and he said he was going to support 64-bit in the future I said no.

I wasn’t expecting to hear anything else for a while, at least until a 64-bit native version turned up, however this afternoon I got another e-mail from Carlos double checking my setup, followed by a zip file containing a replacement for one of the files in the installation. He asked me to replace the file, and run a single command at a DOS prompt, and hey presto, MZTools fired up fine under VS2005.

When you consider what lousy support you can get from some of the big names in the industry, it is great when you come across someone like Carlos with a great little product, and a fantastic level of support to back it up.