I have an ASP.NET (VB.NET) application that calls all VB6 COM DLL via
Interop. The DLL uses functionality contained in a Custom OCX Control
(Also VB6) that in turn contains a standard TreeView control. The
Custom OCX is not used for visual purposes, but has some functionality
that we require (hence hosting an OCX in a DLL).
Everything worked fine until we installed the latest service pack for
each respective windows operating system:
Windows 2003 Server - Service Pack 1
Windows XP - Service Pack 2
Windows 2000 Server - Service Pack 4
Now whenever our COM object attempts to load a form containing the
treeview control the COM object "dies" - by which I mean despite
error-trapping on the VB6 COM side, the application throws an exception
back on the ASP.NET side:
"Object reference not set to an instance of an object."
This occurs immediately after a successful call to the same COM
object, so it's not that the object or method or NULL.
It also appears the issue is happening outside of the error handling of
VB6 - i.e. after the Load(Object) call, but before any user-accessible
hook on the newly created form (extensive logging during debugging
shows the load is the last thing called).
This occurs on calling the Load operation of the form (either
explicitly with a Load(Object) call, or implicity by referencing a
property on the instantiated form); the instantiation of the object
containing the TreeView-hosting form is fine.
If I run my ASP.NET application under the context of the machine
Administrator account (via Impersonation) this still happens - testing
returns the security context from the VB6-side and it is Administrator
as well in this scenario. If I run a comparable VB.NET console
application (even under a less-privileged account than Admin) it works
fine.
STEPS TO REPRODUCE:
1. Create a VB6 DLL - add a form and drag a standard Microsoft TreeView
control onto the form. Name the form "frmTreeView".
2. Add a Class to your DLL with the following code:
Option Explicit
Private myForm As frmTreeView
Public Function StepOne() As String
On Error GoTo err1
Set myForm = New frmTreeView
StepOne = "StepOne Success"
Exit Function
err1:
StepOne = "Error in StepOne: " & Err.Number & ": " &
Err.Description
End Function
Public Function StepTwo() As String
On Error GoTo err2
Call Load(myForm)
StepTwo = "StepTwo Success"
Exit Function
err2:
StepTwo = "Error in StepTwo: " & Err.Number & ": " &
Err.Description
End Function
3. Compile and register your DLL
4. Create a simple ASP.NET application that has a COM-Interop reference
to the DLL. Add a page like:
Private Sub Page_Load(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles MyBase.Load
Dim myTree As New pceWidget.clsPceTreeViewClass
Try
Response.Write("StepOne: " & myTree.StepOne & "<br />")
Response.Write("StepTwo : " & myTree.StepTwo & "<br />")
Catch ex As Exception
Response.Write("TreeView Exception: " & ex.StackTrace & " - " &
ex.Message & "<br />")
End Try
myTree = Nothing
End Sub
5. Run the application. If you are running an OS without the above
mentioned service packs it *should* work, but will fail under any of
the SP-scenarios above. I say *should* as there are potential
situations where a Microsoft HotFix (that is now rolled-up in the SP)
causes the same behaviour.
I figure it's a security issue, but nothing as simple as the security
context of the executing app - something more inline with threading
security changes or COM - also, everything is running on the same box
(no cross-machine boundaries).
Any help will be greatly appreciated!
Thanks,
Mark
