Version compatibility broken, but code didn't change 
Author Message
 Version compatibility broken, but code didn't change

Ok, this one is really baffling me...

First, the environment...
VB5, SP3
NT4W, SP5

I've got an ActiveX control project that contains 15 controls, a class
module, another class module that defines an interfact that all of the
controls implement and a single module file.

1) I compiled the project with no compatibility.  Everything worked fine.
2) Next, I copied the ocx file that was generated to a 'compatibility'
directory and set the project for version compatibilty.  The 'reference'
file was the OCX file I copied to the 'compatibility' directory.  So far, so
good...
3) Now, without changing a single line of code, I recompile the project.

Guess what...

VB thinks that I've broken the compatibility, even though I haven't changed
a single line of code.  When I click the Declaration button, the old and new
declarations are exactly the same.

OK, here's another 'view' of this same problem.

On thing that is causing the compatability to 'break' is a property that has
an argument that's an enum.  I've defined the argument in the source code as
ppsedits.editLabelLocation.  Now, let's try the same scenario again...

1) Compile project with no compatibility.  Everything's fine.
2) Copy the generated ocx file to the 'compatibility directory' and change
the project to version compatibility, just like before.
3) Recompile the project without changing any code.
Once again, VB thinks I've broken compatibility. But this time, when I click
the Declarations button, the message shows a different picture.
It says that the property definition was:
   Property Get LabelLocation() as editLabelLocation
and that it has been changed to:
   Property Get LabelLocation() as ppsedits.editLabelLocation

This doesn't make sense...The argument is defined was defined as
"ppsedits.editLabelLocation" when I built the 'reference' OCX and when I
built the version compatible OCX, so what is telling it that the argument is
defined as just "editLabelLocation"

I've tried exiting VB between each compile and restarting between each
compile, but the results are the same.

Does anyone have any suggestions?

Ron Gallagher
Atlanta, GA



Tue, 29 Jan 2002 03:00:00 GMT  
 Version compatibility broken, but code didn't change
Here's an update....

I was able to get this project 'rearranged' so that I wasn't 'breaking' the
compatibility erroneously.

The project in question contains a collection of controls that we are using
as enhancements to the standard controls that come with VB.  One of the
controls in this project is a 'composite' control.  It uses three other
controls in this same project in order to provide a quick and easy way for
our developers to present/capture address info.  This control is essentially
a composite of three different types of controls that are also in the
project.

The erroneous breakage of the compatibility was occurring on the three
objects that are used in this composite object.  Seeing a possible link
between the erroneous breakage and this composite control, I moved the
composite control into another ActiveX control project.  At this point,
there were no 'composite' controls in the project that was having the
problem.

After doing this, I went through the same sequence of steps:

1) Compile with no compatibility
2) Copy generated OCX file to a 'compatibility' directory
3) Set binary compatibility to OCX in the 'compatibility' directory
4) Recompile

Viola...No erroneous breakage of the compatibility.

This situation only started happening recently.  I recently installed NT SP5
on my system, but I can't recall if the initiation of this problem coincided
with that service pack.

The 'problem' is fixed, but I don't like the solution.  If someone has a
viable explanation for the cause of this problem, I would appreciate hearing
about it via email

Thanks in advance...

Ron Gallagher
Atlanta, GA

Quote:

>Ok, this one is really baffling me...

>First, the environment...
>VB5, SP3
>NT4W, SP5

>I've got an ActiveX control project that contains 15 controls, a class
>module, another class module that defines an interfact that all of the
>controls implement and a single module file.

>1) I compiled the project with no compatibility.  Everything worked fine.
>2) Next, I copied the ocx file that was generated to a 'compatibility'
>directory and set the project for version compatibilty.  The 'reference'
>file was the OCX file I copied to the 'compatibility' directory.  So far,
so
>good...
>3) Now, without changing a single line of code, I recompile the project.

>Guess what...

>VB thinks that I've broken the compatibility, even though I haven't changed
>a single line of code.  When I click the Declaration button, the old and
new
>declarations are exactly the same.

>OK, here's another 'view' of this same problem.

>On thing that is causing the compatability to 'break' is a property that
has
>an argument that's an enum.  I've defined the argument in the source code
as
>ppsedits.editLabelLocation.  Now, let's try the same scenario again...

>1) Compile project with no compatibility.  Everything's fine.
>2) Copy the generated ocx file to the 'compatibility directory' and change
>the project to version compatibility, just like before.
>3) Recompile the project without changing any code.
>Once again, VB thinks I've broken compatibility. But this time, when I
click
>the Declarations button, the message shows a different picture.
>It says that the property definition was:
>   Property Get LabelLocation() as editLabelLocation
>and that it has been changed to:
>   Property Get LabelLocation() as ppsedits.editLabelLocation

>This doesn't make sense...The argument is defined was defined as
>"ppsedits.editLabelLocation" when I built the 'reference' OCX and when I
>built the version compatible OCX, so what is telling it that the argument
is
>defined as just "editLabelLocation"

>I've tried exiting VB between each compile and restarting between each
>compile, but the results are the same.

>Does anyone have any suggestions?

>Ron Gallagher
>Atlanta, GA




Tue, 29 Jan 2002 03:00:00 GMT  
 Version compatibility broken, but code didn't change
Who's Viola?
Quote:

> Here's an update....

> I was able to get this project 'rearranged' so that I wasn't 'breaking' the
> compatibility erroneously.

> The project in question contains a collection of controls that we are using
> as enhancements to the standard controls that come with VB.  One of the
> controls in this project is a 'composite' control.  It uses three other
> controls in this same project in order to provide a quick and easy way for
> our developers to present/capture address info.  This control is essentially
> a composite of three different types of controls that are also in the
> project.

> The erroneous breakage of the compatibility was occurring on the three
> objects that are used in this composite object.  Seeing a possible link
> between the erroneous breakage and this composite control, I moved the
> composite control into another ActiveX control project.  At this point,
> there were no 'composite' controls in the project that was having the
> problem.

> After doing this, I went through the same sequence of steps:

> 1) Compile with no compatibility
> 2) Copy generated OCX file to a 'compatibility' directory
> 3) Set binary compatibility to OCX in the 'compatibility' directory
> 4) Recompile

> Viola...No erroneous breakage of the compatibility.

> This situation only started happening recently.  I recently installed NT SP5
> on my system, but I can't recall if the initiation of this problem coincided
> with that service pack.

> The 'problem' is fixed, but I don't like the solution.  If someone has a
> viable explanation for the cause of this problem, I would appreciate hearing
> about it via email

> Thanks in advance...

> Ron Gallagher
> Atlanta, GA


> >Ok, this one is really baffling me...

> >First, the environment...
> >VB5, SP3
> >NT4W, SP5

> >I've got an ActiveX control project that contains 15 controls, a class
> >module, another class module that defines an interfact that all of the
> >controls implement and a single module file.

> >1) I compiled the project with no compatibility.  Everything worked fine.
> >2) Next, I copied the ocx file that was generated to a 'compatibility'
> >directory and set the project for version compatibilty.  The 'reference'
> >file was the OCX file I copied to the 'compatibility' directory.  So far,
> so
> >good...
> >3) Now, without changing a single line of code, I recompile the project.

> >Guess what...

> >VB thinks that I've broken the compatibility, even though I haven't changed
> >a single line of code.  When I click the Declaration button, the old and
> new
> >declarations are exactly the same.

> >OK, here's another 'view' of this same problem.

> >On thing that is causing the compatability to 'break' is a property that
> has
> >an argument that's an enum.  I've defined the argument in the source code
> as
> >ppsedits.editLabelLocation.  Now, let's try the same scenario again...

> >1) Compile project with no compatibility.  Everything's fine.
> >2) Copy the generated ocx file to the 'compatibility directory' and change
> >the project to version compatibility, just like before.
> >3) Recompile the project without changing any code.
> >Once again, VB thinks I've broken compatibility. But this time, when I
> click
> >the Declarations button, the message shows a different picture.
> >It says that the property definition was:
> >   Property Get LabelLocation() as editLabelLocation
> >and that it has been changed to:
> >   Property Get LabelLocation() as ppsedits.editLabelLocation

> >This doesn't make sense...The argument is defined was defined as
> >"ppsedits.editLabelLocation" when I built the 'reference' OCX and when I
> >built the version compatible OCX, so what is telling it that the argument
> is
> >defined as just "editLabelLocation"

> >I've tried exiting VB between each compile and restarting between each
> >compile, but the results are the same.

> >Does anyone have any suggestions?

> >Ron Gallagher
> >Atlanta, GA




Tue, 29 Jan 2002 03:00:00 GMT  
 Version compatibility broken, but code didn't change

Quote:
> Who's Viola?

Ref the Shakespeare thingie which starts "If music be the food of love, play
on..." -- she was definitely in that, although as I recall it was the butler
who did it.  (Jeeves knows these things.)

Pip pip!

Bertie

PS Talking of violas reminds me of cellos, those genetically-modified violas
which you wrap your legs round.  Sir Thomas Beecham, having made his fortune
in sneezing powder, did a bit of conducting in his spare time and once
endured a spot of rather bad cello playing by a pretty young thing.  He
stopped her after five minutes and asked her in front of the whole orchestra
why it was that, with an instrument between her legs capable of giving
pleasure to thousands, all she could do was scratch it?



Wed, 30 Jan 2002 03:00:00 GMT  
 Version compatibility broken, but code didn't change
This compatibility thing troubles everyone I guess... me too.

Anyone with a comprehensive explanation on how to go about including OCXs
which change often in project without this problem will be a "god sent" :-)

--
Manav Sehgal
Consultant - E-business Strategy and Development

Infonetmap Technologies
Web: http://www.infonetmap.com
Phone: 91-11-6943483
ICQ: 41977597
Office: F-93, Sarita Vihar, New Delhi - 110044, India

Quote:
> Who's Viola?


> > Here's an update....

> > I was able to get this project 'rearranged' so that I wasn't 'breaking'
the
> > compatibility erroneously.

> > The project in question contains a collection of controls that we are
using
> > as enhancements to the standard controls that come with VB.  One of the
> > controls in this project is a 'composite' control.  It uses three other
> > controls in this same project in order to provide a quick and easy way
for
> > our developers to present/capture address info.  This control is
essentially
> > a composite of three different types of controls that are also in the
> > project.

> > The erroneous breakage of the compatibility was occurring on the three
> > objects that are used in this composite object.  Seeing a possible link
> > between the erroneous breakage and this composite control, I moved the
> > composite control into another ActiveX control project.  At this point,
> > there were no 'composite' controls in the project that was having the
> > problem.

> > After doing this, I went through the same sequence of steps:

> > 1) Compile with no compatibility
> > 2) Copy generated OCX file to a 'compatibility' directory
> > 3) Set binary compatibility to OCX in the 'compatibility' directory
> > 4) Recompile

> > Viola...No erroneous breakage of the compatibility.

> > This situation only started happening recently.  I recently installed NT
SP5
> > on my system, but I can't recall if the initiation of this problem
coincided
> > with that service pack.

> > The 'problem' is fixed, but I don't like the solution.  If someone has a
> > viable explanation for the cause of this problem, I would appreciate
hearing
> > about it via email

> > Thanks in advance...

> > Ron Gallagher
> > Atlanta, GA


> > >Ok, this one is really baffling me...

> > >First, the environment...
> > >VB5, SP3
> > >NT4W, SP5

> > >I've got an ActiveX control project that contains 15 controls, a class
> > >module, another class module that defines an interfact that all of the
> > >controls implement and a single module file.

> > >1) I compiled the project with no compatibility.  Everything worked
fine.
> > >2) Next, I copied the ocx file that was generated to a 'compatibility'
> > >directory and set the project for version compatibilty.  The
'reference'
> > >file was the OCX file I copied to the 'compatibility' directory.  So
far,
> > so
> > >good...
> > >3) Now, without changing a single line of code, I recompile the
project.

> > >Guess what...

> > >VB thinks that I've broken the compatibility, even though I haven't
changed
> > >a single line of code.  When I click the Declaration button, the old
and
> > new
> > >declarations are exactly the same.

> > >OK, here's another 'view' of this same problem.

> > >On thing that is causing the compatability to 'break' is a property
that
> > has
> > >an argument that's an enum.  I've defined the argument in the source
code
> > as
> > >ppsedits.editLabelLocation.  Now, let's try the same scenario again...

> > >1) Compile project with no compatibility.  Everything's fine.
> > >2) Copy the generated ocx file to the 'compatibility directory' and
change
> > >the project to version compatibility, just like before.
> > >3) Recompile the project without changing any code.
> > >Once again, VB thinks I've broken compatibility. But this time, when I
> > click
> > >the Declarations button, the message shows a different picture.
> > >It says that the property definition was:
> > >   Property Get LabelLocation() as editLabelLocation
> > >and that it has been changed to:
> > >   Property Get LabelLocation() as ppsedits.editLabelLocation

> > >This doesn't make sense...The argument is defined was defined as
> > >"ppsedits.editLabelLocation" when I built the 'reference' OCX and when
I
> > >built the version compatible OCX, so what is telling it that the
argument
> > is
> > >defined as just "editLabelLocation"

> > >I've tried exiting VB between each compile and restarting between each
> > >compile, but the results are the same.

> > >Does anyone have any suggestions?

> > >Ron Gallagher
> > >Atlanta, GA




Wed, 30 Jan 2002 03:00:00 GMT  
 Version compatibility broken, but code didn't change
Which calls to mind the Southern California dentist Dr. Beauchamps who
was apparently not terribly successful until he took to the airwaves
with ads (adverts to you?) pronouncing himself (without
re-orthographizing) Beecham . . .  which reminds me of your compatriot I
once worked with who swore his name was pronounced Si-de'-bot-tom (short
i, short e) and that all who said Sidebottom were just ignorant twits
(thus a real-life corollary of the Bucket-pronounced-Boo-kay clan) . . .
which leads inevitably(?) to Sir Alec Douglas of the Hume Office . . .

What was the question again?

Have a nice day!

Quote:



> > Who's Viola?

> Ref the Shakespeare thingie which starts "If music be the food of love, play
> on..." -- she was definitely in that, although as I recall it was the butler
> who did it.  (Jeeves knows these things.)

> Pip pip!

> Bertie

> PS Talking of violas reminds me of cellos, those genetically-modified violas
> which you wrap your legs round.  Sir Thomas Beecham, having made his fortune
> in sneezing powder, did a bit of conducting in his spare time and once
> endured a spot of rather bad cello playing by a pretty young thing.  He
> stopped her after five minutes and asked her in front of the whole orchestra
> why it was that, with an instrument between her legs capable of giving
> pleasure to thousands, all she could do was scratch it?



Wed, 30 Jan 2002 03:00:00 GMT  
 Version compatibility broken, but code didn't change
Taken from:  Visual Basic Concepts

When Should I Use Version Compatibility?

Visual Basic provides two mechanisms for maintaining backward compatibility while
enhancing software components the Version Compatibility feature and the Implements
feature.

Version Compatibility
Visual Basics Version Compatibility feature is a way of enhancing your components while
maintaining backward compatibility with programs that were compiled using earlier
versions. The Version Compatibility box, located on the Component tab of the Project
Properties dialog box, contains three options:

No Compatibility: Each time you compile the component, new type library information is
generated, including new class IDs and new interface IDs. There is no relation between
versions of a component, and programs compiled to use one version cannot use subsequent
versions.

Project Compatibility: Each time you compile the component the type library identifier is
kept, so that your test projects can maintain their references to the component project.
All class IDs from the previous version are maintained; interface IDs are changed only for
classes that are no longer binary-compatible with their earlier counterparts.
Note   This is a change in Project Compatibility from Visual Basic 5.0, where all class
IDs and interface IDs in the project changed if any one class was no longer
binary-compatible.

Important   For the purpose of releasing compatible versions of a component, Project
Compatibility is the same as No Compatibility.

Binary Compatibility: When you compile the project, if any binary-incompatible changes are
detected you will be presented with a warning dialog. If you choose to accept the warning,
the component will retain the type library identifier and the class IDs. Interface IDs are
changed only for classes that are no longer binary-compatible. This is the same behavior
as Project Compatibility.
If, however, you choose to ignore the warning, the component will also maintain the
interface IDs. This option is only available when the compiler determines that the change
was in the procedure ID or signature of a method.

Caution   You should only choose the Ignore button if you are absolutely sure that the
changes you have made won't break compatibility. If you aren't absolutely sure, take the
safe alternative and choose the Accept button to allow the interface ID's to be changed.

Important   The option to override the compiler's warning represents a change in behavior
from Visual Basic 5.0. It is important that you fully understand the implications of
incompatible changes before proceeding with this option.

Note   When people talk about Version Compatibility, theyre usually referring to Binary
Compatibility.

The appropriate use of these options is described below.

Using the Implements Statement for Compatibility
The Implements statement allows you to add multiple interfaces to class modules, as
described in "Polymorphism, Interfaces, Type Libraries, and GUIDs" and "Providing
Polymorphism by Implementing Interfaces" in "General Principles of Component Design," and
in "Polymorphism" in "Programming with Objects," in the Visual Basic Programmers Guide.

Multiple interfaces allow your systems to evolve over time, without breaking existing
components or requiring massive re-compiles, because a released interface is never
changed. Instead, new functionality is added to a system by creating new interfaces.

This approach is much more in keeping with the design philosophy of the Component Object
Model (COM), on which the ActiveX specification is based.

Note   The Binary Compatibility option of Version Compatibility is useful in conjunction
with Implements and multiple interfaces, to prevent changes to the default interfaces of
your classes.

When to Use Version Compatibility Options
If you decide to use the Version Compatibility feature, you may find the following rules
helpful in determining when to use the different options:

Use No Compatibility to Make a Clean Break
When you begin working on a new version of an existing component, you may decide that the
only way to make necessary enhancements is to break backward compatibility. In this case,
set No Compatibility the first time you compile your project. This guarantees that youll
start with a clean slate of identifiers, and that existing programs wont mistakenly try
to use the incompatible version.

Before compiling an existing project with No Compatibility, you must also:

Change the file name of your component, so that the incompatible version wont over-write
earlier versions on your users hard disks.

Change the Project Name on the General tab of the Project Properties dialog box, so that
the incompatible component will have a different type library name. This ensures that the
objects the component provides will have unique programmatic IDs.
These items are discussed in more detail in "Levels of Binary Version Compatibility."

After compiling once with No Compatibility, switch to Project Compatibility to simplify
your development tasks.

Use Project Compatibility for New Development
Use the Project Compatibility setting when youre developing the first version of a
component. Project Compatibility preserves the type library identifier, so that youre not
continually setting references from your test projects to your component projects.

Using Project Compatibility also makes it easier to switch between the component project
and the compiled component when youre testing.

Project Compatibility is discussed in "Project Compatibility: Avoiding MISSING
References."

Use Binary Compatibility for New Versions of Existing Components
Switch to Binary Compatibility mode when you begin work on the second version of any
component, if you want applications compiled using the earlier version to continue to work
using the new version.

Switching to Binary Compatibility is discussed in the related topic "Providing a Reference
Point for Compatibility."

Dont Mix Binary Compatibility and Multiple Interfaces
If you use multiple interfaces and the Implements statement to provide backward
compatibility, dont use Binary Compatibility to modify the abstract interfaces youve
defined for use with Implements.

If you enhance any of the interfaces in a component, Visual Basic will change their
interface IDs. The technique of evolving component software by adding interfaces depends
on interface invariance. That is, an interface once defined is never changed including
the interface ID.

For More Information   See "Providing Polymorphism by Implementing Interfaces" in "General
Principles of Component Design" for information about component software design using
multiple interfaces. "Maintaining Binary Compatibility" describes the versioning system
Visual Basic uses to prevent compatibility problems.



Thu, 31 Jan 2002 03:00:00 GMT  
 Version compatibility broken, but code didn't change
Visual Basic Concepts

Levels of Binary Version Compatibility

Visual Basic defines three levels of version compatibility for the interfaces you describe
in your class modules.

Version identical means that the interfaces are all the same, so the new version of the
type library is exactly the same as the old one. The code inside methods or Property
procedures may have been changed or enhanced, but this is transparent to client
applications.

Version compatible means that objects and/or methods have been added to the type library,
but no changes were made to existing properties or methods. Both old and new client
applications can use the component.

Version incompatible means that at least one property or method that existed in the old
type library has been changed or removed. Existing client applications that have
references to the component cannot use the new version.
Version-Identical Interfaces
Once your component has been distributed as part of an application, there are several
situations that might cause you to release an update. You might want to optimize the
performance of a method that had turned out to be a bottleneck for users. You might also
need to change the internal implementation of an objects method to reflect changes in the
business rule on which the method was based.

You can change the code in existing Property procedures or methods, and still have a
version-identical interface, as long as you do not change the names or data types of their
parameters, the order of the parameters, the name of the property or method, or the data
type of the return value.

When you create the executable for a version-identical upgrade, you can use the same file
name for the executable. Visual Basic uses the same version number for the type library.

Important   When you release a new version of your component with a version-identical or
version-compatible interface, and retain the same file name for the executable, you should
always use the Make tab of the Project Properties dialog box to increment the file version
number. This ensures that the setup programs for applications that use your component will
replace old versions during setup.

Version-Compatible Interfaces
When you enhance your component by adding new classes, or new properties and methods to
existing classes, you can continue to use the same name for your executable. As long as
you make no changes to existing properties and methods, Visual Basic updates the version
number of the type library but keeps it compatible with the old version number.

Client applications that are built using the new version of your component will compile
with the new version number, and can make use of all the new features. They cannot be used
with earlier versions of your component, however, because type library versions are only
upward-compatible.

As with version-identical releases, remember to increment the file version number of the
executable.

Version-Incompatible Interfaces
Sometimes design decisions made in an earlier version of a component fail to anticipate
future needs. If you want the code in the component to be useful in new development
projects, you have to change the interface.

For example, the CupsPerAnnum parameter of the Coffee method might be implemented as an
Integer in the first version of a component. It may become apparent, after the component
has been in use for some time, that some clients need to pass a larger value than can be
contained in an Integer.

Changing the declaration of a method is only one of several actions that will cause Visual
Basic to make the version number of the type library incompatible, rendering the new
version unusable with client applications compiled with earlier versions. The following
changes will cause a version incompatibility:

Changing the Project Name field on the General tab of the Project Properties dialog box.

Changing the Name property of any class module whose Public property is True (controls),
or whose Instancing property is not Private (class modules).

Deleting a public class module, or setting its Instancing property to Private.

Deleting a public variable, procedure, or Property procedure from a public class module or
control, or changing it to Private or Friend.

Changing the name or data type of a public variable, procedure, or Property procedure in a
public class module or control.

Changing the names, data types, or order of the parameters of a public procedure or
Property procedure in a public class module or control.

Changing the Procedure ID (DispID) or other parameters in the Procedure Attributes dialog
box.

Time to Take Stock
When youve identified a necessary change that will cause your component to be
incompatible with earlier versions, its a good idea to take the time to evaluate the
entire set of interfaces, before plunging ahead and creating an incompatible version of
your component.

Consider Multiple Interfaces
Remember that there are alternatives to using Version Compatibility. Consider enhancing
your component by adding new interfaces with the Implements statement, as described in
"Providing Polymorphism by Implementing Interfaces" in "General Principles of Component
Design."

Multiple interfaces, a key feature of the Component Object Model (COM) on which the
ActiveX specification is based provide a more flexible way to enhance software
components. They allow you to evolve your systems over time, without breaking existing
components.

You dont have to tackle the daunting task factoring your existing class module interfaces
into small interfaces more suitable for use with Implements one of the benefits of using
multiple interfaces is that you can start small, adding new interfaces to the system only
where new functionality is required.

Going Ahead with Incompatibility
If you decide to go ahead with an incompatible version, you can minimize future problems
for the users of your component by concentrating in one release all the changes you can
anticipate that might break compatibility again if they have to be made in later releases.

In planning for an incompatible change, treat the project as a fresh start. Devote as much
care to planning as you would if you were creating a brand new component.

Creating an incompatible version requires three steps: changing the project name, changing
the file name, and compiling with No Compatibility selected.

Changing the Project Name
The key change you must make, when you need to distribute an incompatible version of your
component, is the project name. The project name, which is set on the General tab of the
Project Properties dialog box, is the first part of the programmatic ID of each class your
component provides.

For example, the SmallMechanicals component might provide a Widgets class. A client
application would create a variable to contain a reference to a Widget object as follows:

Private wdgDriver As SmallMechanicals.Widget

The programmatic ID is the combination of project name and class name, and it must be
unique. If you create a new version of this component, you might give it the project name
SmallMechanicals200. Both versions of the Widget object could then be registered in the
same Windows Registry without confusion.

Changing the File Name
You must change the file name of an incompatible component. If you use the old file name
without incrementing the file version number, the incompatible component may not install
on computers where the old file exists. If you increment the file version, the new file
will over-write the old, and applications that used the old version will fail.

Compiling with No Compatibility
Before you compile the incompatible component for the first time, open the Project
Properties dialog box (accessible from the Project menu), select the Component tab, then
select No Compatibility in the Version Compatibility box.

Do not omit this step. Compiling with No Compatibility ensures that the new executable
will not contain any GUIDs (for example, class IDs or interface IDs) that belong to the
previous version. This is necessary for applications that use the original version to
continue working correctly.

Tip   After compiling once with No Compatibility, switch to Project Compatibility to
simplify your development tasks.

Alternatives to Version-Incompatible Changes
If you prefer not to make the change to multiple interfaces, as described above, you can
take a similar approach with classes.

That is, you can avoid changes that cause version incompatibility by adding new objects,
properties, and methods, instead of changing existing ones. Existing applications continue
using the old methods and objects, while developers of new applications can use the new
objects.

For example, you might discover that to take advantage of enhancements to your General
Ledger system, you need to add a SubAccount parameter to several business rules in your
FinanceRules component.

If each rule is implemented as a method of the GL object, you could avoid creating an
incompatible version of the component by adding a new object named GL97. This object would
have the same methods as the GL object, but with a SubAccount parameter where appropriate.

If you need to add new versions of existing methods to an object, you can give the new
methods the same name with a version or sequence number added for example, Execute2.

This approach is not as flexible or efficient as implementing multiple interfaces. You may
end up replicating entire classes, and class interfaces may become large and unwieldy
for example, you might find yourself using a Query class with an Execute method, an
Execute2 method, an Execute3 method, and so on. However, its a step in the right
direction.

For More Information   "Providing a Reference Point for Binary Version Compatibility"
describes when and how to specify a version of your component as a reference point for
version compatibility. See "Version Compatibility" for a ...

read more »



Thu, 31 Jan 2002 03:00:00 GMT  
 Version compatibility broken, but code didn't change
Visual Basic Concepts

Maintaining Binary Compatibility

Visual Basic maintains backward compatibility by preserving class ID and interface ID
information from previous versions of your component, as described in "Polymorphism,
Interfaces, Type Libraries, and GUIDs," in "General Principles of Component Design." This
information is not maintained in the type library, but is stored elsewhere in your
component.

When a client application is compiled using a particular version of your component, the
class ID and interface ID of each object it uses will be compiled in. When the client is
run, the class ID is used to create an instance of the class, and the interface ID is used
to verify that its safe to make the property and method calls that were compiled into the
client.

If you make a new version of your component, using the Binary Compatibility option, the
new version will contain the class IDs and interface IDs the old client needs to create
objects and use their properties and methods, as well as class IDs and interface IDs of
the enhanced versions of the classes.

New client applications compiled using the new version of your component can make use of
the enhancements, because they compile in the new class IDs and interface IDs.

For example, suppose that in version 1.0 of your component, your Widget object has a Spin
method, and that youve compiled a client application that creates a Widget object and
calls the Spin method.

Now suppose you set the Binary Compatibility option and compile a new version of your
component, in which the Widget object also has an Oscillate method. Visual Basic creates a
new interface ID for the enhanced Widget. Because adding a method doesnt break binary
compatibility, Visual Basic also maintains the class ID and interface ID of the old
Widget.

When your previously compiled application uses these old IDs, it gets an enhanced Widget
which is fine, because the new Widget still has the Spin method the old application needs
to call.

Note   Binary Compatibility applies only to the default interface of a class that is,
the Public Sub, Function, and Property procedures you add to the class module. Interfaces
you add using Implements are ignored.

Incompatible Interface Changes
Suppose that instead of adding an Oscillate method, you changed the arguments of the Spin
method. For example, you might add a Direction argument.

If you could compile your component using the old class ID and interface ID for the Widget
class, your old client application would be in trouble. It would be able to create the new
Widget, but when it called the Spin method it would put the wrong arguments on the stack.
At the very least, a program error would occur. Even worse, data could be corrupted.

Preventing Incompatibility
If youve selected the Binary Compatibility option, Visual Basic warns you when youre
about to compile an incompatible version of your component. You can reverse the edits that
would make your component incompatible, or change the file name and Project Name so that
the new version will not replace the old when users run Setup.

If you choose to disregard the warnings and compile an incompatible version of your
component with the same file name and Project Name, Visual Basic may dump some of the
interface IDs from previous versions of your component.

When the incompatible component is installed on a computer that has a client application
compiled using an earlier version, it will overwrite the earlier version. Subsequently,
when the client application attempts to create objects, it will receive error 430, "Class
does not support Automation or does not support expected interface."

This averts more serious and subtle errors that might occur when the application attempts
to invoke the properties and methods of the incompatible interface.

Limited Protection For Late-Bound Client Applications
Late binding is used when variables are declared As Object, because the compiler doesnt
know the class ID of the objects and interfaces that may be assigned to the variable at
run time. Applications that use late binding create instances of your classes using the
CreateObject function and the programmatic ID, as shown here:

Dim obj As Object
Set obj = CreateObject("MyComponent.MyObject")

The CreateObject function looks up the class ID in the Windows Registry, and uses it to
create the object. Thus it will always create the most recent version of the object.

As long as you preserve binary compatibility, late-bound clients will continue to work
successfully with your component.

If you make an incompatible version of your component using the same programmatic IDs for
your objects, late-bound clients can still create the objects, because theyre looking up
the class ID instead of having it compiled in. When they call methods whose arguments have
changed, or methods youve deleted, program failure or data corruption may occur.

For More Information   See "Levels of Binary Version Compatibility" for a description of
the degrees of compatibility employed by Visual Basic. See "Version Compatibility" for a
list of topics related to this feature. See "Polymorphism, Interfaces, Type Libraries, and
GUIDs," in "General Principles of Component Design" for background information and
concepts.



Thu, 31 Jan 2002 03:00:00 GMT  
 Version compatibility broken, but code didn't change
Visual Basic Concepts

Providing a Reference Point for Binary Version Compatibility

To determine the degree of compatibility between two versions of a component, Visual Basic
needs a reference point. You provide this reference point by entering the path to a
previously compiled version of your component in the Version Compatibility box on the tab
of the Project Properties dialog box.

You need to do this whenever you begin work on a new version of a component you have
shipped, put into production, or used as part of an application.

To specify a reference version of the component type library

Open the project.

From the Project menu, choose Project Properties to open the Project Properties dialog
box, and select the Component tab.

Click Binary Compatibility to lock down the class IDs in the project.
Note   As explained in "Project Compatibility: Avoiding MISSING References," the Project
Compatibility setting actually has nothing to do with the Version Compatibility feature.

Update the box at the bottom of the Version Compatibility frame with the full path and
name of the most recent version of your component.
Whenever you make a new executable from your component project, Visual Basic compares the
new interfaces of your classes to the ones described in the file you have specified.
Visual Basic updates the type library version number according to the level of
compatibility between the interfaces.

For More Information   "Using Binary Version Compatibility" describes when and how to use
the feature, problems you may encounter, and messages you may get from Visual Basic. See
"Version Compatibility" for a list of topics related to this feature.



Thu, 31 Jan 2002 03:00:00 GMT  
 Version compatibility broken, but code didn't change
Visual Basic Concepts

Using Binary Version Compatibility

Whenever you begin work on a new version of an existing component, you need to specify a
type library which Visual Basic can use as a reference point for determining
compatibility. In most cases, this will be the type library included in executable (.exe,
.dll, or .ocx file) for the last version of the component you distributed.

Each time you build an interim version of your updated component, Visual Basic extracts
information about the old interfaces from this .exe file and compares it to the new
interfaces of your class modules.

"Providing a Reference Point for Compatibility" explains the procedure for creating a
reference point.

Keeping the Reference Version Separate from Interim Builds
Important   Keep the copy of the .exe file you specify as your reference version separate
from the build copy of the new version.

Each time you make an interim build, Visual Basic adds a new set of interface identifiers
to the executable, one identifier for each class module. If you specify your build copy as
the reference version, it will accumulate a complete set of interface identifiers for
every version-compatible interim build you have ever done. (Interface identifiers do not
change for version-identical builds.)

In addition to the six{*filter*} bytes taken up by each interface identifier, having unused
interface identifiers in your executable only your test applications ever use the
interim versions can slow down cross-process access to your component in some
situations, and the Windows Registry of any computer your component is installed on will
be cluttered with unused interface identifiers.

If your reference version is a copy of your last released executable, all your interim
builds will have the same interface version number, and your final build will have only
the interface identifiers it needs: all the sets from the reference version (to provide
backward compatibility) plus the set of interface identifiers for all the classes in your
new release.

Note   When youre developing the first version of a component, using Project
Compatibility instead of Binary Compatibility, exactly the opposite is true: The reference
version should be your interim build. This does not bulk up the type library, because
Project Compatibility never saves the interface identifiers.

Avoiding Version Trees
Because Visual Basic produces the version number for the new type library by incrementing
the type library version number it finds in the reference version, the released versions
of your component form a chain, each link derived from its predecessor. As mentioned
earlier, each new release contains all the interface identifiers for preceding versions,
so that a client application compiled with any previous version will still work with the
latest.

Whats a Version Tree?
Version trees arise when your components version history acquires branches that is,
when you produce two physically distinct components based on the same source code. Its
important to keep the version history of your component straight, and avoid such
branching.

Figure 7.4 shows some of the problems that can be caused by version trees. (The version
numbers are for illustrative purposes only, and are not intended to represent actual type
library version numbers.)

The long branch at the right shows four successive versions of a component executable, and
a new executable that has been created by adding to the source code for the executable
whose type library version is 1.3.

The correct continuation of this version history is for the latest executable to be
compiled with the version 1.3 executable as its reference version. The new type library
version number is 1.4. The .exe file maintains compatibility with client applications
compiled using any of its predecessors.

Because its at the end of a chain of compatible versions, the new executable could also
be compiled with the version 1.0 executable as its reference version. In this case, its
type library version number will be 1.1. This could cause problems for clients compiled to
take advantage of features of the new version. If theyre placed on a computer with the
earlier version 1.1 executable, the new features will not be available, and the
applications will fail.

A different problem arises when the new component is installed on computers that have
client applications compiled with type library version numbers 1.1, 1.2, and 1.3. Standard
practice is to increase the file version number of each new executable file, to ensure
that Setup will replace earlier versions of the executable. (Remember that file version
numbers are independent of type library version numbers.)

Thus the new executable, containing interface identifiers for type library versions 1.0
and 1.1, will replace older executables that contained interface identifiers for type
library versions 1.0 through 1.3.

If the computer already has client applications compiled with type library versions 1.2
and 1.3, those clients will be unable to use the new version of the component.

Divergent Versions
The left side of the tree shows divergent versions. This can arise when the source code
for an early version of your component is taken as the basis of a new component, and
classes are added that do not exist in your main version history.

If the executable for your component is used as the reference version for the divergent
version, the type library version numbers of the divergent version and its successors will
overlap the version numbers of your components. The results for client applications will
be disastrous.

Tip   You can easily avoid the creation of version trees by always setting aside a copy of
the previous version of your components executable file (.exe, .dll, or .ocx) as the
reference version for the next release, as described earlier in this topic.

Tip   If you decide to use the source code of an earlier version of your component as the
basis of a new component, give the new component a different project name and executable
name.

Version Trees with Project Compatibility
Version trees can also arise when youre using Project Compatibility, the difference being
that its the major version number of the type library that changes (instead of the minor
version number, as shown in Figure 7.4). The consequences to client applications can be
equally disastrous.

As with Binary Compatibility, the best way to avoid this is not to split your source tree.
If you take a copy of your source code at a particular stage of the project as the basis
for another component, use a different project name and executable name for this new
project.

Version Compatibility Messages
For performance reasons, Visual Basic does not fully compare interfaces as you edit. When
you run your component project, Visual Basic will always display a compatibility warning
if the new version is incompatible with the old. (Version-identical and version-compatible
interfaces will compile without compatibility warnings.)

Note   Version compatibility is judged on a project-wide basis. A change in the
declaration of just one method in one class module causes the entire project to be marked
as incompatible with the previous version. See "Levels of Version Compatibility," earlier
in this chapter, for a listing of changes that will cause a version incompatibility.

Version Incompatibility Warnings
Suppose you add a new argument to the Spin method of the Widget object. When you run the
project, youll get a warning that binary compatibility has been broken. You can examine
the old declaration by clicking the Declaration button on this message. If you made the
change accidentally, you can click Edit to bring up the code and fix it.

If you choose to accept the warning, the component will retain the type library identifier
and the class IDs. Interface IDs are changed only for classes that are no longer binary
compatible. This is the same behavior as Project Compatibility.

If, however, you choose to ignore the warning, the component will also maintain the
interface IDs. This option is only available when the compiler determines that there was a
change in the signature of a method.

Caution   You should only choose to ignore the warning if you are absolutely sure that the
changes you have made won't break compatibility. If you aren't absolutely sure, take the
safe alternative.

Important   The option to override the compiler's warning represents a change in behavior
from Visual Basic 5.0. It is important that you fully understand the implications of
incompatible changes before proceeding with this option.

Incompatible EXE File
If you have not changed the project name, when you use the Make EXE File command, you will
get a warning that your application is incompatible with the .exe file you specified as
your reference version, as shown in Figure 7.5.

Clicking Continue at this point creates an executable file that could cause existing
client applications to fail. In order for existing clients to continue working, you must
take the following steps when you create an incompatible version of a component:

Change the file name.

Change the project name.

Compile with Version Compatibility set to No Compatibility.
These steps are discussed in detail in "Levels of Binary Version Compatibility."

For More Information   See "Version Compatibility" for a list of topics related to this
feature.



Thu, 31 Jan 2002 03:00:00 GMT  
 
 [ 11 post ] 

 Relevant Pages 

1. activeX doc didn't download latest version

2. Link Manager change didn't take, exactly

3. SQL code didn't work on VB.

4. Version Compatibility with a ActiveX Code Component DLL.

5. Compatibility between Version 7 and Version 2

6. I'm disapointed with VB.NET backward compatibility changes

7. Preserve compatibility doesn't preserve compatibility

8. Microsoft's Fix: This action will reset the current code in break mode

9. Break Word with section breaks and pagesetup changes

10. Running a file: Shell didn't work... AppActivate didn't work...

11. MS Broke Compatibility on FileSystemObject!!!

12. Public WithEvents X as OCX - breaks Binary Compatibility

 

 
Powered by phpBB® Forum Software