GetObjectContext Returns Null

  • Thread starter Thread starter Michael Vanhoutte
  • Start date Start date
M

Michael Vanhoutte

We have an ASP.NET website written in C# that accesses a
VB6 COM component. That component accesses the ASP-objects
in the following manner:
Set objContext = GetObjectContext
Set objRequest = objContext("Request")
strAddress = objRequest.ServerVariables("REMOTE_ADDR")
Set objContext = Nothing
Set objRequest = Nothing

On all the pages of our website the ASPCompAt-property is
set to True. We have pages in our website though where
GetObjectContext returns Nothing and others where it
returns an object.

For example, page 1 in the our ASP.NET website has
ASPCCompAt set to True and can successfully access the ASP
Request-object.

Page 2 also has the ASPCompAt-property set to True, but
the GetObjectContext-function returns Nothing (Null)
there. We've spend a significant amount of time trying to
find the difference between these two pages and the only
difference that we saw was that a Server.Transfer-call is
done before we call GetObjectContext on page 1.
As soon as we also did a Server.Transfer in page 2, the
GetObjectContext function returned a valid object.

For example:
private void Page_Load(object sender, System.EventArgs e)
{
// Doing a Server.Transfer if GetObjectContext
// returns Nothing. This is only done once
if (ourVB6Component.GetObjectContext2() == null) {
Server.Transfer("page2.aspx");
}

// The following method calls GetObjectContext internally
// and only works if a Server.Transfer is first called.
ourVB6Component.DoMethod;
}

Can anybody explain why GetObjectContext would behave
differently after a Server.Transfer? Is there a clean way
to get GetObjectContext to work correctly at all times?
 
Hi Michael,

Thank you for posting to the MSDN newsgroups.

I am interested in this issue and am researching on it now. I will update
you as soon as possible.

Best regards,

Jacob Yang
Microsoft Online Partner Support
Get Secure! ¨C www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
 
Hi Michael,

Based on my research, I found several articles that are helpful for this
issue. Please check them out.

HOW TO: Access ASP.NET Intrinsic Objects from .NET Components Using Visual
Basic .NET
http://support.microsoft.com/default.aspx?scid=kb;EN-US;319429

HOW TO: Access ASP.NET Intrinsic Objects from .NET Components by Using
Visual C# .NET
http://support.microsoft.com/default.aspx?scid=kb;EN-US;810928

HOW TO: Access ASP.NET Intrinsic Objects in a Visual Basic 6.0 Component
http://support.microsoft.com/default.aspx?scid=kb;EN-US;323259

If I have misunderstood your concern, please feel free to let me know.

Best regards,

Jacob Yang
Microsoft Online Partner Support
Get Secure! ¨C www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
 
Hello Jacob,

The article "Access ASP.NET Intrinsic Objects in a Visual
Basic 6.0 Component" is the one that applies to our
current situation. However, we've already tried the steps
discussed in the article without result.
We're still not able to access any of the ASP.NET
intrinsic objects (Response, Request and Server). When we
perform a Server.Transfer before excecuting the method
that connects to those objects, we're able to access and
perform a Response.Write through the VB6 component.

Some code to clarify my situation:
try
{
objApp.ResponseWriteThumbnail(intPage);
<-- This is the VB6 method that uses GetObjectContext
}
catch(System.Runtime.InteropServices.COMException)
{
Server.Transfer("showImage.aspx");
}
catch(Exception excp)
{
Response.Write(excp.Message);
}
}

In the code above, the ResponseWriteThumbnail-method will
fail and generate a COMException. When this exception is
caught, my page will perform a Server.Transfer and the
second time the page is processed, the
ResponseWriteThumbnail-method will work as expected.

My first impression was that there is no instance of the
intrinsic objects until the object is called for the first
time. So when your VB6 component calls the
GetObjectContext-method before there is an instance, it
returns nothing. Is this correct? If this is correct, why
does the GetObjectContext-method still return nothing when
I call Response.Write before I call the VB6 method that
uses the GetObjectContext-method.
For example:
try
{
Response.Write("Something")
objApp.ResponseWriteThumbnail(intPage);
<-- This is the VB6 method that uses GetObjectContext
}
catch(Exception excp)
{
Response.Write(excp.Message);
}
}
Will generate an error.


Some additional information:
I'm working with:
Windows 2000 5.00.2195 SP 4
Microsoft Development Environment 2002 7.0.9466
..NET Framework v1.1.4322

Kind regards,

Michael
 
Hi Michael,

Thank you for your update.

I have followed the steps mentioned in the article below,

HOW TO: Access ASP.NET Intrinsic Objects in a Visual Basic 6.0 Component
http://support.microsoft.com/default.aspx?scid=kb;EN-US;323259

It seems to work fine on my side. I tested it with VS.NET 2003, however,
with the same version of .NET Framework v1.1.4322.

By checking your code, I want to know how the VB6 component was created in
your ASP.NET application. I mean the objApp variable.

It may be the problem here. In my testing code, I created a reference to
the VB6 component via the HttpServerUtility.CreateObject method.

Please let me know the detailed results.

Best regards,

Jacob Yang
Microsoft Online Partner Support
Get Secure! ¨C www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
 
Jacob thank you for your help so far.

We didn't use the CreateObject-method because we're
developing our website in C# and not in VB.NET. The
HttpServerUtility.CreateObject-method is easy to use in
VB.NET, but calling methods on COM-objects created using
CreateObject in C# is really a lot of work and hardly
improves the readability of the code.

We've created a wrapper for our component using tlbimp and
we've linked that wrapper to the References of our C#-
project. We can then create an instance using early
binding.

So, this is what we've found so far:
We've created a Visual Basic 6 ActiveX-object that uses
GetObjectContext to get access to the intrinsic ASP-
objects.
We've created an instance of this object in a C# ASP.NET-
website using early binding.
We can access the ActiveX-object perfectly but the
GetObjectContext-function inside that ActiveX-object only
seems to return a valid context when it is executed after
we've called Server.Transfer or Server.Execute in the
ASP.NET-website.

Any more ideas?
 
Hi Michael,

Before I go ahead with a similar test with yours on my side, I found the
following important information from MSDN documentation:

If you use aspcompat mode with STA components, you should create COM
components only from the Page_Load event or later in the execution chain
and not at page construction time. For example, the following member
declaration creates the component at construction time.

<%@ ASPCOMPAT="TRUE" %>
<script runat="server" language="VB">
' The components is created at construction time.
Dim comObj As MyComObject = New MyComObject()
Public Sub Page_Load(Src As Objects, E As EventArgs)
' The object is first used here.
comObj.DoSomething()
End Sub
</script>
Instead, use code like the following:
<%@ ASPCOMPAT="TRUE" %>
<script runat="server" language="VB">
Public Sub Page_Load(Src As Objects, E As EventArgs)
' The component is created and used after the code is running
' on the STA thread pool.
comObj = New MyObject()
comObj.DoSomething()
End Sub

If you created the VB6 component at the page construction time, please
change the code appropriately and check whether the problem still exists.
According to the symptom you mentioned that the httpcontext is only
available when a server.execute or a server.transfer was executed.

I hope it helps. On my side, I am also doing a test and I will update you
with the results as soon as possible.

Best regards,

Jacob Yang
Microsoft Online Partner Support
Get Secure! ¨C www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
 
Jacob,

Indeed, this is what was wrong! We've changed our code
according to your specification and it works fine now.

Thanks. I'm very glad that we've got a solution that
required very little change from our side.

Again, Thank You
Michael
 
Back
Top