com, Binary Compatibility - confused :(

microsoft.public.vb.com - Microsoft Visual Basic


com >> Binary Compatibility - confused :(

by Mwob » Tue, 31 Jan 2006 01:24:43 GMT

I have a confusing problem with VB binary compatibility that I am
unsure how to solve. Here's the scenario:

I have a ActiveX class library (DLL) called DLLproject1, that contains
amongst other things a class - called for the sake of simplicity
"PropertiesClass". I have another ActiveX class library
(DLLProject2) that contains a reference to DLLproject1 and contains a
class that exposes an instance of the PropertiesClass as a property -
like this:

Public Property Get PropClass() As DLLproject1.PropertiesClass
....
End Property

Both these classes use binary compatibility. If I need to change
something in DLLproject1 that breaks binary compatibility, then I go
ahead and do this. But when I go back to DLLproject2 and try to build,
I get the error "The binary compatibility DLL or EXE contains a
parameter type or return type whose definition can not be found".

I understand why it is telling me this, its because I broke binary
compatibility in the referenced DLL. But I need to tell it to build
anyway. The only way I can get round this is to turn binary
compatibility off for DLLProject2, build, and then turn it back on
again and build again. This takes ages and its a real pain in
development when the interface for DLLproject1 might change quite
often.

Is there something I can do? Please help, I am pulling my hair out with
this problem.

Matt Roberts

P/S Apologies, I also posted this in vb.general.discussion, and then
found this group.


Top

com >> Binary Compatibility - confused :(

by Ken Halter » Tue, 31 Jan 2006 01:50:05 GMT






Since both components are broken, you'll have to rebuild both.

The "trick" to getting rid of that error is to set that component's
compatibility to None before attempting to build. That way, VB's not even
looking at the interfaces in the older component.

imo, the very best thing you can do when preparing to break is...

Start by unregistering any components you plan on breaking.
Now, delete those components (or use winzip, etc, to get rid of them)
Thing is, if VB can find them, it'll "think" it's doing you a favor by
re-registering them. That causes problems.

Lastly, rebuild in reverse dependency order.... so, if DLLA needs DLLB,
build DLLB first, then DLLA


--
Ken Halter - MS-MVP-VB - Please keep all discussions in the groups..
DLL Hell problems? Try ComGuard - http://www.vbsight.com/ComGuard.htm
Freeware 4 color Gradient Frame? http://www.vbsight.com/GradFrameCTL.htm




Top

com >> Binary Compatibility - confused :(

by Lance Wynn » Tue, 31 Jan 2006 01:58:02 GMT

Hi,
I think that's the only way to do it.
It's supposed to be a pain, because breaking interfaces like that (So often
that it's a hassle to remove, and re-add binary compatibility when it
happens) is bad. Not that it's unnecessary, but I think it is bad practice.
If those are the only 2 interfaces you are concerned with, and the project
is not distributed widely, or if the DLL's are only accessed from a script
interface (Such as ASP, or VBS), you may consider putting both projects into
a project group, and setting compatibility to the project level.

If you use these dll's in external applications, you will run into
compatibility issues that will be much worse to track down then this, but if
not then you could probably get by with project compatibility, and perhaps
save yourself some time (but it may cost you more time in the long run).

Lance




I have a confusing problem with VB binary compatibility that I am
unsure how to solve. Here's the scenario:

I have a ActiveX class library (DLL) called DLLproject1, that contains
amongst other things a class - called for the sake of simplicity
"PropertiesClass". I have another ActiveX class library
(DLLProject2) that contains a reference to DLLproject1 and contains a
class that exposes an instance of the PropertiesClass as a property -
like this:

Public Property Get PropClass() As DLLproject1.PropertiesClass
....
End Property

Both these classes use binary compatibility. If I need to change
something in DLLproject1 that breaks binary compatibility, then I go
ahead and do this. But when I go back to DLLproject2 and try to build,
I get the error "The binary compatibility DLL or EXE contains a
parameter type or return type whose definition can not be found".

I understand why it is telling me this, its because I broke binary
compatibility in the referenced DLL. But I need to tell it to build
anyway. The only way I can get round this is to turn binary
compatibility off for DLLProject2, build, and then turn it back on
again and build again. This takes ages and its a real pain in
development when the interface for DLLproject1 might change quite
often.

Is there something I can do? Please help, I am pulling my hair out with
this problem.

Matt Roberts

P/S Apologies, I also posted this in vb.general.discussion, and then
found this group.



Top

Binary Compatibility - confused :(

by Mike Harrington » Tue, 31 Jan 2006 15:42:54 GMT

I guess it would be prudent for me to ask why DLLproject1 would change and
break compatibility so often. If this is happening you may want to look
back at how the component is designed.

In some cases like these it's best to create multiple versions of a class
within a DLL and use Interfaces to make them backwards compatible (look at
any of Microsoft's XML libraries after version 2 for example). Also think
about trying things like a standard factory design pattern to create the
objects. In the same line of thought if DLLProject2 is the only thing that
is ever referencing DLLProject1 it would be wise to just combine them
together.

HTH

Mike






Top

Binary Compatibility - confused :(

by roberts.mattroberts » Tue, 31 Jan 2006 15:49:04 GMT

Thanks Ken and Lance,

I understand that VB makes this a pain because I am breaking my
interface constantly, but the DLL is undergoing a large scale change,
so we will break compatibility often. Luckily, these DLL's are only
used by ASP script, no other extral applications are currently using
them so that does make like a bit easier for us. I think I will try
going down the route of using project compatibility while we are in
development, and then when we are coming to the end of development and
are about to ship, I will change to binary compatibility.

Thanks for the tips - much appreciated.


Top

Binary Compatibility - confused :(

by Ken Halter » Tue, 31 Jan 2006 23:24:05 GMT





What I do is.... instead of breaking often (and driving myself nuts), I add
methods that take extra or different arguments and call those "EX" methods
(similar, I suppose, to dotNet's overloaded methods).. so, instead of
something like....

Call classname.FillForm(SomeArgs)

...I use....

Call classname.FillFormEX(SomeOtherArgs, AnotherArg)

...then, when things are real close, I remove the obsolete methods (which
breaks things), rename the EX methods and rebuild. One thing to keep in mind
is.... before making anything public, be absolutely sure you need to make it
public. Once it's public, you're hosed if things change.

Another "trick" when releasing a "beta" version that you know will break
is.... use Variants for argument types. That way, you can pass arrays,
objects, whatever you need. When things are close to completion, make the
break and change the Variants to the "real" types.

Just remember to unregister and hide (delete or zip) any components you plan
on breaking so VB doesn't "think" it's doing you a favor by re-registering
the obsolete pieces.

--
Ken Halter - MS-MVP-VB - Please keep all discussions in the groups..
DLL Hell problems? Try ComGuard - http://www.vbsight.com/ComGuard.htm
Freeware 4 color Gradient Frame? http://www.vbsight.com/GradFrameCTL.htm



Top
Similar Threads

1. Binary Compatibility and Preserve Compatibility ??? 

Hi all,

I have a query about that dreaded subject of binary compatibility, as I'm 
expreiencing strange behaviour.

We have two dlls which have been binary compatible for quite some time now, 
any in-compatibilities addressed by updating the compat version with the new 
dll etc and all was fine, until recently when a change was made to a no of 
methods where the interface was modified by adding an new optional param.

When we re-compiled VB informed us that it was in-compatible and we where 
presented with the usual dialogue where we could go ahead and break 
compatibility but also had the option of preserving compatibility which we 
selected and recompiled, and so later in our test env this went bang!, only 
getting around the problem by either recompiling both dlls (which I couldn't 
understand as I had chosen to preserve compatibility), or by treating the dll 
as though compatibility had been broken and going the thru the process of 
re-compiling, preserving and updating the compat dll with the updated.

So what I guess I'm asking is does preserve compatibility do what it says on 
the tin, or does it only work for certain changes or not at all.

If anyone got any ideas/info I love to hear 'em as it seems if a 
compatibility issue arises with either the option of breaking AND preserving, 
whichever you choose you must always update the compat dll to ensure the dlls 
are still compatible with previous versions.

Thanks in advance,

Stephen.

2. Binary Compatibility VB from VC

3. Reflection, Classes and the Lack of Binary Compatibility 

Does anyone happen to have a snippet of [VB 2003] code that,
for a given Type, produces a list of [all] the properties, methods,
constructors, and so on for that Class?

TIA,
    Phill  W.

4. Binary Compatibility in .NET - VB.Net

5. ActiveX EXE Binary compatibility 

Hi

Does ActiveX EXE have the same issues as ActiveX DLL with Binary
compatibility in VB6?

Ian

6. Avoiding breaking binary compatibility?

7. Binary compatibility 

Hi,
    I am to create a ATL COM DLL which is binary compatible with a VB DLL.
 To do this I took out the IDL from the DLL and used that to create the COM
IDL. Though the DLL's (VB and VC) are binary compatible in terms of using
the same ProgID, CLSID and the same LIB ID, the VB Clients are not able to
refer to the ATL COM DLL perfectly.
On further investigation, I found that there is a minor difference between
the IDL definitions between the two DLLs.

In the VB DLL.the following line is mentioned in the IDL

    typedef [uuid(1A998014-A9B4-11D3-84D3-00C04F6D1303), version(1.0),
public]
    _ErrorLog ErrorLog___v0;

In the VC DLL, the same line appears as

    typedef [uuid(1A998014-A9B4-11D3-84D3-00C04F6D1303), version(1.0),
public]
    _ErrorLog* ErrorLog___v0;

Please note that the difference between the declarations is that there is a
pointer sign in front of the ErrorLog___v0;

Has anybody ever dealt with compatibility between VB DLL and VC DLL's ??

Thanks in advance.

Regards,
Biswajit

8. Binary compatibility and parameter type definition can not be found