Weird – I did a comparison of the registry values in the
self-registration and those in the merge module but they seem to be very
similar. I’m not sure what’s going on there – sorry. The only thing I can
think of would be to export your HKCR hive in the broken state, then run the
self-reg, then export it again to see what changed. That might provide some
clues. Derek From: Dave Williamson
[mailto:[EMAIL PROTECTED] The log file was too big for email accounts so is there any
particular part you want to see? Here is the section that copies the mscomm32.ocx: MSI (s) (B0:F4): Executing op:
SetTargetFolder(Folder=C:\WINDOWS\System32\) Keep in mind that in this particular case the file is getting
installed but it isn't getting registered completely because a manual
registration after the install corrects any missing or invalid registration. Dave Williamson From:
Dave Williamson [mailto:[EMAIL PROTECTED] Yes the file gets installed. I was using a fresh install of
windows XP in virtual pc so the file does not exist at all to begin with.
And yes I have a verbose log (it is attached). Dave Williamson From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Derek Cicerone When you use the merge module, do you see the mscomm32.ocx file
get installed? Do you have a verbose installation log? Those are
really useful for tracking down issues. Derek From: Dave Williamson
[mailto:[EMAIL PROTECTED] mscomm32.msm Dave Williamson From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Derek
Cicerone Which msm is causing problems (what is its exact name)? Thanks, Derek From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dave
Williamson The versions of the file are the same. Actually it was the
same physical file just to be sure (I used the extracted file from the msm). OK. So now I'm back to using the Tallow generated code
(because it works) but I'm at a cross roads. Rob has said that the
component's GUID is super important when trying to keep up with shared files
installed on a machine ... in this case the shared file is a vb 6 ocx
control. And the Tallow code does not match the Dark code of the msm so
technically I should not use the msm component GUID with the tallow code
because they are different ... yet what is being accomplished is installing a
shared file, mscomm32.ocx, on the end user's system32 dir, registered,
and reference counted ... and that does need to be coordinated with other folks
installing that same file. If I use the same GUID then the mscomm32.ocx should not be
uninstalled prematurely if my app is uninstalled and other apps that have
installed the ocx are still installed. If I use a different GUID then the mscomm32.ocx could be
uninstalled if the basic reference counting is out of whack. What a [EMAIL PROTECTED] if you do and [EMAIL PROTECTED] if you don't situation. Dave Williamson From: Bob Arnson [mailto:[EMAIL PROTECTED] Dave Williamson wrote: The Dark output showed some interesting constructs that were not
directly in the tallow code but seemed like they were the same thing but
represented in a different manner. Yes, tallow doesn't know how to
use the strongly-typed COM-registration elements. (Heat, in WiX v3, does.) So
it just turns them into registry values. -- sig://boB http://bobs.org |
------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users