Okay - well, no, it's not really. For those who do client-side development that requires you to go to the threading level of programming at times, you may have encountered this already, that if you use GetCurrentThreadID in your applications, the compiler will whine now saying that its been obsoleted. Why?
Threads in .Net aren't necessarily threads in the traditional sense of the word (the Win32 sense of the word, that is), just like AppDomains aren't processes in the traditional sense of the word. The reason is because threads, in .Net, can actually be implemented using the old-school construct of fibers. So, it's possible for two seperate threads, then, in the .Net framework to actually have the same real-world threadID (and, GetCurrentThreadID() returns the real-world ThreadID). What was added, then, to the 2.0 frameworks was Thread.ManagedThreadID; which provides a unique identifier for the "thread" the calling code is running on.
...see, I'm writing an application right now which utilizes windows hooks, and I require the actual ID of the calling thread; which Thread.ManagedThreadID does NOT provide.
