Remember to clean up your services; WCF Clients need love too

Remember to clean up your services; WCF Clients need love too

All developers cringe when they start working on another person’s code base; it is never in the state we would like it to be. Mostly that is because we developers are a picky bunch; everything has to be just perfect and nothing anyone else does ever is! profanity Today I have been working on someone else’s project, and the first thing that jumped out at me when I was doing some clean up was that none of the WCF Service calls (well most of them) had been closed. Whilst the program was being run by a single user in debug this wasn’t really a problem, but add more users into the mix and it all goes pear-shaped.

Remember to close your WCF Services

An open WCF Service consumes resources; memory, CPU, and anything it connects to (database readers etc). Especially if the developer of the service expected to dispose of their creations when the client was closed.

Picture this; you call a WCF Service method (let’s call it GetMyStuff(int sessionId)). The GetMyStuff call hits a database to determine what stuff is yours, then to be nice and fast it spawns a bunch of threads to go and get all that stuff from other databases. You now have several connections to multiple databases open; all waiting to be closed when the service client is closed. But no one closes the client!

Normally a database will provide a few hundred possible connections to an application; when they are all open the application has to wait for more. If none of them is closed then the application will wait for a long time!

How do you close a WCF Service Client?

if(clientObject != null && clientObject.State == System.ServiceModel.CommunicationState.Opened){

Just remember to run the above code somewhere after you are done with the client, if you are using the client in a ‘using statement’ just try this:

using(var client = new ServiceClient()){


Thanks to Alina Grubnyak for providing the header image for this post on

Read more

Is HTTPS everything?

Is HTTPS everything?

This post is part of a series on HTTPS and browser security; it is partly to spread knowledge, but mostly to allow me to learn more about the subject by putting it ‘down on paper’! Enjoy, and please comment, correct, and discuss.

If you are involved in designing, developing, testing, publishing, or managing a website then you have likely already heard about HTTPS. HTTPS has been discussed from start to finish several times in recent years; by some notable people (Troy Hunt, Scott Helme, etc) and some less notable people (Don’t Take Security Advice from SEO Experts or Psychics). In the past the subject of website security was generally restricted to the purchasing of an SSL Certificate, that has changed! This series of blog posts is aimed at demystifying website security and expanding both my and your knowledge of both HTTPS and it’s supporting protocols.

Part 1: What is HTTPS?


Protocol (computing) noun: ‘a set of rules governing the exchange or transmission of data between devices.’

The internet runs over a protocol called the Hypertext transfer protocol (or HTTP for short). The Hypertext transfer protocol was originally created by the internet giant Sir Tim Berners-Lee at CERN in 1989; it allows the transfer of hypertext (HTML to you and me) over a distributed network of machines (the internet).

HTTP served us well for many years (and continues to do so), but it needed something more. The secure version of the protocol was born with the simple addition of the letter S; HTTPS. Even the most ill-informed of surfers know that the green padlock (or is it a handbag) means that their connection is secure (sort of, more on that later in the series); the HTTPS protocol is what gives us that padlock.

How does HTTPS work?

At it’s most basic HTTPS works by verifying the remote web server is who it claims to be. This is achieved by the use of a digital certificate that states they are who they say they are; think of it like a passport for a website. Taking that passport metaphor a step further; when someone shows you their British passport you know they are who they claim to be. Why, because Her Britannic Majesty’s Government has stated so, and you trust them right?


This ‘chain of trust’ for a passport applies directly to the ‘certificate chain’ used by HTTPS. When you purchased your computer/mobile/etc you indicated that you trusted the people who wrote it’s software; a company like Microsoft, Google, or Apple. Installed on your device are a set of certificates known as root certificates, companies like Microsoft install these certificates because they have explicit trust in their owners (companies like Comodo, Go Daddy, and DigiCert). Not all root certificates are managed by the operating system; your chosen web browser also bundles some certificates and can choose to trust or distrust them itself (more on that later in the series).

Those root certificates are owned by companies known as root certification authorities or root CAs for short. They choose to sell certificates onto the people who create websites; or in some cases, they delegate that trust onto other firms who act as resellers (this has been known to go a bit wrong sometimes, search for Trustico revoke if you want to know more!). So when you see an ‘HTTPS Certificate’ on this website you can trust I am who I claim to be because another firm that is trusted by the software maker you trust has said so! A chain of people, a chain of trust; simple.

Is that it?

The certificate by itself does not make the connection secure; a transfer protocol that is known as TLS (previously SSL, which is an older now less secure encryption protocol) provides the security. When you access a secure website (over https) your browser sends some information to the web server stating which secure protocols it can support. The server then picks one and a key exchange takes place (known as a handshake); this creates a secure tunnel between your browser and the remote server. From then onwards the communication is secure. How this works is a bit in-depth for this simple article, so check back later in the series for a more detailed explanation of how it works (and the dangers when it doesn’t).

Want to know more?

Subscribe to my RSS feed and keep an eye out for future articles in the series; or if you cant wait, check out the HTTP and HTTPS pages on Wikipedia.

The header image for this post came from Giulio Magnifico via

Read more

Write more, manage less

Write more, manage less

This post is intended to be short and to the point; it is not fancy or well written nor is it meant to be a masterpiece of modern blogging! It is just a statement, and hopefully a promise (to myself more than you my dear reader <– singular I expect).

I have hosted a blog for many years (over on another domain name that we won’t speak of for now); over those years I have written less than many posts. Many of those posts were written out of desperation at not having written many posts! I have decided that I want to write more; not because I think that people want to read why I write, more because I do enjoy doing it.

Writing detailed posts on a technical subject is fun (I am a geek, you should know this), and it encourages me to learn more about the subject, which in turn makes be better at what I do.

I am a software developer from the United Kingdom, I write mainly in C# using the .NET framework. I write web, desktop, mobile, back-end, services, database, and anything else I need to complete the task at hand and I like to believe that I am rather good at all of them (now if that isn’t full stack then I don’t know what is).

I promise to myself that I am going to write more posts; focusing on technical, development, and security subjects (likely with some random thrown in once in a while). So keep with me, the posts are likely to get better the more I write, I need to find my style and learn how to write strong coherent posts! I don’t apologise for writing some lesser quality posts to begin with; that being said…. sorry!

If you are feeling unsuccessful just think about this: eagles may soar, but weasels don’t get sucked into jet engines. anon

Cover photo via Annie Spratt on

Read more

Comment Policy

Comment Policy

There is a really simple comment policy here:

Keep it clean, keep it friendly. You can be negative, just be constructive and don’t be a dick. Oh and spam is being a dick.

The header image for this page came from Matthew Henry via

Read more