Windows registry updates under Project compatibility 2

[catalina36]

I'm a bit confused about the Project compatibility option available to ActiveX components. One book I have says that under Project compatibility the Windows registry is updated each time the ActiveX server/component is compiled, thus requiring you to recompile all the clients too. However, another book says the Widows registry is only modified if a component is no longer backward-compatible. Only in that event, will you need to recompile the clients. Can anybody shed some light this discrepancy?

It might be useful to me and others if somebody could compare and contrast Project Compatibility and Binary Compatibility in plain English.

Thanks,
Jon

 

[Ruairi]

heres the basics:

In the application that uses the .dll or control:

Early Bound:
Dim ThisObject As NameOfYourObject
OR
select the object from the refrences menu

With early binding the CLSID's and InterfaceID's of the object and its methods are compiled into the executable. Calls to this object will be made using the ID's. The Object will not be queried to see if the method being called exists. If the call does not match the declaration (correct # of arguments, etc..) an error occurs. If you are going to use early binding in your client apps you need to be compiling your components with binary compatibility to ensure that the old interfaces (clsid and iid's) will still be supported when you add functionality and recompile your .dll or control. The only problem with binary compatibility is that you cannot change the interface to an existing method (the # or type of arguments it takes, etc..
If you do the compatibility is broken and you will have to recompile all clients against the new .dll or control.

Late Bound:

Dim ThisObject As Object

Set ThisObject = CreateObject("SomeObject.SomeClass&quot

With late binding the IUnknown interface (a standard interface for all COM objects, automatically created by VB)
is queried to find a method by name when it is called. Changes to the interface do not require the clients to be recompiled.

so, the basic differences:
binary: can use early binding with this. If you recompile and don't get an error message from VB saying that your changes will break compatibility then it is safe to distribute the new component to client app's built against an earlier version of the .dll or control.

project: This doesnt preserve the ID's, therefore if a client app is early bound to the dll or control it will be compiled with the old ID's and will need to be recompiled whenever the control is. This kinda defeats the purpose of dll's. I always use binary compatibility.

I hope this was clear and helpful. If not post again and i will try to help.

Ruairi

Could your manufacturing facility benefit from real time process monitoring? Would you like your employees to be able to see up to the minute goal and actual production?
For innovative, low cost solutions check out my website.

http://www.plccontroltechnologies.com

 

[catalina36]

In a nutshell you're saying:

-- With late binding the ID's are irrelevant. Therefore, binary and project compatibility are for all intents and purposes equivalent and irrelevant.

-- With early binding the ID's are used to make calls to the object's methods. Since recompiling the component with the version compatibility set to project will always cause the ID's to change (regardless of extent of the change), the client app will also always have to be recompiled so that it incorporates the new ID's. On the other hand binary compatibility is more forgiving in that it retains the ID's as long as you have not changed the interface.

Please let me know if I'm off base here.

Thanks for your help,
Jon