ActiveX DLL Binary Compatibilty Problems

[pmccorm]

Hi, I have developed a DLL which is used by several different machines. I have the DLL set as Binary Compatibile to allow me to make enhancement upon the DLL whist allowing the old version to still run on all the other PCS. This has work great while making enhancements to existing methods or properties.

But I have ADDED a new method (Function) and re-complied my DLL. But I am getting a error of all other PCS saying Object variable or With block variable not set (Error 91).

I don't get a warning stating I have broken compatibilty, because I haven't changed the parameters or data types of existing methods or properties.

What have I done wrong???

Thanks, Paul

[André]

I would sugges that you debug this component and find the spot where the error occurs.

It seems to me, that this problem has nothing to do with binary compatibility.

Are you opening a recordset without setting the rs object?
anything similar?

André

[pmccorm]

Thanks for that Andre, I think you have pointed me in the right direction.

What we have is a General Library as a ActiveX DLL. We have been enhancing the existing functions and re-compiling the DLL with the component as Binary Compatibility. Everything has been fine. Just this week I ADDED a new function and re-compiled the DLL to get the error : Object variable or With block variable not set (Error 91) whenever I run my client side executable.

But when I unregister and then re-register this DLL on the client PC the error message is removed.

Any clues to resolve this registering, what have I done wrong? Cause with hundreds of PCs the thought of having to re-register them all is not a option.

Thanks again,

Paul

[André]

Hundreds of PCs outch!!!

Hmmmm, I have some questions:

The Client PC you refer to is it your development machine?

When you have successfully recompiled your DLL with binary compatibilty, you should not need to unregister and then re-register, you should just overwrite your existing Dll.

How do you distribute your new versions?

Are these machines on a LAN?

If yes:
Why not centralize the DLL on a server, install it in MTS/COM+ and export the package to your clients?

André

[pmccorm]

Hi again,

no the client PC isn't the Development PC. We develop all our software(DLL and .exe's) in our development suite, the client PCs are in the rest of the company, who use these programs.

When we re-compile our DLL we overwrite the existing DLL and this is on our LAN. Our client PC's are pointing to this location of the DLL on our LAN. The client PCs and our .exe programs are all centralised on our LAN.

Thanks again,

Paul

[André]

Are you still experiencing the problem?

André

[pmccorm]

Yeah we still get the client PC's error as before.

Don't really want to register the DLL on all the client PCs. This seems a work around not actually solving the problem!

Thanks in advance,

Paul

[tumblingdown]

Is your new method on an exisitng class in the dll, or have added a new class, which contains the method?


td.

[pmccorm]

The new method is within a existing class in the DLL.

Thanks in advance,

Paul

[tumblingdown]

umm ok.

There are probs with bin compat when adding new classes (the new class guid will change every compile), but i haven't heard of existing ones changing. I'll have a scout around.

Does you lib have any dependancies that may have changed?


td.

[tumblingdown]

i ask this because you said un-reging and re-reging removes the problem. This could indicate that with the re-reg, you are getting the latest verison of the dependacy reference.


td.

[pmccorm]

Thanks for that,

I re-compiled my DLL without any new functions, and the client PCs can all run the exe.

To not have any new dependacy upon the DLL I added a simple new function. To display a Hello World messagae in a messageBOx. Re-compiled the DLL and still had the same problem. Which would say that I don't have any new dependacy on my DLL.

Thanks in advance,

Paul

[frank ashley]

Just a quick thought,

have you increased the dlls version no?

[pmccorm]

Hi,

in the project properties the Auto Increment,in the MAKE tab, is ticked to increment the versions.

[André]

I don't see what this is good for?

André

[pmccorm]

Do you think I souldn't have this Auto Increment selected???

[André]

What I mean is that this make autoincrement does not affect your compatibility issue. It's just to know the compile version. It's just information about your latest compiled version.

[André]

Try the following steps:

On project properties:

check the unattended execution checkbox
then check the retained in memory checkbox

On your class check the persistable property to 1-Persistable.

Let me know if this does the trick

André

[André]

Hi again,

If the latter does not help try to compile to P-code. This compilation form does wonders sometimes.

André

[pmccorm]

Hi,

I looked at the General Tab on the project properties. The two boxes (options) you mentioned are disabled, I cannot checked them!

What do I do to be able to select them,

Many thanks again,

Paul

[André]

Hi there, these properties have to be checked on your Dll project, not the exe's!!!

André

[pmccorm]

Hi,

The properties I have checked are those on my DLL. They are disabled. I have even opened a new project DLL and checked the properties there but they are also disabled. I must admit I am confused here!! WHy are they disabled?

Thanks,

Paul

[André]

Unattended execution should be enabled.
Retained in memory is not enabled by default. It becomes enabled once you check the unattended execution checkbox.

Are you working on a project group? what version of VB are you running? SP4?

André

[pmccorm]

Hi,

The buttons do become available under a new DLL, my mistake. But they aren't in our existing DLL. And yes this DLL is a Groub Project.

We have VB6 Enterprise Edition. How can I tell if we have SP4? Not sure what this is sorry!

Many thanks,

Paul

[André]

When you open VB a Splashscreen appears, if you have it there should be SP4 written there.

Anyway, have you tested if there is any difference?
Remeber the persistable property.

André

[pmccorm]

The only way I final got the DLL to work was remove the other projects that made it a Group project, removed all Binary Compatibility settings and then saved my DLL, NOT compiling it. Re-opened it and re-created the Group Project and added the Binary Compatibilty settings and then compiled the DLL.

Added new functions and the existing exe's on the Client PC's that where compiled under the old DLL still worked.

So I don't reallt know what happened, strange!!

Thanks a lot