Thanks John.
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.
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?
Cheers,
David.
_____
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of John Hall
Sent: Tuesday, 31 July 2007 11:48 PM
To: David Howell; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue
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?
David,
Not that I know of.
I strip out everything apart from the TypeLib element inside the File
element for my DLL.
Most of the rest outside the File element seems to be RegistryValue elements
and the other TypeLibs to do with the VB runtime. The VB runtime gets
installed elsewhere and it seems to me that installing those registry
entries violates the component rules. More worringly they contain hard-coded
strings such as "C:\WINDOWS\system32\MSVBVM60.DLL", which is clearly wrong.
This approach seems to work for me, but I would be interested to know
whether it works for other people.
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
