AppDomain.GetCurrentThreadId() and ManagedThreadId are different

[peter.moss]

I have an application that use log4net for operational logging. I
store some user data elsewhere and need to tie the two together. To
achieve this I pass the ThreadId across on the user table so I can see
what thread the user was running under and then look in the log4net
table to see what they were up to.

This works fine when I use AppDomain.GetCurrentThreadId() as the
ThreadIds match, but the compiler throws up an obsolete warning and
says to use Threads ManagedThreadId property.

Howerever they return different Id's, in fact ManagedThreadId seems to
always return 1 (???).
Here's some unit testing code that won't work:

Assert.AreEqual(AppDomain.GetCurrentThreadId(),
System.Threading.Thread.CurrentThread.ManagedThrea dId);

So, the question is, what method/property returns the Id which is akin
to the old AppDomain CurrentThreadId? My suspicion is, because of the
unstable nature of AppDomain the answer is there isn't - but what is
the closest (otherwise I will have to stick with AppDomain despite
compiler warnings).

Cheers

[Nicholas Paldino [.NET/C# MVP]]

Peter,

And they almost never will equal, not anymore.

In .NET 2.0, the hosting model allows for the same thread to be used to
process different "logical" threads of execution. Mainly, this was inserted
to allow the CLR to be hosted in SQL Server.

Now, the call to GetCurrentThreadId was a call to the GetCurrentThreadId
function through the P/Invoke layer. If one was to use this as a unique
identifier which is relative to the logical thread of execution, then this
could have an effect on existing code.

As a result, the ManagedThreadId property is recommended, as it will
differentiate between two logical threads, even though they might run on the
same thread.

The reason it returns 1 is that 1 is the first id generated (it uses the
hash codes of the objects, I believe) for the Thread instance you are using.

So, the solution, assuming that you are using the result of
GetCurrentThreadId as an identifier for ^logical^ threads of execution, is
to move to ManagedThreadId.

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

<pe********@gmail.com> wrote in message
news:11**********************@g49g2000cwa.googlegr oups.com...

I have an application that use log4net for operational logging. I
store some user data elsewhere and need to tie the two together. To
achieve this I pass the ThreadId across on the user table so I can see
what thread the user was running under and then look in the log4net
table to see what they were up to.

This works fine when I use AppDomain.GetCurrentThreadId() as the
ThreadIds match, but the compiler throws up an obsolete warning and
says to use Threads ManagedThreadId property.

Howerever they return different Id's, in fact ManagedThreadId seems to
always return 1 (???).
Here's some unit testing code that won't work:

Assert.AreEqual(AppDomain.GetCurrentThreadId(),
System.Threading.Thread.CurrentThread.ManagedThrea dId);

So, the question is, what method/property returns the Id which is akin
to the old AppDomain CurrentThreadId? My suspicion is, because of the
unstable nature of AppDomain the answer is there isn't - but what is
the closest (otherwise I will have to stick with AppDomain despite
compiler warnings).

Cheers