• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 585
  • Last Modified:

Error in Loading DLL


I have two DLLs that were built with COM+ implementation. Each DLL is loaded into a separate COM+ package. Both packages function perfectly in my development environment: Windows 2000 Professional (SP2), VB6.

Our staging environment is Windows 2000 Server (SP2). One DLL functions perfectly. The other DLL accesses a component in the first package, and fails with the error message "Error in loading DLL" when it attempts to create a reference to that object using early binding. The problem goes away if I use late binding.

I prefer to use early binding, but can not figure out the problem. Both packages are authenticated with same Windows User Account. I have also included this user account in dcomcnfg for default access and launch, to no avail.

Any thoughts?
0
ppastor
Asked:
ppastor
  • 7
  • 6
  • 4
  • +2
1 Solution
 
RainUKCommented:
You cannot use early binding with a COM+ dll unless it is installed on the local machine. Which defeats the point of COM+ middle tier stuff!

When you test it on your dev machine using early binding it will work because the dll is on your dev machine locally referenced in the registry.

You have to use late binding as the proxy points to a dll on the server, again that is one of the main points of using COM+.

Why do you want to use early binding in this instance?

0
 
ppastorAuthor Commented:

Thanks for the response.

The two DLLs are synergistic. They are both installed on the same server. They simply need to work together in certain cases. I contend that they are both performing middle tier functionality.

Are you saying that this needed to be designed differently? Why does this work perfectly when built for MTS on Windows NT 4 Server?
0
 
EDDYKTCommented:
Do you compile your first component to be binary compilitity?

0
Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
RainUKCommented:
Sorry slightly misread your question (Middle Tier part).

Calling 'New' to create an object from a configured component thats part of the same DLL is always bad (In COM+). The new object gets created without its own context.

This means the new object cannot reliably call GetObjectContext or use the ObjectContext interface. Doing so can result in the same types of problems when using New in MTS (Your DLL call works in MTS(NT4) because I assume you use CreateInstance when creating objects from a class of a configured component(The other DLL)).

So you should use the CreateObject function instead of the New operator in situations when one configured component is creating an object from another configured component in the same DLL.

Hmm try debugging your 2 DLLs in the same project to see what I mean. Basically when you try to run it the DLL which uses the New operator to instantiate an object in the configured DLL will get created but without the assistance of the SCM (Service Control Manager), therefore the new object won't get created by the COM+ runtime in a valid context. Basically you will get Error91 "Object variable or with block not set". Basically the calling code (New operator) receives a null reference from the call to GetObjectContext.

But it will work if you open up two instances of VB (one DLL project in each project) and then call the other DLL using New. 2 Different threads.

Are with me on this ? Or have I lost the plot?

Basically in COM+ when the DLLs get istantiated in the same STA the 'New' operator causes an invalid reference.

0
 
rkot2000Commented:
To RainUK
Re Your statements :
1.     You cannot use early binding with a COM+ dll unless it is installed on the local machine. Which defeats the point of COM+ middle tier stuff!
     
Is 100% wrong.

2.     So you should use the CreateObject function instead of the New operator in situations when one configured component is creating an object from another configured component in the same DLL.
     
With COM+ you can use New or CreateObject, but with MTS you must use CreateObject
0
 
RainUKCommented:
rkot2000

Please explain why 1. is wrong for my benefit.
Also with 2. how can you use NEW to instantiate another COM+ DLL, without error please? Or in that event how can you get a client to call a COM+ DLL on the server by using the NEW keyword?

0
 
ppastorAuthor Commented:
To EDDYKT: Yes, I am maintaining binary compatibility.

To RainUK and rkot2000:
Thanks for your assistance with this.

I realize that I am not being very clear, so I will try to do better.

There are two different DLLs, each in their own package.
The first DLL has a security class (among other classes). The second DLL accesses the security class in the first DLL to do user authentication, etc...

In the second DLL I have a reference to the first DLL in the VB Project References. When I call...
set objSecurity = New clsSecurity
...I get the "Error in Loading DLL".

Also, note that the statement...
Dim objSecurity as clsSecurity
...does not cause an error (I don't know if that matters or not).


As I mentioned this works fine in development. It also works fine in the existing production environment which is Windows NT Server using MTS. In the production version I reference the Microsoft Transaction Server Object Library. For our staging environment (soon to be production) I reference the COM+ Object Library.

0
 
rkot2000Commented:
did you check your event log for any information?
0
 
ppastorAuthor Commented:
To EDDYKT: Yes, I am maintaining binary compatibility.

To RainUK and rkot2000:
Thanks for your assistance with this.

I realize that I am not being very clear, so I will try to do better.

There are two different DLLs, each in their own package.
The first DLL has a security class (among other classes). The second DLL accesses the security class in the first DLL to do user authentication, etc...

In the second DLL I have a reference to the first DLL in the VB Project References. When I call...
set objSecurity = New clsSecurity
...I get the "Error in Loading DLL".

Also, note that the statement...
Dim objSecurity as clsSecurity
...does not cause an error (I don't know if that matters or not).


As I mentioned this works fine in development. It also works fine in the existing production environment which is Windows NT Server using MTS. In the production version I reference the Microsoft Transaction Server Object Library. For our staging environment (soon to be production) I reference the COM+ Object Library.

0
 
RainUKCommented:
Okay understand me!

In the second DLL I have a reference to the first DLL in the VB Project References. When I call...
set objSecurity = New clsSecurity
...I get the "Error in Loading DLL".

If you reference the DLL in your project, the exe looks for the DLL entry in the local registry not COM+ (RegDB). MTS had this thing where it would install DLLs to the local registry, thats why you used to have to make sure you de-registered it. But now in COM+, COM+ has something called RegDB (its own registry for DLLs).

Thats why it cannot load your DLL because it cannot find it in the local registry. Does this make sense?
0
 
ppastorAuthor Commented:

I do see "The redirector was unable to initialize security context or query context attributes."

What does that mean?

P.S.

Sorry about that double post.
0
 
RainUKCommented:
If you read my note about ObjectContext in the first long post. Because 'New' bypasses the SCM which obtains an ObjectContext for COM+ component, remember in MTS you use getObjectCOntext etc! In COM+ you don't have to, by using GetObject the object context is returned implicitly.

The ObjectContext is being returned as NULL. Thats why it won't instantiate your DLL. Nothing to reference!

0
 
ppastorAuthor Commented:

I do see "The redirector was unable to initialize security context or query context attributes."

What does that mean?

P.S.

Sorry about that double post.
0
 
rkot2000Commented:
try to use like this :

Dim objSecurity as clsSecurity
set objSecurity = CreateObject("YOURPROGID.clsSecurity")
0
 
ppastorAuthor Commented:
Thanks for all of your help. It is going to take me a while to digest the differences between MTS and COM+, but late binding works for now.
0
 
rkot2000Commented:
did you try my sample?
it uses early binding.
 
0
 
ppastorAuthor Commented:
Yes, I did. It fails as well.

The folloing does work...

Dim objSecurity as Object
set objSecurity = getObjectContext.CreateInstance("YOURPROGID.clsSecurity")

0
 
RainUKCommented:
You don't need to use GetObjectContext in COM+ anymore for late binding.
As I said it is implicity called when you do CreateObject (Sorry last post I wrote GetObject).

Dim objSecurity as Object
Set objSecurity = CreateObject("YOURPROGID.clsSecurity")


0
 
mirghaniCommented:
hi all, i have gone through this negotiation and i'm facing a problem in my Dll's, and i think u all got a good idea about that could u pls join my Ques:
http://www.experts-exchange.com/Programming/Programming_Languages/Visual_Basic/Q_20537844.html
rgrds Meer.
0

Featured Post

Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

  • 7
  • 6
  • 4
  • +2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now