Re: [WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue
Hi Guys, I've done some further testing. I upgraded to 3.0.3127 and tried that. I created a brand new ActiveX DLL in VB6, compiled it once and ran heat. I got interesting results: On Vista, Wix 3.0.3127, DLL compiled in Vista: I get no TypeLib entries. I get a lot of Class, Interface, RegistryValue entries, mostly children of the Component element. On Windows 2000, Wix 3.0.3127 (VirtualPC), same DLL file copied to it (DLL compiled in Vista): I get the correct TypeLib entry under File. I get TypeLib entries for the VB6RM under Component (I discard these anyway) I get almost no RegistryValue entries (not related to the DLL anyway, so discarded)! So, it looks as though something has changed between 3.0.2925 and 3.0.3127. It also seems Vista does something to hinder heat's interrogation/harvest. Note that I run heat as Administrator on Vista. I had a look at the heat harvesting extension code, only out of curiosity. Would you recommend to not run heat in Vista for ActiveX/COM DLLs? Cheers, David. _ From: Mike Dimmick [mailto:[EMAIL PROTECTED] 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
Re: [WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue
Thanks Mike. I appreciate the detailed explanations. It confirms what I thought was happening, but I was never quite sure. With DLLs, I never have no compatibility (chaos mode!). So no probs there. The thing is, with what you've said below regarding DLLs and compatibility should not affect the way heat harvests the TypeLibs? Also, from my previous post with the Vista/Windows 2000 on a new DLL compiled once, produced different results. I am now resorting to running heat on a Win2k Pro VPC to get my TypeLibs, Classes and Interfaces as this seems correct (although the heat output sometimes corrupts, and misses some required attributes). Regardless of compat mode (Binary or Project), I will need to run heat after a new compile, for example if I were to add new Classes to the project and if auto-increment is on for versioning. Cheers, David. _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Dimmick Sent: Friday, 3 August 2007 7:38 AM To: 'David Howell'; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue 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
Re: [WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue
Yeah, I agree that heat will produce a lot of RegistryValue
elements that are not related to the DLL being looked at (like you said,
usually VB Runtime related). Which is fine since heat shouldn't be used
for automated builds etc, and the output should be hand-tooled/cleaned
up. But I would expect it to create the TypeLibs for the DLL.
I am using heat in an automated fashion... I have written a MSBuild task
that invokes heat and then opens the XML file and tidies up the XML
structure. However, your comments are making me go back and check the
output more carefully.
What also struck me as odd was that heat is generating Class and
Interface elements as Component elements as well as File elements, e.g.:
Component
Class
ProgID /
/Class
Class
ProgID /
/Class
File
Class
ProgID /
/Class
/File
Interface /
Interface /
Interface /
...
RegistryValue /
RegistryValue /
RegistryValue /
...
/Component
And these Class elements were directly related to the DLL being
looked at. In the above instance, there was no TypeLib element at all...
Heat will generate TypeLibs for some of the other DLLs.
Any suggestions?
No suggestions really. I've looked at the output for some of my DLLs and
OCXs and there are some entries outside the File element that are
related, and they are all of this kind of form:
RegistryValue Root=HKCR
Key=CLSID\{5406F822-32BA-4AC7-B355-AD5E8DC28DEC}\Control Value=
Type=string Action=write /
RegistryValue Root=HKCR
Key=CLSID\{5406F822-32BA-4AC7-B355-AD5E8DC28DEC}\MiscStatus\1
Value=131473 Type=string Action=write /
RegistryValue Root=HKCR
Key=CLSID\{5406F822-32BA-4AC7-B355-AD5E8DC28DEC}\MiscStatus Value=0
Type=string Action=write /
RegistryValue Root=HKCR
Key=CLSID\{5406F822-32BA-4AC7-B355-AD5E8DC28DEC}\ToolboxBitmap32
Value=[!controls.ocx], 3 Type=string Action=write /
or Interface entries like this that seem to just forward to interfaces
defined inside the File element:
Interface Id={296923CA-99E8-40B8-87E3-0BEF5FF0D67C}
Name=dbUtils ProxyStubClassId={00020424---C000-0046}
ProxyStubClassId32={00020424---C000-0046} /
RegistryValue Root=HKCR
Key=Interface\{296923CA-99E8-40B8-87E3-0BEF5FF0D67C}\Forward
Value={107C147F-8A37-4E29-813D-5958F10B97CF} Type=string
Action=write /
I don't see any extra Class elements. I need to go away and test the
installation thoroughly to see if I'm throwing away too much.
Cheers,
John
-
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
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
Re: [WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue
Hey mike, What would you consider the future of heat? I don't see heat as a starting point at all, I see it as a beginning of an automated build extractor/creator. I know its not there yet, but its really not that far off. I need create installers (out of TFS) daily in a repeatable and manageable way. Right now I'm using wise which works but is limited, I'm looking towards WIX because I see it's potential to solve many of the issues I have right now with an automated build process. The truth be told in this day and age, I can't believe solutions are not available out there to do this, it sounds simple enough. This is the holy grail of installer tech, if WIX cracks this nut it will quickly make everything else obsolete. Jimbo From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Dimmick Sent: Tuesday, July 31, 2007 12:58 PM 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
Re: [WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue
Jimbo, In addition to what Mike was saying (regarding understanding what's been generated), the WiX source files should be created during the development phase of a project (early). The wxs files will be developed as the project is developed, I would consider it one of the most important parts of a project (since if the installer isn't working correctly, the rest doesn't matter). After that, the wxs files should remain relatively static. Automated builds are necessary, however automated builds that change the WiX files is dangerous (in my opinion, I guess it depends on the situation too). InstallShield does things like COM Extract at Build, which is useful but I find the cleanliness of WiX more suitable for smaller projects. I hope this helps, David. _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Collins, James Sent: Wednesday, 1 August 2007 5:58 AM To: Mike Dimmick; David Howell; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue Hey mike, What would you consider the future of heat? I don't see heat as a starting point at all, I see it as a beginning of an automated build extractor/creator. I know its not there yet, but its really not that far off. I need create installers (out of TFS) daily in a repeatable and manageable way. Right now I'm using wise which works but is limited, I'm looking towards WIX because I see it's potential to solve many of the issues I have right now with an automated build process. The truth be told in this day and age, I can't believe solutions are not available out there to do this, it sounds simple enough. This is the holy grail of installer tech, if WIX cracks this nut it will quickly make everything else obsolete. Jimbo _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Dimmick Sent: Tuesday, July 31, 2007 12:58 PM 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
Re: [WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue
Thanks Dave, I understand what your saying, but I'm managing installers with 16,000+ files. That's not something I'm going to do manually and files can be added and deleted on a daily basis. Heat looks good from my prospective however its missing a critical piece, and that's (what believe what you call) a component catalog. Is there any plans on the horizon for such a feature in heat? Thanks again Jimbo From: David Howell [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 31, 2007 4:17 PM To: Collins, James; 'Mike Dimmick'; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue Jimbo, In addition to what Mike was saying (regarding understanding what's been generated), the WiX source files should be created during the development phase of a project (early). The wxs files will be developed as the project is developed, I would consider it one of the most important parts of a project (since if the installer isn't working correctly, the rest doesn't matter). After that, the wxs files should remain relatively static. Automated builds are necessary, however automated builds that change the WiX files is dangerous (in my opinion, I guess it depends on the situation too). InstallShield does things like COM Extract at Build, which is useful but I find the cleanliness of WiX more suitable for smaller projects. I hope this helps, David. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Collins, James Sent: Wednesday, 1 August 2007 5:58 AM To: Mike Dimmick; David Howell; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue Hey mike, What would you consider the future of heat? I don't see heat as a starting point at all, I see it as a beginning of an automated build extractor/creator. I know its not there yet, but its really not that far off. I need create installers (out of TFS) daily in a repeatable and manageable way. Right now I'm using wise which works but is limited, I'm looking towards WIX because I see it's potential to solve many of the issues I have right now with an automated build process. The truth be told in this day and age, I can't believe solutions are not available out there to do this, it sounds simple enough. This is the holy grail of installer tech, if WIX cracks this nut it will quickly make everything else obsolete. Jimbo From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Dimmick Sent: Tuesday, July 31, 2007 12:58 PM 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
Re: [WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue
Jimbo, I see your predicament! Again, InstallShield has the ability to add files via wildcards etc (not that I'm promoting InstallShield, for the cost its pretty clunky), can't remember the exact term. A question I would ask is that if you have 16,000+ files that are being changed, added, deleted on a daily basis, with daily builds, is msi technology your best option? Without know the circumstances (e.g. is it an internal project only) perhaps there is an easier way? Sorry, getting off-topic. As for the future of heat, I have no idea. I'm just a user ;-) Good Luck! Dave. _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Collins, James Sent: Wednesday, 1 August 2007 9:19 AM To: David Howell; Mike Dimmick; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue Thanks Dave, I understand what your saying, but I'm managing installers with 16,000+ files. That's not something I'm going to do manually and files can be added and deleted on a daily basis. Heat looks good from my prospective however its missing a critical piece, and that's (what believe what you call) a component catalog. Is there any plans on the horizon for such a feature in heat? Thanks again Jimbo _ From: David Howell [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 31, 2007 4:17 PM To: Collins, James; 'Mike Dimmick'; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue Jimbo, In addition to what Mike was saying (regarding understanding what's been generated), the WiX source files should be created during the development phase of a project (early). The wxs files will be developed as the project is developed, I would consider it one of the most important parts of a project (since if the installer isn't working correctly, the rest doesn't matter). After that, the wxs files should remain relatively static. Automated builds are necessary, however automated builds that change the WiX files is dangerous (in my opinion, I guess it depends on the situation too). InstallShield does things like COM Extract at Build, which is useful but I find the cleanliness of WiX more suitable for smaller projects. I hope this helps, David. _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Collins, James Sent: Wednesday, 1 August 2007 5:58 AM To: Mike Dimmick; David Howell; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue Hey mike, What would you consider the future of heat? I don't see heat as a starting point at all, I see it as a beginning of an automated build extractor/creator. I know its not there yet, but its really not that far off. I need create installers (out of TFS) daily in a repeatable and manageable way. Right now I'm using wise which works but is limited, I'm looking towards WIX because I see it's potential to solve many of the issues I have right now with an automated build process. The truth be told in this day and age, I can't believe solutions are not available out there to do this, it sounds simple enough. This is the holy grail of installer tech, if WIX cracks this nut it will quickly make everything else obsolete. Jimbo _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Dimmick Sent: Tuesday, July 31, 2007 12:58 PM 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
[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
