GetObjectContext problems when calling COM+ components from .NET

[lage]

I am working with a system using a Com+ layer built in VB6. I am now trying to use these components from VB.Net.
I have added the component as reference and .Net seem to communicate with the component.

I am using the following code to connect:
[code=vbnet]
Dim adm_event As Admin.Event
adm_event = CreateObject("a dmin.event")
[/code]

While running the procedure I get the error:
ErrorCode=-2147467259
Message="[DBNETLIB][ConnectionOpen (Connect()).]SQL Server does not exist or access denied."
Source="Microso ft OLE DB Provider for SQL Server"

The connection string is stored in Global,asa as well as a few other parameters.
[code=vbnet]
Set objContext = GetObjectContex t()
connstring = objContext.Item ("Application") ("connstring ")
[/code]
I think it's this part that doesn't work.

It's important to get this working because we shall reuse a lot of Com+ components while beginning the migration to .Net

I really appreciate any help on this. I have not worked much with VB.Net yet, but have searched a lot to find a solution, without luck :-(

Lage

[mldisibio]

Without seeing any code I cannot be certain, but it looks like your .Net app is picking up the connection string from the COM component just fine. The error you are receiving is occuring in an attempt to resolve the connection string.

Perhaps the syntax in the COM Component for the connection string needs to be modified for the .Net SqlConnection to parse it correctly.

If you add some Debug.Write(con nectionString) code to your .Net in the method where SqlConnection.O pen is called, you can print out the ConnectionStrin g it is trying to resolve. If the problem is not obvious, post the results of the Debug output and someone in the forum will look at it.

[lage]

Without seeing any code I cannot be certain, but it looks like your .Net app is picking up the connection string from the COM component just fine. The error you are receiving is occuring in an attempt to resolve the connection string. Perhaps the syntax in the COM Component for the connection string needs to be modified for the .Net SqlConnection to parse it correctly. If you add some Debug.Write(con nectionString) code to your .Net in the method where SqlConnection.O pen is called, you can print out the ConnectionStrin g it is trying to resolve. If the problem is not obvious, post the results of the Debug output and someone in the forum will look at it.

Thank you for your answer! I am pretty sure it's not the syntax. I pasted the same connection string “hard coded” into the VB6 code and it worked without problem. The database is connected only within the Com+ component in this test, but I will probably connect the database from the .Net application when I implement the new parts to the current system.
So it looks like it’s the application object that doesn’t appear when called from .Net.

In the VB6 Com+ component, the connection string is fetched by the following code:
Set objContext = GetObjectContex t()
connstring = objContext.Item ("Application") ("connstring ")

Any suggestions?

Lage

[mldisibio]

To clarify, is it the old VB6 COM Component that is executing the call to GetObjectContex t()? So the COM Component is getting the connection string and opening the database, not the .Net app?

You say the connection string is stored in global.asa? So is this an ASP application, hosting a COM+ component, that you are now trying to wrap or call to from ASP.Net?

So basically, this is still a legacy ASP app that is doing all the work and you are trying to get the data pumped out into a .Net process?

(Those were all questions, so please confirm...)

If so, I don't have enough experience with that mix to give a authoritative answer.

Nonetheless it still seems to me that the particular error you are receiving indicates a problem actually connecting to the database, and not a problem retrieving the connection string. I don't think you get such an explicit error if the connection string is null.

When trying to wrap components, sometimes the original entry point gets bypassed. For example, did the original application have a way to open the connection and keep it open? (Sometimes the COM component is hosted in Distributed Transaction Server which keep it alive) In the original application, there may have been a persistent connection, but now with the wrapper approach, the operations may be more atomic (Call COM component and open connection...Ca ll COM component and execute query...but the connection closes between the two calls)

I am just hazarding guesses here, and I hope someone else with more experience will jump in.

In the meantime, I will give one other suggestion from a mile-high perspective: (This is strictly just an opinion.) I understand you may have requirements to transition using the legacy COM components and the requirements may be out of your control, but quite honestly, the time spent trying to get legacy custom COM components to work with newer ASP.Net applications, IMHO could be better spent converting the COM to a .Net class library. Honestly, the task/scope of a COM component is usually pretty specific and simply converting it to a .Net library is straightforward . Trying to get legacy COM in an ASP hosted process to talk to .Net in an ASP.Net hosted process often leads to much wrestling with the quirks of the underlying technology and loses focus on the business model and robust design.

[lage]

Thank you again for your answer. You were right about the connection string. There was an old exception retrieving an obsolete connection string while not calling the Com+ component from an asp-file.

I have got answer from a MS employee at MSDN now and I hope they will help me to sort this out.

http://social.msdn.microsoft.com/Forums/en-US/vbinterop/thread/e61fb2a9-2210-4137-bed6-41d98346562f/

Thanks for your help

Lage