Binary Compatibility Blues
-
I have a fairly large VB 6 program group that generates 20 DLLs (each a separate project brought together by one VB project group). This is a system which I must keep running (i.e. conversion to .NET and/or code consolidation is not an option at this point in time - just in case you ask :-D ). These DLLs are used in Microsoft Office apps to provide custom connections between those apps and the document management system. There are also many Word document template files coded in VBA which use the objects provided by these DLLs. Thus far these DLLs have been separately compiled in VB 6 with No Compatibility making it very difficult to deploy simple changes without recompiling all the dependent DLLs and templates. I want to change this to use binary compatibility but am having great trouble. The procedure followed so far: 1. unregistered all DLLS on my machine. 2. copied the current build of the DLLs (compiled with No Compatibility) to a separate directory named "Compatibility" in the VB 6 project tree. 3. Changed the project definition of each separate project to use Binary Compatibility and set the compatible component to reference the corresponding DLL in the Compatibility directory. 4. Rebuilt the project group. It is at this stage the first compile warns that "The get property for the 'ActiveControl' property in the 'LogReview' class module is missing from a similar declararion in the version-compatible component." There is only one choice available - the radio button to Break Compatibility is set, the other for Preserve is disabled. If I choose to break compatibility, I will be in the same situation that I was trying to avoid in the first place. I really don't want to manually recompile all the templates to reference the new CLSIDs unless absolutely necessary. Can anyone offer some advice on how to proceed? Cheers. ...Steve
-
I have a fairly large VB 6 program group that generates 20 DLLs (each a separate project brought together by one VB project group). This is a system which I must keep running (i.e. conversion to .NET and/or code consolidation is not an option at this point in time - just in case you ask :-D ). These DLLs are used in Microsoft Office apps to provide custom connections between those apps and the document management system. There are also many Word document template files coded in VBA which use the objects provided by these DLLs. Thus far these DLLs have been separately compiled in VB 6 with No Compatibility making it very difficult to deploy simple changes without recompiling all the dependent DLLs and templates. I want to change this to use binary compatibility but am having great trouble. The procedure followed so far: 1. unregistered all DLLS on my machine. 2. copied the current build of the DLLs (compiled with No Compatibility) to a separate directory named "Compatibility" in the VB 6 project tree. 3. Changed the project definition of each separate project to use Binary Compatibility and set the compatible component to reference the corresponding DLL in the Compatibility directory. 4. Rebuilt the project group. It is at this stage the first compile warns that "The get property for the 'ActiveControl' property in the 'LogReview' class module is missing from a similar declararion in the version-compatible component." There is only one choice available - the radio button to Break Compatibility is set, the other for Preserve is disabled. If I choose to break compatibility, I will be in the same situation that I was trying to avoid in the first place. I really don't want to manually recompile all the templates to reference the new CLSIDs unless absolutely necessary. Can anyone offer some advice on how to proceed? Cheers. ...Steve
If you make breaking changes to the interface of your components, such as changing a method parameter or removing a method, this breaks binary compatibility. You might want to read Maintaining Binary Compatibility[^] and How To Use Project and Binary Compatibility[^] for more information. RageInTheMachine9532 "...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
-
If you make breaking changes to the interface of your components, such as changing a method parameter or removing a method, this breaks binary compatibility. You might want to read Maintaining Binary Compatibility[^] and How To Use Project and Binary Compatibility[^] for more information. RageInTheMachine9532 "...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
Dave, I agree and have read those articles, but I have used the current DLL as the binary compatible version. There were no code changes at all when I recompiled yet compatibility was somehow broken. This is what I cannot understand. ...Steve
-
If you make breaking changes to the interface of your components, such as changing a method parameter or removing a method, this breaks binary compatibility. You might want to read Maintaining Binary Compatibility[^] and How To Use Project and Binary Compatibility[^] for more information. RageInTheMachine9532 "...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
Dave, Egg on face time... seems like I've been given DLLs that were NOT compiled with the 'official' source code. :( VB is telling me the truth after all. Cheers. ...Steve
-
Dave, Egg on face time... seems like I've been given DLLs that were NOT compiled with the 'official' source code. :( VB is telling me the truth after all. Cheers. ...Steve
Even the best of us make mistakes like that. We can even make some real stupid mistakes! I was chasing my tail yesterday for about 6 hours, then found out I didn't even need the system I was working on... :-D RageInTheMachine9532 "...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
-
Dave, Egg on face time... seems like I've been given DLLs that were NOT compiled with the 'official' source code. :( VB is telling me the truth after all. Cheers. ...Steve
Seems like it was my fault to begin with - I had recompiled the DLLs on my machine many times before cleaning the registry and copying all files again from Visual Source Safe. Looks like my registry still has orphaned entries which are upsetting the build process. A full rebuild with binary compatibility on another (fresh) machine solved the problem. Anyone know of a good and free utility to clean the registry? The ones I have found so far on the net all require $$'s (yes - I'm cheap :-D). ...Steve