Fog Creek Software
Discussion Board




Version Compatibility Settings in VB

In the Project->Properties->Component->Version Compatibility in VB for an ActiveX DLL, there are 3 options:

Binary Compatibility
Project Compatibility
No Compatibility

What do these stand for?

John
Wednesday, May 28, 2003

Do a search in your VB documentation (or MSDN) for 'version compatibility' and you'll get several perfectly good articles on the subject. Check out the ones under Visual Basic Concepts in particular.

As an aside, if you have any interest in becoming a professional software developer this is the kind of simple research that you should get used to doing on your own. Documentation, web and usenet searches can uncover all sorts of goodies.

Stephen Martin
Wednesday, May 28, 2003

They don't "stand" for anything per se. It's to do with what GUIDs get generated for the type library, interface and coclasses generated from your ActiveX project.

Always use Binary Compatibility where you can, otherwise you'll break all your clients every time you compile the server.

Better Than Being Unemployed...
Wednesday, May 28, 2003

What's wrong with clicking the Help button on that dialogue box?

John Topley
Wednesday, May 28, 2003

Thanks... I did click on Help and got the following help:

Version Compatibility

Allows you to set the level of version compatibility

No Compatibility — Compatibility not enforced.


Project Compatibility — If selected, the Location box is active and allows you to search for the file with which this project is to be compatible. If cleared, the Location box is not available.
For all ActiveX project types, Project Compatibility is selected by default.

Binary Compatibility — Useful for maintaining compatibility among projects that have been compiled using your component.

I got some articles from informit also...

John
Wednesday, May 28, 2003

It would be nice if the help actually told you what version compatibility was, though...

Better Than Being Unemployed...
Wednesday, May 28, 2003


A good place to start:

http://www.microsoft.com/msj/0100/versioning/versioning.aspx

And Pattison's book on VB/COM+ is as good as any.

Stephen wrote:
> As an aside, if you have any interest in becoming a
> professional software developer this is the kind of simple
> research that you should get used to doing on your own.
> Documentation, web and usenet searches can uncover all
> sorts of goodies.

Whilst I agree with your general point, for someone starting off in COM programming in VB (or C++) the terminology and methods can be confusing at first. The VB documentation is particularly poor in this respect. "Version compatibility" doesn't readily relate to interface definitions and typelibs for COM.

Rgds

Pietro
Wednesday, May 28, 2003

When you make a ActiveX DLL it has a certain interface, defined in Visual Basic by the classes you include their properties and their methods. Each interface, their properties, and their methods is assigned a GUID (a unique ID). All this is done so that VB/COM application can go into the registry and find your DLL.

With no compatibility checked the GUIDs for everything changes when you compile. It is not really suited for day to day development as anything referencing the DLL will break.

Once in a blue moon  VB gets confused and gives me a [[BadRefImp?????]] error on compiled. The only way that I have found to fix this is start at the bottom of my hierarchy of DLLS and recompile once with no compatbility on and then again with binary compatibility on.

Project Compatibility keeps the interface GUIDs stable so other projects can reference it. but initializes the GUID for  properties and methods everytime you compile. This what you use when you coding your project before your first beta release. There are no restrictions on what changes you make . Although you can break stuff if you delete a method/property a module referencing the DLL was expecting.

Binary Compatbility keeps all the GUIDs stable. This allows you to fix bugs and just copy the DLL over the older copy.
However this comes at a cost. The cost is that you can't make a change to method/property name, a method parameter list, or delete method/property.

All of this is because Visual Basic is a thin wrapper around COM and the rules of COM are VB's rules for Active X DLLs.

This scheme is now considered a BAD IDEA by Microsoft and others and .NET  addresses this issue. .NET allows you just to copy your application and it's DLLS in a single directory tree and it will just work.

Robert Conley
Wednesday, May 28, 2003

There are two types of identifiers you have to keep in mind.  CLSIDs (class IDs) identify a COM class (i.e your VB class) and IIDs (interface IDs) identify the interfaces that your COM class implements (each VB class has a default interface called _<WhateverYourClassNameIs>)

No Compatibility - CLSIDs and IIDs change.
Project Compatibility - CLSIDs remain constant, IIDs change
Binary Compatibility - CLSIDs remain constant, IIDs remain constant

Rick Childress (www25.brinkster.com/rchildress)
Wednesday, May 28, 2003

BTW the best thing to do here is to use .NET instead.
Failing that if you MUST use this for activeX Dlls then design your interface, then view it using the oleviewer, getting an IDL file which you can then recompile and use to implement against. Your steps should be:

Create a class called IMyObject,
Add all the things you need (properties methods etc)
Compile this as your activex dll (or whatever)
Use OleView to get out the IDL for it
Use Midl to compile this to get the .tlb (You'll probably need to copy vba.Dll into the same subdirectory)
Create your actual class CMyObject and make it implement IMyObject.
When using your objects people should put references against the .tlb NOT against your DLL. They should then create objects this way:

Dim MyObj as IMyObject
Set MyObj= CreateObject("MyDll.MyObj")

At this point compatibilty stops mattering in the real world and your life will  be much happier.
VB tries real hard to hide this from you, but it never works and then you start having to register and unregister servers etc and life is just plain horrid. If you don't do this you WILL regret it!

Peter Ibbotson
Wednesday, May 28, 2003

http://www.vb-faq.com/Articles/Hughson/bincomp.asp

Matthew
Wednesday, May 28, 2003

Peter Ibbotson said (Wednesday, May 28, 200)

>Failing that if you MUST use this for activeX Dlls then
>design your interface, then view it using the oleviewer,
>getting an IDL file which you can then recompile and use
>to implement against. Your steps should be:

Actually you can stay in the VB world and get pretty much the same benefit by creating a DLL that defines the interface and then have your real DLL implement that interface.  This avoids the need to mess with IDL and allows your programmers to put comments and so on in a familiar location (VB source code).  Apart from using the interface definition DLL instead of a TLB the method is the same.

Kevin Whitefoot
Wednesday, March 10, 2004

*  Recent Topics

*  Fog Creek Home