WindowsIdentity is IDisposable.

Recently I went on a quest to dispose of IDisposable objects wherever I could find them, since many types are IDisposable but people are not aware of this fact. (Suggestion for VS2010, shade types which are IDisposable a different color in the IDE.)

WindowsIdentity.GetCurrent() returns an instance which you should dispose, otherwise you temporarily leak a user handle. (Its a safehandle so its not a huge deal).
Infact, most times you use WindowsIdentity it is good to dispose of the item. Except for one case.

If you call Impersonate() on a WindowsIdentity instance, disposing it will cause hard to diagnose crashes.

It took me a while to work out why, so I thought I would write this up, maybe it’ll save someone else out there the trouble once.

Reflecting through windows identity related code, tokens get duplicated and new WindowsIdentity instances get created all over the place, so it would seem that you were safe to dispose.
However, when you call Impersonate, the WindowsIdentity instance, and its internal safe handle, get stuffed into the current security context, without being copied or duplicated. I don’t know whether that security context disposes the instance later (looks like it doesn’t), but it effectively takes ownership of it, so you can’t.

If you do dispose of it, and you start a timer or queue a work item before the impersonation is undone, when that timer or work item is executed, the .net framework attempts to set up the security context by impersonating again, but the safe handle is already disposed.

As a bonus, you can disable security support in the .Net runtime, in which case the newly corrected code temporarily leaks handles without the runtime being responsible for the leak.

.Net 4

So I have had a chance to look at the CTP briefly and I’ve found a few things of interest

  1. There are currently breaking changes, and .Net 4 installs side by side with .net 3.5 much like 1.1 does with 2.0. (Array.Sort method change from the .Net 3.5 beta is back.)
  2. BigInteger is now public and in System rather than System.Core
  3. System.Core has a few command line app tools, including a command line parser.
  4. With the dispose pattern it is no longer considered bad to have Dispose being virtual.
  5. Code contract support, I believe the compiler is allowed to optimize based on assertions made using code contracts.
  6. AggregateException, an exception containing multiple exceptions. Useful for parallel or pseduo parallel task execution.
  7. Concurrent data structures, several of them.
  8. Parallel task library integrated into mscorlib
  9. A couple of helper classes for common multithread tasks. LazyInit/WriteOnce.
  10. Monitor now has methods which use ref parameter for lock taken rather than return value. This allows for reliable lock release, which was previously impossible since an asynchronous exception could occur inside Monitor.TryEnter. Additionally Monitor.Enter also allows for the scenario where an asynchronous exception is thrown during its execution, and has a ref lock taken parameter as well.
  11. ManualResetEventSlim, SemaphoreSlim – cheaper non-named synchronization control objects.
  12. SpinWait/SpinLock
  13. Barrier, a multiple worker thread synchronization structure.
  14. Supported platforms attribute, platforms enumeration includes unix, mac, winCE and xbox(?!?) as well as 3 types of win32.
  15. Some attributes and reflection stuff for improved com interop capabilities without requiring interop assemblies. This includes a magical feature where two seperate interfaces can be identified as being the same interface and the runtime magically pretends they are the same internally, as much as it can.

I haven’t really played arround with c# 4 yet, so I haven’t discovered any cool new syntax. (Although I’ve heard about dynamic, and generic variance.)

Also i’ve really only looked at mscorlib and system. System.Core was a brief eyeball in reflector, everything else I’ve not had a chance to examine.