Project, Binary or No Compatability?

[agmorgan]

I have an ActiveX control that I use in a web page via the <OBJECT> tags.
I read an ini file which has the relevent ClassID and version number in it then dynamically create the page.
This way, I only need to change the details for my ActiveX components in one place, the ini file.

Recently I have been making lots of changes, making CAB files for each version that needs testing.

If I use Binary compatability the ClassID stays the same and only the version number changes.
If I use No compatability both change.
I dont know the effect of Project compatability.

Each of these has different effects on how the control is updated on the client PC.

Ideally I would want 1 file in the Downloaded Program Files directory that changed (uninstalled, reinstalled)
every time that I updated my control.

Unfortunately I am having difficulties.
Sometimes if I dont remove the earlier version manually, the new version doesnt get updated
and the old version stays in use.
Othertimes there seems to be some sort of conflict and only a blank square is displayed.

What is the best practice for this?
Which type of compatability should I use?
How do I do it so that several copies (different versions) of my files arent on the client PC at any one time
and the newest version automatically installs and runs?

[freewilly]

Hi agmorgan

Binary Compatibility preserves the external signature of the control. This is the public interface. This is what any app using you control is looking for and know how to use. This means that any program that uses the control can continue to use it after you have made internal changes. You change anything in the control that is not public. You can even change how public functions work so long as you don't change their name, input parameters and return values.

However, this also means that binaray compatibilty can not be maintained if any public part of the control changes, for example, a new public function is added or the type of a public function parameter is changed. If you have make such changes you have to recompile the program that uses the control with the recompiled control.

No Compatabilty creates a control with an entirly new external signature. This means that any app using the control will not be able to find it. It will be looking for the signature that it was compiled with and won't be able to find it.

I'm not sure how to use project compatibilty. I use binary compatability exclusivly unless I'm forced to use no compatabilty due to a change in the external signature. Then I create the new control, addit back into the main app, and then switch back to Binary compatabilty.

In practice I create the control and then change its name to <ControlName>Master. I then set the binary compatabilty to this master control. This seems to save problems with setting compatabilty to a control I'm replacing.

Good Luck

FW

[techgnome]

For the most part, I agree with freewilly, but I think his assertion of binary compatibility and changing the public interface is not accurate.

Setting Binary Compatibility does a couple of things. First it ensures that the Prog ID (GUIID) doesn't change. No compatibility will cause this to change on every compile, while Project Compatibility will only ensure that within the project, things will be OK.

The second thing it does is that if you EXTEND the interface - add a new method, property or even adding a control - that anything referencing the object will continue to be able to do so. It also helps to warn you if you change the interface beyond the current signatire, like say you change the return type of a function from an integer to a string.

TG