Navigate to Definition in Visual Studio 2010

Visual Studio has a window that will show you the source code of any selected method, class, property or field. It is called the Code Definition window. You can display this window by using the menu and going to View->Code Definition Window (or Ctrl+\,Ctrl+D). This displays under the code editor by default.

You can use this in sync with the Call Hierarchy Window to quickly navigate to interface implementations. By right clicking on an item in the Code Defintion Window and choosing View Call Heirarchy (or Ctrl+K, Ctrl+T). When you are viewing the call heirarchy on an abstract item, a folder displays called Implements. In this folder will be displayed all the classes that implement this method, and clicking on one of them will take you to the definition indicated.


  1. highlight the definition you want to see. It automatically shows up in the Code Definition Window.
  2. Press Ctrl+\,Ctrl+D to navigate to the Code Definition Window
  3. Finally, press Ctrl+K, Ctrl+T to show the Code Hierarchy Window


ASP.NET and the ThreadStaticAttribute do not work well together.

ASP.NET has its own thread pool. In an effort to increase performance, the ASP.NET runtime will return threads to the thread pool if a process is blocking so that it can be handed off to other incoming requests. When the blocking process returns, ASP.NET will randomly pick a thread in the pool and that process can continue executing. The interesting thing is that this may not be the same process that the request originally began executing on. Most of the time you never even notice this is happening. That is until you introduce the ThreadStaticAttribute.

The ThreadStaticAttribute causes feilds marked with the static keyword to be unique to each thread. In other words each thread gets its own copy of that static value. It has a unique quirk. You cannot set its value via a static constructor, or by in place
declaration and assignment like so:

// Example 1
public class Baz

 // all of these only get executed once 
 // when the .NET runtime loads the class

 static int foo = 1;

 static int bar;

 static Baz()
  bar = 3;

This is because the .NET runtime only executes static constructors and in place assignment once when the class is loaded, therefore you cannot be sure if your thread is the one that loaded this class. You can however initialize it in any operation you call which is usually static itself. The following example uses two thread static fields to store a resource that needs to be refreshed hourly. The refresh is lock free at the expense that each thread has its own copy. This copy is stored in what is commonly referred to as thread local storage.

// Example 2
public class Baz
 static DateTime _lastLoaded;

 static Resource _resource;

 static TimeSpan timeout = new TimeSpan(1, 0, 0); // one hour

 public static Resource ProcessStuff()
  if (_lastLoaded.Add(timeout) < DateTime.Now)
   _resources = GetResourcesFromExternalLocation();
   _lastLoaded = DateTime.Now;
  return _resource;
The thread local storage ensures that the values in _resource and _lastLoaded are the values created by the thread executing ProcessStuff(). This is rather efficent. However when ASP.NET joins the picture, meyham ensuse.

Remember from earlier that ASP.NET will recycle threads. Basically when you begin an operation, at any point, it could be put to sleep, and its thread recycled. When ASP.NET decides it time to wake up the operation it randomly chooses a thread from the pool to resume execution of the operation. The thread used to continue the operation has all of the thread static values from the last operation using it. Locks do not fix this problem.


action speaks louder than words

Speaking out and letter writing accomplish nothing. Knowledge and action are the true weapons with which to reclaim our country.


Why you shouldn't handle exceptions

Every programmer understands exception handling. You put your code in a try block. If it pukes, do something with in a catch block. Finally, if you need to clean up anything regardless of failure, put it in the finally block. What I would like to focus on today is the middle step, catching exceptions.

try {
} catch { } // we don't care if this call fails

I know some of you are cringing at this point. However lots of programmers do this. On the surface it seems logical. This
may be a call to some external resource that may or may not be there, and the application doesn't care about it. Did you know that?
  • This code can leave the system in a exploitable state.
  • You may have deprived a hosting application (e.g. web server) from logging its own error.
  • The operating system itself may now be in an unrecoverable state. Causing several applications on the machine to act up. With no record of what happened.

These are all very real and serious issues. Let's see if we can fix this:

try {
} catch (Exception fail) {
Logger.Log(fail); // we don't care if this call fails

There that looks better. Or is it? You still have the same issues as above, but now at
least you have something to help track them down. This doesn't leave me feeling warm and fuzzy. I wouldn't want to be
known as the guy who let some hacker bring down our systems, or worse. Let's see if we can do this:

if (externalResouce.CanConnect())

Much better! Unfortunately our third party code doesn't have this method. So we are still stuck with our exception
handler. Woe is me what ever shall we do? I know, let's see what exception is actually being thrown and catch that.

try {
} catch (CannotConnectException fail) {

Perfect. Now we aren't catching any of the exceptions that we don't know what to do with. We
are also logging the one that occurred so at least someone can be made aware of it.

Six months goes by, everyone is happy. Then one day:

Dept B: We saw the application you built for Dept. A and we saw it sends stuff to ExternalResource.
We want a new application too. We currently enter this information into ExternalResource by hand, but now
that we know you can do it automatically. We want it in our new application.

You: no problem. I thought someone else might want to use that functionality. I put it in a separate library.

Dept B: ???

You: Nevermind. Yes we can do that for you.

Now the application for Dept. B has been in production for a week, and everyone is excited
that you were able to write it so quickly. Things are looking good!

A bug report pops up in your queue: "Dept. B application is not writing to ExternalResouce." What? This can't be my code.
I saw it write to ExternalResouce every time when we wrote and tested the application.

Later that day...

You: boss, um .. we ... um .. have a problem

Boss: what is it?

You: I figured out what the ExternalResouce issue is for Dept. B application

Boss: how is that a problem?

You: well the code that writes to ExternalResouce doesn't fail if ExternalResource is unavailable. If I remove this check
then the application for Dept. A will start breaking. They don't care about ExternalResouce. So now we need to modify Dept. A application
to ignore ExternalResouce, modify the shared library to propagate the exception, and modify Dept. B application to notify the user
that ExternalResouce is unavailable.


// in shared library

That is what the code in your library looks like now. Moral of the story? Don't handle exceptions
unless that piece of code knows what to do with it. In our example scenario, if the programmer had
not handled the exception in his library, and instead let the application decide what to do with it, the
problem at the end wouldn't have existed.

If your code is going to be used by some other code, or to say it does not stand on its own.
Then you shouldn't be catching an exception. If your code does know what to do with that exception
and how to recover from it without involving its user, then first check that there is a non-exception way to make the call:
if (File.Exists(myFile))


Visual Studio 2010 after installation

Well I got Visual Studio 2010 installed and the first thing I tried out was the entity framework designer. I really enjoy the pin and remove feature of the start page. I'm always building ConsoleApplication24 so i can test an idea. Now I can finally get rid of them without having to delete or move them. It appears to handle more complicated associations and inheritance better but still seems a little shy of prime time. It handled the following class hierarchy:

The above hierarchy was built all from one table. With a condition on the child classes specifying an expected value for a TransactionTypeId column. This compiled with only one error. Something about the TransactionTypeId requiring a default value. I opened up the edmx file and added, to my suprise, a DefaultValue attribute with the assistance of intellisense. After that it compiled fine.

My new tables do not have primary keys on all of them yet. The designer tried to infer the keys for each entity from something, but it did not get them correct. I had to go and remove extra columns from the entity keys.

Hopefully I will have more information in the future. I'll post again on VS 2010 when I find or use something interesting again. Until then, happy coding.


VS 2010 Beta

I've decided to download and install Visual Studio 2010 Professional (Beta 1). The download page says it will run on Windows 7, which is what i've been running at home for about a month now. I chose not to get the team suite edition due to the fact that I don't get to use that version at work. I don't want to be upset that my development environment at work is inferior to what i'm used to at home, since (unfortunately) I spend more time doing development at work than at home.

It actually downloaded a web installer. While i'm waiting for it to download, not only VS 2010, but .NET 4.0, Microsoft Help 3.0, and a whole bunch of other stuff (I'm guessing they are all required components). I noticed they also have a Visual Studio 2010 and .NET Framework 4 Training Kit - May Preview. I'll download that if I need it, but I think I'm just going to try and figure things out on my own first.

Another interesting thing I notice in the downloader is that it has VS 2010 64-bit prerequisites. I hope that speeds up the environment.


.NET Source Stepping

Visual Studio 2008 has a feature that lets you step through the source code of the .NET framework when you are debugging. This can come in handy when you are trying to, for example, inherit from asp.net server controls to customize them, or figure out why a class is not operating as expected. This is not a feature that you will want turned on all the time because it will be inconvenient when debugging to have almost all of your errors stop in a .NET source file. Such as a KeyNotFoundException stopping in the Dictionary class. So be aware that this also turns off the Enable Just My Code (Managed only) option. You may want to turn this back on for regular development. However, To access this feature follow the steps below.

  1. On the menu navigate to Tools -> Options

  2. In the tree on the left inside the Options dialog that appears, navigate to Debugging -> General

  3. Scroll down and check the option Enable .NET Framework source stepping

the screen shot below shows the sections in the Options dialog where you need to make changes

Get widget