Office pranks are among the funniest and we’ve probably all done some of our own over the years. This time, my boss and I came up with a good one. Write an add-in for Windows Live Messenger that auto replies to all incoming messages. We would then install it on a co-worker's computers when he goes to lunch. We would define some sentences that by random is sent to the sender of any incoming message.

Building the add-in

To our big surprise, this was the easy part. There are some good tutorials on the web that tells you exactly what to do and that is actually not very much. The thing that took the longest time was to come up with the sentences. It was important that they weren’t too offensive, but at the same time be humiliating for the victim of our prank. These are the sentences (notice the last one. It sends emoticons).

• I can go to the toilet on my own now
• I'm not fat! Just a little heavy around the hips
• I could use a clean pair of shorts
• I don't wear any pants right now
• (bah)(}) - absolutely wonderful

Install the add-in

Start by downloading the AutoReplyAddIn.zip file below. It contains the add-in (MessWithMessenger.MessWithMessenger.dll) and a script (WLMessengerAddins.reg). Add-ins is by default disabled in Messenger, which is why you need the script to enable it.

1. Copy the two downloaded files onto the victim’s computer
2. Double-click WLMessengerAddins.reg and click OK to enable add-ins
3. Restart Messenger
4. Open the options dialog in Messenger and select the new Add-ins tab
5. Press the “Add to Messenger” button and select the MessWithMessenger.MessWithMessenger.dll file
6. In the main window of Messenger, turn on the add-in as the picture shows below.

It only works on Windows Live Messenger, not on MSN Messenger. Be careful not to prank a co-worker who has a lot of Messenger chats with customers. Good luck with the prank.

Download

AutoReplyAddIn.zip (2,63 KB)
AutoReplyAddInSource.zip (60,02 KB)

The Session in ASP.NET is a very simple way of storing user specific data for the duration of a single user session. I’ve many times added data to the Session that had an even shorter lifespan. That could be as a data store for properties on AJAX enabled web pages and those properties don’t belong in the session after the visitor navigates to another page on my website. To clean up, I would then delete those session objects that no longer is in use.

There are two way of deleting individual objects from the Session. You can set it to null or remove it.

Session[

"key"] = null;>

or

Session.Remove(

"key");> >

I used to think that the Session would treat the two ways the same, but that is not the case. If you set the object to null, the key still exists in the Session even though the value is null. This behaviour is the same as any other dictionary type classes in the CLR, but for some reason I thought that the Session was different.

That’s probably because you can ask if an key is present in the session without it throws an exception like many collection and dictionary type classes do if it isn't. It's because the Session is based on a HashTable. After .NET 2.0 with Generics was released, I haven't used a Hashtable one single time ever since. I always use the strongly typed generic collections and dictionary type classes instead, so that was probably what confused me.

Recap: If you want to remove an object completely from the Session, you should use the Session.Remove(“key”) method. It wont throw an exception if the key is not present in the Session.