The horror of calling Microsoft PSS.. resulting in asking for help of the blog community

Man am I vexed. I just burnt through a Microsoft PSS case (that's the premium support services you pay money for) trying to get some help with a BadImageFormatException I was having... only to be brushed off 4 days later with a statement to the effect of:

"... we can't help you because it includes an open source component"

Great. WHY THE HECK DIDN'T YOU TELL ME THIS 4 DAYS AGO WHEN I SENT YOU A SAMPLE PROJECT WITH CODE SHOWING THE ISSUE... before I spent all the time trying to communicate with you about the problem I am having. And to boot, it was really difficult speaking with the person, who I can only assume works in Banglore, as her extremely strong accent made me feel as if she was being confrontational the entire time.

To be fair, the exception IS occuring in the open source component... but at the result of including a Microsoft IE OCX control. I can add other user controls without incident. I can't understand what the problem is and was going to MS PSS for help, under direction by a Canadian Microsoft employee who wasn't able to help me. Microsoft doesn't offer .NET libraries for MMC 2.0 in .NET 1.1 (which will continue to reside on SBS for some time yet), and I was forced to use the open source components.

At this point, it is clear that Microsoft isn't able to help me on this issue. The PSS person said something about her manager telling her to delete all of my sample code as the open source piece hasn't been passed through "legal". So I gather I can't talk to any of the MS friends I have either about this. *sigh*

Hopefully someone out there in blog land can help me out. I have a sample project that shows the exception. If you are running VS.NET 2003 with C++ and C# installed you should be able to unzip this into the c:\code dir and build right away.

The issue I am having is trying to add the Microsoft IE control (AxWebBrowser) to a FormsNode acting as a RootNode in the open source MMCLib2 library. When you click on the snapin, it causes a "BadImageFormatException" for the IE control.

Steps to Repo the Exception:

1. Run in Debug (F5). An empty MMC console should pop up.
   
2. Add a new Snapin (CTRL+M)
   
3. Press the "Add" button
   
4. Scroll to bottom of Add Standalone Snap-in dialog and select "Test Dashboard"
   
5. Hit "Add Button"
   
6. Hit "Close" Button to close "Add standalone Snap-in" dialog
   
7. Hit "OK" to close "Add/Remove Snap-in" dialog
   
8. Click on the "Test Dashboard" snapin now in the tree. Notice that the snapin loads correctly, and there is a blank groupbox.
   
9. Close the MMC console. Do not save settings when prompted.
   
10. Uncomment line 40 in TestDashboardControl.cs
    
11. Rebuild Solution. (CTRL+Shift+B)
    
12. Repeat steps 1 through 7.
    
13. Click on the "Test Dashboard" snapin now in the tree. Notice the exception occuring on line 117 of FormNode.cs. This is the issue to be resolved.
    

If there is ANYONE out there that has any ideas on what the problem is, I would love the help. I tried getting help from both the open source community and Microsoft, and I am now starting to feel like I am being orphaned/alienated for using the bloody library. This is just nuts.

UPDATE - Nov 12th 6:30pm:Many thanks to Aaron Robinson for emailing me a workaround to my issue yesterday. It looks like my use of aximp has created a somewhat fubar set of interop libs for the ShDocVw.dll and AxShDocVw.dll. He gave me a different set of command line parameters that seems to create images that the system is willing to accept. I have NO IDEA why those same "corrupted" images work fine on stand alone winforms, but not as controls in a snapin base with the MMCLIb2 stuff. Anyways, if you are interested, here is the work around:

• Remove the AxShDocVw and ShDocVw references. Toast the DLLs in the project dir.
  
• Add a reference directly to c:\windows\system32\shdocvw.dll. This created the interop assembly in the /bin/Debug folder, interop.shdocvw.dll
  
• Open up a cmd window and cd into the project folder
  
• Run aximp with the following cmd line args:
  
  aximp c:\windows\system32\shdocvw.dll /rcw:c:\code\TestDashboard\bin\Debug\interop.shdocvw.dll
  
  This produces AxShDocVw.dll in the project folder.
  
• Add a reference to the new AxShDocVw.dll
  
• Recompile with line 40 uncommented.
  

Walla. That works and the browser control comes up as expected. Now to figure out WHY that works, and to determine what dlls I should be distributing in the installer. I am not sure if interop.shdocvw.dll has to be distributed... and if I am allowed to legally.

Thanks again to Aaron for the help!