Miscellaneous Debris

Outlook Miscellany: Erasing a name from the Autocomplete Cache

The drop-down list of names that Outlook gives us to auto-complete a name or address being written is stored in a file called <ProfileName>.NK2 in our Application Data\Microsoft\Outlook directory. This file is stored in a proprietary binary format, and there's no known documentation for it as far as I know. There seems to be a company that (apparently) reverse-engineered the format and are selling a cache-editing tool, but it's pricey - the basic desktop version can edit, import/export and print for $35. The network/helpdesk editions can do remote NK2 editing for all computer on the network, but gets really pricy with per-seat licenses and so forth.
(They're called Ingressor, if anyone needs those tools)

It turns out, however, that the most common usage for such an editor isn't necessary. If we just want to remove an item from the cache we can do it from within Outlook itself - simply navigate the drop-down options using the arrow keys and press Del on the one we want to erase - and away it goes.

Very simple, and even logical when you think about it. We're just not used to live editing of an auto-complete list.

Disposable Unimpersonation

A while ago, I discussed the possibility of using RevertToSelf() to avoid Double Hop problems. I suggested this pattern can be wrapped inside a class implementing IDisposable to easily use it.

This is the implementation of this Unimpersonator class:

Code:

using System;
using System.Runtime.InteropServices;
using System.Security.Principal;
namespace Strawjackal.Utils
{
   public class Unimpersonator : IDisposable
   {
      private WindowsIdentity m_CurrentUser;
     
      public Unimpersonator()
      {
         m_CurrentUser = WindowsIdentity.GetCurrent();
         RevertToSelf();
      }

      public void Dispose()
      {
         if (m_CurrentUser != null)
         m_CurrentUser.Impersonate();
      }

      [DllImport("advapi32.dll")]
      private static extern int RevertToSelf();

   }
}

Usage:

Control.DefaultValue isn't.

Here is a common source of confusion and frustration that's been experienced by most people developing a custom control in .NET - in WinForms,WebForms, Sharepoint and whatnot.

One of the designer attributes you can put on a control's properties is the System.ComponentModel.DefaultValue attribute, that defines the default value for a property if no specific value has been assigned to it. A common (and understandable) misconception is that setting this attribute will set the specified value for the property.

This is not the case.

The DefaultValue attribute relates to serialization of the value by the framework. Since the DefaultValue is assumed to be the same as the initial value set in code, the framework responsible for serializing and restoring the property's values (the Visual Studio IDE, the Web Parts Framework, etc) will skip serialization of the value if it matches the default value.

Setting the DefaultValue attribute will not actually set the value of the member, and we will get confusing and unexpected results at runtime if we assume it will.

Caveat Developer