I’ve got a small C# Security Application that I’m writing an Editor for.  I was hoping to let the user run the application as whoever they choose to, and then use LogonUser to create a WindowsImpersonationContext and log them in as SOMEONE ELSE to do the DPAPI Encryption (because it will be that other use that will be decrypting the data.)

I’m using DPAPI with a User Store, not a Machine Store.  I’ve got a managed wrapper for DPAPI that works fine.  I’ve got a Managed “ImpersonateUser” function that returns a WindowsImpersonationContext and internally users LogonUser and also works fine.  

The psuedocode/gist is be basically:

Load App

            Do some stuff

            Load XML File

            Call ImpersonateUser (someotherguy) [succeeds and WindowsIdentity.GetCurrent().Name changes to reflect the change

            Call DPAPI to Encrypt Element Context (this works fine if I DON’T IMPERSONATE...)

                        ERROR: Win32 Marshal.GetLastWin32Error() reports “The System couldn’t find the file specified”

            Save File

            Call ImpersonationContext.Undo

Exit App

Apparently this is either utterly stupid of me, or noone has ever tried it.   All the doc on DPAPI is either highly theoretical “how it works internally” or very trivial “here’s how I used the Machine Store from ASP.NET.”  The doc on WindowsImpersonationContext is even worse.

Am I going to just make the user to a “RunAs” to launch my app? (which works fine, BTW)  It just would have been so nice to have a "Run As" menu item...thoughts anyone?

Sometimes a lot of "Old School" technology seems to pop up all at once.  It's Tuesday and already I've worked on two old school issues.  Here's what I told them and learned myself:

Viewing a PDF inside of Internet Explorer doesn't work when ActiveX is turned off in IE Security

From a user's point of view, there are two implementations of ActiveX technology in Internet Explorer: ActiveX Controls (created with an <object> tag in an HTML page) and ActiveX Documents (created when IE sees a mime/type that is handled by an registered application.)

When you open up a Word Document or a Adobe PDF and it appears INSIDE Internet Explorer that is an "ActiveX Document."   When you open up an HTML page that contains en <embed> or <object> tag that is an "ActiveX Control."

Both of these technologies, along with "Authenticode" (when a dialog pops up and warns you about downloading code, do you trust, etc.) are collectively, to the layman, "ActiveX."

When you turn off ActiveX in the IE Tools|Options|Security you are affecting ActiveX Documents as well.  If you click on a PDF and try to open it in IE, you'll likely get a blank page or a "broken window" graphic.  You'll be unable to View|Source because there is no HTML source to view!

Use of NEW on one line in Visual Basic 6 - as in "Dim oX as New Thing"

In VB6, what is the difference SPECIFICIALLY between: 

    Dim oCalcutta As FooBar
   Set oCalcutta = New FooBar

and

    Dim oCalcutta As New FooBar

 Is there a speed difference? (there doesn’t appear to be a major one) COM difference? (are internals handled differently?)

Turns out there is a difference.  (Thanks to Stephen Forte, Francesco Balena, Ralf Westphal, and especially Henrik Nielsen)

When you write code like this:

  Dim obj As New Class1
  obj.Method

Then each reference to a member such as:

  obj.Method

will be compiled to the following code (pseudo-code):

  If obj Is Nothing Then
    Set obj = New Class1
  End If
  obj.Method

This of course implies a certain performance hit – but I wouldn’t expect it to be in any way significant.

Much more important (in my opinion) is the difference in semantics (which follows from the above) between the two constructions:

  Dim obj As Class1
  Set obj = New Class1
  Set obj = Nothing
  obj.Method

and

  Dim obj As New Class1
  Set obj = Nothing
  obj.Method 

The first construction will result in a run-time error (Object variable or With block variable no set) and the second will not.

UPDATE: Some wisdom from Dan Appleman. "The reason [you're told] not to use [a Dim on one line] is that this can result in subtle bugs - especially during cleanup - when you are either accidentally recreating objects you think you cleaned up, or are referencing new objects when you accidentally cleared old ones."

After discovering that .NET/ASMX didn't want to let me change the prefix on the root element of a SOAP payload, I did the unthinkable, but appropriate action and wrote a SoapExtension to please the client of this Web Service.  Certainly the world of Web Services is a worse place that I had to write this.

Of course, the prefix is not needed, but it made them happy, and that is satisfaction enough, eh?  And at least it is implemented as an Attribute, so it can be easily removed in the future.

I won't ruin my karma by posting the project here, but the gist is this.  (If you want the code, and to go to hell, email me):

[WebMethod]
[SoapDocumentMethod(Action="http://www.ford.com/Sample",
RequestNamespace="http://www.ford.com/Request",
RequestElementName="GetCarRequest",
ResponseNamespace="http://www.ford.com/Response",
ResponseElementName="MyCar")]
[XmlRootForcePrefix(Prefix="scott")]
public Car HelloFord()
{
   Car c = new Car();
   c.Namespaces.Add("yoyoyo","hanselman");
   return c;
}

results in this (added stuff in red).  Note that the default namespace remains, and the added prefix uses that full qualified namespace.  The goal wasn't to fundamentally change the structure of the document, just add the prefix.

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <soap:Body>
    <scott:MyCar xmlns="http://www.ford.com/Response" xmlns:scott="http://www.ford.com/Response">
      <car xmlns:yoyoyo="hanselman" xmlns="hanselman">
        <yoyoyo:engine>some engine</yoyoyo:engine>
        <yoyoyo:color>red</yoyoyo:color>
      </car>
    </scott:MyCar >
  </soap:Body>
</soap:Envelope>