Broken SmtpClient in .Net

I’ve been meaning to post about this for a while as I discovered the bug a few weeks ago, SmtpClient in .Net 1.1 – 3.5 is broken.

By broken, I mean non-standards compliant with the SMTP specification.  The SmtpClient object is a fantastic little object that can handle most scenarios you would need for personal apps and sending emails, including multiple encoding formats and SSL handling.  However, it has a flaw – it doesn’t close connections to the server correctly.

The SMTP spec calls for the client to issue the “QUIT” command when finishing up communications.  The SmtpClient object instead, after sending the mail data, returns control back to the calling app and leaves the connection hanging.  Most servers seem to handle this ok but it’s certainly not good practice, and it’s causing me no end of bother now.

I’ve been working on a project called PseudoSmtpServer, which is exactly as it sounds, a fake smtp server designed for Test-Driven Development.  It implements the standards-based smtp commands but instead of possessing the usual smtp internals, it stores all information its sent so that it can be queried by test code to ensure sends occurred properly.

It’s been an interesting project, but I’ve had quite a lot of problems, some of which are due to this SmtpClient bug and some due to the TCPListener not performing as expected (in particular, taking a long time to release a socket.)  This generally leads to performing erratically, seeming to fail without cause generally because the previous test claims to have cleaned up but in reality hasn’t finished releasing the socket for the next test.

I’m currently rewriting my listener to make direct use of sockets rather than relying on TCPListener’s implementation, and I am led to believe that the bug in SmtpClient may finally have been fixed (about time!) with the release of .Net 4.0.  I’m currently trying to upgrade the project to .Net 4.0 but am having difficulty with the Moq libraries.  I’m currently investigating this and will post more later on the topic.


AddressAccessDeniedException thrown when starting a service with ServiceHost on Localhost

I’ve been working my way through Apress’ “Introducing dot Net 4.0 with Visual Studio 2010” to get a handle on what’s new in the latest version of my environment. I skipped this step when moving from 2.0 to 3.5 which led to me missing quite a few great tips, which I was determined would not happen this time.

Working through Chapter 7, WCF Services, I’ve found something the book author seems to have missed. One of his code samples fails to work for some people, including myself. I tracked down the problem to the fact I was running Vista (strangely, I would assume the problem exists then on Windows 7, the authors operating system, but maybe not).

Basically, the example instructs you, having written a service, to create a console app that registers a ServiceHost object and open it, thus starting your service. This is done like this:

ServiceHost Host = new ServiceHost(typeof(YourServiceType), new Uri(“http://localhost:8888/myservice”); Host.Open();

After this, assuming all goes well, you can browse to localhost:8888/myservice and view the service as published. For me, it didn’t go well. I hit F5 and as the application began to run, it threw an AddressAccessDeniedException claiming that I didn’t have access rights to create an endpoint at that address.

This is confusing of course, until you realise that Vista requires you to elevate your permissions to do various things, one of which is open ports and create address endpoints. F5 in Visual Studio is completely unable to perform this task.

I have found two solutions to this issue.

The first, given that in this particular example we’re using a console app, is to open a command prompt with full administrator access (Run As Administrator), change directory to the bin/debug directory of the program and run it from there. It works fine.

The second is to open Visual Studio itself with full administrator access and then F5 will work as expected. It’s an interesting little bug/feature and worth keeping in mind next time you stumble over an unexpected access denied issue.

Geordie Guy waxing lyrical on the HTC Desire

An old friend of mine, Geordie, has recently posted his appraisal of the HTC Desire, considered against his own iPhone 3Gs. It makes a good read.

Click here for the whole article

Want the capsule summary? He puts it like this:

I think the Desire, the HTC brand and the Google OS are all direct threats to Apple’s smartphone market and they better make up another batch of addictive koolaid before the tides turn. I don’t think they will.

It’s about time we got a bit of competition in this market before all innovation slowly stagnates under the control of Big Brother Jobs. 😉

Nintex Workflow 2007

Recently I’ve been working on site with a local client helping to set up a new SharePoint 2007 based intranet site. Those of you who have been following my blog for some time would realise that this is really a bit of a homecoming for me; its the work I started out doing so many years ago.

I’ve learnt a lot these last few days, looking at things once again from a customers perspective. Our client was quite technical himself and I was there less to design and build the intranet site itself and more to provide the benefit of my experience and bootstrap his own learning.

As is usual in these sort of situations, his own explorations prior to engaging me showed me a few things I hadn’t encountered myself to this point. One of these was Nintex Workflow, a third party add-on to SharePoint 2007.

I have, as a rule, stayed away from third party add-ons in the past. In my regular role I design and develop solutions to be deployed to client servers and so we tend to stay away from including third part controls, over which we have no control, to our solutions lest they cause unknown problems we might be unable to resolve.

Nintex Workflow however is far too tempting to pass up. Traditionally our method has been to suggest the built in workflows wherever possible, and to use SharePoint designer as another (uncomfortable) option for simple workflows. SharePoint designer has the advantage of being fast and simple, however workflows created this way must be created in-situ as they are hard-wired into the environment they are created in. This is not a great situation for us, as we prefer to develop off site on test systems and create a deployment package wherever possible.

The other option of course is to use completely custom workflows. This is a powerful option that provides full control over every aspect of the workflow, but has its own disadvantages. One of these is that even tiny changes to the workflow often require a complete rebuild and redeploy to make it happen.

Nintex Workflow takes SharePoint designer workflows and custom workflows, sticks them in a blender and serves you up the result. It provides a visual editor inside the SharePoint environment itself in order to plot out the workflow flowchart and a massive library of components ranging from built-in approval/feedback tasks similar to the standard SharePoint ones all the way to the ability to make calls to external web-services. They also provide the ability to import and export workflows, which would likely aid in deployment.

A quick dart around their website reveals they are also providing an SDK to allow developers to create their own specialised components (one of the few saving graces of SharePoint designer workflows) and a version is currently in the works targeting SharePoint 2010.

Whilst working on-site I’ve created several small workflows for their new intranet and it really is the simplest, most powerful SharePoint workflow tool I’ve yet used. If you’re maintaining, or planning, on complicated workflows, you really should give it a look.

Nintex Workflow 2007

Disclosure: I am not affiliated with Nintex in any way, have received no compensation of any kind for this review, and in fact have never had any communication with them whatsoever. I just really do think this is a great product.