Link to home
Start Free TrialLog in
Avatar of MelissaEvans
MelissaEvans

asked on

Binary Compatibility Distribution Problems

OK... This is something that I thought I understood, but apparently do not.  *sigh*  I have developed an OCX with Binary Compatibility.  The file that it's pointing to is the current version of the OCX.  I don't know what it's doing with this file.  I had assumed it was checking for differences between what is there and what's being compiled to be sure it's "compatible."  I added some methods, and recompiled it.  It recompiled just fine.  All seemed well.  Then I gave the new OCX (and shell since the shell also changed - the shell had been recompiled with the new ocx also) to our customers.  They're getting the errir, "Failed to activate control 'VB.UserControl'. This control may be incompatible with your application. Make sure that you are using the version of the control that was provided with your application."  

MSDN says the resolution is to "Ensure that the Binary Compatibility is alwasy set to the latest version of your ActiveX component, or a version that includes all Public Methods and Properties."  As far as I know, I'm doing this.

It also says to "reset the Binary Compatible file to the seoncd version of the ActiveX .ocs file."  I haven't changed this file and am unsure what I should change it to and why.  

The users had unregistered the old version, copied over the new version, then registered the new version of the OCX.  

I hope that that's all the information you need.  Any help is greatly appreciated.  Thanks.
~Melissa

Avatar of rspahitz
rspahitz
Flag of United States of America image

As I understand it, the binary compatibility allows you to create a unique ID that references your component.  As long as your component is backward compatible to old components, then a simple re-registration should be sufficient.

If your app is not backward compatible (certain functions were removed/obsoleted), then your best bet is to give your component a new name.

After the users unregistered/re-registered, did they still have the problem?
(We had similar problems when we did not properly remove our components.)
Avatar of MelissaEvans
MelissaEvans

ASKER

That's my understaning of Binary Compatibility also.  

The control is backwards compatible - nothing was taken away; but some methods were added.  This wouldn't affect apps using the older version, so it should be fine.. right?

The problem only has occured when they unregister the old control, then register the new control.  
My experience with this is limited, and I don't see a lot of other experts jumping in here, so I suspect there isn't much knowledge about it...

New methods shouldn't adversely affect your component, and would only offer new features when implemented.

However, if you changed the definition of an existing method, that essentially removed the old one and could be the cause of some problems.

As for unregister/re-register, that shouldn't cause any problems unless the unregister process fails.
How are they unregistering: through the uninstall process? add/remove programs? or manually through regsvr32 -u?
My experience with this is limited, and I don't see a lot of other experts jumping in here, so I suspect there isn't much knowledge about it...

New methods shouldn't adversely affect your component, and would only offer new features when implemented.

However, if you changed the definition of an existing method, that essentially removed the old one and could be the cause of some problems.

As for unregister/re-register, that shouldn't cause any problems unless the unregister process fails.
How are they unregistering: through the uninstall process? add/remove programs? or manually through regsvr32 -u?
I didn't alter the existing methods (I know that makes it very angry), only added brand new ones.

I used regsvr32 to un/register the control.
If there were no errors displayed while un/re-registering, then everything should have worked.

Did you try the install on a clean machine that never had it?  Then what happens when you un/re-register?

--
This from the book "ActiveX Control Programming in 21 Days":

"There is one more ver important consideration when generating a control.  You need to make sure that each time you generate a new version of an existing control, the class ID information that is stored in the System Registry information stays the same.  If this class ID changed each time you generated a nwe version of the control, widespread pain and suffering woudl result!  Host applications integrate a control based on this ID.  If it changes, all the host applications that once worked would suddenly not be able to reference the control at all.

"This problem is easily remedied. ...Select [Project] properties]...Select the Component tab...

"Notice that there are several compatibility options under the Version Compatibility area.  The first, No Compatibility, would provide you with no compatibility at all.  New calss IDs woudl be generated every time an OCX was built.  The second option, Project Compatibility, keeps some information consistent to support project-level integration, but does not guarantee to keep all interfaces the saem.  The Binary Compatibility option is the one to select.  Binary compatibility indicates that you want to keep the Registry-related information consistent from one build of the control to another."

"Visual Basic needs to know where to find the previous version of the OCX file in order to enforce this consistency.  Therefore a file-specification box is under the Binary Compatibility option.  The location of the OCX file you just generated should be specified here.  This specification process is a one-time step.  Once you tell Visual Basic where to find your OCS, the file in that location will be considered to be the master location that is used to force consistency in subsequent builds.  Therefore, each time you generate a new OCX file, you should place it in this location.  Then your latest version will always be used for the consistency checks as you build subsequent versions."

Does that help any?
One thing I've found which causes nightmares with binary compatibility is enums. Are you using them? If you change them you don't get a warning, but it breaks compatibility and causes this sort of problem.
I guess my enums are pretty static, but it makes sense that this would cause the object to change.  However, it would be annoying to have it force a need to upgrade when all you do is add a new enum entry.
rspahitz - I tried it on a clean machine and un/re-registered and it worked fine.  Then I tried to re-register without unregistering and it worked just fine too.  The fact that it works for me is good and bad.  I would rather it broke so that I could fix it with some certainty that it will work on the customer's machines.  

andyclap - no, I am not using any enums.  

For the record, the compatibility file is the ocx that I'm making as I go along.  I've read that I shouldn't do this, but it's been done for months now.  It seems to indicate that it's verifying compatibility against the last compiled version (which is fine as far as I can tell).  

~Melissa
Come to think of it, I "upgraded" many times when I was on site, and it worked fine.  It's just when someone else tries that it dies.  I can't get it to break here.  Am I magic?  I gave them exact directions (unregister, rename, copy, register) and have talked them through it on the phone, and they seem to be doing the same thing.

The other part that has me quite confused is the fact that I've sent them a new shell application (for now, there's only one app that uses the control).  The shell I sent them was compiled with the new version of the control.  It shouldn't have any issues.  
>For the record, the compatibility file is the ocx that I'm making as I go along
That could be your problem. I usually have a 'gold' directory containing the dlls/ocxs for binary compatibility away from the compilation destination.
Have you tried getting them to send you the dll, store it off somewhere and compile against it?
One thing to try.  Get regclean from microsoft.  Delete the control on the customer's PC and then run regclean. Prior to running regclean, search the hard drive for all occurances of this ocx.   There may be other copies.

This should remove any stray registry entries that may be causing the problem.  Then registry the new OCX.

Since you have given the customer the application that uses the control, and it works on your PC  I don't understand why it does not work.

Also..are you sure the customer is running the same service pack level of VB support files.  Could you have upgraded your PC, but the customer has older VB support DLLs and controls?
ASKER CERTIFIED SOLUTION
Avatar of Hencah
Hencah

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Hencah - P&D failed misserably at getting everything the package needed.  We used Install Shield.

As for manually un/re-registering, it was the quickest way to get it to them (there are six sites running it).  If this continues to be an issue, then we'll try making a full blown package out of it again.  
"(unregister, rename, copy, register)"

I noticed that I had problems when I renamed the original.  If the unregister failed, it would rename it in the registry and cause problems.

As such, I've learned to: Copy (original), Delete (original), Rename (from copy to original name), Register.

You can see it that helps.
This doesn't have really anything to do with versioning...  the version of the OCX is probably correct as long as you propogated it to the users...  the problem you are having is with the OCX's cache file it creates.  It creates an .oca file when it is run the first time.  If you do not wipe it out, your program will continue to use the OLD cached file...   Kill the oca and run the program again

:)
Dave - The OCA on the devolpment computer?  If that were the case, wouldn't it be broken all the time?  There isn't an OCA file on the customer's computer to kill.  
you have performed a search on the client machine and found no *.oca file...?  that's odd
Yes.  I am only able to run this on a test client machine - our customers are on the East coast and three hours ahead of us, they already went home.  I'll have them look for it tomorrow morning though.  I have another test machine at my house, I'll look for it there too...
Thanks for pointing me in the right direction.  We made a new installation and it went well.  =)