Generally you should endeavour not to break binary compatibility!
As I recall - the product on which I use the feature requires binary
compatibility, so a break of compatibility is not permitted - Visual Basic
prompts to tell you that you have done so and would you like to continue? If
you accept the break, it switches into project compatibility mode.
In binary compatibility mode, it preserves class, interface and type library
GUIDs. If you make a compatible change to an interface, it increments the
type library's minor version number by 1, generates a new GUID for that
interface, and typedefs the old interface (plus corresponding IID) to the
new one. The new interface is laid out with the new methods at the end,
regardless of where you put them in the class declaration. (You can see this
in the OLE/COM Object Viewer that comes with VS 6.0). When registering, it
registers the old interface GUID with a Forward registry key pointing to the
new GUID (this feature doesn't seem to be documented anywhere!)
In project compatibility mode, VB generates new GUIDs for modified
interfaces, but preserves class and type library GUIDs. It lays out the
interface in the class declaration order. It bumps the type library's major
version by one. It does not forward the interface's old GUID to the new one
(as it hasn't guaranteed binary compatibility by building the common methods
in the same order).
If you don't use any compatibility mode, VB generates everything from
scratch every time. This is the 'chaos' mode which litters your registry
every time you build the component. I would at least set project
compatibility between builds which don't change the component's interfaces.
If you use these modes it is important to ensure that you know when you've
made a change to the interface of the component, so you can update the
reference copy of the DLL.
I would recommend using one of the compatibility modes so that your
registration settings aren't changing between releases. Strictly, I think a
changed registry key would be a different resource, meaning you've changed
the make-up of the MSI component. The MSI component rules would suggest you
should change the component's GUID, but then that has the knock-on effect
that you should change the name or install path of the file resources too,
otherwise you can get multiple components owning the same resources. Windows
Installer tracks component references, not resources - uninstalling one of
the components can lead to the resources being prematurely removed.
This would perhaps suggest that your COM registry keys should actually be in
different MSI components from the files that implement those COM classes, so
that the keys can vary separately from the files. You then run into
difficulty with minor versus major upgrades, since minor upgrades aren't
allowed to modify the makeup of a feature - you can only add new child
features. This would tend to suggest you can only modify your COM interfaces
in a major upgrade!
--
Mike Dimmick
_____
From: David Howell [mailto:[EMAIL PROTECTED]
Sent: 01 August 2007 00:07
To: 'Mike Dimmick'; wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue
Thanks Mike.
And I agree regarding your points. Unfortunately Binary Compatibility hasn't
been set with these DLLs (and isn't really required for this project).
Should I set Binary Compatibility anyway?
If this is the cause, then what happens a change breaks Binary Compatibility
(it does happen)?
I've attached some of the output from heat.
Cheers,
David.
_____
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Mike Dimmick
Sent: Wednesday, 1 August 2007 5:28 AM
To: 'David Howell'; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue
Generally you should consider Heat's output as a starting point, not a final
product. You need to understand what's been generated.
Heat captures the raw registry output from running the DllRegisterServer
output; it then transforms what's been harvested into the higher-level
values. Anything left as RegistryValue elements was written by the DLL but
didn't match the TypeLib information. Could you post what's shown?
If you're not already doing so, I would recommend using VB's Binary
Compatibility setting to ensure that the GUIDs are stable as far as
possible.
--
Mike Dimmick
_____
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of David Howell
Sent: 31 July 2007 01:03
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue
Hello,
I've been using WiX 3.0.2925 to install some of our COM DLLs (created by
Visual Basic 6.0 SP6).
With WiX 3.0.2925 when I use:
"heat file MyLibrary.dll -out MyLibrary.wxs"
I will often get a mixture of <TypeLib> entries (which is what I want) and a
mixture of <RegistryValue> entries (which seem to be instead of other
<TypeLib> entries).
This makes it very difficult to edit a wxs file when interfaces have changed
etc.
Is there any way to force heat to produce only the <TypeLib> entries?
Cheers,
David.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
