Using Managed Thread Local Storage

No comments

Wednesday, August 27, 2008

At work we needed to keep information about each thread. Due to application's nature we couldn't know when a thread would call our code and to make things more interesting we couldn't even rely on the thread id for unique identification.

Because of those restrains an external data structure was out of the question and we needed to find a way to store that data in the thread itself.

Luckily .NET Thread has the ability to store data on the thread itself using DataSlots:

To Save Data from sameVariable in the current thread local storage:

LocalDataStoreSlot dataSlot = Thread.oo("DATA1");

Thread.SetData(dataSlot, someVariable);

And then we can get that information by using:

LocalDataStoreSlot dataSlot = Thread.GetNamedDataSlot("DATA1");

string val = Thread.GetData(dataSlot).ToString();

And finally we need to release it:


It that simple. The only problem I found is that we can only set and get data from the current thread.

You can read more about it at msdn.

The Problem With Design Patterns

No comments

Friday, August 22, 2008

The first time I've learnt about OOP Design Patterns was at a Software Engineering introductory course. Since then I had a growing feeling that there is something wrong in the way that the industry treats them.

Don't get me wrong - those patterns exist so that developers wouldn't need to reinvent the wheel each time they encounter a problem that was already solved the problem is that many times developers misunderstand how they were meant to use them.

Design patterns are general reusable solutions to a commonly occurring problems in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations.

From Wikipedia on Design Patterns

Several times at my work I would hear the following: "We should use pattern X with pattern Y and then create a..." or "the reason I did X is because that's how pattern Y is implemented". It always seemed to me that those talks were a case of when All you have is a Hammer, Everything Looks Like a nail. People seemed to bend the software so that it would fit the design pattern and not the other way around.

That is why when I saw the post Pattern for Pattern (from The Programmer's Paradox) I felt like someone else share the same frustration I have on the subject.

In the post the author explains how he implemented a design pattern without planning to simply by writing his code to solve a business problem.

I think that all software developers (not to mention architects) would greatly benefit from studying design patterns that exist in the domain of the problem they need to solve but should treat them as a they would treat a code someone else wrote - tae what you need and not just copy paste it as is.


Coding Spell Book

No comments

Tuesday, August 19, 2008

Professor Henry Jones: Well, he who finds the Grail must face the final challenge.
Indiana Jones: What final challenge?
Professor Henry Jones: Three devices of such lethal cunning.
Indiana Jones: Booby traps?
Professor Henry Jones: Oh yes. But I found the clues that will safely take us through, in the Chronicles of St. Anselm.
Indiana Jones: But what are they?
Indiana Jones: Can't you remember?
Professor Henry Jones: I wrote them down in my Diary so that I wouldn't *have* to remember.

From Indiana Jones and the Last Crusade via IMDB


How many times have found yourself looking for the exact syntax of some operation you need for your application?

I'm not saying that developers should only know how to search for the information on the net. a good software developer needs to know a lot of things on a lot of subjects, but not to memorize the exact phrase to use for every single operation possible.

After finding myself looking at the Internet for the hundredth time to find how to serialize an object (two simple lines that somehow I keep forgetting) I decided there must be a better way.

This blog post introduced me to the idea of keeping a coding "spell book" to keep coding related information from simple syntax to complicate tricks. The idea is to keep a notebook with all your learned tricks and tips for quick reference in the future.

Instead of a paper notebook you can use a WIKI that gives the ability to search & tag. See Dave's SQL spellbook for instructions.

Personally I prefer to use Evernote (in public beta right now) to keep my book of code.


Evernote helps me sort, tag and search my notes. it syncs my notes between my computers, and even have web site where I can view and edit my notes.

How do you keep your code?

How to find assembly path ,name and version at runtime

No comments

Monday, August 18, 2008

nametag Ever needed to find the location of your executable in runtime? what about getting a certain dll name?

Look no further - the following is a quick overview on the .NET objects and functions that can solve your problem.



System.Windows.Forms.Application has static methods and properties that help manage an application, as well as properties to get information about an application.

What It can do:

Get the path (and name) of the current running application


Finding the running application path is as simple as calling Application.ExecutablePath.



System.Reflection.Assembly Represents an assembly and can be used to query a certain assembly properties.

What it can do:
Get the path, version and name of a certain assembly (dll or exe).

Assembly.GetExecutingAssembly returns the assembly that contains the code that is currently executing.
Assembly.GetCallingAssembly returns the assembly of the method that invoked the currently executing method.

Notice that there is a difference between the two: in case you run executable A which references assembly B which calls a function foo calling GetCallingAssembly from foo will return assembly A but GetCallingAssembly will return assembly B.

We than get the following:

  • Version using x.GetName().Version,
  • Path (similar to Application.ExecutablePath) with x.Location.
  • Full assembly name from x.GetName().FullName or just the "short" name with x.GetName().Name.



The process class which is part of the System.Diagnostics namespace provides access to manage processes and enables you to start and stop local system processes. The function GetCurrentProcess() creates a new Process class and associates it with the current running process.

What It can do:

Name of the running executable.


Process.GetCurrentProcess().ProcessName will return the running process name which is (most of the time) the same name as the executable.

in case of class library (dll) run by another executable you get the executable name.


Simple Sample

Try This: create a new windows forms project with containing textbox and add the following code to the main form:


Can you explain the results?


Related Posts Plugin for WordPress, Blogger...