Re: [WiX-users] Heat 3.0.4923 vs 3.0.5217 vb6 dll output
Great Work Brian!!
I just incorporated WiX 3.0.5308 into our build and harvested all 128 VB6
COM DLLs. Your fix works like a charm:
[exec] heat.exe : warning HEAT5156 : Ignoring the registry key
'Interface\{F3DB7AC0-A581-48C6-A973-8860578A77E1}\ProxyStubClsid/', it has
already been added to the component 'EstimationEngine.dll'. The registry key
value '{00020424---C000-0046}' will not be harvested.
Also, here are some statistics for Heat when I harvested my 128 files:
Version 3.0.4923: WiX file produced is 25540 lines, 4.7 MB
Version 3.0.5308: WiX file produced is 3794 lines, 601 KB
That's a great performance improvement!
Thanks again for all the help. Heat is definitely a rock solid tool.
Roy
Roy Abou Assaly wrote:
I have filed the following bug:
https://sourceforge.net/tracker/?func=detailatid=642714aid=2783049group_id=105970
and included test cases and the binary where you can reproduce how light
is broken on the COM VB6 WiX output from Heat from version 3.0.4923 to
3.0.5224.
Please let me know if I can be of any help at all.
Roy Abou Assaly wrote:
Sorry. I'll explain the situation. I sort of cried wolf in the
beginning since I used an XSLT to massage my XML after Heat produced the
XML. At that point Candle wouldn't compile. That was my mistake as
confirmed by Brian and yourself. I fixed that error. When it came to
running Light to produce my merge module, these were my findings:
In 3.0.4923 (my current build setup)
1. Run Heat : OK ($heat dir d:\foo -svb6 -sfrag -suid -gg -our
PrismShell.wxs)
2. Run Candle: ERROR:
[exec] D:\Builds\PRISM XP\Build
11.51.\Bin\PrismShell.wxs(180) : error CNDL0010 : The Class/@Server
attribute was not found; it is required.
Fixed by running a custom XSLT that added the Class/@Server attribute.
3. Run Light: OK (PrismShell.msm produced and later incorporated into an
MSI).
In 3.0.5217 and in 3.0.5224 (I'm trying to upgrade to the latest version
of WiX)
1. Run Heat: OK ($heat dir d:\foo -svb6 -sfrag -suid -gg -our
PrismShell.wxs)
2. Run Candle: OK
3. Run Light: Error:
[exec] Microsoft (R) Windows Installer Xml Linker version 3.0.5217.0
[exec] Copyright (C) Microsoft Corporation. All rights reserved.
[exec]
[exec] Updating file information.
[exec] Creating cabinet files.
[exec] Creating cabinet
'C:\Users\assalr\AppData\Local\Temp\fkjhmoud\#MergeModule.CABinet'.
[exec] Generating database.
[exec] D:\Builds\PRISM XP\Build 11.51.\Bin\PrismShell.wxs(19) :
error LGHT0130 : The primary key
'reg0387C011F3F8A22BDFC14B72466D9C9A.C7AC8538_65ED_4C2B_AE16_6291871D0918'
is duplicated in table 'Registry'. Please remove one of the entries or
rename a part of the primary key to avoid the collision.
The WiX XML that is generating the above error looks like the same that
you had generated before:
Component Id=DisplayFridayListUI.dll
Guid={821C19F9-E65C-48D5-BF11-07F593D7839B}
File Id=DisplayFridayListUI.dll KeyPath=yes
Source=SourceDir\DisplayFridayListUI.dll
TypeLib Id={3515D627-3FA0-490F-9330-02A73023E0C0}
Description=DisplayFridayListUI HelpDirectory=PRISMMsi Language=0
MajorVersion=1 MinorVersion=0
Class Id={9AF8DE3E-3FFB-4F1C-AA59-3DBAB1725BB9}
Context=InprocServer32
Description=DisplayFridayListUI.CDisplayFridayList
ThreadingModel=apartment Version=1.0 Programmable=yes
ProgId
Id=DisplayFridayListUI.CDisplayFridayList
Description=DisplayFridayListUI.CDisplayFridayList /
/Class
Interface Id={2D3FD2B6-AF78-4DFD-A5C9-7CE97BC4A594}
Name=CDisplayFridayList
ProxyStubClassId={00020424---C000-0046}
ProxyStubClassId32={00020424---C000-0046} /
/TypeLib
/File
RegistryValue Root=HKCR
Key=CLSID\{9AF8DE3E-3FFB-4F1C-AA59-3DBAB1725BB9}\Implemented
Categories\{40FC6ED5-2438-11CF-A3DB-080036F12502} Value= Type=string
Action=write /
RegistryValue Root=HKCR
Key=Interface\{2D3FD2B6-AF78-4DFD-A5C9-7CE97BC4A594}\ProxyStubClsid
Value={00020424---C000-0046} Type=string
Action=write /
RegistryValue Root=HKCR
Key=Interface\{2D3FD2B6-AF78-4DFD-A5C9-7CE97BC4A594}\ProxyStubClsid32
Value={00020424---C000-0046} Type=string
Action=write /
RegistryValue Root=HKCR
Key=Interface\{2D3FD2B6-AF78-4DFD-A5C9-7CE97BC4A594}
Value=_CDisplayFridayList Type=string Action=write /
/Component
Yes, it compiles, but it's not linking with Light.
This is where I am right now. Please note that the XML that Heat
produces in 3.0.4923 is much, much bigger than in 3.0.5217 and 3.0.5224.
Let me know if you need me to send you a binary (DisplayFridayListUI.dll)
that can reproduce this.
If I can't resolve this issue, I'm afraid I will have to stick with
3.0.4923 as 3.0.5224 has a break that I can't work around
Re: [WiX-users] Heat 3.0.4923 vs 3.0.5217 vb6 dll output
I have filed the following bug:
https://sourceforge.net/tracker/?func=detailatid=642714aid=2783049group_id=105970
and included test cases and the binary where you can reproduce how light is
broken on the COM VB6 WiX output from Heat from version 3.0.4923 to
3.0.5224.
Please let me know if I can be of any help at all.
Roy Abou Assaly wrote:
Sorry. I'll explain the situation. I sort of cried wolf in the
beginning since I used an XSLT to massage my XML after Heat produced the
XML. At that point Candle wouldn't compile. That was my mistake as
confirmed by Brian and yourself. I fixed that error. When it came to
running Light to produce my merge module, these were my findings:
In 3.0.4923 (my current build setup)
1. Run Heat : OK ($heat dir d:\foo -svb6 -sfrag -suid -gg -our
PrismShell.wxs)
2. Run Candle: ERROR:
[exec] D:\Builds\PRISM XP\Build 11.51.\Bin\PrismShell.wxs(180)
: error CNDL0010 : The Class/@Server attribute was not found; it is
required.
Fixed by running a custom XSLT that added the Class/@Server attribute.
3. Run Light: OK (PrismShell.msm produced and later incorporated into an
MSI).
In 3.0.5217 and in 3.0.5224 (I'm trying to upgrade to the latest version
of WiX)
1. Run Heat: OK ($heat dir d:\foo -svb6 -sfrag -suid -gg -our
PrismShell.wxs)
2. Run Candle: OK
3. Run Light: Error:
[exec] Microsoft (R) Windows Installer Xml Linker version 3.0.5217.0
[exec] Copyright (C) Microsoft Corporation. All rights reserved.
[exec]
[exec] Updating file information.
[exec] Creating cabinet files.
[exec] Creating cabinet
'C:\Users\assalr\AppData\Local\Temp\fkjhmoud\#MergeModule.CABinet'.
[exec] Generating database.
[exec] D:\Builds\PRISM XP\Build 11.51.\Bin\PrismShell.wxs(19) :
error LGHT0130 : The primary key
'reg0387C011F3F8A22BDFC14B72466D9C9A.C7AC8538_65ED_4C2B_AE16_6291871D0918'
is duplicated in table 'Registry'. Please remove one of the entries or
rename a part of the primary key to avoid the collision.
The WiX XML that is generating the above error looks like the same that
you had generated before:
Component Id=DisplayFridayListUI.dll
Guid={821C19F9-E65C-48D5-BF11-07F593D7839B}
File Id=DisplayFridayListUI.dll KeyPath=yes
Source=SourceDir\DisplayFridayListUI.dll
TypeLib Id={3515D627-3FA0-490F-9330-02A73023E0C0}
Description=DisplayFridayListUI HelpDirectory=PRISMMsi Language=0
MajorVersion=1 MinorVersion=0
Class Id={9AF8DE3E-3FFB-4F1C-AA59-3DBAB1725BB9}
Context=InprocServer32
Description=DisplayFridayListUI.CDisplayFridayList
ThreadingModel=apartment Version=1.0 Programmable=yes
ProgId
Id=DisplayFridayListUI.CDisplayFridayList
Description=DisplayFridayListUI.CDisplayFridayList /
/Class
Interface Id={2D3FD2B6-AF78-4DFD-A5C9-7CE97BC4A594}
Name=CDisplayFridayList
ProxyStubClassId={00020424---C000-0046}
ProxyStubClassId32={00020424---C000-0046} /
/TypeLib
/File
RegistryValue Root=HKCR
Key=CLSID\{9AF8DE3E-3FFB-4F1C-AA59-3DBAB1725BB9}\Implemented
Categories\{40FC6ED5-2438-11CF-A3DB-080036F12502} Value= Type=string
Action=write /
RegistryValue Root=HKCR
Key=Interface\{2D3FD2B6-AF78-4DFD-A5C9-7CE97BC4A594}\ProxyStubClsid
Value={00020424---C000-0046} Type=string
Action=write /
RegistryValue Root=HKCR
Key=Interface\{2D3FD2B6-AF78-4DFD-A5C9-7CE97BC4A594}\ProxyStubClsid32
Value={00020424---C000-0046} Type=string
Action=write /
RegistryValue Root=HKCR
Key=Interface\{2D3FD2B6-AF78-4DFD-A5C9-7CE97BC4A594}
Value=_CDisplayFridayList Type=string Action=write /
/Component
Yes, it compiles, but it's not linking with Light.
This is where I am right now. Please note that the XML that Heat produces
in 3.0.4923 is much, much bigger than in 3.0.5217 and 3.0.5224. Let me
know if you need me to send you a binary (DisplayFridayListUI.dll) that
can reproduce this.
If I can't resolve this issue, I'm afraid I will have to stick with
3.0.4923 as 3.0.5224 has a break that I can't work around.
If anything is unclear, let me know. Thanks again,
Roy
Neil Sleightholm wrote:
I am not sure I understand what you are asking, could you explain?
Neil
-Original Message-
From: Roy Abou Assaly [mailto:royass...@gmail.com]
Sent: 24 April 2009 16:02
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Heat 3.0.4923 vs 3.0.5217 vb6 dll output
Can anyone run light 3.0.5217 on this to confirm this? The merge module
simple won't build and that Interface element is indeed needed.
Thanks again.
Roy Abou Assaly wrote:
Oh, and one more:
00020420---C000-0046
After that, I was able to build my merge module and link them and
create
my MSI which contains 129 vb6 com DLLs and various OCXs
Re: [WiX-users] Heat 3.0.4923 vs 3.0.5217 vb6 dll output
Sorry. I'll explain the situation. I sort of cried wolf in the beginning
since I used an XSLT to massage my XML after Heat produced the XML. At that
point Candle wouldn't compile. That was my mistake as confirmed by Brian
and yourself. I fixed that error. When it came to running Light to produce
my merge module, these were my findings:
In 3.0.4923 (my current build setup)
1. Run Heat : OK ($heat dir d:\foo -svb6 -sfrag -suid -gg -our
PrismShell.wxs)
2. Run Candle: ERROR:
[exec] D:\Builds\PRISM XP\Build 11.51.\Bin\PrismShell.wxs(180) :
error CNDL0010 : The Class/@Server attribute was not found; it is required.
Fixed by running a custom XSLT that added the Class/@Server attribute.
3. Run Light: OK (PrismShell.msm produced and later incorporated into an
MSI).
In 3.0.5217 and in 3.0.5224 (I'm trying to upgrade to the latest version of
WiX)
1. Run Heat: OK ($heat dir d:\foo -svb6 -sfrag -suid -gg -our
PrismShell.wxs)
2. Run Candle: OK
3. Run Light: Error:
[exec] Microsoft (R) Windows Installer Xml Linker version 3.0.5217.0
[exec] Copyright (C) Microsoft Corporation. All rights reserved.
[exec]
[exec] Updating file information.
[exec] Creating cabinet files.
[exec] Creating cabinet
'C:\Users\assalr\AppData\Local\Temp\fkjhmoud\#MergeModule.CABinet'.
[exec] Generating database.
[exec] D:\Builds\PRISM XP\Build 11.51.\Bin\PrismShell.wxs(19) :
error LGHT0130 : The primary key
'reg0387C011F3F8A22BDFC14B72466D9C9A.C7AC8538_65ED_4C2B_AE16_6291871D0918'
is duplicated in table 'Registry'. Please remove one of the entries or
rename a part of the primary key to avoid the collision.
The WiX XML that is generating the above error looks like the same that you
had generated before:
Component Id=DisplayFridayListUI.dll
Guid={821C19F9-E65C-48D5-BF11-07F593D7839B}
File Id=DisplayFridayListUI.dll KeyPath=yes
Source=SourceDir\DisplayFridayListUI.dll
TypeLib Id={3515D627-3FA0-490F-9330-02A73023E0C0}
Description=DisplayFridayListUI HelpDirectory=PRISMMsi Language=0
MajorVersion=1 MinorVersion=0
Class Id={9AF8DE3E-3FFB-4F1C-AA59-3DBAB1725BB9}
Context=InprocServer32
Description=DisplayFridayListUI.CDisplayFridayList
ThreadingModel=apartment Version=1.0 Programmable=yes
ProgId
Id=DisplayFridayListUI.CDisplayFridayList
Description=DisplayFridayListUI.CDisplayFridayList /
/Class
Interface Id={2D3FD2B6-AF78-4DFD-A5C9-7CE97BC4A594}
Name=CDisplayFridayList
ProxyStubClassId={00020424---C000-0046}
ProxyStubClassId32={00020424---C000-0046} /
/TypeLib
/File
RegistryValue Root=HKCR
Key=CLSID\{9AF8DE3E-3FFB-4F1C-AA59-3DBAB1725BB9}\Implemented
Categories\{40FC6ED5-2438-11CF-A3DB-080036F12502} Value= Type=string
Action=write /
RegistryValue Root=HKCR
Key=Interface\{2D3FD2B6-AF78-4DFD-A5C9-7CE97BC4A594}\ProxyStubClsid
Value={00020424---C000-0046} Type=string Action=write
/
RegistryValue Root=HKCR
Key=Interface\{2D3FD2B6-AF78-4DFD-A5C9-7CE97BC4A594}\ProxyStubClsid32
Value={00020424---C000-0046} Type=string Action=write
/
RegistryValue Root=HKCR
Key=Interface\{2D3FD2B6-AF78-4DFD-A5C9-7CE97BC4A594}
Value=_CDisplayFridayList Type=string Action=write /
/Component
Yes, it compiles, but it's not linking with Light.
This is where I am right now. Please note that the XML that Heat produces
in 3.0.4923 is much, much bigger than in 3.0.5217 and 3.0.5224. Let me know
if you need me to send you a binary (DisplayFridayListUI.dll) that can
reproduce this.
If I can't resolve this issue, I'm afraid I will have to stick with 3.0.4923
as 3.0.5224 has a break that I can't work around.
If anything is unclear, let me know. Thanks again,
Roy
Neil Sleightholm wrote:
I am not sure I understand what you are asking, could you explain?
Neil
-Original Message-
From: Roy Abou Assaly [mailto:royass...@gmail.com]
Sent: 24 April 2009 16:02
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Heat 3.0.4923 vs 3.0.5217 vb6 dll output
Can anyone run light 3.0.5217 on this to confirm this? The merge module
simple won't build and that Interface element is indeed needed.
Thanks again.
Roy Abou Assaly wrote:
Oh, and one more:
00020420---C000-0046
After that, I was able to build my merge module and link them and
create
my MSI which contains 129 vb6 com DLLs and various OCXs. Again, my
experience in this area is weak, but the product seems to install and
uninstall without issues even though I remove those elements that I
didn't
fully understand.
So I went and test the application, and of course, it threw an error
saying the Interface isn't registered, which makes sense since I
removed
them. So my ignorance has cost me. I really need those interface
elements or else
Re: [WiX-users] Heat 3.0.4923 vs 3.0.5217 vb6 dll output
Can anyone run light 3.0.5217 on this to confirm this? The merge module
simple won't build and that Interface element is indeed needed.
Thanks again.
Roy Abou Assaly wrote:
Oh, and one more:
00020420---C000-0046
After that, I was able to build my merge module and link them and create
my MSI which contains 129 vb6 com DLLs and various OCXs. Again, my
experience in this area is weak, but the product seems to install and
uninstall without issues even though I remove those elements that I didn't
fully understand.
So I went and test the application, and of course, it threw an error
saying the Interface isn't registered, which makes sense since I removed
them. So my ignorance has cost me. I really need those interface
elements or else the application won't work.
Roy Abou Assaly wrote:
Still kind of stuck. I was able to generate the exact xml as Brian did.
Candle compiled fine, but light is complaining. I'm trying to generate a
merge module out of it. Getting this error:
[exec] D:\Builds\PRISM XP\Build 11.51.\Bin\PrismShell.wxs(18) :
error LGHT0130 : The primary key 'reg0387C011F3
F8A22BDFC14B72466D9C9A.C7AC8538_65ED_4C2B_AE16_6291871D0918' is
duplicated in table 'Registry'. Please remove one of the entries or
rename a part of the primary key to avoid the collision.
D:\Builds\PRISM XP\Build 11.51.\Bincandle -v PrismShell.wxs
Microsoft (R) Windows Installer Xml Compiler version 3.0.5217.0
Copyright (C) Microsoft Corporation. All rights reserved.
PrismShell.wxs
D:\Builds\PRISM XP\Build 11.51.\Binlight -v PrismShell.wixobj
Microsoft (R) Windows Installer Xml Linker version 3.0.5217.0
Copyright (C) Microsoft Corporation. All rights reserved.
Updating file information.
Creating cabinet files.
Creating cabinet
'C:\Users\roy\AppData\Local\Temp\jyewbz0r\#MergeModule.CABinet'.
Generating database.
D:\Builds\PRISM XP\Build 11.51.\Bin\PrismShell.wxs(18) : error
LGHT0130 : The primary key 'reg0387C011F3F8A22BDFC14B
72466D9C9A.C7AC8538_65ED_4C2B_AE16_6291871D0918' is duplicated in table
'Registry'. Please remove one of the entries or
rename a part of the primary key to avoid the collision.
My merge module looks like this:
?xml version=1.0 encoding=utf-8?
Wix xmlns:wi=http://schemas.microsoft.com/wix/2006/wi;
xmlns=http://schemas.microsoft.com/wix/2006/wi;
Module Id=PrismShell Language=1033 Version=1.0.0.0
Package Id=C7AC8538-65ED-4C2B-AE16-6291871D0918 Description=PRISM
Shell Module Comments=PRISM Shell Merge Module Manufacturer=Acme
InstallerVersion=300
/Package
Icon Id=PRISM.ICO SourceFile=PRISM.exe
/Icon
Directory Id=TARGETDIR Name=SourceDir
Directory Id=ProgramFilesFolder Name=Program Files
Directory Id=HOCDir Name=Acme
Directory Id=INSTALLLOCATION Name=PRISM Shell
Component Id=DisplayFridayListUI.dll
Guid={77B6CDD1-B9C6-4497-B7F5-242B9783D6A3}
File Id=DisplayFridayListUI.dll KeyPath=yes
Source=SourceDir\DisplayFridayListUI.dll
TypeLib
Id={3515D627-3FA0-490F-9330-02A73023E0C0}
Description=DisplayFridayListUI HelpDirectory=TARGETDIR Language=0
MajorVersion=1 MinorVersion=0
Class
Id={9AF8DE3E-3FFB-4F1C-AA59-3DBAB1725BB9}
Context=InprocServer32
Description=DisplayFridayListUI.CDisplayFridayList
ThreadingModel=apartment Version=1.0 Programmable=yes
ProgId
Id=DisplayFridayListUI.CDisplayFridayList
Description=DisplayFridayListUI.CDisplayFridayList /
/Class
Interface
Id={2D3FD2B6-AF78-4DFD-A5C9-7CE97BC4A594}
Name=CDisplayFridayList
ProxyStubClassId={00020424---C000-0046}
ProxyStubClassId32={00020424---C000-0046} /
/TypeLib
/File
RegistryValue Root=HKCR
Key=CLSID\{9AF8DE3E-3FFB-4F1C-AA59-3DBAB1725BB9}\Implemented
Categories\{40FC6ED5-2438-11CF-A3DB-080036F12502} Value= Type=string
Action=write /
RegistryValue Root=HKCR
Key=Interface\{2D3FD2B6-AF78-4DFD-A5C9-7CE97BC4A594}\ProxyStubClsid
Value={00020424---C000-0046} Type=string
Action=write /
RegistryValue Root=HKCR
Key=Interface\{2D3FD2B6-AF78-4DFD-A5C9-7CE97BC4A594}\ProxyStubClsid32
Value={00020424---C000-0046} Type=string
Action=write /
RegistryValue Root=HKCR
Key=Interface\{2D3FD2B6-AF78-4DFD-A5C9-7CE97BC4A594}
Value=_CDisplayFridayList Type=string Action=write /
/Component
/Directory
/Directory
/Directory
Directory Id=ProgramMenuFolder Name=Programs
Directory Id
[WiX-users] Heat 3.0.4923 vs 3.0.5217 vb6 dll output
Hi,
In 3.0.4923, I used to get the following output (note how the Interface
element is *outside* of the File element):
Component Id=DisplayFridayListUI.dll
Guid={C4773BDF-6383-423D-BB34-BBB961BFD6DF}
File Id=DisplayFridayListUI.dll
Name=DisplayFridayListUI.dll KeyPath=yes Source=D:\Builds\PRISM
XP\Build 11.50.\Bin\PRISMMsi\DisplayFridayListUI.dll
Class Id={9AF8DE3E-3FFB-4F1C-AA59-3DBAB1725BB9}
Context=InprocServer32
Description=DisplayFridayListUI.CDisplayFridayList
Server=DisplayFridayListUI.dll ThreadingModel=apartment Version=1.0
ProgId Id=DisplayFridayListUI.CDisplayFridayList
Description=DisplayFridayListUI.CDisplayFridayList
/ProgId
/Class
/File
Interface Id={2D3FD2B6-AF78-4DFD-A5C9-7CE97BC4A594}
Name=CDisplayFridayList
ProxyStubClassId={00020424---C000-0046}
ProxyStubClassId32={00020424---C000-0046}
/Interface
In 3.0.5217, the heat output is (note how the Interface element is *inside*
the File element):
Component Id=cmp40C4F6ADC9C48FEFA7144101F481848A
Guid={00C04661-3A43-4FD9-B484-0B27EF2BF049}
Class Id={D5DE8D20-5BB8-11D1-A1E3-00A0C90F2731}
Context=InprocServer32 Description=VBPropertyBag
ThreadingModel=apartment ForeignServer=msvbvm60.dll /
File Id=filA79D608464525B697087B7D7200AF704
KeyPath=yes Source=SourceDir\DisplayFridayListUI.dll
TypeLib Id={3515D627-3FA0-490F-9330-02A73023E0C0}
Description=DisplayFridayListUI
HelpDirectory=dir667CD14ED201BFF0942A99F02E55F065 Language=0
MajorVersion=1 MinorVersion=0
Class
Id={9AF8DE3E-3FFB-4F1C-AA59-3DBAB1725BB9} Context=InprocServer32
Description=DisplayFridayListUI.CDisplayFridayList
ThreadingModel=apartment Version=1.0 Programmable=yes
ProgId
Id=DisplayFridayListUI.CDisplayFridayList
Description=DisplayFridayListUI.CDisplayFridayList /
/Class
Interface
Id={2D3FD2B6-AF78-4DFD-A5C9-7CE97BC4A594} Name=CDisplayFridayList
ProxyStubClassId={00020424---C000-0046}
ProxyStubClassId32={00020424---C000-0046} /
/TypeLib
/File
Using the -svb6 doesn't change anything. When using Candle to compile, I
get the following error:
error CNDL0005 : The File element contains an unexpected child element
'Interface'.
This wasn't the case before. Should I file a bug? I'm sure you're starting
to hate my constant emails regarding vb6 and heat :)
--
View this message in context:
http://n2.nabble.com/Heat-3.0.4923-vs-3.0.5217-vb6-dll-output-tp2686239p2686239.html
Sent from the wix-users mailing list archive at Nabble.com.
--
Crystal Reports #45; New Free Runtime and 30 Day Trial
Check out the new simplified licensign option that enables unlimited
royalty#45;free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Heat 3.0.4923 vs 3.0.5217 vb6 dll output
Hi Brian,
The bug is:
https://sourceforge.net/tracker/?func=detailaid=2779893group_id=105970atid=642714
I've attached a DLL you can use to test with in case you don't have one to
reproduce the issue.
Thanks!
Roy
Brian Rogers wrote:
Hey Roy,
Please file a bug.
Thanks,
Brian Rogers
Intelligence removes complexity. - Me
http://icumove.spaces.live.com
On Thu, Apr 23, 2009 at 1:31 PM, Roy Abou Assaly
royass...@gmail.comwrote:
Hi,
In 3.0.4923, I used to get the following output (note how the Interface
element is *outside* of the File element):
Component Id=DisplayFridayListUI.dll
Guid={C4773BDF-6383-423D-BB34-BBB961BFD6DF}
File Id=DisplayFridayListUI.dll
Name=DisplayFridayListUI.dll KeyPath=yes Source=D:\Builds\PRISM
XP\Build 11.50.\Bin\PRISMMsi\DisplayFridayListUI.dll
Class Id={9AF8DE3E-3FFB-4F1C-AA59-3DBAB1725BB9}
Context=InprocServer32
Description=DisplayFridayListUI.CDisplayFridayList
Server=DisplayFridayListUI.dll ThreadingModel=apartment
Version=1.0
ProgId Id=DisplayFridayListUI.CDisplayFridayList
Description=DisplayFridayListUI.CDisplayFridayList
/ProgId
/Class
/File
Interface Id={2D3FD2B6-AF78-4DFD-A5C9-7CE97BC4A594}
Name=CDisplayFridayList
ProxyStubClassId={00020424---C000-0046}
ProxyStubClassId32={00020424---C000-0046}
/Interface
In 3.0.5217, the heat output is (note how the Interface element is
*inside*
the File element):
Component Id=cmp40C4F6ADC9C48FEFA7144101F481848A
Guid={00C04661-3A43-4FD9-B484-0B27EF2BF049}
Class Id={D5DE8D20-5BB8-11D1-A1E3-00A0C90F2731}
Context=InprocServer32 Description=VBPropertyBag
ThreadingModel=apartment ForeignServer=msvbvm60.dll /
File Id=filA79D608464525B697087B7D7200AF704
KeyPath=yes Source=SourceDir\DisplayFridayListUI.dll
TypeLib
Id={3515D627-3FA0-490F-9330-02A73023E0C0}
Description=DisplayFridayListUI
HelpDirectory=dir667CD14ED201BFF0942A99F02E55F065 Language=0
MajorVersion=1 MinorVersion=0
Class
Id={9AF8DE3E-3FFB-4F1C-AA59-3DBAB1725BB9} Context=InprocServer32
Description=DisplayFridayListUI.CDisplayFridayList
ThreadingModel=apartment Version=1.0 Programmable=yes
ProgId
Id=DisplayFridayListUI.CDisplayFridayList
Description=DisplayFridayListUI.CDisplayFridayList /
/Class
Interface
Id={2D3FD2B6-AF78-4DFD-A5C9-7CE97BC4A594} Name=CDisplayFridayList
ProxyStubClassId={00020424---C000-0046}
ProxyStubClassId32={00020424---C000-0046} /
/TypeLib
/File
Using the -svb6 doesn't change anything. When using Candle to compile, I
get the following error:
error CNDL0005 : The File element contains an unexpected child element
'Interface'.
This wasn't the case before. Should I file a bug? I'm sure you're
starting
to hate my constant emails regarding vb6 and heat :)
--
View this message in context:
http://n2.nabble.com/Heat-3.0.4923-vs-3.0.5217-vb6-dll-output-tp2686239p2686239.html
Sent from the wix-users mailing list archive at Nabble.com.
--
Crystal Reports #45; New Free Runtime and 30 Day Trial
Check out the new simplified licensign option that enables unlimited
royalty#45;free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Crystal Reports #45; New Free Runtime and 30 Day Trial
Check out the new simplified licensign option that enables unlimited
royalty#45;free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
View this message in context:
http://n2.nabble.com/Heat-3.0.4923-vs-3.0.5217-vb6-dll-output-tp2686239p2686605.html
Sent from the wix-users mailing list archive at Nabble.com.
--
Crystal Reports #45; New Free Runtime and 30 Day Trial
Check out the new simplified licensign option that enables unlimited
royalty#45;free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https
Re: [WiX-users] Heat 3.0.4923 vs 3.0.5217 vb6 dll output
Both of you are correct. I have an XSLT that massage the XML that heat
generates in order to ensure certain shortcuts are added and changes a few
other things as well. In the process, the XSLT is not doing its job. I
would cancel the bug as it looks like like it's a data issue on my end.
Sorry for the trouble.
On Thu, Apr 23, 2009 at 5:39 PM, Neil Sleightholm (via Nabble)
ml-user+58265-122838...@n2.nabble.comml-user%2b58265-122838...@n2.nabble.com
wrote:
Running heat and candle against the file you attached to the bug doesn't
generate the error you reported could you give more details of the
command lines you are using?
Neil
-Original Message-
From: Roy Abou Assaly
[mailto:royass...@...http://n2.nabble.com/user/SendEmail.jtp?type=nodenode=2686897i=0]
Sent: 23 April 2009 22:18
To:
wix-us...@...http://n2.nabble.com/user/SendEmail.jtp?type=nodenode=2686897i=1
Subject: Re: [WiX-users] Heat 3.0.4923 vs 3.0.5217 vb6 dll output
Hi Brian,
The bug is:
https://sourceforge.net/tracker/?func=detailaid=2779893group_id=105970
atid=642714
I've attached a DLL you can use to test with in case you don't have one
to
reproduce the issue.
Thanks!
Roy
Brian Rogers wrote:
Hey Roy,
Please file a bug.
Thanks,
Brian Rogers
Intelligence removes complexity. - Me
http://icumove.spaces.live.com
On Thu, Apr 23, 2009 at 1:31 PM, Roy Abou Assaly
royass...@...http://n2.nabble.com/user/SendEmail.jtp?type=nodenode=2686897i=2wrote:
Hi,
In 3.0.4923, I used to get the following output (note how the
Interface
element is *outside* of the File element):
Component Id=DisplayFridayListUI.dll
Guid={C4773BDF-6383-423D-BB34-BBB961BFD6DF}
File Id=DisplayFridayListUI.dll
Name=DisplayFridayListUI.dll KeyPath=yes Source=D:\Builds\PRISM
XP\Build 11.50.\Bin\PRISMMsi\DisplayFridayListUI.dll
Class Id={9AF8DE3E-3FFB-4F1C-AA59-3DBAB1725BB9}
Context=InprocServer32
Description=DisplayFridayListUI.CDisplayFridayList
Server=DisplayFridayListUI.dll ThreadingModel=apartment
Version=1.0
ProgId Id=DisplayFridayListUI.CDisplayFridayList
Description=DisplayFridayListUI.CDisplayFridayList
/ProgId
/Class
/File
Interface Id={2D3FD2B6-AF78-4DFD-A5C9-7CE97BC4A594}
Name=CDisplayFridayList
ProxyStubClassId={00020424---C000-0046}
ProxyStubClassId32={00020424---C000-0046}
/Interface
In 3.0.5217, the heat output is (note how the Interface element is
*inside*
the File element):
Component Id=cmp40C4F6ADC9C48FEFA7144101F481848A
Guid={00C04661-3A43-4FD9-B484-0B27EF2BF049}
Class Id={D5DE8D20-5BB8-11D1-A1E3-00A0C90F2731}
Context=InprocServer32 Description=VBPropertyBag
ThreadingModel=apartment ForeignServer=msvbvm60.dll /
File Id=filA79D608464525B697087B7D7200AF704
KeyPath=yes Source=SourceDir\DisplayFridayListUI.dll
TypeLib
Id={3515D627-3FA0-490F-9330-02A73023E0C0}
Description=DisplayFridayListUI
HelpDirectory=dir667CD14ED201BFF0942A99F02E55F065 Language=0
MajorVersion=1 MinorVersion=0
Class
Id={9AF8DE3E-3FFB-4F1C-AA59-3DBAB1725BB9} Context=InprocServer32
Description=DisplayFridayListUI.CDisplayFridayList
ThreadingModel=apartment Version=1.0 Programmable=yes
ProgId
Id=DisplayFridayListUI.CDisplayFridayList
Description=DisplayFridayListUI.CDisplayFridayList /
/Class
Interface
Id={2D3FD2B6-AF78-4DFD-A5C9-7CE97BC4A594} Name=CDisplayFridayList
ProxyStubClassId={00020424---C000-0046}
ProxyStubClassId32={00020424---C000-0046} /
/TypeLib
/File
Using the -svb6 doesn't change anything. When using Candle to
compile, I
get the following error:
error CNDL0005 : The File element contains an unexpected child
element
'Interface'.
This wasn't the case before. Should I file a bug? I'm sure you're
starting
to hate my constant emails regarding vb6 and heat :)
--
View this message in context:
http://n2.nabble.com/Heat-3.0.4923-vs-3.0.5217-vb6-dll-output-tp2686239p
2686239.html
Sent from the wix-users mailing list archive at Nabble.com.
--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensign option that enables unlimited
royalty-free distribution of the report engine for externally
facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
___
WiX-users mailing list
wix-us...@...http://n2.nabble.com/user/SendEmail.jtp?type=nodenode=2686897i=3
https
Re: [WiX-users] Heat 3.0.4923 vs 3.0.5217 vb6 dll output
at this for too long.
Roy
Roy Abou Assaly wrote:
Both of you are correct. I have an XSLT that massage the XML that heat
generates in order to ensure certain shortcuts are added and changes a few
other things as well. In the process, the XSLT is not doing its job. I
would cancel the bug as it looks like like it's a data issue on my end.
Sorry for the trouble.
On Thu, Apr 23, 2009 at 5:39 PM, Neil Sleightholm (via Nabble)
ml-user+58265-122838...@n2.nabble.comml-user%2b58265-122838...@n2.nabble.com
wrote:
Running heat and candle against the file you attached to the bug doesn't
generate the error you reported could you give more details of the
command lines you are using?
Neil
-Original Message-
From: Roy Abou Assaly
[mailto:royass...@...http://n2.nabble.com/user/SendEmail.jtp?type=nodenode=2686897i=0]
Sent: 23 April 2009 22:18
To:
wix-us...@...http://n2.nabble.com/user/SendEmail.jtp?type=nodenode=2686897i=1
Subject: Re: [WiX-users] Heat 3.0.4923 vs 3.0.5217 vb6 dll output
Hi Brian,
The bug is:
https://sourceforge.net/tracker/?func=detailaid=2779893group_id=105970
atid=642714
I've attached a DLL you can use to test with in case you don't have one
to
reproduce the issue.
Thanks!
Roy
Brian Rogers wrote:
Hey Roy,
Please file a bug.
Thanks,
Brian Rogers
Intelligence removes complexity. - Me
http://icumove.spaces.live.com
On Thu, Apr 23, 2009 at 1:31 PM, Roy Abou Assaly
royass...@...http://n2.nabble.com/user/SendEmail.jtp?type=nodenode=2686897i=2wrote:
Hi,
In 3.0.4923, I used to get the following output (note how the
Interface
element is *outside* of the File element):
Component Id=DisplayFridayListUI.dll
Guid={C4773BDF-6383-423D-BB34-BBB961BFD6DF}
File Id=DisplayFridayListUI.dll
Name=DisplayFridayListUI.dll KeyPath=yes Source=D:\Builds\PRISM
XP\Build 11.50.\Bin\PRISMMsi\DisplayFridayListUI.dll
Class Id={9AF8DE3E-3FFB-4F1C-AA59-3DBAB1725BB9}
Context=InprocServer32
Description=DisplayFridayListUI.CDisplayFridayList
Server=DisplayFridayListUI.dll ThreadingModel=apartment
Version=1.0
ProgId Id=DisplayFridayListUI.CDisplayFridayList
Description=DisplayFridayListUI.CDisplayFridayList
/ProgId
/Class
/File
Interface Id={2D3FD2B6-AF78-4DFD-A5C9-7CE97BC4A594}
Name=CDisplayFridayList
ProxyStubClassId={00020424---C000-0046}
ProxyStubClassId32={00020424---C000-0046}
/Interface
In 3.0.5217, the heat output is (note how the Interface element is
*inside*
the File element):
Component Id=cmp40C4F6ADC9C48FEFA7144101F481848A
Guid={00C04661-3A43-4FD9-B484-0B27EF2BF049}
Class Id={D5DE8D20-5BB8-11D1-A1E3-00A0C90F2731}
Context=InprocServer32 Description=VBPropertyBag
ThreadingModel=apartment ForeignServer=msvbvm60.dll /
File Id=filA79D608464525B697087B7D7200AF704
KeyPath=yes Source=SourceDir\DisplayFridayListUI.dll
TypeLib
Id={3515D627-3FA0-490F-9330-02A73023E0C0}
Description=DisplayFridayListUI
HelpDirectory=dir667CD14ED201BFF0942A99F02E55F065 Language=0
MajorVersion=1 MinorVersion=0
Class
Id={9AF8DE3E-3FFB-4F1C-AA59-3DBAB1725BB9} Context=InprocServer32
Description=DisplayFridayListUI.CDisplayFridayList
ThreadingModel=apartment Version=1.0 Programmable=yes
ProgId
Id=DisplayFridayListUI.CDisplayFridayList
Description=DisplayFridayListUI.CDisplayFridayList /
/Class
Interface
Id={2D3FD2B6-AF78-4DFD-A5C9-7CE97BC4A594} Name=CDisplayFridayList
ProxyStubClassId={00020424---C000-0046}
ProxyStubClassId32={00020424---C000-0046} /
/TypeLib
/File
Using the -svb6 doesn't change anything. When using Candle to
compile, I
get the following error:
error CNDL0005 : The File element contains an unexpected child
element
'Interface'.
This wasn't the case before. Should I file a bug? I'm sure you're
starting
to hate my constant emails regarding vb6 and heat :)
--
View this message in context:
http://n2.nabble.com/Heat-3.0.4923-vs-3.0.5217-vb6-dll-output-tp2686239p
2686239.html
Sent from the wix-users mailing list archive at Nabble.com.
--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensign option that enables unlimited
royalty-free distribution of the report engine for externally
facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
___
WiX-users mailing list
wix-us...@...http://n2.nabble.com/user
Re: [WiX-users] Heat 3.0.4923 vs 3.0.5217 vb6 dll output
Oh, and one more:
00020420---C000-0046
After that, I was able to build my merge module and link them and create my
MSI which contains 129 vb6 com DLLs and various OCXs. Again, my experience
in this area is weak, but the product seems to install and uninstall without
issues even though I remove those elements that I didn't fully understand.
Roy Abou Assaly wrote:
Still kind of stuck. I was able to generate the exact xml as Brian did.
Candle compiled fine, but light is complaining. I'm trying to generate a
merge module out of it. Getting this error:
[exec] D:\Builds\PRISM XP\Build 11.51.\Bin\PrismShell.wxs(18) :
error LGHT0130 : The primary key 'reg0387C011F3
F8A22BDFC14B72466D9C9A.C7AC8538_65ED_4C2B_AE16_6291871D0918' is duplicated
in table 'Registry'. Please remove one of the entries or rename a part of
the primary key to avoid the collision.
D:\Builds\PRISM XP\Build 11.51.\Bincandle -v PrismShell.wxs
Microsoft (R) Windows Installer Xml Compiler version 3.0.5217.0
Copyright (C) Microsoft Corporation. All rights reserved.
PrismShell.wxs
D:\Builds\PRISM XP\Build 11.51.\Binlight -v PrismShell.wixobj
Microsoft (R) Windows Installer Xml Linker version 3.0.5217.0
Copyright (C) Microsoft Corporation. All rights reserved.
Updating file information.
Creating cabinet files.
Creating cabinet
'C:\Users\roy\AppData\Local\Temp\jyewbz0r\#MergeModule.CABinet'.
Generating database.
D:\Builds\PRISM XP\Build 11.51.\Bin\PrismShell.wxs(18) : error
LGHT0130 : The primary key 'reg0387C011F3F8A22BDFC14B
72466D9C9A.C7AC8538_65ED_4C2B_AE16_6291871D0918' is duplicated in table
'Registry'. Please remove one of the entries or
rename a part of the primary key to avoid the collision.
My merge module looks like this:
?xml version=1.0 encoding=utf-8?
Wix xmlns:wi=http://schemas.microsoft.com/wix/2006/wi;
xmlns=http://schemas.microsoft.com/wix/2006/wi;
Module Id=PrismShell Language=1033 Version=1.0.0.0
Package Id=C7AC8538-65ED-4C2B-AE16-6291871D0918 Description=PRISM
Shell Module Comments=PRISM Shell Merge Module Manufacturer=Acme
InstallerVersion=300
/Package
Icon Id=PRISM.ICO SourceFile=PRISM.exe
/Icon
Directory Id=TARGETDIR Name=SourceDir
Directory Id=ProgramFilesFolder Name=Program Files
Directory Id=HOCDir Name=Acme
Directory Id=INSTALLLOCATION Name=PRISM Shell
Component Id=DisplayFridayListUI.dll
Guid={77B6CDD1-B9C6-4497-B7F5-242B9783D6A3}
File Id=DisplayFridayListUI.dll KeyPath=yes
Source=SourceDir\DisplayFridayListUI.dll
TypeLib
Id={3515D627-3FA0-490F-9330-02A73023E0C0}
Description=DisplayFridayListUI HelpDirectory=TARGETDIR Language=0
MajorVersion=1 MinorVersion=0
Class
Id={9AF8DE3E-3FFB-4F1C-AA59-3DBAB1725BB9}
Context=InprocServer32
Description=DisplayFridayListUI.CDisplayFridayList
ThreadingModel=apartment Version=1.0 Programmable=yes
ProgId
Id=DisplayFridayListUI.CDisplayFridayList
Description=DisplayFridayListUI.CDisplayFridayList /
/Class
Interface
Id={2D3FD2B6-AF78-4DFD-A5C9-7CE97BC4A594}
Name=CDisplayFridayList
ProxyStubClassId={00020424---C000-0046}
ProxyStubClassId32={00020424---C000-0046} /
/TypeLib
/File
RegistryValue Root=HKCR
Key=CLSID\{9AF8DE3E-3FFB-4F1C-AA59-3DBAB1725BB9}\Implemented
Categories\{40FC6ED5-2438-11CF-A3DB-080036F12502} Value= Type=string
Action=write /
RegistryValue Root=HKCR
Key=Interface\{2D3FD2B6-AF78-4DFD-A5C9-7CE97BC4A594}\ProxyStubClsid
Value={00020424---C000-0046} Type=string
Action=write /
RegistryValue Root=HKCR
Key=Interface\{2D3FD2B6-AF78-4DFD-A5C9-7CE97BC4A594}\ProxyStubClsid32
Value={00020424---C000-0046} Type=string
Action=write /
RegistryValue Root=HKCR
Key=Interface\{2D3FD2B6-AF78-4DFD-A5C9-7CE97BC4A594}
Value=_CDisplayFridayList Type=string Action=write /
/Component
/Directory
/Directory
/Directory
Directory Id=ProgramMenuFolder Name=Programs
Directory Id=ProgramMenuDir Name=PRISM
/Directory
/Directory
Directory Id=DesktopFolder SourceName=Desktop
/Directory
/Directory
/Module
/Wix
I then decided to simply remove the following in order to create my merge
module:
Interface Id={2D3FD2B6-AF78-4DFD-A5C9-7CE97BC4A594}
Name=CDisplayFridayList
ProxyStubClassId={00020424---C000-0046}
ProxyStubClassId32={00020424---C000
Re: [WiX-users] Registring CDO.dll - Heat ouput same as before, but Light now giving error
Thanks for the tips guys. We had 2 products using this. One works fine with
the redistributable, but the other didn't like it. So I'm going to chain
the redistributable package for the product that liked it, and we'll just
hold off for the other, until a code change. We got an error:
Marshaler restriction: Excessively long string.
I will leave to the developers to update accordingly and then our plan is to
use the redistributable.
Thanks!
Roy
Roy Abou Assaly wrote:
Hi Brian,
I found this website http://www.cdolive.com/cdo7.htm which lead me to this
MS Collaboration Data Objects, version 1.2.1 (6.5.8067.0) download link:
http://www.microsoft.com/downloads/details.aspx?familyid=2714320d-c997-4de1-986f-24f081725d36displaylang=en
I'm going to talk to the developer and see if 6.5.8067.0 is compatible
with
his application which is using 6.5.7940.0. If there's no problems, I may
just go with the MS re-distributable. I will go that route before I go
and
create any unnecessary tickets. Will get back to with the result.
Thanks for the tip,
Roy
On Mon, Apr 20, 2009 at 4:52 PM, Brian Rogers (via Nabble)
ml-user+58646-1457241...@n2.nabble.comml-user%2b58646-1457241...@n2.nabble.com
wrote:
Roy,
It might be worth you opening a bug. However, you should not be
installing
CDO on your own. There could likely be other pieces that need to be
installed that are not harvested from the DLL itself. This would
invalidate
the installation of CDO on the system and could cause large problems. You
should look for a redistributable and chain that into your installation.
The message you are getting in light is saying that the output of the
harvest is basically not valid which is possible as COM is highly
customizable. Heat does not take into account all possible variations
because of those issues.
Thanks,
Brian Rogers
Intelligence removes complexity. - Me
http://icumove.spaces.live.com
On Mon, Apr 20, 2009 at 12:41 PM, Roy Abou Assaly
royass...@...http://n2.nabble.com/user/SendEmail.jtp?type=nodenode=2666208i=0wrote:
Hi,
I'm in the process of migrating more WiX files to the latest version of
WiX.
I'm using 3.0.5217 and found this error that wasn't occurring in an
older
version of WiX:
error LGHT0130 : The primary key 'regFB26914512AFF203D5986383999BD192'
is
duplicated in table 'Registry'. Please remove one of the entries or
rename
a part of the primary key to avoid the collision.
The DLL in question is actually CDO.dll 6.5.7940.0. I generated the
WiX
for
it using heat many versions ago (6 months or so). I regenerated again
using
heat 3.0.5217 and it produced the same output. However, Light 3.0.5217
is
throwing the error above. Light never gave this error before.
If I comment out:
ProgId Id=ActMsg.Session Description=CDO Session Object /
Light has no problems, but after generating the MSI, I ran Orca on the
MSI,
and I got:
ICE33: Warning Reg key regFB26914512AFF203D5986383999BD192 is used in
an
unsupported way. CLSID - ProdId associations should be registered via
the
Class and ProdId tables. This entry may overwrite a value created
through
those tables.
Should I create a ticket in sourceforge and attach CDO.dll?
Here's the WiX snippet:
!-- CDO.DLL --
Component Id=CDO.DLL
Guid=F1A0C26F-B1CC-4B8D-93C5-EF276E24C3FD SharedDllRefCount=yes
File Id=CDO.DLL Name=CDO.DLL KeyPath=yes
Source=$(var.EXTERNAL_DLL)\CDO.DLL
TypeLib
Id={3FA7DEA7-6438-101B-ACC1-00AA00423326}
Description=Microsoft CDO 1.21 Library Language=0 MajorVersion=1
MinorVersion=21
Class
Id={3FA7DEB3-6438-101B-ACC1-00AA00423326}
Context=InprocServer32 Description=CDO Session Object
ThreadingModel=both
ProgId Id=ActMsg.Session
Description=CDO
Session
Object /
ProgId Id=MAPI.Session.1 Description=CDO
1.21
Session Object
ProgId Id=MAPI.Session Description=CDO
Session
Object /
/ProgId
/Class
/TypeLib
/File
/Component
--
View this message in context:
http://n2.nabble.com/Registring-CDO.dll---Heat-ouput-same-as-before%2C-but-Light-now-giving-error-tp2665723p2665723.html
Sent from the wix-users mailing list archive at Nabble.com.
--
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
[WiX-users] Registring CDO.dll - Heat ouput same as before, but Light now giving error
Hi,
I'm in the process of migrating more WiX files to the latest version of WiX.
I'm using 3.0.5217 and found this error that wasn't occurring in an older
version of WiX:
error LGHT0130 : The primary key 'regFB26914512AFF203D5986383999BD192' is
duplicated in table 'Registry'. Please remove one of the entries or rename
a part of the primary key to avoid the collision.
The DLL in question is actually CDO.dll 6.5.7940.0. I generated the WiX for
it using heat many versions ago (6 months or so). I regenerated again using
heat 3.0.5217 and it produced the same output. However, Light 3.0.5217 is
throwing the error above. Light never gave this error before.
If I comment out:
ProgId Id=ActMsg.Session Description=CDO Session Object /
Light has no problems, but after generating the MSI, I ran Orca on the MSI,
and I got:
ICE33: Warning Reg key regFB26914512AFF203D5986383999BD192 is used in an
unsupported way. CLSID - ProdId associations should be registered via the
Class and ProdId tables. This entry may overwrite a value created through
those tables.
Should I create a ticket in sourceforge and attach CDO.dll?
Here's the WiX snippet:
!-- CDO.DLL --
Component Id=CDO.DLL
Guid=F1A0C26F-B1CC-4B8D-93C5-EF276E24C3FD SharedDllRefCount=yes
File Id=CDO.DLL Name=CDO.DLL KeyPath=yes
Source=$(var.EXTERNAL_DLL)\CDO.DLL
TypeLib Id={3FA7DEA7-6438-101B-ACC1-00AA00423326}
Description=Microsoft CDO 1.21 Library Language=0 MajorVersion=1
MinorVersion=21
Class Id={3FA7DEB3-6438-101B-ACC1-00AA00423326}
Context=InprocServer32 Description=CDO Session Object
ThreadingModel=both
ProgId Id=ActMsg.Session Description=CDO
Session
Object /
ProgId Id=MAPI.Session.1 Description=CDO 1.21
Session Object
ProgId Id=MAPI.Session Description=CDO Session
Object /
/ProgId
/Class
/TypeLib
/File
/Component
--
View this message in context:
http://n2.nabble.com/Registring-CDO.dll---Heat-ouput-same-as-before%2C-but-Light-now-giving-error-tp2665723p2665723.html
Sent from the wix-users mailing list archive at Nabble.com.
--
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Registring CDO.dll - Heat ouput same as before, but Light now giving error
Hi Brian,
I found this website http://www.cdolive.com/cdo7.htm which lead me to this
MS Collaboration Data Objects, version 1.2.1 (6.5.8067.0) download link:
http://www.microsoft.com/downloads/details.aspx?familyid=2714320d-c997-4de1-986f-24f081725d36displaylang=en
I'm going to talk to the developer and see if 6.5.8067.0 is compatible with
his application which is using 6.5.7940.0. If there's no problems, I may
just go with the MS re-distributable. I will go that route before I go and
create any unnecessary tickets. Will get back to with the result.
Thanks for the tip,
Roy
On Mon, Apr 20, 2009 at 4:52 PM, Brian Rogers (via Nabble)
ml-user+58646-1457241...@n2.nabble.comml-user%2b58646-1457241...@n2.nabble.com
wrote:
Roy,
It might be worth you opening a bug. However, you should not be installing
CDO on your own. There could likely be other pieces that need to be
installed that are not harvested from the DLL itself. This would invalidate
the installation of CDO on the system and could cause large problems. You
should look for a redistributable and chain that into your installation.
The message you are getting in light is saying that the output of the
harvest is basically not valid which is possible as COM is highly
customizable. Heat does not take into account all possible variations
because of those issues.
Thanks,
Brian Rogers
Intelligence removes complexity. - Me
http://icumove.spaces.live.com
On Mon, Apr 20, 2009 at 12:41 PM, Roy Abou Assaly
royass...@...http://n2.nabble.com/user/SendEmail.jtp?type=nodenode=2666208i=0wrote:
Hi,
I'm in the process of migrating more WiX files to the latest version of
WiX.
I'm using 3.0.5217 and found this error that wasn't occurring in an older
version of WiX:
error LGHT0130 : The primary key 'regFB26914512AFF203D5986383999BD192' is
duplicated in table 'Registry'. Please remove one of the entries or
rename
a part of the primary key to avoid the collision.
The DLL in question is actually CDO.dll 6.5.7940.0. I generated the WiX
for
it using heat many versions ago (6 months or so). I regenerated again
using
heat 3.0.5217 and it produced the same output. However, Light 3.0.5217
is
throwing the error above. Light never gave this error before.
If I comment out:
ProgId Id=ActMsg.Session Description=CDO Session Object /
Light has no problems, but after generating the MSI, I ran Orca on the
MSI,
and I got:
ICE33: Warning Reg key regFB26914512AFF203D5986383999BD192 is used in an
unsupported way. CLSID - ProdId associations should be registered via
the
Class and ProdId tables. This entry may overwrite a value created
through
those tables.
Should I create a ticket in sourceforge and attach CDO.dll?
Here's the WiX snippet:
!-- CDO.DLL --
Component Id=CDO.DLL
Guid=F1A0C26F-B1CC-4B8D-93C5-EF276E24C3FD SharedDllRefCount=yes
File Id=CDO.DLL Name=CDO.DLL KeyPath=yes
Source=$(var.EXTERNAL_DLL)\CDO.DLL
TypeLib
Id={3FA7DEA7-6438-101B-ACC1-00AA00423326}
Description=Microsoft CDO 1.21 Library Language=0 MajorVersion=1
MinorVersion=21
Class
Id={3FA7DEB3-6438-101B-ACC1-00AA00423326}
Context=InprocServer32 Description=CDO Session Object
ThreadingModel=both
ProgId Id=ActMsg.Session
Description=CDO
Session
Object /
ProgId Id=MAPI.Session.1 Description=CDO
1.21
Session Object
ProgId Id=MAPI.Session Description=CDO
Session
Object /
/ProgId
/Class
/TypeLib
/File
/Component
--
View this message in context:
http://n2.nabble.com/Registring-CDO.dll---Heat-ouput-same-as-before%2C-but-Light-now-giving-error-tp2665723p2665723.html
Sent from the wix-users mailing list archive at Nabble.com.
--
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
___
WiX-users mailing list
wix-us...@...http://n2.nabble.com/user/SendEmail.jtp?type=nodenode=2666208i=1
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use
Re: [WiX-users] Heat missing some RegistryValue elements (Programmable) from VB6 code?
Hi Brian,
I definitely will in the future. Thanks for your all your help!
Roy
On Fri, Apr 17, 2009 at 8:57 AM, Brian Rogers (via Nabble)
ml-user+58646-1457241...@n2.nabble.comml-user%2b58646-1457241...@n2.nabble.com
wrote:
Hey Roy,
The fix for this should be in the next drop. I appreciate the detailed
information. When you see issues like this please feel free to file a bug
on
sourceforge.net/projects/wix.
Thanks,
Brian Rogers
Intelligence removes complexity. - Me
http://icumove.spaces.live.com
On Tue, Apr 14, 2009 at 8:15 AM, Roy Abou Assaly
royass...@...http://n2.nabble.com/user/SendEmail.jtp?type=nodenode=2649812i=0wrote:
Hi,
I was away for a week or else I would've replied sooner. I tested the
following using version 3.0.5210.0.
This works:
D:\lab\WiX\XMLEditorheat dir . -v -sfrag -gg -svb6 -out foo.xml
Microsoft (R) Windows Installer Xml Toolset Harvester version 3.0.5210.0
Copyright (C) Microsoft Corporation. All rights reserved.
Trying to harvest D:\lab\WiX\XMLEditor\PRISMXMLEditor.dll as an assembly.
Trying to harvest self-registration information from native DLL
D:\lab\WiX\XMLEditor\PRISMXMLEditor.dll.
Ignoring the registry key
'Interface\{0B7F3153-C8E7-4E6D-AEBE-B6D61D78B9A3}\ProxyStubClsid/', it
has
already been added to the component
'cmpD86DA220B5DFAFDE5B16661AC4E61230'.
Ignoring the registry key
'Interface\{0B7F3153-C8E7-4E6D-AEBE-B6D61D78B9A3}\ProxyStubClsid32/', it
has
already been added to the component
'cmpD86DA220B5DFAFDE5B16661AC4E61230'.
Ignoring the registry key
'Interface\{0B7F3153-C8E7-4E6D-AEBE-B6D61D78B9A3}/', it has already been
added to the component 'cmpD86DA220B5DFAFDE5B16661AC4E61230'.
Ignoring the registry key
'Interface\{1D3D80B3-86A1-4DA7-AF4B-FA12E70BB39F}\ProxyStubClsid/', it
has
already been added to the component
'cmpD86DA220B5DFAFDE5B16661AC4E61230'.
Ignoring the registry key
'Interface\{1D3D80B3-86A1-4DA7-AF4B-FA12E70BB39F}\ProxyStubClsid32/', it
has
already been added to the component
'cmpD86DA220B5DFAFDE5B16661AC4E61230'.
Ignoring the registry key
'Interface\{1D3D80B3-86A1-4DA7-AF4B-FA12E70BB39F}/', it has already been
added to the component 'cmpD86DA220B5DFAFDE5B16661AC4E61230'.
Ignoring the registry key
'Interface\{399DC087-F09A-4DDE-B2A6-A3755D8506B3}\ProxyStubClsid/', it
has
already been added to the component
'cmpD86DA220B5DFAFDE5B16661AC4E61230'.
Ignoring the registry key
'Interface\{399DC087-F09A-4DDE-B2A6-A3755D8506B3}\ProxyStubClsid32/', it
has
already been added to the component
'cmpD86DA220B5DFAFDE5B16661AC4E61230'.
Ignoring the registry key
'Interface\{399DC087-F09A-4DDE-B2A6-A3755D8506B3}/', it has already been
added to the component 'cmpD86DA220B5DFAFDE5B16661AC4E61230'.
Ignoring the registry key
'Interface\{EAC0509C-5990-48B8-81B3-5A2ECE581DB4}\ProxyStubClsid/', it
has
already been added to the component
'cmpD86DA220B5DFAFDE5B16661AC4E61230'.
Ignoring the registry key
'Interface\{EAC0509C-5990-48B8-81B3-5A2ECE581DB4}\ProxyStubClsid32/', it
has
already been added to the component
'cmpD86DA220B5DFAFDE5B16661AC4E61230'.
Ignoring the registry key
'Interface\{EAC0509C-5990-48B8-81B3-5A2ECE581DB4}/', it has already been
added to the component 'cmpD86DA220B5DFAFDE5B16661AC4E61230'.
This gives an error:
D:\lab\WiX\XMLEditorheat file PRISMXMLEditor.dll -v -sfrag -gg -svb6
-out
foo.xml
Microsoft (R) Windows Installer Xml Toolset Harvester version 3.0.5210.0
Copyright (C) Microsoft Corporation. All rights reserved.
heat.exe : error HEAT0001 : The path is not of a legal form.
Exception Type: System.ArgumentException
Stack Trace:
at System.IO.Path.NormalizePathFast(String path, Boolean fullCheck)
at System.IO.Path.NormalizePath(String path, Boolean fullCheck)
at System.IO.Path.GetFullPathInternal(String path)
at System.IO.Path.GetFullPath(String path)
at
Microsoft.Tools.WindowsInstallerXml.HarvesterCore.ResolveFilePath(String
fileSource)
at
Microsoft.Tools.WindowsInstallerXml.Extensions.UtilHarvesterMutator.MutateFile(IParentElement
parentElement, File file)
at
Microsoft.Tools.WindowsInstallerXml.Extensions.UtilHarvesterMutator.MutateElement(IParentElement
parentElement, ISchemaElement element)
at
Microsoft.Tools.WindowsInstallerXml.Extensions.UtilHarvesterMutator.MutateElement(IParentElement
parentElement, ISchemaElement element)
at
Microsoft.Tools.WindowsInstallerXml.Extensions.UtilHarvesterMutator.MutateElement(IParentElement
parentElement, ISchemaElement element)
at
Microsoft.Tools.WindowsInstallerXml.Extensions.UtilHarvesterMutator.MutateElement(IParentElement
parentElement, ISchemaElement element)
at
Microsoft.Tools.WindowsInstallerXml.Extensions.UtilHarvesterMutator.MutateElement(IParentElement
parentElement, ISchemaElement element
Re: [WiX-users] Heat missing some RegistryValue elements (Programmable) from VB6 code?
Hi,
I was away for a week or else I would've replied sooner. I tested the
following using version 3.0.5210.0.
This works:
D:\lab\WiX\XMLEditorheat dir . -v -sfrag -gg -svb6 -out foo.xml
Microsoft (R) Windows Installer Xml Toolset Harvester version 3.0.5210.0
Copyright (C) Microsoft Corporation. All rights reserved.
Trying to harvest D:\lab\WiX\XMLEditor\PRISMXMLEditor.dll as an assembly.
Trying to harvest self-registration information from native DLL
D:\lab\WiX\XMLEditor\PRISMXMLEditor.dll.
Ignoring the registry key
'Interface\{0B7F3153-C8E7-4E6D-AEBE-B6D61D78B9A3}\ProxyStubClsid/', it has
already been added to the component 'cmpD86DA220B5DFAFDE5B16661AC4E61230'.
Ignoring the registry key
'Interface\{0B7F3153-C8E7-4E6D-AEBE-B6D61D78B9A3}\ProxyStubClsid32/', it has
already been added to the component 'cmpD86DA220B5DFAFDE5B16661AC4E61230'.
Ignoring the registry key 'Interface\{0B7F3153-C8E7-4E6D-AEBE-B6D61D78B9A3}/',
it has already been added to the component
'cmpD86DA220B5DFAFDE5B16661AC4E61230'.
Ignoring the registry key
'Interface\{1D3D80B3-86A1-4DA7-AF4B-FA12E70BB39F}\ProxyStubClsid/', it has
already been added to the component 'cmpD86DA220B5DFAFDE5B16661AC4E61230'.
Ignoring the registry key
'Interface\{1D3D80B3-86A1-4DA7-AF4B-FA12E70BB39F}\ProxyStubClsid32/', it has
already been added to the component 'cmpD86DA220B5DFAFDE5B16661AC4E61230'.
Ignoring the registry key 'Interface\{1D3D80B3-86A1-4DA7-AF4B-FA12E70BB39F}/',
it has already been added to the component
'cmpD86DA220B5DFAFDE5B16661AC4E61230'.
Ignoring the registry key
'Interface\{399DC087-F09A-4DDE-B2A6-A3755D8506B3}\ProxyStubClsid/', it has
already been added to the component 'cmpD86DA220B5DFAFDE5B16661AC4E61230'.
Ignoring the registry key
'Interface\{399DC087-F09A-4DDE-B2A6-A3755D8506B3}\ProxyStubClsid32/', it has
already been added to the component 'cmpD86DA220B5DFAFDE5B16661AC4E61230'.
Ignoring the registry key 'Interface\{399DC087-F09A-4DDE-B2A6-A3755D8506B3}/',
it has already been added to the component
'cmpD86DA220B5DFAFDE5B16661AC4E61230'.
Ignoring the registry key
'Interface\{EAC0509C-5990-48B8-81B3-5A2ECE581DB4}\ProxyStubClsid/', it has
already been added to the component 'cmpD86DA220B5DFAFDE5B16661AC4E61230'.
Ignoring the registry key
'Interface\{EAC0509C-5990-48B8-81B3-5A2ECE581DB4}\ProxyStubClsid32/', it has
already been added to the component 'cmpD86DA220B5DFAFDE5B16661AC4E61230'.
Ignoring the registry key 'Interface\{EAC0509C-5990-48B8-81B3-5A2ECE581DB4}/',
it has already been added to the component
'cmpD86DA220B5DFAFDE5B16661AC4E61230'.
This gives an error:
D:\lab\WiX\XMLEditorheat file PRISMXMLEditor.dll -v -sfrag -gg -svb6 -out
foo.xml
Microsoft (R) Windows Installer Xml Toolset Harvester version 3.0.5210.0
Copyright (C) Microsoft Corporation. All rights reserved.
heat.exe : error HEAT0001 : The path is not of a legal form.
Exception Type: System.ArgumentException
Stack Trace:
at System.IO.Path.NormalizePathFast(String path, Boolean fullCheck)
at System.IO.Path.NormalizePath(String path, Boolean fullCheck)
at System.IO.Path.GetFullPathInternal(String path)
at System.IO.Path.GetFullPath(String path)
at Microsoft.Tools.WindowsInstallerXml.HarvesterCore.ResolveFilePath(String
fileSource)
at
Microsoft.Tools.WindowsInstallerXml.Extensions.UtilHarvesterMutator.MutateFile(IParentElement
parentElement, File file)
at
Microsoft.Tools.WindowsInstallerXml.Extensions.UtilHarvesterMutator.MutateElement(IParentElement
parentElement, ISchemaElement element)
at
Microsoft.Tools.WindowsInstallerXml.Extensions.UtilHarvesterMutator.MutateElement(IParentElement
parentElement, ISchemaElement element)
at
Microsoft.Tools.WindowsInstallerXml.Extensions.UtilHarvesterMutator.MutateElement(IParentElement
parentElement, ISchemaElement element)
at
Microsoft.Tools.WindowsInstallerXml.Extensions.UtilHarvesterMutator.MutateElement(IParentElement
parentElement, ISchemaElement element)
at
Microsoft.Tools.WindowsInstallerXml.Extensions.UtilHarvesterMutator.MutateElement(IParentElement
parentElement, ISchemaElement element)
at
Microsoft.Tools.WindowsInstallerXml.Extensions.UtilHarvesterMutator.MutateElement(IParentElement
parentElement, ISchemaElement element)
at
Microsoft.Tools.WindowsInstallerXml.Extensions.UtilHarvesterMutator.Mutate(Wix
wix)
at Microsoft.Tools.WindowsInstallerXml.Mutator.Mutate(Wix wix)
at Microsoft.Tools.WindowsInstallerXml.Tools.Heat.Run(String[] args)
I ran it with the full path and got this error which looks like it isn't
reading the path correctly for the 'file' harvesting type argument. It's
doubling the name of the last directory in the path
(d:\lab\wix\xmleditor\xmleditor\PRISMXMLEditor.dll).
So I typed: d:\lab\wix\xmleditor\PRISMXMLEditor.dll
But it reads: d:\lab\wix\xmleditor\xmleditor\PRISMXMLEditor.dll
So that could be hint in as to why the 'file' harvesting type doesn't work, but
the 'dir' does. Let me know if there's
Re: [WiX-users] Heat missing some RegistryValue elements (Programmable) from VB6 code?
I have just tried the latest version 3.0.5120.0 and the programmable
attribute on is set for your dll on the ClassId e.g.
Class Id={5A5DBDF3-10F1-43D1-AA51-CDE7EDFA0321}
Description=PRISMXMLEditor.XMLChunk Version=12.3 Programmable=yes
If you are not already you may also want to try the -svb6 option with
Heat as that will remove the VB6 runtime properties that are not
required (see help file).
Neil
Hi Neil and Roger,
I just ran heat 3.0.5120.0 and got this error:
D:\lab\WiX\XMLEditorheat file PRISMXMLEditor.dll -sfrag -gg -vb6 -out
result.xml
Microsoft (R) Windows Installer Xml Toolset Harvester version 3.0.5120.0
Copyright (C) Microsoft Corporation. All rights reserved.
heat.exe : error HEAT0001 : Item has already been added. Key in dictionary:
'Interface\{0B7F3153-C8E7-4E6D-AEBE-B6D61D78B9A3}\ProxyStubClsid/' Key being
added: 'Interface\{0B7F3153-C8E7-4E6
D-AEBE-B6D61D78B9A3}\ProxyStubClsid/'
Exception Type: System.ArgumentException
Stack Trace:
at System.Collections.SortedList.Add(Object key, Object value)
at
Microsoft.Tools.WindowsInstallerXml.Extensions.UtilFinalizeHarvesterMutator.MutateComponents()
at
Microsoft.Tools.WindowsInstallerXml.Extensions.UtilFinalizeHarvesterMutator.Mutate(Wix
wix)
at Microsoft.Tools.WindowsInstallerXml.Mutator.Mutate(Wix wix)
at Microsoft.Tools.WindowsInstallerXml.Tools.Heat.Run(String[] args)
Then I ran 3.0.4923.0
D:\lab\WiX\XMLEditorheat file PRISMXMLEditor.dll -sfrag -gg -vb6 -out
result.xml
Microsoft (R) Windows Installer Xml Toolset Harvester version 3.0.4923.0
Copyright (C) Microsoft Corporation. All rights reserved.
And yes, you're right. Programmable is set as an attribute of Class rather
than being created in RegistryValue. I'm going to assume that those 2 are the
equivalent? Can you confirm this? If that is true, I will stick with
3.0.4923.0 since it works and I have tested the builds with this version.
That's basically where I got confused. I saw that I was missing RegistryValue
elements and figured that certain keys were being missing.
Do you still want me to open a bug Roger? Although, this time it would be for
another Reason. Also, how did it manage to run heat 3.0.5120.0 on your machine
Neil? I hope it's not the dreaded It runs on my machine bug :)
Thanks guys
--
View this message in context:
http://n2.nabble.com/Heat-missing-some-RegistryValue-elements-%28Programmable%29-from-VB6-code--tp2559361p2569042.html
Sent from the wix-users mailing list archive at Nabble.com.
--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Heat missing some RegistryValue elements (Programmable) from VB6 code?
Hi,
No, I was using version 11.34. The same one attached in the email. I just
redownloaded the DLL I had attached to you and ran it in 3.0.5120.0...still
the same exception. Strange.
On Wed, Apr 1, 2009 at 3:36 PM, Neil Sleightholm (via Nabble)
ml-user+58265-122838...@n2.nabble.comml-user%2b58265-122838...@n2.nabble.com
wrote:
I just tried this again and didn't see an error, has the dll changed from
the one you sent me?
Neil
Neil Sleightholm
X2 Systems Limited
n...@...http://n2.nabble.com/user/SendEmail.jtp?type=nodenode=2571127i=0mailto:
n...@...http://n2.nabble.com/user/SendEmail.jtp?type=nodenode=2571127i=1
From: Roy Abou Assaly
[mailto:royass...@...http://n2.nabble.com/user/SendEmail.jtp?type=nodenode=2571127i=2]
Sent: Wed 01/04/2009 14:39
To:
wix-us...@...http://n2.nabble.com/user/SendEmail.jtp?type=nodenode=2571127i=3
Subject: Re: [WiX-users] Heat missing some RegistryValue elements
(Programmable) from VB6 code?
I have just tried the latest version 3.0.5120.0 and the programmable
attribute on is set for your dll on the ClassId e.g.
Class Id={5A5DBDF3-10F1-43D1-AA51-CDE7EDFA0321}
Description=PRISMXMLEditor.XMLChunk Version=12.3 Programmable=yes
If you are not already you may also want to try the -svb6 option with
Heat as that will remove the VB6 runtime properties that are not
required (see help file).
Neil
Hi Neil and Roger,
I just ran heat 3.0.5120.0 and got this error:
D:\lab\WiX\XMLEditorheat file PRISMXMLEditor.dll -sfrag -gg -vb6 -out
result.xml
Microsoft (R) Windows Installer Xml Toolset Harvester version 3.0.5120.0
Copyright (C) Microsoft Corporation. All rights reserved.
heat.exe : error HEAT0001 : Item has already been added. Key in dictionary:
'Interface\{0B7F3153-C8E7-4E6D-AEBE-B6D61D78B9A3}\ProxyStubClsid/' Key
being added: 'Interface\{0B7F3153-C8E7-4E6
D-AEBE-B6D61D78B9A3}\ProxyStubClsid/'
Exception Type: System.ArgumentException
Stack Trace:
at System.Collections.SortedList.Add(Object key, Object value)
at
Microsoft.Tools.WindowsInstallerXml.Extensions.UtilFinalizeHarvesterMutator.MutateComponents()
at
Microsoft.Tools.WindowsInstallerXml.Extensions.UtilFinalizeHarvesterMutator.Mutate(Wix
wix)
at Microsoft.Tools.WindowsInstallerXml.Mutator.Mutate(Wix wix)
at Microsoft.Tools.WindowsInstallerXml.Tools.Heat.Run(String[] args)
Then I ran 3.0.4923.0
D:\lab\WiX\XMLEditorheat file PRISMXMLEditor.dll -sfrag -gg -vb6 -out
result.xml
Microsoft (R) Windows Installer Xml Toolset Harvester version 3.0.4923.0
Copyright (C) Microsoft Corporation. All rights reserved.
And yes, you're right. Programmable is set as an attribute of Class rather
than being created in RegistryValue. I'm going to assume that those 2 are
the equivalent? Can you confirm this? If that is true, I will stick with
3.0.4923.0 since it works and I have tested the builds with this version.
That's basically where I got confused. I saw that I was missing
RegistryValue elements and figured that certain keys were being missing.
Do you still want me to open a bug Roger? Although, this time it would be
for another Reason. Also, how did it manage to run heat 3.0.5120.0 on your
machine Neil? I hope it's not the dreaded It runs on my machine bug :)
Thanks guys
--
View this message in context:
http://n2.nabble.com/Heat-missing-some-RegistryValue-elements-%28Programmable%29-from-VB6-code--tp2559361p2569042.html
Sent from the wix-users mailing list archive at Nabble.com.
--
___
WiX-users mailing list
wix-us...@...http://n2.nabble.com/user/SendEmail.jtp?type=nodenode=2571127i=4
https://lists.sourceforge.net/lists/listinfo/wix-users
--
___
WiX-users mailing list
wix-us...@...http://n2.nabble.com/user/SendEmail.jtp?type=nodenode=2571127i=5
https://lists.sourceforge.net/lists/listinfo/wix-users
--
View message @
http://n2.nabble.com/Heat-missing-some-RegistryValue-elements-%28Programmable%29-from-VB6-code--tp2559361p2571127.html
To unsubscribe from Heat missing some RegistryValue elements (Programmable)
from VB6 code?, click here (link removed) .
--
View this message in context:
http://n2.nabble.com/Heat-missing-some-RegistryValue-elements-%28Programmable%29-from-VB6-code--tp2559361p2572340.html
Sent from the wix-users mailing list archive at Nabble.com.
--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Heat missing some RegistryValue elements (Programmable) from VB6 code?
Hi,
I'm running heat (WiX 3.0.4923.0) to harvest some DLLs. I don't have the
version that I was using before, but I know it was working before I had
upgraded sometime in the Fall.
I noticed that Programmable is being ommitted:
RegistryValue Root=HKCR
Key=CLSID\{5A5DBDF3-10F1-43D1-AA51-CDE7EDFA0321}\Programmable Value=
Type=string Action=write /
This key existed in our December build, and now, in many more places in the wix
file for many DLLs, RegistryValue elements who's key is Programmable are no
longer there. I believe keys ending with Control may also be affected. Is
this related to this ticket?
http://sourceforge.net/tracker/?func=detailatid=642714aid=1888456group_id=105970
Thanks,
Roy
--
View this message in context:
http://n2.nabble.com/Heat-missing-some-RegistryValue-elements-%28Programmable%29-from-VB6-code--tp2559361p2559361.html
Sent from the wix-users mailing list archive at Nabble.com.
--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Heat missing some RegistryValue elements (Programmable) from VB6 code?
Yes I do. I have sent it as an attachment to your x2systems email address.
Thanks!
Roy
On Mon, Mar 30, 2009 at 4:55 PM, Neil Sleightholm (via Nabble)
ml-user+58265-122838...@n2.nabble.comml-user%2b58265-122838...@n2.nabble.com
wrote:
Do you have a DLL you could share that shows the problem?
Neil
-Original Message-
From: Roy Abou Assaly
[mailto:royass...@...http://n2.nabble.com/user/SendEmail.jtp?type=nodenode=2559601i=0]
Sent: 30 March 2009 21:02
To:
wix-us...@...http://n2.nabble.com/user/SendEmail.jtp?type=nodenode=2559601i=1
Subject: [WiX-users] Heat missing some RegistryValue elements
(Programmable) from VB6 code?
Hi,
I'm running heat (WiX 3.0.4923.0) to harvest some DLLs. I don't have
the version that I was using before, but I know it was working before I
had upgraded sometime in the Fall.
I noticed that Programmable is being ommitted:
RegistryValue Root=HKCR
Key=CLSID\{5A5DBDF3-10F1-43D1-AA51-CDE7EDFA0321}\Programmable Value=
Type=string Action=write /
This key existed in our December build, and now, in many more places in
the wix file for many DLLs, RegistryValue elements who's key is
Programmable are no longer there. I believe keys ending with Control
may also be affected. Is this related to this ticket?
http://sourceforge.net/tracker/?func=detailatid=642714aid=1888456grou
p_id=105970
Thanks,
Roy
--
View this message in context:
http://n2.nabble.com/Heat-missing-some-RegistryValue-elements-%28Program
mable%29-from-VB6-code--tp2559361p2559361.html
Sent from the wix-users mailing list archive at Nabble.com.
--
___
WiX-users mailing list
wix-us...@...http://n2.nabble.com/user/SendEmail.jtp?type=nodenode=2559601i=2
https://lists.sourceforge.net/lists/listinfo/wix-users
--
___
WiX-users mailing list
wix-us...@...http://n2.nabble.com/user/SendEmail.jtp?type=nodenode=2559601i=3
https://lists.sourceforge.net/lists/listinfo/wix-users
--
This email is a reply to your post @
http://n2.nabble.com/Heat-missing-some-RegistryValue-elements-%28Programmable%29-from-VB6-code--tp2559361p2559601.html
You can reply by email or by visting the link above.
--
View this message in context:
http://n2.nabble.com/Heat-missing-some-RegistryValue-elements-%28Programmable%29-from-VB6-code--tp2559361p2559657.html
Sent from the wix-users mailing list archive at Nabble.com.
--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Writing a Value for RegistryValue element of Type Binary
Hi, I have a registry key that is of type binary and has is a long series of numbers. When I export it from regedit, it looks like this: [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\FooBar\Security] Security=hex:01,00,14,80,90,... I'm having trouble expressing this inside the RegistryKey as: RegistryValue Type=binary Name=Security Value=01,00,... / But I keep getting the error: error LGHT0204 : ICE70: The value '#x01,00' is an invalid hexadecimal value for registry entry reg001E0C73C604AACC31F75D0 How do I express this correctly? Thanks, Roy -- View this message in context: http://n2.nabble.com/Writing-a-Value-for-RegistryValue-element-of-Type-Binary-tp2378965p2378965.html Sent from the wix-users mailing list archive at Nabble.com. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Writing a Value for RegistryValue element of Type Binary
On Tue, Feb 24, 2009 at 1:46 PM, Bob Arnson-6 (via Nabble)
ml-user+58260-683222...@n2.nabble.comml-user%2b58260-683222...@n2.nabble.com
wrote:
Roy Abou Assaly wrote:
RegistryValue Type=binary Name=Security Value=01,00,... /
But I keep getting the error:
error LGHT0204 : ICE70: The value '#x01,00' is an invalid hexadecimal
value
for registry entry reg001E0C73C604AACC31F75D0
How do I express this correctly?
The MSI doc doesn't say. I'd try removing the commas.
Value=00 01 gives:
error LGHT0204 : ICE70: The value '#x01 02' is an invalid hexadecimal value
for registry entry regA16537AC885C7B5BB23019846BB931C1.
Value=00;01 gives:
error LGHT0204 :ICE70: The value '#x01;02' is an invalid hexadecimal value
for registry entry regA16537AC885C7B5BB23019846BB931C1.
Value={01 02}
error LGHT0204 : ICE70: The value '#x{01 02}' is an invalid hexadecimal
value for registry entry regA16537AC885C7B5BB23019846BB931C1.
Hmmm...any other suggestions? If regedit expects a comma, is there some
character replacement for it that WiX would want?
--
View this message in context:
http://n2.nabble.com/Writing-a-Value-for-RegistryValue-element-of-Type-Binary-tp2378965p2379698.html
Sent from the wix-users mailing list archive at Nabble.com.
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Writing a Value for RegistryValue element of Type Binary
Bob Arnson-6 wrote:
Roy Abou Assaly wrote:
Value=00 01 gives:
error LGHT0204 : ICE70: The value '#x01 02' is an invalid hexadecimal
value
for registry entry regA16537AC885C7B5BB23019846BB931C1.
Value=00;01 gives:
error LGHT0204 :ICE70: The value '#x01;02' is an invalid hexadecimal
value
for registry entry regA16537AC885C7B5BB23019846BB931C1.
Value={01 02}
error LGHT0204 : ICE70: The value '#x{01 02}' is an invalid hexadecimal
value for registry entry regA16537AC885C7B5BB23019846BB931C1.
Hmmm...any other suggestions? If regedit expects a comma, is there some
character replacement for it that WiX would want?
WiX isn't complaining; the ICE validators are. Did you try no delimiters
at all? (RegEdit isn't authoritative.)
--
sig://boB
http://joyofsetup.com/
Suppressing the ICE070 validator gets me past that point. But when I try to
install, I get the following error message:
Could not write value SomeBinaryValue to key \SOFTWARE\Foo\Bar. Verify
that you have sufficient access to that key, or contact your support
personnel.
I obviously have access, so it looks like it doesn't like 00 01 or {00
01} or {01,02} or {01, 02} are working.
--
View this message in context:
http://n2.nabble.com/Writing-a-Value-for-RegistryValue-element-of-Type-Binary-tp2378965p2379918.html
Sent from the wix-users mailing list archive at Nabble.com.
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Writing a Value for RegistryValue element of Type Binary
Roy Abou Assaly wrote:
Bob Arnson-6 wrote:
Roy Abou Assaly wrote:
Value=00 01 gives:
error LGHT0204 : ICE70: The value '#x01 02' is an invalid hexadecimal
value
for registry entry regA16537AC885C7B5BB23019846BB931C1.
Value=00;01 gives:
error LGHT0204 :ICE70: The value '#x01;02' is an invalid hexadecimal
value
for registry entry regA16537AC885C7B5BB23019846BB931C1.
Value={01 02}
error LGHT0204 : ICE70: The value '#x{01 02}' is an invalid hexadecimal
value for registry entry regA16537AC885C7B5BB23019846BB931C1.
Hmmm...any other suggestions? If regedit expects a comma, is there some
character replacement for it that WiX would want?
WiX isn't complaining; the ICE validators are. Did you try no delimiters
at all? (RegEdit isn't authoritative.)
--
sig://boB
http://joyofsetup.com/
Suppressing the ICE070 validator gets me past that point. But when I try
to install, I get the following error message:
Could not write value SomeBinaryValue to key \SOFTWARE\Foo\Bar. Verify
that you have sufficient access to that key, or contact your support
personnel.
I obviously have access, so it looks like it doesn't like 00 01 or {00
01} or {01,02} or {01, 02} are working.
Just to be clear. It is NOT working. Forgot to proofread my post.
--
View this message in context:
http://n2.nabble.com/Writing-a-Value-for-RegistryValue-element-of-Type-Binary-tp2378965p2379981.html
Sent from the wix-users mailing list archive at Nabble.com.
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Writing a Value for RegistryValue element of Type Binary
Roy Abou Assaly wrote:
Roy Abou Assaly wrote:
Bob Arnson-6 wrote:
Roy Abou Assaly wrote:
Value=00 01 gives:
error LGHT0204 : ICE70: The value '#x01 02' is an invalid hexadecimal
value
for registry entry regA16537AC885C7B5BB23019846BB931C1.
Value=00;01 gives:
error LGHT0204 :ICE70: The value '#x01;02' is an invalid hexadecimal
value
for registry entry regA16537AC885C7B5BB23019846BB931C1.
Value={01 02}
error LGHT0204 : ICE70: The value '#x{01 02}' is an invalid hexadecimal
value for registry entry regA16537AC885C7B5BB23019846BB931C1.
Hmmm...any other suggestions? If regedit expects a comma, is there
some
character replacement for it that WiX would want?
WiX isn't complaining; the ICE validators are. Did you try no delimiters
at all? (RegEdit isn't authoritative.)
--
sig://boB
http://joyofsetup.com/
Suppressing the ICE070 validator gets me past that point. But when I try
to install, I get the following error message:
Could not write value SomeBinaryValue to key \SOFTWARE\Foo\Bar. Verify
that you have sufficient access to that key, or contact your support
personnel.
I obviously have access, so it looks like it doesn't like 00 01 or {00
01} or {01,02} or {01, 02} are working.
Just to be clear. It is NOT working. Forgot to proofread my post.
SOLUTION: You were right. My brain was stuck. No delimiter is the correct
way. My solution was some like this:
d RegistryValue Type=binary
Name=SomeBinaryValue
Value=0140032001c00010002801400ff010f0001010001020064001400fd0102000101000512001800ff010f00010200052000200214008d010200010100050b001800fd0102000102000520002302010100051200010100051200
KeyPath=yes/
Thanks for the help!
--
View this message in context:
http://n2.nabble.com/Writing-a-Value-for-RegistryValue-element-of-Type-Binary-tp2378965p2380024.html
Sent from the wix-users mailing list archive at Nabble.com.
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] COM Plus Applications and Major Upgrade
Neil Sleightholm wrote: Where do you have RemoveExistingProducts scheduled? Have you tried it after InstallValidate so that is removes everything before reinstalling. Neil Neil Sleightholm X2 Systems Limited n...@x2systems.com mailto:n...@x2systems.com From: Adam Burton [mailto:adz...@googlemail.com] Sent: Mon 09/02/2009 13:08 To: wix-users@lists.sourceforge.net Subject: [WiX-users] COM Plus Applications and Major Upgrade Hi, I have been working on an installer for a COM application. The installer contains a few .NET assemblies, with a couple configuration files and installs a COM application that uses the .NET assemblies (with the ComPlusExtension). Due to our development not being so strict I figured it would probably be easier if each install was a major upgrade than messing with minor and small. So to test this I generated the MSI and installed, all is well so far. Next I changed the product guid (ok well actually I had it set to '*' :-) ) and increased the version from 2.0.0.0 to 2.1.0.0 (both the steps I believe are required to initiate a major upgrade). I generated the MSI and attempted an install. During the install the installation complained a COM application with the specified id already existed, retry had no effect, so I tried ignore and the install completed successfully. I tried minor and small updates afterward just to confirm and they did not complain. So is there something I am missing when it comes to major upgrades and the ComPlusExtension? Or even just something I am missing with Major Upgrades in general? I tried this again 3.0.4805.0 and 3.0.5006.0, same result. Cheers, Adam -- I also do Major upgrades *all* the time. We have a large COM, COM+, VB6 application and I don't dare play games with COM+ registries as I value my time too much :P It's a requirement for us developers to move back and forth along the versions and I want to force uninstall our product regardless what version is installed. 1. I remove the product after InstallFinalize. This has worked for me for about 2 years now using WiX 2.0 and 3.0. InstallExecuteSequence RemoveExistingProducts After=InstallFinalize![CDATA[PREVIOUSVERSIONFOUND]]RemoveExistingProducts /InstallExecuteSequence 2. I set the version in the upgrade element as following: Upgrade Id=C4130B7E-C5F6-4C8D-8806-85D41DB873DC UpgradeVersion IncludeMinimum=yes Minimum=0.0.0.0 property=PREVIOUSVERSIONFOUND / /Upgrade Please note that the above will produce a warning in light - ICE61 (http://msdn.microsoft.com/en-us/library/aa369005(VS.85).aspx). I'm fully aware that by not setting a Maximum, and putting the minimum at 0, I ensure *all* versions are detected as previous versions and are uninstalled. You can use suppress this warning in command line interface option for light. Roy -- View this message in context: http://n2.nabble.com/COM-Plus-Applications-and-Major-Upgrade-tp2297098p2376186.html Sent from the wix-users mailing list archive at Nabble.com. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] COM Plus Applications and Major Upgrade
Don Benson wrote: I also do Major upgrades *all* the time. We have a large COM, COM+, VB6 application and I don't dare play games with COM+ registries as I value my time too much :P It's a requirement for us developers to move back and forth along the versions and I want to force uninstall our product regardless what version is installed. 1. I remove the product after InstallFinalize. This has worked for me for about 2 years now using WiX 2.0 and 3.0. InstallExecuteSequence RemoveExistingProducts After=InstallFinalize![CDATA[PREVIOUSVERSIONFOUND]]RemoveExisting Products /InstallExecuteSequence Are you using the ComPlus extension to manage the COM+ application(s). I have a similar line, except I am not putting a condition on the RemoveExistingProducts action. Sincerely, - Don Benson - Unfortunately not. We simply (and this was done before my time) export through the windows api. So from the COM+ catalog (i think that's the official name for dcomcnfg) after the COM+ are installed, we export and the MSI is produced. I personally don't like it as that export function doesn't produce the most robust MSI. However, it's very hard to justify rewriting what works, especially when there's 300+ COM plus DLLs. The part where we use WiX is for the client side app. We maintain the same GUID for every component in the .wxs file (UI DLL, ActiveX, EXEs, etc..there's about 130 something), and then harvest the DLLs using heat and use an XSLT to inject the harvested registry keys into our wxs file. The XSLT cleans up the harvest by removing any registry keys that are redundant. Sorry to go off topic, but yeah, try that condition and see how it changes the behaviour. My setup worked on XP and Vista. Not sure what OS you're using. -- View this message in context: http://n2.nabble.com/COM-Plus-Applications-and-Major-Upgrade-tp2297098p2376335.html Sent from the wix-users mailing list archive at Nabble.com. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] ClickThrough 3.0.4805.0 throws exception when selectiong Isolated Apps
Hi, I'm using the WiX Beta Exit build 3.0.4805.0. 1. I start ClickThrough 2. I select Click Through for Office Addins (shouldn't it be ClickThrough and Click Through? Typo?) 3. I get taken to the Build page with the 7 steps. Everything is good. Now, when 1. I start ClickThrough 2. I select Click Through for Isolated Applications (shouldn't it be ClickThrough and Click Through? Typo?) 3. An exception is thrown and I stay on the Welcome Page I had another colleague test it on his machine and he got the same exception. I'm using Windows Vista SP1. Any help is appreciated. Thanks, Roy See the end of this message for details on invoking just-in-time (JIT) debugging instead of this dialog box. ** Exception Text ** System.ArgumentException: Win32 handle that was passed to Icon is not valid or is the wrong type. at System.Drawing.Icon..ctor(IntPtr handle, Boolean takeOwnership) at System.Drawing.Icon..ctor(IntPtr handle) at System.Drawing.Icon.FromHandle(IntPtr handle) at Microsoft.Tools.WindowsInstallerXml.Extensions.ClickThrough.NativeMethods.GetDirectoryIcon(Boolean small, Boolean open) at Microsoft.Tools.WindowsInstallerXml.Extensions.ClickThrough.PickEntryStep..ctor() at Microsoft.Tools.WindowsInstallerXml.Extensions.IsolatedAppClickThroughUI.GetControls() at Microsoft.Tools.WindowsInstallerXml.Tools.ClickThrough.WorkPage.InitializeFromFabricator() at Microsoft.Tools.WindowsInstallerXml.Tools.ClickThrough.WorkPage.set_Extension(ClickThroughUIExtension value) at Microsoft.Tools.WindowsInstallerXml.Tools.ClickThrough.ClickThroughForm.ShowWorkPage(Object sender, ClickThroughUIExtension extension) at Microsoft.Tools.WindowsInstallerXml.Tools.ClickThrough.WelcomePage.ComboBox_SelectedIndexChanged(Object sender, EventArgs e) at System.Windows.Forms.ComboBox.OnSelectedIndexChanged(EventArgs e) at System.Windows.Forms.ComboBox.WmReflectCommand(Message m) at System.Windows.Forms.ComboBox.WndProc(Message m) at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message m) at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message m) at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam) ** Loaded Assemblies ** mscorlib Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.3053 (netfxsp.050727-3000) CodeBase: file:///C:/Windows/Microsoft.NET/Framework/v2.0.50727/mscorlib.dll ctui Assembly Version: 3.0.0.0 Win32 Version: 3.0.4805.0 CodeBase: file:///C:/Program%20Files/Windows%20Installer%20XML%20v3/bin/ctui.exe System.Windows.Forms Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.3053 (netfxsp.050727-3000) CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll System Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.3053 (netfxsp.050727-3000) CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll System.Drawing Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.3053 (netfxsp.050727-3000) CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll wui Assembly Version: 3.0.0.0 Win32 Version: 3.0.4805.0 CodeBase: file:///C:/Program%20Files/Windows%20Installer%20XML%20v3/bin/wui.DLL wix Assembly Version: 3.0.0.0 Win32 Version: 3.0.4805.0 CodeBase: file:///C:/Program%20Files/Windows%20Installer%20XML%20v3/bin/wix.DLL System.Configuration Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.3053 (netfxsp.050727-3000) CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Configuration/2.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll System.Xml Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.3053 (netfxsp.050727-3000) CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Xml/2.0.0.0__b77a5c561934e089/System.Xml.dll WixIsolatedAppExtension Assembly Version: 3.0.0.0 Win32 Version: 3.0.4805.0 CodeBase: file:///C:/Program%20Files/Windows%20Installer%20XML%20v3/bin/WixIsolatedAppExtension.DLL wconsole Assembly Version: 3.0.0.0 Win32 Version: 3.0.4805.0 CodeBase: file:///C:/Program%20Files/Windows%20Installer%20XML%20v3/bin/wconsole.DLL WixOfficeExtension Assembly Version: 3.0.0.0 Win32 Version: 3.0.4805.0 CodeBase: file:///C:/Program%20Files/Windows%20Installer%20XML%20v3/bin/WixOfficeExtension.DLL
Re: [WiX-users] ClickThrough 3.0.4805.0 throws exception when selectiong Isolated Apps
Rob Mensching-2 wrote: ClickThrough has significant bugs that have all been punted to WiX v4 essentially rendering ClickThrough useless until then. Thanks for the quick reply! -- View this message in context: http://n2.nabble.com/ClickThrough-3.0.4805.0-throws-exception-when-selectiong-Isolated-Apps-tp1639081p1639549.html Sent from the wix-users mailing list archive at Nabble.com. -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Uninstalling or Installing while an exe of the product is running errors
Hi, I was experimenting with an MSI packaged on Vista (WiX v 3.0.4207.0) and installed on Vista with some situations trying to figure out the behaviour: 1. Install Prism.msi version 10.61 C:\Windows\system32msiexec /i \\isdist01z\prism\Vista\Build_10.61.0\MSI\Prism.msi /q /l* C:\Prog ramData\House of Commons\Prism\PRISM.VB6.install.61.log 2. Launch Prism.exe version 10.61 3. Uninstall Prism.msi version 10.61 while foo.exe is running C:\Windows\system32msiexec /x \\isdist01z\prism\Vista\Build_10.61.0\MSI\Prism.msi /q /l* C:\Prog ramData\House of Commons\Prism\PRISM.VB6.uninstall.61.running.log Prism.exe simply hangs and says (Not Responding). I checked the eventvwr and got the following error messages in chronological order: 1. Starting session 1 - 2008/07/02 9:35:13 PM. 2. Application 'C:\Program Files\House Of Commons\PRISM Shell\PRISM.exe' (pid 4984) cannot be restarted - Application SID does not match Conductor SID.. 3. Machine restart is required. 4. Starting session 1 - 2008/07/02 9:35:14 PM. Here's the weird part. I did this at 5:35:14 pm and NOT 9:35:14pm. So the question is. Why am I off by 4 hours ahead? I live in Ottawa, Canada (EST) by the way which is UTC - 5. Also, what does Application SID does not match Conductor SID mean? Is there is a more gracefull way of doing silent installs of a product when the user is running the said product? Thanks! Here's the uninstall log file: === Logging started: 2008/07/02 17:35:13 === Action start 17:35:13: INSTALL. Action start 17:35:13: SystemFolder.B05A204B_CEB8_4A82_B515_ADFB4AE6965C. Action ended 17:35:13: SystemFolder.B05A204B_CEB8_4A82_B515_ADFB4AE6965C. Return value 1. Action start 17:35:13: ProgramFilesFolder.B05A204B_CEB8_4A82_B515_ADFB4AE6965C. Action ended 17:35:13: ProgramFilesFolder.B05A204B_CEB8_4A82_B515_ADFB4AE6965C. Return value 1. Action start 17:35:13: ProgramFilesFolder.C7AC8538_65ED_4C2B_AE16_6291871D0918. Action ended 17:35:13: ProgramFilesFolder.C7AC8538_65ED_4C2B_AE16_6291871D0918. Return value 1. Action start 17:35:13: ProgramMenuFolder.C7AC8538_65ED_4C2B_AE16_6291871D0918. Action ended 17:35:13: ProgramMenuFolder.C7AC8538_65ED_4C2B_AE16_6291871D0918. Return value 1. Action start 17:35:13: DesktopFolder.C7AC8538_65ED_4C2B_AE16_6291871D0918. Action ended 17:35:13: DesktopFolder.C7AC8538_65ED_4C2B_AE16_6291871D0918. Return value 1. Action start 17:35:13: FindRelatedProducts. Action ended 17:35:13: FindRelatedProducts. Return value 0. Action start 17:35:13: ValidateProductID. Action ended 17:35:13: ValidateProductID. Return value 1. Action start 17:35:13: CostInitialize. Action ended 17:35:13: CostInitialize. Return value 1. Action start 17:35:13: FileCost. Action ended 17:35:13: FileCost. Return value 1. Action start 17:35:13: CostFinalize. Action ended 17:35:13: CostFinalize. Return value 1. Action start 17:35:13: InstallValidate. Action ended 17:35:54: InstallValidate. Return value 1. Action start 17:35:54: InstallInitialize. Action ended 17:35:54: InstallInitialize. Return value 1. Action start 17:35:54: ProcessComponents. Action ended 17:35:55: ProcessComponents. Return value 1. Action start 17:35:55: UnpublishFeatures. Action ended 17:35:55: UnpublishFeatures. Return value 1. Action start 17:35:55: RemoveRegistryValues. Action ended 17:35:59: RemoveRegistryValues. Return value 1. Action start 17:35:59: RemoveShortcuts. Action ended 17:35:59: RemoveShortcuts. Return value 1. Action start 17:35:59: RemoveFiles. Action ended 17:35:59: RemoveFiles. Return value 0. Action start 17:35:59: InstallFiles. Action ended 17:35:59: InstallFiles. Return value 1. Action start 17:35:59: CreateShortcuts. Action ended 17:35:59: CreateShortcuts. Return value 1. Action start 17:35:59: WriteRegistryValues. Action ended 17:35:59: WriteRegistryValues. Return value 1. Action start 17:35:59: RegisterUser. Action ended 17:35:59: RegisterUser. Return value 0. Action start 17:35:59: RegisterProduct. Action ended 17:35:59: RegisterProduct. Return value 1. Action start 17:35:59: PublishFeatures. Action ended 17:35:59: PublishFeatures. Return value 1. Action start 17:35:59: PublishProduct. Action ended 17:35:59: PublishProduct. Return value 1. Action start 17:35:59: InstallFinalize. Info 1903. Scheduling reboot operation: Deleting file C:\Config.Msi\540af.rbf. Must reboot to complete operation. Info 1903. Scheduling reboot operation: Deleting file C:\Config.Msi\540b5.rbf. Must reboot to complete operation. Info 1903. Scheduling reboot operation: Deleting file C:\Config.Msi\540bc.rbf. Must reboot to complete operation. Info 1903. Scheduling reboot operation: Deleting file C:\Config.Msi\54102.rbf. Must reboot to complete operation. Info 1903. Scheduling reboot operation: Deleting file C:\Config.Msi\54118.rbf. Must reboot to complete operation. Info 1903. Scheduling reboot operation: Deleting file C:\Config.Msi\54129.rbf. Must reboot to complete operation. Action ended 17:36:19: InstallFinalize. Return value 1. Action ended 17:36:19:
Re: [WiX-users] Creating COM+ components using Wix 3.0
Fredrik Grohn-4 wrote: There is a custom action library to do COM+ registration in WiX. For v2 see the PubCA schema: http://wix.sourceforge.net/manual-wix2/pubca_xsd_index.htm I am on the road, so I don't have an example ready to send, but if you search the list archive there should be something. Thanks Fredrik. I'll be checking it out this week. Roy -- View this message in context: http://www.nabble.com/Creating-COM%2B-components-using-Wix-3.0-tp17808293p17864754.html Sent from the wix-users mailing list archive at Nabble.com. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Creating COM+ components using Wix 3.0
Roy Abou Assaly wrote: Hi, Some background: I'm trying to replace a legacy builder tool. The old builder tool compiled hundreds of vbp project files. Some ActiveX, some Exes, some Com+. The compilation was successful in NAnt. I also have created a WiX file that currently installs the UI DLLs and Exe and it works great on Windows XP and Vista. One task I'm getting worried about is for Com+ components, the old builder tool would compile them and install them on the build machine in Component Services, in COM+ Applications. We then would programmatically export them using the COM+ Application Export API to produce the MSIs. I used heat on the COM+ Server DLLs, but it didn't help me too much since it didn't specify that the DLL is a ComPlus component. I would like to eliminate this export task and go to a pure NAnt + WiX solution. Is this possible? If so, are there any tricks to automating the start? P.S. I'm using WiX 2.0 in production and it's been wonderful. I'm hoping WiX 3.0 will get me out of this jam. COM+ is not fun to play with. Thanks Guess nobody knows? Or nobody wants to near COM+ again? -- View this message in context: http://www.nabble.com/Creating-COM%2B-components-using-Wix-3.0-tp17808293p17822873.html Sent from the wix-users mailing list archive at Nabble.com. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Creating COM+ components using Wix 3.0
Hi, Some background: I'm trying to replace a legacy builder tool. The old builder tool compiled hundreds of vbp project files. Some ActiveX, some Exes, some Com+. The compilation was successful in NAnt. I also have created a WiX file that currently installs the UI DLLs and Exe and it works great on Windows XP and Vista. One task I'm getting worried about is for Com+ components, the old builder tool would compile them and install them on the build machine in Component Services, in COM+ Applications. We then would programmatically export them using the COM+ Application Export API to produce the MSIs. I used heat on the COM+ Server DLLs, but it didn't help me too much since it didn't specify that the DLL is a ComPlus component. I would like to eliminate this export task and go to a pure NAnt + WiX solution. Is this possible? If so, are there any tricks to automating the start? P.S. I'm using WiX 2.0 in production and it's been wonderful. I'm hoping WiX 3.0 will get me out of this jam. COM+ is not fun to play with. Thanks -- View this message in context: http://www.nabble.com/Creating-COM%2B-components-using-Wix-3.0-tp17808293p17808293.html Sent from the wix-users mailing list archive at Nabble.com. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] WiX build 3.0.4207 - missing mergmod.dll
Hi, I know I've seen a few blog posts about this and how it's been fixed in WiX v3, but that you're working on it for v2, but it seems to back in build 3.0.4207. I get the following message: light.exe : error LGHT0001 : Unable to load DLL 'mergemod.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E) Exception Type: System.DllNotFoundException Stack Trace: at Microsoft.Tools.WindowsInstallerXml.MergeMod.NativeMethods.MergeModGetClassObject(Guid clsid, Guid iid) at Microsoft.Tools.WindowsInstallerXml.MergeMod.NativeMethods.GetMsmMerge() at Microsoft.Tools.WindowsInstallerXml.Binder.ProcessMergeModules(Output output, FileRowCollection fileRows) at Microsoft.Tools.WindowsInstallerXml.Binder.BindDatabase(Output output, String data baseFile) at Microsoft.Tools.WindowsInstallerXml.Binder.Bind(Output output, String file) at Microsoft.Tools.WindowsInstallerXml.Tools.Light.Run(String[] args) Binder temporary directory located at 'C:\Users\me\AppData\Local\Temp\khxhpgly'. Validator temporary directory located at 'C:\Users\me\AppData\Local\Temp\i6vv_t07'. Where can I get my hands on this magical DLL and where should I put it. Thanks! -- View this message in context: http://www.nabble.com/WiX-build-3.0.4207---missing-mergmod.dll-tp17782619p17782619.html Sent from the wix-users mailing list archive at Nabble.com. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiX build 3.0.4207 - missing mergmod.dll
Lucky me. I found this post by Bob: http://www.joyofsetup.com/2008/06/09/wix-v2-needs-fixed-mergemoddll-too/ So I downloaded the zip file for build 3.0.4207.0 (http://wix.sourceforge.net/releases/3.0.4207.0/) and took the mergmod.dll from there and copied it. So it looks like the binaries in the zip file have mergemod.dll, but the MSI file doesn't. Only the mergmod.cub file is in the MSI file. The mergemod.dll file that copied from the binaries zip file is 3.0.3790.371 -- View this message in context: http://www.nabble.com/WiX-build-3.0.4207---missing-mergmod.dll-tp17782619p17782786.html Sent from the wix-users mailing list archive at Nabble.com. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiX build 3.0.4207 - missing mergmod.dll
Bob Arnson-6 wrote: Roy Abou Assaly wrote: Lucky me. I found this post by Bob: http://www.joyofsetup.com/2008/06/09/wix-v2-needs-fixed-mergemoddll-too/ So I downloaded the zip file for build 3.0.4207.0 (http://wix.sourceforge.net/releases/3.0.4207.0/) and took the mergmod.dll from there and copied it. So it looks like the binaries in the zip file have mergemod.dll, but the MSI file doesn't. Only the mergmod.cub file is in the MSI file. The mergemod.dll file that copied from the binaries zip file is 3.0.3790.371 See also http://www.joyofsetup.com/2008/05/27/the-case-of-the-missing-mergemoddll-in-wix-v304123/. Aaah. That explains it. Thanks for the prompt reply Bob! -- sig://boB http://joyofsetup.com/ - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- View this message in context: http://www.nabble.com/WiX-build-3.0.4207---missing-mergmod.dll-tp17782619p17783210.html Sent from the wix-users mailing list archive at Nabble.com. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Vista registry virtualization
Simon Topley wrote: We have recently been having issues with our COM interface and the finger was pointed at the installers as ever. It seems in vista being logged in as an Administrator doesn't mean what it once did. Most programs are run by default as a user, you have to right click and run as administrator then sign you name in blood and answer a phone in central park within 5 minutes. When our software is run by a user it uses some other virtual store hive that obviously doesn't contain the COM registration for our product. All is well if you run as administrator. ... I suspect that I am registering the interfaces incorrectly. I'm adding all of the details manually (CLSID, TYPELIB blah blah blah) maybe there is a COM registration component I'm not aware of that would take care of this. If not then I'm not sure where the fix should be, should I be adding this data to the registry with different permission levels or is the problem in the software in the way we read from the registry (with a KEY_READ which gets no redirection or KEY_ALL_ACCESS which gets the redirection and make KEY_READ kind of pointless) Hi, Even though you are local admin on your machine, the process must be elevated. For MSI, you get prompted for the elevation (correct me if I'm wrong). However, If you run any other process that attempts to register those DLLs without elevation, then the keys get registered in the virtual store. I highly recommend you delete any entries in your virtual store that are related to your current installation because the virtualstore takes precedence over the real entries. For example, You register x.dll without enough privilege It gets registered to your virtualstore x.dll gets updated You register x.dll *with* privilege It get registered to your HKLM. When your app runs, it will reference your virtualstore and never touch HKLM. solution: delete the entry in your virtualstore and your HKLM will be referenced. That's what I found from my experience. So be aware that if anything gets installed without enough privilege, you have to go and clean up that mess. I've struggled without migration to Vista, and so that was one of the lessons I learned. Good luck. Roy -- View this message in context: http://www.nabble.com/Vista-registry-virtualization-tp15824051p15854551.html Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiX v3: COM on Vista. I have some success, but worried about heat's erroneous output
John Hall-9 wrote:
I've been reading more about heat, vb6 and vista. I'm now
starting to get worried that there's a potential difference
between running Heat on Vista versus XP. And yes, you do
need to run as Admin, and elevated for Heat to actually
extract anything. Also, Should I be deleting all the
registry entries that refer to the VB Virtual Machine Runtime
DLL...I forget the exact key, but it references
c:\windows\system32 ... MSVBRuntime(forgot name).dll.
I remove the following:
1. The VB runtime CLSID: {D5DE8D20-5BB8-11D1-A1E3-00A0C90F2731}
2. The two VB typelibs: {EA544A21-C82D-11D1-A3E4-00A0C90AEA82} and
{000204EF---C000-0046}.
3. All interfaces that reference either of the typelibs.
Hi John,
To do the above 3 things, would've meant editing about 5000 lines out of my
25000 line file. I'm not an XSL wiz by any standard, but I came up with
this solution:
* Create XSLT file that processes the above 3 GUIDS and simply removes the
element where the attribute value contains or is the GUID in question.
* Open it up with Notepadd++ and use the friendly Macro Remove Blank Lines
for that blank lines that the XSLT processing leaves behind.
I downloaded MSXSL command line utility from Microsoft
(http://www.microsoft.com/downloads/details.aspx?FamilyID=2FB55371-C94E-4373-B0E9-DB4816552E41displaylang=en)
To use it, in a command prompt: D:\msxsl Original.wxs Cleanup.xslt -o
NiceAndClean.xml
I'm including my XSLT file (Cleanup.xslt) in case anybody else wants to use
it:
Cleanup.xsl
==
?xml version=1.0?
xsl:stylesheet xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
version=1.0
!-- stylesheet output --
xsl:output method=xml omit-xml-declaration=no /
!-- Root template. --
xsl:template match=/
xsl:apply-templates/
/xsl:template
!-- Identity copy of all processing-instructions. --
xsl:template match=comment()|processing-instruction()
xsl:copy /
/xsl:template
!-- Identity copy of all elements. --
xsl:template match=*
xsl:copy
xsl:apply-templates select=@*/
xsl:apply-templates/
/xsl:copy
/xsl:template
!-- Identity copy of all attributes. --
xsl:template match=@*
xsl:copy-of select=./
/xsl:template
!-- Remove all the elements that contain the following attributes: --
xsl:template
match=[EMAIL
PROTECTED]'{D5DE8D20-5BB8-11D1-A1E3-00A0C90F2731}']/xsl:template
xsl:template
match=[EMAIL
PROTECTED]'{EA544A21-C82D-11D1-A3E4-00A0C90AEA82}']/xsl:template
xsl:template
match=[EMAIL
PROTECTED]'{000204EF---C000-0046}']/xsl:template
xsl:template
match=[EMAIL
PROTECTED]'Software\Classes\TypeLib\{EA544A21-C82D-11D1-A3E4-00A0C90AEA82}\6.0\9\win32']/xsl:template
xsl:template
match=[EMAIL
PROTECTED]'Software\Classes\TypeLib\{EA544A21-C82D-11D1-A3E4-00A0C90AEA82}\6.0\FLAGS']/xsl:template
xsl:template
match=[EMAIL
PROTECTED]'Software\Classes\TypeLib\{EA544A21-C82D-11D1-A3E4-00A0C90AEA82}\6.0\HELPDIR']/xsl:template
xsl:template
match=[EMAIL
PROTECTED]'Software\Classes\TypeLib\{EA544A21-C82D-11D1-A3E4-00A0C90AEA82}\6.0']/xsl:template
xsl:template
match=[EMAIL
PROTECTED]'Software\Classes\TypeLib\{000204EF---C000-0046}\6.0\9\win32']/xsl:template
xsl:template
match=[EMAIL
PROTECTED]'Software\Classes\TypeLib\{000204EF---C000-0046}\6.0\FLAGS']/xsl:template
xsl:template
match=[EMAIL
PROTECTED]'Software\Classes\TypeLib\{000204EF---C000-0046}\6.0\HELPDIR']/xsl:template
xsl:template
match=[EMAIL
PROTECTED]'Software\Classes\TypeLib\{000204EF---C000-0046}\6.0']/xsl:template
/xsl:stylesheet
--
View this message in context:
http://www.nabble.com/WiX-v3%3A-COM-on-Vista.--I-have-some-success%2C-but-worried-about-heat%27s-erroneous-output.-tf4510373.html#a12890714
Sent from the wix-users mailing list archive at Nabble.com.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] WiX v3: COM on Vista. I have some success, but worried about heat's erroneous output.
I basically have about 150 COM, ActiveX VB6 files. I ran heat to produce the
output and then modified them to produce 2 merge modules. I used heat to
avoid using the SelfRegCost attribute which as been frowned upon by many
here. I read Rob's blog about that :)
I ran into 2 warnings which were ICE33 and ICE82. I scoured the archive and
was able to find that I can safely ignore the ICE33 and ICE82 warnings. I
ran ORCA as well just to be safe which is why ICE33 showed up since I later
realized that WiX suppresses it by default.
examples are:
light.exe: warning LGHT1076 : ICE82: This action
ProgramMenuFolder.C7AC8538_65ED_4C2B_AE16_6291871D0918 has duplicate
sequence number 2 in the table InstallExecuteSequence
orca.exe: ICE33 WARNING Reg key reg7EF074BB025A80CBFE2087521879C64E is
used in an unsupported way. ProgId should be registered via the ProgId
table. This entry may overwrite a value created through that table.
After ignoring those 2 warning, I then proceeded to build my MSI and ran
into 2 more errors that were output by candle:
1. RequiredFiles.wxs(81) : error CNDL0010 : The Class/@Context attribute was
not found; it is required
when attribute {3E28E9C7-A265-41D6-B6EA-132B62605C75} is specified.
2. RequiredFiles.wxs(81) : error CNDL0010 : The Class/@Server attribute was
not found; it is required.
Initially, the entry looked like this:
Class Id={479066AE-099A-41CB-80F2-A54BD8E891EF} Description=Contains a
List a ValueItem objects. Version=1.1
ProgId Id=GridEX20.JSValueList Description=Contains a List a
ValueItem objects. /
/Class
To solve 1, I added the attribute Context=InprocServer32 into the Class
element:
To solve 2, I added the attribute Server=NameOfDll.dll into the Class
element:
Class Id={479066AE-099A-41CB-80F2-A54BD8E891EF} Context=InprocServer32
Server=GridEX20.ocx Description=Contains a List a ValueItem objects.
Version=1.1
ProgId Id=GridEX20.JSValueList Description=Contains a List a
ValueItem objects. /
/Class
After doing all that, I ran into one more problem that involved ActiveX
DLLs. The error I got was a couple of times for the various ActiveX DLLs
and was produced by light:
RequiredFiles.wxs(500) : error LGHT0130 : The primary key
regB69CCE91B63112D0023E330FD9CCE948.B05A
204B_CEB8_4A82_B515_ADFB4AE6965C' is duplicated in table 'Registry'. Please
remove one of the entries or rename a part of the primary key to avoid the
collision.
I didn't quite understand this. The line it referred to was this:
Class Id={D5DE8D20-5BB8-11D1-A1E3-00A0C90F2731} Context=InprocServer32
Server=GridEX20.ocx Description=VBPropertyBag ThreadingModel=apartment
/
I commented the line out and error was gone, but I have to admit I don't
know what I did!! Can someone please shed some light on this? I really
don't want to use SelfRegCost and take the easy way out ;)
--
View this message in context:
http://www.nabble.com/WiX-v3%3A-COM-on-Vista.--I-have-some-success%2C-but-worried-about-heat%27s-erroneous-output.-tf4510373.html#a12863906
Sent from the wix-users mailing list archive at Nabble.com.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiX v3: COM on Vista. I have some success, but worried about heat's erroneous output.
Roy Abou Assaly wrote:
I basically have about 150 COM, ActiveX VB6 files. I ran heat to produce
the output and then modified them to produce 2 merge modules. I used heat
to avoid using the SelfRegCost attribute which as been frowned upon by
many here. I read Rob's blog about that :)
I ran into 2 warnings which were ICE33 and ICE82. I scoured the archive
and was able to find that I can safely ignore the ICE33 and ICE82
warnings. I ran ORCA as well just to be safe which is why ICE33 showed up
since I later realized that WiX suppresses it by default.
examples are:
light.exe: warning LGHT1076 : ICE82: This action
ProgramMenuFolder.C7AC8538_65ED_4C2B_AE16_6291871D0918 has duplicate
sequence number 2 in the table InstallExecuteSequence
orca.exe: ICE33 WARNING Reg key reg7EF074BB025A80CBFE2087521879C64E is
used in an unsupported way. ProgId should be registered via the ProgId
table. This entry may overwrite a value created through that table.
After ignoring those 2 warning, I then proceeded to build my MSI and ran
into 2 more errors that were output by candle:
1. RequiredFiles.wxs(81) : error CNDL0010 : The Class/@Context attribute
was not found; it is required
when attribute {3E28E9C7-A265-41D6-B6EA-132B62605C75} is specified.
2. RequiredFiles.wxs(81) : error CNDL0010 : The Class/@Server attribute
was not found; it is required.
Initially, the entry looked like this:
Class Id={479066AE-099A-41CB-80F2-A54BD8E891EF} Description=Contains a
List a ValueItem objects. Version=1.1
ProgId Id=GridEX20.JSValueList Description=Contains a List a
ValueItem objects. /
/Class
To solve 1, I added the attribute Context=InprocServer32 into the Class
element:
To solve 2, I added the attribute Server=NameOfDll.dll into the Class
element:
Class Id={479066AE-099A-41CB-80F2-A54BD8E891EF}
Context=InprocServer32 Server=GridEX20.ocx Description=Contains a
List a ValueItem objects. Version=1.1
ProgId Id=GridEX20.JSValueList Description=Contains a List a
ValueItem objects. /
/Class
After doing all that, I ran into one more problem that involved ActiveX
DLLs. The error I got was a couple of times for the various ActiveX DLLs
and was produced by light:
RequiredFiles.wxs(500) : error LGHT0130 : The primary key
regB69CCE91B63112D0023E330FD9CCE948.B05A
204B_CEB8_4A82_B515_ADFB4AE6965C' is duplicated in table 'Registry'.
Please remove one of the entries or rename a part of the primary key to
avoid the collision.
I didn't quite understand this. The line it referred to was this:
Class Id={D5DE8D20-5BB8-11D1-A1E3-00A0C90F2731}
Context=InprocServer32 Server=GridEX20.ocx Description=VBPropertyBag
ThreadingModel=apartment /
I commented the line out and error was gone, but I have to admit I don't
know what I did!! Can someone please shed some light on this? I really
don't want to use SelfRegCost and take the easy way out ;)
I've been reading more about heat, vb6 and vista. I'm now starting to get
worried that there's a potential difference between running Heat on Vista
versus XP. And yes, you do need to run as Admin, and elevated for Heat to
actually extract anything. Also, Should I be deleting all the registry
entries that refer to the VB Virtual Machine Runtime DLL...I forget the
exact key, but it references c:\windows\system32 ... MSVBRuntime(forgot
name).dll.
Perhaps there's a list of things that should be deleted..as in, after heat
produces the output, we need to do the following steps:
1. Ignore ICE82
2. Delete anything related to the VB Runtime DLL, etc.
3. Run Smoke, ORCA, etc..
Any help would be appreciated as our migration to Vista is proving to be
painstakingly difficult. I'm almost there, I'd just like to this clean up
now while I'm in development, rather than later when the product goes out
for testing.
Roy
--
View this message in context:
http://www.nabble.com/WiX-v3%3A-COM-on-Vista.--I-have-some-success%2C-but-worried-about-heat%27s-erroneous-output.-tf4510373.html#a12872113
Sent from the wix-users mailing list archive at Nabble.com.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] msbuild nant task and WiX
I use NAnt to call in a similar fashion but add some more options since I'm
paranoid. I also have NAnt version my WiX file on the fly using the
XMLPoke task after I've built my project. To clarify, I use WiX v2:
!-- Create the MSI executable. We are using the WiX toolset to do
this.
--
target name=msi
!-- First, we compile the WiX XML file. Second, we link the
WiX object
file so that we get an MSI executable file. --
exec program=candle workingdir=${project.build.dir}
commandline=-v0
-w0 -trace -pedantic:legendary ${project.wixfilename}.wxs/
exec program=light workingdir=${project.build.dir}
commandline=-v0
-w0 -trace -pedantic:legendary ${project.wixfilename}.wixobj/
/target
Lerudjordet, Morten Minge wrote:
In you'r msbuild file you can do something like this.
Target Name=MakeMSI
Exec Command=candle.exe -out DestOfWiXObjFiles\Product.wixobj
Product.wxs/Exec
Exec Command=light.exe -out DestFolderOfMSI\MyProdctName.msi
Product.wixobj +ALL OTHER WIXOBJ files you need -loc
WixUI_en-us.wxl/Exec
/Target
Target Name=MakeSetup DependsOnTargets=GenerateConfig;MakeMSI
/Target
morten
Message: 5
Date: Mon, 6 Nov 2006 13:18:36 -
From: Pawel Pabich [EMAIL PROTECTED]
Subject: [WiX-users] msbuild nant task and WiX
To: wix-users@lists.sourceforge.net
Message-ID:
[EMAIL PROTECTED]
Content-Type: text/plain; charset=us-ascii
Hi,
What is the easiest way of being able to build my WiX installer project
taking into account
that I'm using msbuild task to build my solution?
Thanks
Pawel Pabich
-- next part --
An HTML attachment was scrubbed...
URL:
http://sourceforge.net/mailarchive/forum.php?forum=wix-users/attachments
/20061106/1413cde3/attachment.html
--
Message: 6
Date: Mon, 6 Nov 2006 14:20:58 +0100
From: Friedrich, Oliver [EMAIL PROTECTED]
Subject: Re: [WiX-users] preprocessor variable $(var.Build)
To: wix-users@lists.sourceforge.net
Message-ID: [EMAIL PROTECTED]
Content-Type: text/plain; charset=us-ascii
Alright, just found out, where this variable was set. It is set on the
commandline while calling the batch-file to start the compilation of the
setup.
The batch-file is called as Pre-build event command line in VS2005.
The variable var.Build is set to the value of $(ConfigurationName).
The last is homemade of VisualStudio. How can I access this
ConfigurationName under WiX-V3?
Sorry for the trouble...
Oliver
From: Bob Arnson [mailto:[EMAIL PROTECTED]
Sent: Friday, November 03, 2006 6:04 PM
To: Friedrich, Oliver
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] preprocessor variable $(var.Build)
Friedrich, Oliver wrote:
No, we did not use Votive V2, just plain wxs-files that
we added to a simple solution, we did not use Votive V2.
Sorry, I'm not understanding. Are you asking how to set the
Build variable using Votive?
--
sig://boB
http://bobs.org
-- next part --
An HTML attachment was scrubbed...
URL:
http://sourceforge.net/mailarchive/forum.php?forum=wix-users/attachments
/20061106/70c1b015/attachment.html
--
-
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=lnkkid=120709bid=263057dat=121642
--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
End of WiX-users Digest, Vol 6, Issue 21
-
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=lnkkid=120709bid=263057dat=121642
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
View this message in context:
http://www.nabble.com/%3Cmsbuild%3E-nant-task-and-WiX-tf2582295.html#a7206871
Sent from the wix-users mailing list archive at Nabble.com.
-
Using Tomcat but need to do more? Need to support web services,
[WiX-users] UCS-2 Little Endian encoding of MSI Log file problem.
When I install an msi, I am keeping a log like so: c:\msiexec /i foo.msi /l* foo.log The problems is that when I open foo.log, it turns out it's in UCS-2 Little Endian encoding. Chaning the encoding in .NET is trivial, but we have a legacy app that needs to append to the log file, and it's in VB6. I'm having quite a bit of trouble converting the file to ASCII from UCS-2 Little Endian. Without the conversion, the file gets mangled with garbage. Is there a particular reason why UCS-2 Little Endian is used to create the MSI log file? I don't think VB6 has the programmatic capacity to natively read such an encodingI'm googling a solution now :-/ -- View this message in context: http://www.nabble.com/UCS-2-Little-Endian-encoding-of-MSI-Log-file-problem.-tf2292707.html#a6368349 Sent from the wix-users mailing list archive at Nabble.com. - 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=lnkkid=120709bid=263057dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] UCS-2 Little Endian encoding of MSI Log file problem.
Solution: Someone replied...the answer was to use the MultiByteToWideChar function to convert from ANSI to UCS-2 before appending to the file. Thanks! Roy Abou Assaly wrote: When I install an msi, I am keeping a log like so: c:\msiexec /i foo.msi /l* foo.log The problems is that when I open foo.log, it turns out it's in UCS-2 Little Endian encoding. Chaning the encoding in .NET is trivial, but we have a legacy app that needs to append to the log file, and it's in VB6. I'm having quite a bit of trouble converting the file to ASCII from UCS-2 Little Endian. Without the conversion, the file gets mangled with garbage. Is there a particular reason why UCS-2 Little Endian is used to create the MSI log file? I don't think VB6 has the programmatic capacity to natively read such an encodingI'm googling a solution now :-/ -- View this message in context: http://www.nabble.com/UCS-2-Little-Endian-encoding-of-MSI-Log-file-problem.-tf2292707.html#a6371589 Sent from the wix-users mailing list archive at Nabble.com. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Launching program after installation completes gives occassional error. (Roy Abou Assaly)
Date: Thu, 31 Aug 2006 10:32:18 -0400
From: Roy Abou Assaly [EMAIL PROTECTED]
Subject: [WiX-users] Launching program after installation completen
giveoccassional error.
I don't know if this is my fault or not. At the end of tte
installation, we have a checkbox which is by default on, such that
when the user clicks 'Finish', the program that he just installed,
launches. I *sometimes* get the following error in my Application
eventlog in the following chronological order:
FIRST (ERROR):
Product: FOO.NET Development -- The installer has encountered an
unexpected error installing this package. This may indicate a problem
with this package. The error code is 2753. The arguments are: file58,
,
SECOND (WARNING):
-
Detection of product '{CC30DEFD-A923-419C-A20C-77C9621BF6FD}', feature
'DefaultFeature', component '{FE33C480-C05B-40A0-BF9C-A196CDE97544}'
failed. The resource 'C:\Program Files\My Application\FOO.NET
Development\FOO.NET.Development.exe' does not exist.
THIRD (WARNING):
-
Detection of product '{CC30DEFD-A923-419C-A20C-77C9621BF6FD}', feature
'DefaultFeature' failed during request for component
'{FE33C480-C05B-40A0-BF9C-A196CDE97544}'
The WiX XML is the following:
DECLARATION:
---
Component Id=component58
Guid=FE33C480-C05B-40A0-BF9C-A196CDE97544 DiskId=1
File Id=file58 Name=foo.exe
LongName=FOO.NET.Development.exe src=FOO.NET.Development.exe
KeyPath=yes
Shortcut Id=ProgramShortcut
Directory=ProgramMenuDir Name=FOO.NET LongName=FOO.NET
Development Target=DefaultFeature Show=normal
WorkingDirectory=INSTALLDIR /
/File
/Component
UI:
Control Id=Launch Type=CheckBox X=140 Y=120
Width=10 Height=10 Property=LAUNCHPRODUCT CheckBoxValue=1
/Control
Control Id=LaunchText Type=Text X=154 Y=120
Width=220 Height=20 Transparent=yes NoPrefix=yes
TextLaunch ![CDATA[[ProductName] [ProductVersion]]]/Text
/Control
/Dialog
/UI
BACKEND:
CustomAction Id=LaunchFile FileKey=file58 ExeCommand=
Return=asyncNoWait /
InstallUISequence
Show Dialog=ProgressDlg After=MigrateFeatureStates /
Show Dialog=ExitDlg OnExit=successNOT Installed/Show
/InstallUISequence
InstallExecuteSequence
RemoveExistingProducts
Before=InstallValidate![CDATA[PREVIOUSVERSIONFOUND]]/RemoveExistingProducts
/InstallExecuteSequence
Any help would be greatly appreciated. And like I said, it's like 1/5
odds that we get this error. I simply click OK on the error, and
launch the program manually, at which point, the MSI GUI with only the
progress bar comes, does something, and then program launches and
everyone lives happily ever after...until then next autoupdated is
detected.
Roy
So nobody sees anything wrong there? How about the BACKEND portion.
Does the squence contain anything fishy? Again, this is an
intermittent bug.
Roy
-
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=lnkkid=120709bid=263057dat=121642
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Launching program after installation completen give occassional error.
I don't know if this is my fault or not. At the end of tte
installation, we have a checkbox which is by default on, such that
when the user clicks 'Finish', the program that he just installed,
launches. I *sometimes* get the following error in my Application
eventlog in the following chronological order:
FIRST (ERROR):
Product: FOO.NET Development -- The installer has encountered an
unexpected error installing this package. This may indicate a problem
with this package. The error code is 2753. The arguments are: file58,
,
SECOND (WARNING):
-
Detection of product '{CC30DEFD-A923-419C-A20C-77C9621BF6FD}', feature
'DefaultFeature', component '{FE33C480-C05B-40A0-BF9C-A196CDE97544}'
failed. The resource 'C:\Program Files\My Application\FOO.NET
Development\FOO.NET.Development.exe' does not exist.
THIRD (WARNING):
-
Detection of product '{CC30DEFD-A923-419C-A20C-77C9621BF6FD}', feature
'DefaultFeature' failed during request for component
'{FE33C480-C05B-40A0-BF9C-A196CDE97544}'
The WiX XML is the following:
DECLARATION:
---
Component Id=component58
Guid=FE33C480-C05B-40A0-BF9C-A196CDE97544 DiskId=1
File Id=file58 Name=foo.exe
LongName=FOO.NET.Development.exe src=FOO.NET.Development.exe
KeyPath=yes
Shortcut Id=ProgramShortcut
Directory=ProgramMenuDir Name=FOO.NET LongName=FOO.NET
Development Target=DefaultFeature Show=normal
WorkingDirectory=INSTALLDIR /
/File
/Component
UI:
Control Id=Launch Type=CheckBox X=140 Y=120
Width=10 Height=10 Property=LAUNCHPRODUCT CheckBoxValue=1
/Control
Control Id=LaunchText Type=Text X=154 Y=120
Width=220 Height=20 Transparent=yes NoPrefix=yes
TextLaunch ![CDATA[[ProductName] [ProductVersion]]]/Text
/Control
/Dialog
/UI
BACKEND:
CustomAction Id=LaunchFile FileKey=file58 ExeCommand=
Return=asyncNoWait /
InstallUISequence
Show Dialog=ProgressDlg After=MigrateFeatureStates /
Show Dialog=ExitDlg OnExit=successNOT Installed/Show
/InstallUISequence
InstallExecuteSequence
RemoveExistingProducts
Before=InstallValidate![CDATA[PREVIOUSVERSIONFOUND]]/RemoveExistingProducts
/InstallExecuteSequence
Any help would be greatly appreciated. And like I said, it's like 1/5
odds that we get this error. I simply click OK on the error, and
launch the program manually, at which point, the MSI GUI with only the
progress bar comes, does something, and then program launches and
everyone lives happily ever after...until then next autoupdated is
detected.
Roy
-
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=lnkkid=120709bid=263057dat=121642
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
