I'm running a C# application that needs to encrypt/decrypt files (using NTFS's EFS encryption) on behalf of a specific user account--a user account other than the one under which the application is running.  I didn't want to go through the hassle of firing up a new process (using CreateProcessAsUser) because I'd have to worry about IPC and it'd be less performant.  The question I had was:  is it possible to encrypt/decrypt files as a user other than the one under which the process is running within that process?  I couldn't find any resource on the web that stated an answer definitively, so I wrote some code to try it.  The answer is:  yes.

Here are the steps (it involves a mix of Interop and managed methods):

1. Get a handle to the desired user (the one whose encryption key you want to use) by calling LogonUser.  (You'll need the user's password.)
2. Load the user's profile (aka registry hive) by calling LoadUserProfile.
3. Construct a WindowsIdentity object using the handle provided by the call in step 1.
4. Invoke WindowsIdentity.Impersonate().
5. Perform any file I/O -- it'll be in the context of that user.  The user's encryption key will be used with any File.Encrypt() / FileInfo.Encrypt() invocation.
6. Unload the profile by calling UnloadUserProfile.
7. Close the user handle by calling CloseHandle.

You can do steps 1-4 in the constructor of an IDisposable object and do steps 5-7 in the Dispose() method to ensure proper resource cleanup. 

If you've run a unit test in Visual Studio 2008 that utilizes database connectivity, you may have seen this error when creating a connection object:

Instance names used for writing to custom counters must be 127 characters or less.

The problem crops up when you're running the test within a directory structure with a fairly long name, i.e. you're organizing your code well and giving your projects descriptive names.  Well, this error is punishment for being organized.

There are several Microsoft bug reports on the issue.  One has been ignored, the other closed.

• http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=95049
• http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=176361

There are posts on the web with some workarounds, but none worked for me, perhaps because I'm using Visual Studio 2008?  No matter what I tweaked in .testrunconfig I was still getting the error.  The other approach--shortening the pathname--was really a non-starter.  I wasn't going to compromize well-thought-out organization to get around a Microsoft bug.

So I took a peek at the source of the problem as hinted by the call stack when the error appeared.  It's a method in the internal DbConnectionPoolCounters class in the System.Data.ProviderBase assembly.  Here's the code:

The instance name of the performance counter is being built, in part, from the name of the AppDomain.  When running tests in Visual Studio, this name can be very, very long, especially if your project's home has a long pathname.

The workaround I pursued, then, is to shorten the name of the app domain.  While AppDomain.FriendlyName is a read-only property, and there's no private field of the AppDomain class to change it, there is a private extern method of AppDomain called nSetupFriendlyName.  And, like magic, if you invoke this method and give the app domain a shorter name, problem solved!

Here's the workaround, utilizing a little reflection magic:

Determining whether an object implements the generic version of IDictionary isn't as easy as it seems.  Ideally this would work:

Unfortunately, it doesn't.  Leaving out type parameters (i.e. "<,>") is supported only with the typeof operator.

So, after some experimentation, here's how you can do that type of test, and then invoke a generic method with type parameters: