[WiX-users] Checking for duplicate entry in a table
In a Compiler Extension that we are currently using, we are inserting records into a few custom tables as well as the Binary table. During the execution of that compiler extension, is there a way to check for an existing entry before adding the new record so duplicate entries don't occur? -- View this message in context: http://www.nabble.com/Checking-for-duplicate-entry-in-a-table-tf2377905.html#a6626101 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
[WiX-users] NTFS permissions for the Users Group
Hi Can anyone point me at how to add permissions to the windows temp folder for the Local Users group. I guess I need to know how I add permissions for a group to a folder Im not creating as part of my installer generally. - 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
[WiX-users] CustomTableRef?
With FragmentRef deprecated, is there a supported mechanism for sucking in a CustomTable and associated data from an external file? How about storing data and schema separately (so that developer X can add data rows, but cant muck with my table schema)? Thanks! - 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
[WiX-users] Multiple DLLs into GAC
I have more than a dozen DLLs that I need to install into the GAC. Ive learned how to install a file by merely adding the Assembly=.net attribute. This attribute requires the KeyPath=yes to be there as well. Is there an easy way to install multiple DLLs or do I have to create a component for each DLL? __ Doug Watts - 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
[WiX-users] Calling a CustomAction defined in an MSM.
WiX Users, I have an MSM that defines a set of CustomAction entries. The MSM is merged into the MSI, and it is my responsibility to execute the MSM's custom actions. Unfortunately when I compile my project, light rightly complains: C:\xxx\yyy.xml : error LGHT0112 : Unresolved reference to symbol 'CustomAction:foo' in section 'Product:12345678-1234-1234-1234-123456789012'. It would seem that the CutomAction's in an MSM are not available from the MSI? It is essentially this issue: [ 1541952 ] Unresolved Reference error when using CA declared in MSM The original response seems to be: You cannot create references from products into merge modules. Why is this the case? Is someone able to clarify why products can't reference or call custom actions in merge modules? Any guidance is much appreciated. Cheers, Carlos. - 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
[WiX-users] Wix3.msi build 3.0.2128.0 doesn't recognize VS 2005 properly
Hi,
I'm trying to install Wix3.msi to my computer. Installation succeeds
and but wix projects doesn't work in Visual Studio 2005 Professional.
Some of VS2005 properties seems to point D:\ directory.
Property(C): VS2005PROJECTAGGREGATOR2 = C:\Program Files\Microsoft
Visual Studio 8\Common7\IDE\
Property(C): VS2005_ITEMTEMPLATES_DIR = D:\
Property(C): VS2005_PROJECTTEMPLATES_DIR = D:\
Property(C): VS2005_SCHEMAS_DIR = C:\Program Files\Microsoft Visual
Studio 8\Xml\Schemas\
Property(C): VS2005DEVENV = C:\Program Files\Microsoft Visual Studio
8\Common7\IDE\devenv.exe
Is there something wrong with my VS 2005 installation or in the
wix3.msi? MSI verbose log included below.
Best Regards, Antti
---
=== Verbose logging started: 2.10.2006 15:14:07 Build type: SHIP
UNICODE 3.01.4000.2435 Calling process:
C:\WINDOWS\system32\msiexec.exe ===
MSI (c) (AC:8C) [15:14:07:193]: Resetting cached policy values
MSI (c) (AC:8C) [15:14:07:193]: Machine policy value 'Debug' is 0
MSI (c) (AC:8C) [15:14:07:193]: *** RunEngine:
*** Product: Wix3.msi
*** Action:
*** CommandLine: **
MSI (c) (AC:8C) [15:14:07:273]: Machine policy value 'DisableUserInstalls' is 0
MSI (c) (AC:8C) [15:14:07:613]: SOFTWARE RESTRICTION POLICY: Verifying
package -- 'C:\Documents and
Settings\antti.jarvinen\Desktop\Wix3.msi' against software restriction
policy
MSI (c) (AC:8C) [15:14:07:613]: Note: 1: 2262 2: DigitalSignature 3:
-2147287038
MSI (c) (AC:8C) [15:14:07:613]: SOFTWARE RESTRICTION POLICY:
C:\Documents and Settings\antti.jarvinen\Desktop\Wix3.msi is not
digitally signed
MSI (c) (AC:8C) [15:14:07:623]: SOFTWARE RESTRICTION POLICY:
C:\Documents and Settings\antti.jarvinen\Desktop\Wix3.msi is permitted
to run at the 'unrestricted' authorization level.
MSI (c) (AC:8C) [15:14:07:693]: Cloaking enabled.
MSI (c) (AC:8C) [15:14:07:693]: Attempting to enable all disabled
priveleges before calling Install on Server
MSI (c) (AC:8C) [15:14:07:703]: End dialog not enabled
MSI (c) (AC:8C) [15:14:07:703]: Original package == C:\Documents and
Settings\antti.jarvinen\Desktop\Wix3.msi
MSI (c) (AC:8C) [15:14:07:703]: Package we're running from ==
C:\DOCUME~1\ANTTI~1.JAR\LOCALS~1\Temp\389d5.msi
MSI (c) (AC:8C) [15:14:07:753]: APPCOMPAT: looking for appcompat
database entry with ProductCode
'{C9C442B8-FCB4-4A65-BC0E-44AC970DA32D}'.
MSI (c) (AC:8C) [15:14:07:753]: APPCOMPAT: no matching ProductCode
found in database.
MSI (c) (AC:8C) [15:14:07:773]: MSCOREE not loaded loading copy from system32
MSI (c) (AC:8C) [15:14:08:104]: Machine policy value 'TransformsSecure' is 0
MSI (c) (AC:8C) [15:14:08:104]: User policy value 'TransformsAtSource' is 0
MSI (c) (AC:8C) [15:14:08:154]: Machine policy value 'DisablePatch' is 0
MSI (c) (AC:8C) [15:14:08:154]: Machine policy value 'AllowLockdownPatch' is 0
MSI (c) (AC:8C) [15:14:08:154]: Machine policy value 'DisableLUAPatching' is 0
MSI (c) (AC:8C) [15:14:08:154]: Machine policy value
'DisableFlyWeightPatching' is 0
MSI (c) (AC:8C) [15:14:08:164]: APPCOMPAT: looking for appcompat
database entry with ProductCode
'{C9C442B8-FCB4-4A65-BC0E-44AC970DA32D}'.
MSI (c) (AC:8C) [15:14:08:164]: APPCOMPAT: no matching ProductCode
found in database.
MSI (c) (AC:8C) [15:14:08:164]: Transforms are not secure.
MSI (c) (AC:8C) [15:14:08:164]: Command Line:
CURRENTDIRECTORY=C:\Documents and Settings\antti.jarvinen\Desktop
CLIENTUILEVEL=0 CLIENTPROCESSID=1708
MSI (c) (AC:8C) [15:14:08:164]: PROPERTY CHANGE: Adding PackageCode
property. Its value is '{6813D945-AC20-44AA-BEB7-3C3E92014ADA}'.
MSI (c) (AC:8C) [15:14:08:164]: Product Code passed to
Engine.Initialize: ''
MSI (c) (AC:8C) [15:14:08:164]: Product Code from property table
before transforms: '{C9C442B8-FCB4-4A65-BC0E-44AC970DA32D}'
MSI (c) (AC:8C) [15:14:08:164]: Product Code from property table after
transforms: '{C9C442B8-FCB4-4A65-BC0E-44AC970DA32D}'
MSI (c) (AC:8C) [15:14:08:164]: Product not registered: beginning
first-time install
MSI (c) (AC:8C) [15:14:08:164]: PROPERTY CHANGE: Adding ProductState
property. Its value is '-1'.
MSI (c) (AC:8C) [15:14:08:164]: Entering
CMsiConfigurationManager::SetLastUsedSource.
MSI (c) (AC:8C) [15:14:08:164]: User policy value 'SearchOrder' is 'nmu'
MSI (c) (AC:8C) [15:14:08:164]: Adding new sources is allowed.
MSI (c) (AC:8C) [15:14:08:164]: PROPERTY CHANGE: Adding
PackagecodeChanging property. Its value is '1'.
MSI (c) (AC:8C) [15:14:08:164]: Package name extracted from package
path: 'Wix3.msi'
MSI (c) (AC:8C) [15:14:08:164]: Package to be registered: 'Wix3.msi'
MSI (c) (AC:8C) [15:14:08:164]: Note: 1: 2262 2: AdminProperties 3: -2147287038
MSI (c) (AC:8C) [15:14:08:164]: Machine policy value 'DisableMsi' is 0
MSI (c) (AC:8C) [15:14:08:164]: Machine policy value
'AlwaysInstallElevated' is 0
MSI (c) (AC:8C) [15:14:08:164]: User policy value 'AlwaysInstallElevated' is 0
MSI (c) (AC:8C) [15:14:08:164]: Product installation will be elevated
because user is admin and product is
Re: [WiX-users] Where to start? V2 or V3?
Not that my opinion should carry much weight considering Rob has already voiced his opinion, but he is obligated to take a more cautious stance than the rest of us. I would move whole heartedly to V3. Just the shortfilename, longfilename stuff alone was worth the move for me. Disclaimer: I'm not doing installs of anything particularly complex... Darrel On 10/3/06, Adam D [EMAIL PROTECTED] wrote: Hello, I'm about to get started with WiX as a possible replacement for InstallShield. I would like to get a view on what I should start with - V2 or V3? I want to use Votive, and I quite like the idea of a MSBuild compliant project file, but I don't want to jump in using V3 if it has any fundamental stability issues. I've read http://www.nabble.com/What-use%2C-WiX-2-or-WiX-3---tf1978732.html#a5429391 this post - but I have no feel for where WiX is at right now. I plan to release in the last breath of this year. So - what's the concensus of opinion? Start with V2 or V3? Thanks for your time. Adam. -- View this message in context: http://www.nabble.com/Where-to-start--V2-or-V3--tf2377306.html#a6623942 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 - 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
[WiX-users] Problem creating shortcut
Hi, I have a problem in my installer with creating shortcuts : basically, I need to create a shortcut where the executable isn't part of my installer and I just need to provide parameters. I retrieve the executable path using : Property Id=PROWCINI_PATH RegistrySearch Id=ProwcIniPath Root=HKLM Key=Software\PSC\WebClient Name=ProwciniPath Type=file/ /Property And I add icon using : Shortcut Id=Shortcut1 Advertise=no Directory=DesktopFolder Name=MyShortcut Target=[$PROWCINI_PATH] Arguments=http://localhost/foo/bar/ Problem is that when running the installer, I get my icon created in desktop folder, but executable path isn't the value of PROWCINI_PATH, but to its parent directory. WiX help says for target attribute that the value will be defaulted to the parent File when nested under a File element. So how is it possible to create a shortcut using the correct executable path ? Best regards -- Gilles QUERRET - 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
[WiX-users] WiX Monthly Meeting
The following is meeting notes from the WiX Monthly Meeting from 5:15 PM - 6:00 PM PST on Microsoft campus. The first meeting (last month) was where I announced that the internal Microsoft mailing list for WiX was going to be deprecated. Now (as you may have noticed) all communication happens on the wix-users mailing list. See the Discussion section below to note that I'm going to be looking into other forums for the meeting (and possibly other times) to get more people involved in the Monthly Meeting. --- Roundtable --- * Peter Marcu - starting to get more involved (focusing on advanced needs for VS), such as CustomActions and Media table improvements. Peter Marcu is a new name on the WiX toolset but hopefully you'll be seeing more of him in the not so distant future. * Joe Abbott - still making the builds go * Bob Arnson - Bob has just moved (woohoo!) and now has 3 of his computers back up and running (so hopefully will make forward progress again). Going to finish new UI and start extension to make the new UI easier to use. Will also take a couple interesting bugs in Compiler. Also looking at ShellExecute CustomAction (nice immediate CustomAction). Then back into the extensions. * Justin Rockwood - Votive 3 was released. Seems to be mostly okay. Few bugs but nothing blocking. Going to add $(var.Project.Item) support back like Votive 2 had. That should get Votive 3 totally caught up and beyond Votive 2. * Rob Mensching - Focusing on setup.exe and will slowly be digesting Derek's patching tools. --- Discussion --- * Some questions about UI, in particular branching in the wizard mode. Bob spoke about floating Publish elements available in WiX v3 to make it slightly easier, but still difficult. Bob said he was happy to sit down and talk about it since it is a deep topic. Rob mentioned that at a certain point, you'll exit to a external UI handler and the setup.exe work is intended to make it easier. Bob also noted that sometimes with really complicated UI it may mean you are trying to do too much in your UI. * Rob noted that attendance is really low (two people not working on WiX toolset) and physical meeting doesn't work for those people in other cities/states/countries. Justin mentioned that a conference call may get more people. Then Justin suggested maybe doing an open chat on MSDN. That sounds interesting. Rob will ask around and see what is available. - 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
[WiX-users] Set selection tree options
Hello all I've have selection tree, and I want to set installing way options for features like Install and not install only. I'm trying follow combination, but I've install, not install and network install. How to remove network install? Feature Id='F1' Level='1' Display='expand' ConfigurableDirectory='INSTALLDIR' AllowAdvertise='no' InstallDefault=local TypicalDefault=install (3 way) if i insert into this block another feature Feature Id='F11' Level='1' Display='collapse' AllowAdvertise='no' InstallDefault='followParent' TypicalDefault=install Feature F11 have install and not install options only. Only root Feature have network install But Votive installer have 2 root Feature with install and not install options only. Tanks, Anton. - 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] Disable feature when property is empty
Thanks, got it to work with the following source Feature Id=FirefoxExtension Level=1001 Title=Extension for Mozilla Firefox Description=Extension for Mozilla Firefox TypicalDefault=install InstallDefault=followParent ComponentRef Id=jsFile / ComponentRef Id=overlay / ComponentRef Id=pngIcon / ComponentRef Id=StyleSheet / ComponentRef Id=ManifestChrome / ComponentRef Id=rdfInstall / Condition Level=0FIREFOX_INSTALL_VERSION=/Condition /Feature Stefan -- View this message in context: http://www.nabble.com/Disable-feature-when-property-is-empty-tf2323552.html#a6637061 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
[WiX-users] Preselecting feature and disable install on first use
Salut, disabling the firefox-extension-feature when the browser's not installed now works. Still I got some problem. I'm trying to preselect the firefox extension-feature and disabling the install on first use option as my application does not support it. This is how far I got Feature Id=Complete Title=Basic installation Level=1 Description=Complete installation Display=expand ConfigurableDirectory=INSTALLDIR AllowAdvertise=no Absent=disallow InstallDefault=local Feature Id=MainProgram Title=Program Description=The main executable. Level=2 Absent=disallow TypicalDefault=install InstallDefault=local AllowAdvertise=no ComponentRef Id=MainExecutable / ComponentRef Id=PluginsConnector / ComponentRef Id=DSIEHelper / ComponentRef Id=FileTypeIcon / ComponentRef Id=EnglishLangFile / ComponentRef Id=HelpFileEng / ComponentRef Id=SearchSettings / ComponentRef Id=FileNameCreator / ComponentRef Id=RegKeysPrivileged / ComponentRef Id=RegKeysNonPrivileged / ComponentRef Id=UpdateNotify / ComponentRef Id=FirefoxExtension / /Feature Feature Id=GermanLangPack Title=German Language Pack Description=German Language Pack Level=1000 ComponentRef Id=HelpFileGer / ComponentRef Id=GermanLangFile / /Feature Feature Id=FirefoxExtension Level=1001 Title=Extension for Mozilla Firefox Description=Extension for Mozilla Firefox TypicalDefault=install InstallDefault=followParent ComponentRef Id=jsFile / ComponentRef Id=overlay / ComponentRef Id=pngIcon / ComponentRef Id=StyleSheet / ComponentRef Id=ManifestChrome / ComponentRef Id=rdfInstall / Condition Level=0FIREFOX_INSTALL_VERSION=/Condition /Feature /Feature But no matter which attributes I add to the extension feature, it is not preselected. Can you help me? Thanks in advance, Stefan -- View this message in context: http://www.nabble.com/Preselecting-feature-and-disable-%22install-on-first-use%22-tf2381534.html#a6637113 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
[WiX-users] Can I retrive public property values in merge modules??
Hi, I am trying to use public properties in merge modules (these public property values are passedas command line arguments to the msi package), but I am unable to retrieve the public property values in merge modules.My questions is, Can I use public properties in merge modules? thanks in advance Vij Stay in the know. Pulse on the new Yahoo.com. Check it out. - 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
[WiX-users] ForceReboot action during Uninstallation(2)
Hi list...
My question is probably related to Windows Installer (not to WiX)
but anyway...
I want to use ForceReboot standard action during uninstallation of
the product.
(ForceReboot will ask for immediate reboot of computer and schedule
the installation to continue after reboot)
I have scheduled the ForceReboot action to run right after
InstallInitialize (requirement from MSDN).
Everything works as expected, but after reboot the installer ends
with error:
The installation package could not be opened. Verify that the
package exists and that...
Problem is that the msiexec wants to start the temporary file in
C:\Windows\Installer\ which was deleted (and this is problem) during
cleanup before reboot.
See the excerpt from the log in attachment for details.
Am I doing something wrong? Or the ForceReboot action just should
not be used during uninstall?
Thanks for any response...
Stefan
--
Stefan Pavlik | [EMAIL PROTECTED]
Whitestein Technologies | www.whitestein.com
Panenska 28 | SK-81103 Bratislava | Slovak Republic
Tel +421(2)5930-0735 | Fax +421(2)5443-5512
ÿþA c t i o n e n d e d 1 4 : 1 8 : 5 8 :
I n s t a l l I n i t i a l i z e . R e t u r n v a l u e 1 .
A c t i o n s t a r t 1 4 : 1 8 : 5 8 : F o r c e R e b o o t .
M S I ( s ) ( B 4 : D 4 ) [ 1 4 : 1 8 : 5 8 : 2 4 8 ] :
E x e c u t i n g o p :
P r o d u c t U n r e g i s t e r ( U p g r a d e C o d e = { 9 F E E 1 A 0 0 - 4 C C C - 4 D B 0 - A D 9 9 - 6 7 7 3 C D 2 3 C B 1 E } )
M S I ( s ) ( B 4 : D 4 ) [ 1 4 : 1 8 : 5 8 : 2 6 8 ] : N o t e :
1 : 1 4 0 2 2 :
U N K N O W N \ P r o d u c t s \ C D 4 F F B F F A 3 1 6 5 F 0 4 E 9 0 3 4 6 9 1 8 A 8 E 1 F B 4 \ T r a n s f o r m s
3 : 2
M S I ( s ) ( B 4 : D 4 ) [ 1 4 : 1 8 : 5 8 : 2 6 8 ] : N o t e :
1 : 1 4 0 2 2 :
U N K N O W N \ P r o d u c t s \ C D 4 F F B F F A 3 1 6 5 F 0 4 E 9 0 3 4 6 9 1 8 A 8 E 1 F B 4 \ T r a n s f o r m s
3 : 2
M S I ( s ) ( B 4 : D 4 ) [ 1 4 : 1 8 : 5 8 : 2 6 8 ] :
S c h e d u l i n g f i l e
' C : \ W I N D O W S \ I n s t a l l e r \ 9 2 1 7 d . m s i ' f o r
d e l e t i o n d u r i n g p o s t - i n s t a l l c l e a n u p
( n o t p o s t - r e b o o t ) .
M S I ( s ) ( B 4 : D 4 ) [ 1 4 : 1 8 : 5 8 : 2 8 8 ] : N o t e :
1 : 1 4 0 2 2 :
U N K N O W N \ P r o d u c t s \ C D 4 F F B F F A 3 1 6 5 F 0 4 E 9 0 3 4 6 9 1 8 A 8 E 1 F B 4 \ U s a g e
3 : 2
A c t i o n e n d e d 1 4 : 1 8 : 5 8 : F o r c e R e b o o t .
R e t u r n v a l u e 4 .
A c t i o n e n d e d 1 4 : 1 8 : 5 8 : I N S T A L L . R e t u r n
v a l u e 4 .
M S I ( c ) ( 2 0 : 5 8 ) [ 1 4 : 1 8 : 5 8 : 3 8 8 ] : F o n t
c r e a t e d . C h a r s e t : R e q = 0 , R e t = 0 , F o n t :
R e q = M S S h e l l D l g , R e t = M S S h e l l D l g
T h e i n s t a l l e r m u s t r e s t a r t y o u r s y s t e m
b e f o r e c o n f i g u r a t i o n o f U n l i m i t e d D a t a
M a n a g e r 4 . 0 . 0 c a n c o n t i n u e . C l i c k Y e s
t o r e s t a r t n o w o r N o i f y o u p l a n t o
m a n u a l l y r e s t a r t l a t e r .
M S I ( s ) ( B 4 : D 4 ) [ 1 4 : 1 9 : 2 0 : 8 9 0 ] :
C l e a n i n g u p u n i n s t a l l e d i n s t a l l
p a c k a g e s , i f a n y e x i s t
M S I ( s ) ( B 4 : D 4 ) [ 1 4 : 1 9 : 2 0 : 9 0 0 ] :
P o s t - i n s t a l l c l e a n u p : r e m o v i n g
i n s t a l l e r f i l e
' C : \ W I N D O W S \ I n s t a l l e r \ 9 2 1 7 d . m s i '
M S I ( s ) ( B 4 : D 4 ) [ 1 4 : 1 9 : 2 0 : 9 0 0 ] :
P o s t - i n s t a l l c l e a n u p : r e m o v i n g
i n s t a l l e r f i l e
' C : \ W I N D O W S \ I n s t a l l e r \ { F F B F F 4 D C - 6 1 3 A - 4 0 F 5 - 9 E 3 0 - 6 4 1 9 A 8 E 8 F 1 4 B } \ i n s t i c o n . i c o '
M S I ( s ) ( B 4 : D 4 ) [ 1 4 : 1 9 : 2 0 : 9 0 0 ] :
P o s t - i n s t a l l c l e a n u p : r e m o v i n g
i n s t a l l e r f o l d e r
' C : \ W I N D O W S \ I n s t a l l e r \ { F F B F F 4 D C - 6 1 3 A - 4 0 F 5 - 9 E 3 0 - 6 4 1 9 A 8 E 8 F 1 4 B } \ '
( i f e m p t y )
M S I ( s ) ( B 4 : D 4 ) [ 1 4 : 1 9 : 2 0 : 9 1 0 ] :
M a i n E n g i n e T h r e a d i s r e t u r n i n g 1 6 4 1
M S I ( s ) ( B 4 : C C ) [ 1 4 : 1 9 : 2 0 : 9 1 0 ] :
D e s t r o y i n g R e m o t e A P I o b j e c t .
M S I ( s ) ( B 4 : 0 C ) [ 1 4 : 1 9 : 2 0 : 9 1 0 ] : C u s t o m
A c t i o n M a n a g e r t h r e a d e n d i n g .
= = = L o g g i n g s t o p p e d : 1 0 / 4 / 2 0 0 6
1 4 : 1 9 : 2 0 = = =
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and
[WiX-users] Upgraded merge modules
I've got a set of merge modules that have been used in installers sent to customers. Now I've got to recompile my wix files to pick up the newest versions of the executables (bug fixes, new features etc). Should the GUID in Module be changed to indicate the file contents have changed, or do I keep the same number and rely on whoever writes the installer to change the Upgrade Code? I need Windows Installer to recognise that these are replacement files, not new files that just happen to install over the top of existing files. Thanks... - 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
[WiX-users] Creating a custom action that runs on install only
Im looking at the attributes for the CustomAction element and it is not clear to me how you would make the custom action only run on install. Another possibility may be to create a condition on the Custom element associated with the CustomAction? For example: Custom Action="" After=InstallFinalizeNOT Installed/Custom It takes me about an hour to spin a new msi and try this stuff so Im wondering if someone could point me in the right direction and save me some time J Jeff - 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] Displaying status text for CAQuietExec action ?
From: Bob Arnson [EMAIL PROTECTED] Use the ProgressText element to add a row to the ActionText table. Note Thanks, this is exactly what I was looking for. And another related question. I have multiple deferred CAQuietExec actions. Is possible detect which of them had failed and display corresponding error message ? I tried to use the action value as a condition without a luck. Petr BTW The email archive page on sf.net got stuck. I can see latest message from 2006-10-02 06:34. - 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
[WiX-users] dependencies when building MSI using VS2005/MSBuild
Hi. I use VS2005/MSBuild to build the MSI file. I experience that the build step only depends on the wxs files and wixlib files. However the resulting MSI file needs to be rebuilt whenever one of the refered files have changed. A line like File Id=filea.exe Name=filea.exe Source=$(var.src)\filea.exe/ means that if filea.exe has changed then the MSI must be rebuilt. How do I achieve this? in C++ projects, there is a setting like Additional dependencies, but that is not the case for MSBuild projects. However, it would be even better if the WixTasks.dll could take care of all this, so you would need to manual maintain a list of files seperate from the one already found in the .wxs file. I am not expert in building MSBuild tasks, but is it possible to have the WixTasks.dll take care of that? Jarl -- Jarl Friis Softace ApS Omøgade 8, 2.sal 2100 København Ø. Denmark Phone: +45 26 13 20 90 E-mail: [EMAIL PROTECTED] LinkedIn: https://www.linkedin.com/in/jarlfriis - 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
[WiX-users] Authoring of Required Dialogs
Hi All, I've authored my WiX with a set of dialogs comprising my setup wizard, and then I found this page on msdn: http://windowssdk.msdn.microsoft.com/en-us/library/aa368283.aspx Does this mean that I have to author the Reserved Dialog and Required Dialog boxes into my wix? I only found this issue because I ran msival2 on my .msi... And for whatever reason I don't believe my team is using the WiX UI library, and instead authoring from scratch. Cheers, Alec - 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
[WiX-users] Customizing the uninstall progress dialog.
I'm working on setting up an installer using WiX. When I uninstall my product, there's a dialog box displayed that just has a progress bar. I'd like to customize this uninstall dialog with some strings that explain to the user what's going on. Please would you let me know how to do that. I haven't found anything relevant in any of the documentation or in the examples that come with WiX. Thanks! Alex - 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
[WiX-users] Combobox websites
Title: Combobox websites Hi! Was wondering if anybody out there has played around with comboboxes and extracting the field based on user selection. I have a script that populates both websites and application pools to a combobox, and based on the user selection populate the given website and application pool with the package. For the combobox: Control Id=WebSiteCombo Type=ComboBox X=18 Y=126 Width=120 Height=100 Property=TARGETWEBCOMBO .. Control Id=AppPoolCombo Type=ComboBox X=210 Y=126 Width=120 Height=200 Property=TARGETAPPPOOLCOMBO If I use the reference to TARGETWEBCOMBO and TARGETAPPPOOLCOMBO after the user makes the selection form the combobox, I get the Value part and not the Text part of the combobox. What I really want to do is use something like this WebSite Id=Something Description=[TARGETWEBCOMBO] ... And have the package install itself under the given website. For the appPool: WebAppPool Id=Something Name=[TARGETAPPPOOLCOMBO] ... To get this to work in a not ideal way, I populated the Value field of the combobox with the site name to be able to use TARGETWEBCOMBO reference. Is there a way to select the Text field when one has the Value in the TARGETAPPPOOLCOMBO var? Also is it possible to reference the WebSite and WebAppPool in the manner I want to, so my website is installed under the one the user choose? Regards Morten - 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] Using a generated (by tallow.exe) fragment file in acomponent
If I understand correctly, I believe Bob is saying that the component GUIDs in your installer should also be stable, which cannot currently be achieved with tallow. The Windows Installer SDK suggests that if you change the contents of a component to be incompatible with previous versions of the component, you should change the component GUID. Otherwise you should keep the same component ID. However, if you do this, you should install the new component somewhere else, otherwise if both old and new components are installed, then the old component uninstalled, the new resource will be removed. That's the point of Rob's blog post. Quite how this interacts with assemblies installed to the GAC I'm not sure, since their install location depends on the strong name (version, culture, public key token). Should a new version of such an assembly be considered the same component as a previous version of the assembly, or a new component, since in fact a new version of an assembly is not automatically compatible with an old version (either publisher policy or .config file bindingRedirect must be used to force old clients to the new version)? This - putting the assembly in the GAC - is the recommended way of using COM Interop, BTW. You can use the /codebase flag to regasm (which will create a Codebase value) which allows COM Interop to use a non-GAC assembly, but I had some problems with this when using publisher policy to redirect some references from the non-GAC assembly to a newer version of primary interop assemblies (.NET-to-COM). This was done so that I didn't have to distribute every version of PIAs that had ever previously shipped, although this may not have been the best choice in retrospect. On the other hand, if you have multiple packages shipping these components installing into the GAC, you _must_ use the same installer component GUIDs, for the same reason as in Rob's blog post. -- Mike Dimmick -Original Message- From: Jarl Friis [mailto:[EMAIL PROTECTED] Sent: 04 October 2006 07:22 To: Bob Arnson Cc: Mike Dimmick; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Using a generated (by tallow.exe) fragment file in acomponent Bob Arnson [EMAIL PROTECTED] writes: Jarl Friis wrote: appropriate Component element). I have expected to be able to avoid that for the standard reasons: It's time consuming. It does not require intelligence. It's error prone; In half-a-year, when I actually do make an Problem is: It does require intelligence. See, for example: http://blogs.msdn.com/robmen/archive/2003/10/18/56497.aspx. This blog is discussing GUIDs for components, the guids that I talk about which is found in an output from regasm.exe /regfile MyAssembly.dll are COM-related GUIDs, such as class IDs and interface IDs. As Mike wrote these are new when (assembly name, version, culture, public key token) are changed, where version means value of [AssemblyVersion] or [ComCompatibleVersion] if present. hence I could limit the intelligence to control these parameters. If I got something wrong please enlight me, as I still don't see the requirement for intelligence in this task. Jarl -- Jarl Friis Softace ApS Omøgade 8, 2.sal 2100 København Ø. Denmark Phone: +45 26 13 20 90 E-mail: [EMAIL PROTECTED] LinkedIn: https://www.linkedin.com/in/jarlfriis - 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
[WiX-users] Please help... disable feature based on another feature
Hello, Can someone help. I have a SelectionTree and need to disable or enable a hidden feature based on the selection of another feature. I've worked out I can use publish events on my next button to enable or disable a feature based on a property, but how can I base this on the status of another feature instead? Alternatively if I can set a property when a feature status is changed in the ui I could make this work, but not sure how to do that? Any ideas? Thanks, Mike - 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
[WiX-users] No messages from WiX-Users for 2 days
Hi all Anybody has an Idea why the wix-users forum is not working? I haven't received any mail from this forum for two days (since 2006-10-03). I hope that it is not the end of the WiX forum Stefan -- View this message in context: http://www.nabble.com/No-messages-from-WiX-Users-for-2-days-tf2387690.html#a6656305 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
[WiX-users] CustomActions does not invoke in InstallExecuteSequence rather gets invoked in InstallUISequence
Hi, What could possibly be the reason for Custom Actions not being invoked if mentioned in InstallExecuteSequence table but works fine if mentioned in InstallUISequence table. Thanks, Abani - 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
[WiX-users] ODBC data source name hard coded
Hello, I would really appreciate your help with this issue. I'm using Wix-2.0.4415.0 under XP Professional SP2. I 'd like to let the user to chose its ODBC datasource name. I use an Edit control in a dialog, with a public property ODBCNAME attached and I set the ODBCDataSource's Name to this property. I also save the custom typed value in the registry for uninstall, patches etc... I have no errors while compiling the MSI file. During the installation I have the right to the Id=1919 error: Error configuring ODBC data source: [ODBCNAME], ODBC error 11: ConfigDSN or ConfigDriver or ConfigTranslator Driver Error. Verify that the file [ODBCName] exists and that you can access it. I do the SAME procedure for the web site name and it WORKS! Can you tell me what makes the difference? Does anyone had this need before and handled it? Thanks a lot. Roxana - 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] Multiple DLLs into GAC
One component per DLL. The general suggestion is one component per file, unless there is a very good reason not to (e.g. multi-file assemblies such as publisher policy assemblies, which must be a single component). -- Mike Dimmick From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Douglas WattsSent: 03 October 2006 22:42To: wix-users@lists.sourceforge.netSubject: [WiX-users] Multiple DLLs into GAC I have more than a dozen DLLs that I need to install into the GAC. Ive learned how to install a file by merely adding the Assembly=.net attribute. This attribute requires the KeyPath=yes to be there as well. Is there an easy way to install multiple DLLs or do I have to create a component for each DLL? __ Doug Watts - 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] WiX-users Digest, Vol 5, Issue 11
snip I have an MSM that defines a set of CustomAction entries. The MSM is merged into the MSI, and it is my responsibility to execute the MSM's custom actions. Unfortunately when I compile my project, light rightly complains: C:\xxx\yyy.xml : error LGHT0112 : Unresolved reference to symbol 'CustomAction:foo' in section 'Product:12345678-1234-1234-1234-123456789012'. /snip Custom Actions in an MSM are available as CustomAction.GUID. Add the merge module to your package, candle/light it, then crack open the MSI with Orca, and you'll see it there in your CustomAction table. You should be able to insert CustomAction.GUID without light complaining. - 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] WiX 3 in Team Foundation Build
light.exe has, I believe,to load the .msi in order to perform the validation step. For the moment, you could suppress validation with the -sval switch which I think is a SuppressValidation property (I'm not familiar with MSBuild). -- Mike Dimmick From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peterson, JoelSent: 04 October 2006 01:19To: wix-users@lists.sourceforge.netSubject: [WiX-users] WiX 3 in Team Foundation Build Hi all. Im new to this list so please correct me if this has already been discussed. Ive installed the latest weekly build of WiX 3 on my development system and also on my Team Foundation Server/Team Foundation Build. The WiX solution builds fine on my development system, in all Debug/Release configurations. I checked that solution in to the main project on the Team Foundation Server, and configured a Build for it. When I start the build, its all run with the DOMAIN\TFSService user account as specified in the Team Foundation Installation manual. Everything runs fine, until it gets to Light: Target PrepareForBuild: Creating directory "obj\Release\". Creating directory "D:\Build\ProjectName\WiX - Web Client Printer\Binaries\Release\". Target Compile: C:\Program Files\Windows Installer XML v3\bin\candle.exe -out "obj\Release\Web Client Printer.wixobj" "Web Client Printer.wxs" Target Link: C:\Program Files\Windows Installer XML v3\bin\Light.exe -out "D:\Build\ProjectName\WiX - Web Client Printer\Binaries\Release\Web_Client_Printer.msi" "obj\Release\Web Client Printer.wixobj" light.exe : error LGHT0216: An unexpected Win32 exception with error code 0x659 occurred: This installation is forbidden by system policy. Contact your system administrator Done building target "Link" in project "Web Client Printer.wixproj" -- FAILED. This error is what one would get if they ran a MSI with a user account that did not have Administrative priviledges, but why would that appear during the link process? The Team Foundation Server Installation manual specifically says not to give DOMAIN\TFSService administrative priviledges for security reasons, but I did anyways to see if it would get around this issue. It did not, and I still received the same error message. I can provide the full build log if necessary, I havent had a chance to redact it yet. Joel Peterson [EMAIL PROTECTED] - 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] Calling a CustomAction defined in an MSM.
I think it's simply that all the references are resolved by the linker _before_ the MSMs are merged in. This makes it impossible to reference anything in the MSM. I think merge module custom actions should be scheduled by authoring them in the ModuleInstallExecuteSequence (or ModuleInstallUISequence) table. Merging the module then places the custom action in the right relative place in the corresponding Install sequence. I'm not sure how to do this with WiX - it's possible that including the InstallExecuteSequence in a Module will do the right thing. If all your installers are using WiX, and you wrote this merge module, it seems to me that you might get better results by simply referencing WiX Fragments. If you have a lot of Fragments and you want to save the compile time, you could use lit.exe to make a .wixlib from the resulting .wixobj files. Anyone know better? -- Mike Dimmick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos O'Donell Sent: 02 October 2006 20:59 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Calling a CustomAction defined in an MSM. WiX Users, I have an MSM that defines a set of CustomAction entries. The MSM is merged into the MSI, and it is my responsibility to execute the MSM's custom actions. Unfortunately when I compile my project, light rightly complains: C:\xxx\yyy.xml : error LGHT0112 : Unresolved reference to symbol 'CustomAction:foo' in section 'Product:12345678-1234-1234-1234-123456789012'. It would seem that the CutomAction's in an MSM are not available from the MSI? It is essentially this issue: [ 1541952 ] Unresolved Reference error when using CA declared in MSM The original response seems to be: You cannot create references from products into merge modules. Why is this the case? Is someone able to clarify why products can't reference or call custom actions in merge modules? Any guidance is much appreciated. Cheers, Carlos. - 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=DEVDE V ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - 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] CustomTableRef?
Your latter scenario should work today. If you create a CustomTable with only Rows in it, it will automatically create a reference to the CustomTable with the definitions. Did that not work? If not, then please do open a bug and someone will fix it because it is supposed to work that way. smile/ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Hybner Sent: Tuesday, October 03, 2006 1:23 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] CustomTableRef? With FragmentRef deprecated, is there a supported mechanism for sucking in a CustomTable and associated data from an external file? How about storing data and schema separately (so that developer X can add data rows, but cant muck with my table schema)? Thanks! - 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] Upgraded merge modules
Check out the File Versioning topic in the MSI SDK. That is what will control how your files get upgraded. Changing the GUID on the Merge Module won't affect them. The Merge Module signature has a version, I would suggest leaving the GUID the same and just up'ing the version number... unless the Merge Module is some breaking change and installs everything to completely different locations. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Antony Walmsley Sent: Wednesday, October 04, 2006 7:55 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Upgraded merge modules I've got a set of merge modules that have been used in installers sent to customers. Now I've got to recompile my wix files to pick up the newest versions of the executables (bug fixes, new features etc). Should the GUID in Module be changed to indicate the file contents have changed, or do I keep the same number and rely on whoever writes the installer to change the Upgrade Code? I need Windows Installer to recognise that these are replacement files, not new files that just happen to install over the top of existing files. Thanks... - 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 - 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] Calling a CustomAction defined in an MSM.
You should schedule your CustomAction inside the Merge Module. When the Merge Module is merged it will be put in the correct sequence in the final MSI. The MSI SDK has more information about sequencing CustomActions in Merge Modules. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos O'Donell Sent: Monday, October 02, 2006 12:59 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Calling a CustomAction defined in an MSM. WiX Users, I have an MSM that defines a set of CustomAction entries. The MSM is merged into the MSI, and it is my responsibility to execute the MSM's custom actions. Unfortunately when I compile my project, light rightly complains: C:\xxx\yyy.xml : error LGHT0112 : Unresolved reference to symbol 'CustomAction:foo' in section 'Product:12345678-1234-1234-1234-123456789012'. It would seem that the CutomAction's in an MSM are not available from the MSI? It is essentially this issue: [ 1541952 ] Unresolved Reference error when using CA declared in MSM The original response seems to be: You cannot create references from products into merge modules. Why is this the case? Is someone able to clarify why products can't reference or call custom actions in merge modules? Any guidance is much appreciated. Cheers, Carlos. - 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 - 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] Embedding MSI in a bootstrapper
You have to extract it. The Windows Installer engine doesn't know how to read MSI files out of resource streams. Besides, you're going to want to put the MSI in a place where future repair operations can find it. Otherwise the user will get prompted to find an MSI that is hidden inside your boostrapper (which may or may not be around anymore). You can see the setup.exe with WiX v3 caches. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Magus Sent: Tuesday, October 03, 2006 3:24 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Embedding MSI in a bootstrapper Not really a wix questions, but I did create my program in wix, just wondering if anyone had done this before. My bootstrapper is suppose to control the UI for the Installer, and also check to see if the file is already installed and prompt user to play or uninstall if it is already installed. With that in mind I don't want to user to run the MSI itself I want to insure that that run the Bootstrapper. Is there a way to embed the msi inside the bootstrapper as a resource and then run it? I would like not to have to extract the MSI during runtime but to instead just run it from resource if its possible -- View this message in context: http://www.nabble.com/Embedding-MSI-in-a-bootstrapper-tf2379080.html#a6630105 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 - 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] Where to start? V2 or V3?
True, I take a more cautious stance. I really do want you guys to like me and giving bad advice doesn't seem like a good way to do that. smile/ One thing I would add to Darrel's statement below is that WiX v3 is still under development. From build to build, you may run into changes in the schema that break you. Peter Marcu is looking at better ways to organize the Media elements (because it is pretty annoying to create multi-Media installs right now with WiX). It is possible that he'll end up with a breaking change there. Of course, we try to always keep WixCop up to date so the migration from one build to another is easy. Just be aware of what you're signing up for with the unstable development branch. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Darrel Miller Sent: Tuesday, October 03, 2006 10:03 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Where to start? V2 or V3? Not that my opinion should carry much weight considering Rob has already voiced his opinion, but he is obligated to take a more cautious stance than the rest of us. I would move whole heartedly to V3. Just the shortfilename, longfilename stuff alone was worth the move for me. Disclaimer: I'm not doing installs of anything particularly complex... Darrel - 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] Guid=*
The intent is to generate a stable - the same - component GUID for the same resource. Rob's blog post 'Component Rules 101' describes how multiple components (remember, identified by GUID) installing the same resource can cause problems such as prematurely-removed resources or orphaned resources. That being so, there should _not_ be any random elements, rebuilding the MSI with the same canonical target paths should yield the same GUID. Your suggestion of hashing the content would break the component rules. If you create a compatible version of a resource, and it is installed to the same place, it should retain the same component GUID. If it is incompatible, you should change the resource's installation location and give it a new GUID. -- Mike Dimmick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jarl Friis Sent: 04 October 2006 08:39 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Guid=* I am trying out the new feature Guid=* as described on http://installing.blogspot.com/2006/09/automatically-generating-component.html I got some questions: In the blog beta-testers are encouraged to try it out: When using it a warning is shown, that this is experimental. Among others it claims that it (the generated GUID, I guess) can COLLIDE WITH OTHER COMPANY'S PRODUCTS Is that possible? it of course depends on the generation algorithm. Derek does not ellaborate to much on this: Basically he says that it is based on a predetermined Wix namespace Guid and the [canonicall] path to the file. Derek encourage users to Review the overall design for this feature.. In an attempt to review this design, I would ask someone to say some more on this desgin? Questions are: *) Is canonical path and wix namespace te only input to the alforithm, or is there some randomish included as well? Answer is probably yes. *) Does that mean that rebuilding the MSI file with same canonical paths, yield the same GUID? Answer is probably no? *) I suggest that the content (could be md5sum of content) of the key path file should also be an input to the algorithm. This means that e.g. rebuilding a DLL (with even just the smallest change in source code), will result in a new component GUID. Would it be an idea to seperate this feature out to an separate external tool to compute such Guid? Name suggestions match.exe or spark.exe Jarl -- Jarl Friis Softace ApS Omøgade 8, 2.sal 2100 København Ø. Denmark Phone: +45 26 13 20 90 E-mail: [EMAIL PROTECTED] LinkedIn: https://www.linkedin.com/in/jarlfriis - 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 - 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] Multiple DLLs into GAC
One GACd assembly per Component is the rules from the Windows Installer. Honestly, when considering the Component Rules, I would suggest one file per Component in almost all cases. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Douglas Watts Sent: Tuesday, October 03, 2006 2:42 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Multiple DLLs into GAC I have more than a dozen DLLs that I need to install into the GAC. Ive learned how to install a file by merely adding the Assembly=.net attribute. This attribute requires the KeyPath=yes to be there as well. Is there an easy way to install multiple DLLs or do I have to create a component for each DLL? __ Doug Watts - 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] Upgraded merge modules
Ahh, well, you should probably file a bug against InstallShield. They arent doing the right thing according to the MSI SDK (unless Im misunderstanding the SDK, which is possible... I did write that spec a very long time ago when I was an intern smile/). From: Antony Walmsley [mailto:[EMAIL PROTECTED] Sent: Thursday, October 05, 2006 9:26 AM To: Rob Mensching Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Upgraded merge modules Thanks Rob. This issue has come about because our product groups use InstallShield to incorporate the merge modules into their installers. It seems that InstallShield uses the module GUID and locale to decide whether 2 merge modules are the same. These values are the same in both the new and old merge modules so when IS brings up the list of available modules it only shows the latest version even if the version number and file name (and folder location) are different. Since they still want to release installers for older versions, we will need to change the module GUID so that both versions appear in InstallShield's list of modules. On 05/10/06, Rob Mensching [EMAIL PROTECTED] wrote: Check out the File Versioning topic in the MSI SDK.That is what will control how your files get upgraded.Changing the GUID on the Merge Module won't affect them.The Merge Module signature has a version, I would suggest leaving the GUID the same and just up'ing the version number... unless the Merge Module is some breaking change and installs everything to completely different locations. - 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] Calling a CustomAction defined in an MSM.
Actually, your suggestion about using Fragments is a very much recommended. Merge Modules should be used when you are distributing blocks of code to across organizations that don't all use the WiX toolset. Otherwise, .wixlibs are far more efficient and powerful. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Dimmick Sent: Thursday, October 05, 2006 8:04 AM To: Carlos O'Donell; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Calling a CustomAction defined in an MSM. I think it's simply that all the references are resolved by the linker _before_ the MSMs are merged in. This makes it impossible to reference anything in the MSM. I think merge module custom actions should be scheduled by authoring them in the ModuleInstallExecuteSequence (or ModuleInstallUISequence) table. Merging the module then places the custom action in the right relative place in the corresponding Install sequence. I'm not sure how to do this with WiX - it's possible that including the InstallExecuteSequence in a Module will do the right thing. If all your installers are using WiX, and you wrote this merge module, it seems to me that you might get better results by simply referencing WiX Fragments. If you have a lot of Fragments and you want to save the compile time, you could use lit.exe to make a .wixlib from the resulting .wixobj files. Anyone know better? -- Mike Dimmick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos O'Donell Sent: 02 October 2006 20:59 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Calling a CustomAction defined in an MSM. WiX Users, I have an MSM that defines a set of CustomAction entries. The MSM is merged into the MSI, and it is my responsibility to execute the MSM's custom actions. Unfortunately when I compile my project, light rightly complains: C:\xxx\yyy.xml : error LGHT0112 : Unresolved reference to symbol 'CustomAction:foo' in section 'Product:12345678-1234-1234-1234-123456789012'. It would seem that the CutomAction's in an MSM are not available from the MSI? It is essentially this issue: [ 1541952 ] Unresolved Reference error when using CA declared in MSM The original response seems to be: You cannot create references from products into merge modules. Why is this the case? Is someone able to clarify why products can't reference or call custom actions in merge modules? Any guidance is much appreciated. Cheers, Carlos. - 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=DEVDE V ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - 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 - 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] No messages from WiX-Users for 2 days
I actually thought the mailing bounced me off the list (again). I think now it was just an outage in SF tons of mail showed up today. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stefan Pavlik Sent: Thursday, October 05, 2006 3:45 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] No messages from WiX-Users for 2 days Hi all Anybody has an Idea why the wix-users forum is not working? I haven't received any mail from this forum for two days (since 2006-10-03). I hope that it is not the end of the WiX forum Stefan -- View this message in context: http://www.nabble.com/No-messages-from-WiX-Users-for-2-days-tf2387690.html#a6656305 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 - 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] Access violation in light.exe (v2.0.4005.0)
You could try moving to a more recent build. There were some minor fixes but nothing that I think will actually fix this. Im a bit at a loss on how to even go about debugging this. What version of the CLR are you running? I wonder if maybe there is a double Dispose() in the code somehow. Does this happen often? Is there a way to get a debugger on it? We could pull the exception handler off of light.exe to see if we cant get it to fault into the default debugger on the machine if it repros often. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ilya Kleyman Sent: Thursday, October 05, 2006 9:34 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Access violation in light.exe (v2.0.4005.0) Wix-Users, We are seeing the following access violation in light.exe (filever 2.0.4409.0) that seems to have something to do with concurrent invocation of two instances of light.exe. Has anyone seen something similar? Unhandled Exception: System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt. at Microsoft.Tools.WindowsInstallerXml.Msi.Interop.MsiInterop.MsiCloseHandle(IntPtr database) at Microsoft.Tools.WindowsInstallerXml.Msi.MsiHandle.Close() at Microsoft.Tools.WindowsInstallerXml.Msi.MsiHandle.Dispose(Boolean disposing) at Microsoft.Tools.WindowsInstallerXml.Msi.MsiHandle.Finalize() Two build threads simultaneously laying out two different MSIs were working at the time of failure (prefix at the beginning of each line is build-thread index) Excerpts from the build-log showing the immediate pre-history of the problem is below. Stop. message indicates that the build thread has finished its work. I am omitting non-essential information for clarity. 101 tools\light.exe -nologo -wx -v0 -out .msi Xa.wixobj Xb.wixobj Xc.wixobj Z1.wixobj Z2.wixobj sca.wixlib wixca.wixlib 102 tools\light.exe -nologo -wx -v0 -out .msi Ya.wixobj Yb.wixobj Yc.wixobj Z1.wixobj Z2.wixobj sca.wixlib wixca.wixlib 102Updating file information. 101Updating file information. 102Generating database. 102Merging modules. 101Generating database. 101Merging modules. 102Processing media information. 102Cabbing file X0001.aaa . . . . 68 files 101Processing media information. 101Cabbing file Y0001.bbb . . . . 149 files 102Importing streams. 102Importing binary stream from X0001.ccc . . . . 12 streams, icons, cabs 101Importing streams. 101Importing binary stream from Y0001.ddd . . . . 15 streams, icons, cabs 102Laying out media. 102Moving file . . . .\txxd3s8j\.msi' to . . . X.msi'. . . . 102Stop. . . . . 101Laying out media. 101Moving file . . . \b4fepmve\.msi' to . . . .msi. 101Copying file . . . \DIR1\ABCDEF.sys' to . . .\DIR2\ABCDEF.sys'. . . . 101 101Unhandled Exception: System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt. 101 at Microsoft.Tools.WindowsInstallerXml.Msi.Interop.MsiInterop.MsiCloseHandle(IntPtr database) 101 at Microsoft.Tools.WindowsInstallerXml.Msi.MsiHandle.Close() 101 at Microsoft.Tools.WindowsInstallerXml.Msi.MsiHandle.Dispose(Boolean disposing) 101 at Microsoft.Tools.WindowsInstallerXml.Msi.MsiHandle.Finalize() . . . 101NMAKE : fatal error U1077: . . \tools\light.exe' : return code '0xc005' 101Stop. Thanks, Ilya - 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] Displaying status text for CAQuietExec action ?
Petr Vones wrote: And another related question. I have multiple deferred CAQuietExec actions. Is possible detect which of them had failed and display corresponding error message ? I tried to use the action value as a condition without a luck. Not really. When the CA fails, MSI rolls the install back. If you need finer-grained control than that, you'll want a DLL CA. -- sig://boB http://bobs.org - 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] Where to start? V2 or V3?
On Tue, 3 Oct 2006 13:02:42 -0400 Darrel Miller [EMAIL PROTECTED] wrote: Not that my opinion should carry much weight considering Rob has already voiced his opinion, but he is obligated to take a more cautious stance than the rest of us. I would move whole heartedly to V3. Just the shortfilename, longfilename stuff alone was worth the move for me. Disclaimer: I'm not doing installs of anything particularly complex... The only problem I know of is the lacking of documentation. For instance the help file included in wix3 contains docs for wix2. I've been thinking of going for Wix3, but since theres very limited docs for it I probably want to go for Wix2. -- chs - 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] Wix3.msi build 3.0.2128.0 doesn't recognize VS 2005 properly
Antti Järvinen wrote: I'm trying to install Wix3.msi to my computer. Installation succeeds and but wix projects doesn't work in Visual Studio 2005 Professional. Some of VS2005 properties seems to point D:\ directory. Can you export the values in your HKLM\SOFTWARE\Microsoft\VisualStudio\8.0\Setup\VS registry key and post them in a message? -- sig://boB http://bobs.org - 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] Votive 3 (ErrorDialog) error
Magus wrote: I keep getting an error with my ErrorDlg Error LGHT0204: ICE20: Specified ErrorDialog: 'ErrorDlg' not found in Dialog table (or its Control_First control is not 'ErrorText'). I have my ErrorDlg created just fine so the problem is the Control_First not being ErrorText. I do have an errorText in my Dialog, but I don't know how to in Votive or Wix to make it the Control_First WiX sets the first Control child of Dialog as Control_First. -- sig://boB http://bobs.org - 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] ForceReboot action during Uninstallation(2)
Stefan Pavlik wrote: Problem is that the msiexec wants to start the temporary file in C:\Windows\Installer\ which was deleted (and this is problem) during cleanup before reboot. When are you scheduling ForceReboot? The cached package shouldn't be removed until the install completes. Am I doing something wrong? Or the ForceReboot action just should not be used during uninstall? Well, it's pretty rude, but...g -- sig://boB http://bobs.org - 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] Set selection tree options
Anton Filippov wrote: I'm trying follow combination, but I've install, not install and network install. How to remove network install? Make sure your features have components and not just child features. Even if the feature favors local, MSI offers run-from-source as an option if there are no components. -- sig://boB http://bobs.org - 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] Please help... disable feature based on another feature
Michael Carlisle wrote: Can someone help. I have a SelectionTree and need to disable or enable a hidden feature based on the selection of another feature. I've worked out I can use publish events on my next button to enable or disable a feature based on a property, but how can I base this on the status of another feature instead? Alternatively if I can set a property when a feature status is changed in the ui I could make this work, but not sure how to do that? In the Next button, publish AddLocal and Remove control events to enable or disable the feature. Use FeatureName to check the feature's action state (see Conditional Statement Syntax in the MSI SDK for details). -- sig://boB http://bobs.org - 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] Where to start? V2 or V3?
Christer Solskogen wrote: The only problem I know of is the lacking of documentation. For instance the help file included in wix3 contains docs for wix2. The WiX.chm in the WiX v3 releases contains schema doc for WiX v3. There are other topics that refer to WiX v2, however. -- sig://boB http://bobs.org - 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] Preselecting feature and disable install on first use
vbtricks wrote: But no matter which attributes I add to the extension feature, it is not preselected. Can you help me? What do you mean by preselected? -- sig://boB http://bobs.org - 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] .Net assembly registration possible bug
David Welch wrote: If I have _mainFile at the bottom of the component everything works. If I have _componentFile1 at the bottom, this file is added to the msi as a .Net assembly with version 0.0.0.0. Registration does not work on this file because I don't think it has a strong name. Anyway, I would expect the KeyPath file to be the file that is added to the MsiAssemblyName tables. Also I though each dll had to be in its own component, or is this no longer the case. I believe MSI needs each assembly in its own component, though I can't find any doc on that. But it also sounds like a linker bug that it puts in the wrong assembly version. Can you file a bug that shows how to reproduce the problem? -- sig://boB http://bobs.org - 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] WiX 3 in Team Foundation Build
Hi Rob. Do you have any details on what specific domain policy is giving Light a headache? I can have that changed, but only if I know what specific policy setting is causing the issue. Id like to do that explicitly for our Team Foundation Server, rather than opening up security holes by adding DOMAIN\TFSService to local Administrators (which didnt work, maybe Ill have more on that later). Thanks, Rob. Thanks, Mike. Thanks, Bob (Outlook Desktop Alert was driving me nuts on your reply fest :D) Joel Peterson [EMAIL PROTECTED] From: Rob Mensching [mailto:[EMAIL PROTECTED] Sent: Thursday, October 05, 2006 9:44 AM To: Mike Dimmick; Peterson, Joel; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] WiX 3 in Team Foundation Build Mike is correct. However, ideally, youd look at getting the policy in the domain tweaked so you could run validation on your build servers. You will catch bugs much earlier running it there. If worse comes to worse, maybe you could only suppress validation on the build machines but ensure all dev machines still run validation. In case anyone hasnt noticed, Mike is just tearing up the mailing list with answers that are almost always *right on target* (very few times have I thought, Well, I would do that a bit differently, but whatever). If you havent said, Thanks, Mike recently, you should do that. At the same time, you might also say, Thanks, Bob since Bob also does quite a bit of work here (Bobs just been busy lately moving into his new condo). And, dont let these guys scare you away. If you know the answer to someone elses question, feel free to fire it off. If youre not quite right, someone will provide slightly adjusted guidance. One of the best ways to learn something well is to give a slightly wrong answer and then get corrected well, at least I remember those cases very well. smile/ Okay, time for me to get back to shipping Vista. Thanks, Mike. Thanks, Bob. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Dimmick Sent: Thursday, October 05, 2006 7:48 AM To: Peterson, Joel; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] WiX 3 in Team Foundation Build light.exe has, I believe,to load the .msi in order to perform the validation step. For the moment, you could suppress validation with the -sval switch which I think is a SuppressValidation property (I'm not familiar with MSBuild). -- Mike Dimmick From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peterson, Joel Sent: 04 October 2006 01:19 To: wix-users@lists.sourceforge.net Subject: [WiX-users] WiX 3 in Team Foundation Build Hi all. Im new to this list so please correct me if this has already been discussed. Ive installed the latest weekly build of WiX 3 on my development system and also on my Team Foundation Server/Team Foundation Build. The WiX solution builds fine on my development system, in all Debug/Release configurations. I checked that solution in to the main project on the Team Foundation Server, and configured a Build for it. When I start the build, its all run with the DOMAIN\TFSService user account as specified in the Team Foundation Installation manual. Everything runs fine, until it gets to Light: Target PrepareForBuild: Creating directory obj\Release\. Creating directory D:\Build\ProjectName\WiX - Web Client Printer\Binaries\Release\. Target Compile: C:\Program Files\Windows Installer XML v3\bin\candle.exe -out obj\Release\Web Client Printer.wixobj Web Client Printer.wxs Target Link: C:\Program Files\Windows Installer XML v3\bin\Light.exe -out D:\Build\ProjectName\WiX - Web Client Printer\Binaries\Release\Web_Client_Printer.msi obj\Release\Web Client Printer.wixobj light.exe : error LGHT0216: An unexpected Win32 exception with error code 0x659 occurred: This installation is forbidden by system policy. Contact your system administrator Done building target Link in project Web Client Printer.wixproj -- FAILED. This error is what one would get if they ran a MSI with a user account that did not have Administrative priviledges, but why would that appear during the link process? The Team Foundation Server Installation manual specifically says not to give DOMAIN\TFSService administrative priviledges for security reasons, but I did anyways to see if it would get around this issue. It did not, and I still received the same error message. I can provide the full build log if necessary, I havent had a chance to redact it yet. Joel Peterson [EMAIL PROTECTED] - 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
Re: [WiX-users] Embedding MSI in a bootstrapper
If the Installation is interrupted by the user then the extracted MSI could still be left behind, I don't want the file to be left on the end Users computer. Rob Mensching-2 wrote: You have to extract it. The Windows Installer engine doesn't know how to read MSI files out of resource streams. Besides, you're going to want to put the MSI in a place where future repair operations can find it. Otherwise the user will get prompted to find an MSI that is hidden inside your boostrapper (which may or may not be around anymore). You can see the setup.exe with WiX v3 caches. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Magus Sent: Tuesday, October 03, 2006 3:24 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Embedding MSI in a bootstrapper Not really a wix questions, but I did create my program in wix, just wondering if anyone had done this before. My bootstrapper is suppose to control the UI for the Installer, and also check to see if the file is already installed and prompt user to play or uninstall if it is already installed. With that in mind I don't want to user to run the MSI itself I want to insure that that run the Bootstrapper. Is there a way to embed the msi inside the bootstrapper as a resource and then run it? I would like not to have to extract the MSI during runtime but to instead just run it from resource if its possible -- View this message in context: http://www.nabble.com/Embedding-MSI-in-a-bootstrapper-tf2379080.html#a6630105 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 - 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 -- View this message in context: http://www.nabble.com/Embedding-MSI-in-a-bootstrapper-tf2379080.html#a6665791 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] Embedding MSI in a bootstrapper
That's why I'm planning to write a Disk Clean-up Wizard plug-in for WiX. smile/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Magus Sent: Thursday, October 05, 2006 11:42 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Embedding MSI in a bootstrapper If the Installation is interrupted by the user then the extracted MSI could still be left behind, I don't want the file to be left on the end Users computer. - 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
[WiX-users] Custom Action Return code changed from SUCCESS to FAILURE?
In a C++ custom action DLL we have, we are returning an ERROR_SUCCESS at the end of our action. But it seems like the value is being changed after we leave our dll into ERROR_INSTALL_FAILURE and the install rolls back. What could cause this and what can I do to protect our action? Thanks for your input Below is a log snippet: [3828] MSI (a) (F4:D4) [15:38:20:324]: Passing to service: MsiRecordSetString(67, 1, Return ERROR_SUCCESS) [3828] [3828] MSI (a) (F4:D4) [15:38:20:324]: Passing to service: MsiRecordSetString(67, 0, [1]) [3828] [3828] MSI (a) (F4:D4) [15:38:20:324]: Passing to service: MsiProcessMessage(0, 67108864, 67) [3828] [3828] MSI (a) (F4:D4) [15:38:20:324]: Passing to service: MsiCloseHandle(67) [3828] [3828] MSI (a) (F4:D4) [15:38:20:324]: Custom Action RunDefCA returned unexpected value 0. Converted to ERROR_INSTALL_FAILURE. [3828] [3828] MSI (a) (F4:D4) [15:38:20:334]: Custom action server's custom action is returning 1603. (C:\WINDOWS\Installer\MSI48.tmp, RunDefCA) [3828] [2244] MSI (s) (C4:10) [15:38:20:334]: User policy value 'DisableRollback' is 0 - 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] Votive 3 (ErrorDialog) error
Title: Re: [WiX-users] Votive 3 (ErrorDialog) error I'm going to hazard a guess that Text controls can't receive the focus, and therefore that they're not normally allowed to be the Control_First. However, I see that WixUI's ErrorDlg uses TabSkip="no" to work around this issue. The code in ParseControlElement in src\wix\Compiler.cs normally sets Billboard, Bitmap, GroupBox, Icon, Line, ProgressBar, Text andVolumeCostList controls to be 'not tabbable', and therefore not in consideration for being Control_First. The TabSkip attribute can be used to override this. This attribute is also used to set the tab order (Control_Next in the Control/BBControl table). -- Mike Dimmick From: [EMAIL PROTECTED] on behalf of Bob ArnsonSent: Thu 05/10/2006 20:12To: MagusCc: wix-users@lists.sourceforge.netSubject: Re: [WiX-users] Votive 3 (ErrorDialog) error Magus wrote: I wish that were happening, but its not. I thought that might be the case but its not working that way.You might want to take a look at how WixUI's ErrorDlg works.--sig://boBhttp://bobs.org-Take Surveys. Earn Cash. Influence the Future of ITJoin SourceForge.net's Techsay panel and you'll get the chance to share youropinions on IT business topics through brief surveys -- and earn cashhttp://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___WiX-users mailing listWiX-users@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wix-users- 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] Votive 3 (ErrorDialog) error
That worked changing to TabSkip=no just something I guess I overlooked. Mike Dimmick wrote: I'm going to hazard a guess that Text controls can't receive the focus, and therefore that they're not normally allowed to be the Control_First. However, I see that WixUI's ErrorDlg uses TabSkip=no to work around this issue. The code in ParseControlElement in src\wix\Compiler.cs normally sets Billboard, Bitmap, GroupBox, Icon, Line, ProgressBar, Text and VolumeCostList controls to be 'not tabbable', and therefore not in consideration for being Control_First. The TabSkip attribute can be used to override this. This attribute is also used to set the tab order (Control_Next in the Control/BBControl table). -- Mike Dimmick From: [EMAIL PROTECTED] on behalf of Bob Arnson Sent: Thu 05/10/2006 20:12 To: Magus Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Votive 3 (ErrorDialog) error Magus wrote: I wish that were happening, but its not. I thought that might be the case but its not working that way. You might want to take a look at how WixUI's ErrorDlg works. -- sig://boB http://bobs.org http://bobs.org/ - 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 - 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 -- View this message in context: http://www.nabble.com/Votive-3-%28ErrorDialog%29-error-tf2379414.html#a6668796 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] Access violation in light.exe (v2.0.4005.0)
Rob, MSDN documentation for MsiCloseHandle at http://windowssdk.msdn.microsoft.com/en-us/library/aa370067.aspx says that the function must be called from the same thread that requested creation of the handle. Given that the below call-stack is that of a finalizer called into by .NET GC, it is not clear how this requirement can be satisfied by managed code, which does not know what thread GC will use to call. Just a random shot. Ilya From: Ilya Kleyman Sent: Thursday, October 05, 2006 11:05 AM To: Rob Mensching; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Access violation in light.exe (v2.0.4005.0) What is the most recent WIX build? We run against released .NET 2.0 CLR (Whidbey build v2.0.50727) This happened only once so far. Weve been using WIX for more than a year. Last time we upgraded was in April this year, to v2.0.4005.0 I dont know how to get this to repro under debugger. We dont know how to repro it at all seems like a one-off random issue. Dont know whether it is relevant or not, but examining the part of the build log that is immediately preceding the crash, I see that build-thread 102 was calling into candle.exe (in the previous e-mail I had dots in the place where this was happening). Here is the updated part of the log: 102Stop. . . . 102 tools\wixcop.exe -nologo -f -indent:4 CC.wxs 102 tools\candle.exe -nologo -wx -IDIR1 -IDIR2 -DVAR1=VAL1 -dVAR2=VAL2 -dMSI_COMPRESSION_LEVEL=high -out .wixobj dVAR3=VAL3 CC.wxs 101Laying out media. 101Moving file . . . \b4fepmve\.msi' to . . . .msi. 101Copying file . . . \DIR1\ABCDEF.sys' to . . .\DIR2\ABCDEF.sys'. . . . 101 101Unhandled Exception: System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt. 101 at Microsoft.Tools.WindowsInstallerXml.Msi.Interop.MsiInterop.MsiCloseHandle(IntPtr database) 101 at Microsoft.Tools.WindowsInstallerXml.Msi.MsiHandle.Close() 101 at Microsoft.Tools.WindowsInstallerXml.Msi.MsiHandle.Dispose(Boolean disposing) 101 at Microsoft.Tools.WindowsInstallerXml.Msi.MsiHandle.Finalize() 102 CC.wxs 102 tools\candle.exe -nologo -wx -IDIR1 -IDIR2 -dVAR1=VAL1 -dVAR2=VAL2 -dMSI_COMPRESSION_LEVEL=high -out .wixobj FF.wxs 102 F.wxs 101NMAKE : fatal error U1077: . . \tools\light.exe' : return code '0xc005' 101Stop. Ilya From: Rob Mensching Sent: Thursday, October 05, 2006 10:01 AM To: Ilya Kleyman; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Access violation in light.exe (v2.0.4005.0) You could try moving to a more recent build. There were some minor fixes but nothing that I think will actually fix this. Im a bit at a loss on how to even go about debugging this. What version of the CLR are you running? I wonder if maybe there is a double Dispose() in the code somehow. Does this happen often? Is there a way to get a debugger on it? We could pull the exception handler off of light.exe to see if we cant get it to fault into the default debugger on the machine if it repros often. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ilya Kleyman Sent: Thursday, October 05, 2006 9:34 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Access violation in light.exe (v2.0.4005.0) Wix-Users, We are seeing the following access violation in light.exe (filever 2.0.4409.0) that seems to have something to do with concurrent invocation of two instances of light.exe. Has anyone seen something similar? Unhandled Exception: System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt. at Microsoft.Tools.WindowsInstallerXml.Msi.Interop.MsiInterop.MsiCloseHandle(IntPtr database) at Microsoft.Tools.WindowsInstallerXml.Msi.MsiHandle.Close() at Microsoft.Tools.WindowsInstallerXml.Msi.MsiHandle.Dispose(Boolean disposing) at Microsoft.Tools.WindowsInstallerXml.Msi.MsiHandle.Finalize() Two build threads simultaneously laying out two different MSIs were working at the time of failure (prefix at the beginning of each line is build-thread index) Excerpts from the build-log showing the immediate pre-history of the problem is below. Stop. message indicates that the build thread has finished its work. I am omitting non-essential information for clarity. 101 tools\light.exe -nologo -wx -v0 -out .msi Xa.wixobj Xb.wixobj Xc.wixobj Z1.wixobj Z2.wixobj sca.wixlib wixca.wixlib 102 tools\light.exe -nologo -wx -v0 -out .msi Ya.wixobj Yb.wixobj Yc.wixobj Z1.wixobj Z2.wixobj sca.wixlib wixca.wixlib 102Updating file information. 101Updating file information. 102Generating database. 102Merging modules. 101Generating database. 101Merging modules. 102Processing media information. 102Cabbing file X0001.aaa . . . . 68 files 101Processing media information. 101Cabbing file Y0001.bbb
Re: [WiX-users] Calling a CustomAction defined in an MSM.
On 10/5/06, Mike Dimmick [EMAIL PROTECTED] wrote: I think it's simply that all the references are resolved by the linker _before_ the MSMs are merged in. This makes it impossible to reference anything in the MSM. Mike, Thanks for the reply. Yes, It was initially obvious that the wix linker resolves references befor merging the MSM. I don't know if this is the right thing to do in this case. I think merge module custom actions should be scheduled by authoring them in the ModuleInstallExecuteSequence (or ModuleInstallUISequence) table. Merging the module then places the custom action in the right relative place in the corresponding Install sequence. I'm not sure how to do this with WiX - it's possible that including the InstallExecuteSequence in a Module will do the right thing. Ok, thanks for this recommendations. If all your installers are using WiX, and you wrote this merge module, it seems to me that you might get better results by simply referencing WiX Fragments. If you have a lot of Fragments and you want to save the compile time, you could use lit.exe to make a .wixlib from the resulting .wixobj files. Anyone know better? Unfortuantely all of my installers are not authored using wix. The MSM comes from a third party who prodives drivers through the MSM. More and more driver vendors are providing their files as MSM's, which is nice, but often the MSM's are broken by design. Cheers, Carlos. - 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] Calling a CustomAction defined in an MSM.
It is looking like this isn't going to be an easy thing to do, so I may push back and say Sequence the custom actions yourself please. Any comments from you would be much appreciated. The MSI SDK for Merge Modules agrees with you. They are not building their Merge Modules correctly. Anything you do will be a hack. It's usually better to avoid the hacks... smile/ - 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] Combobox websites
Morten: What are you trying to do specifically? We install WebSites WebAppPools based upon the results of checkboxes (checked value controls feature option that is selected for install). We use it to control which WebSite / WebAppPool is installed for our different application environments (Dev, Test, Qa, Prod). We added an additional Dialog to WixMondo that allows the IP values to be overridden dependent upon which environment check box is selected. David Adams MSN MessengerID: [EMAIL PROTECTED] Hi! Was wondering if anybody out there has played around with comboboxes and extracting the field based on user selection. I have a script that populates both websites and application pools to a combobox, and based on the user selection populate the given website and application pool with the package. For the combobox: Control Id=WebSiteCombo Type=ComboBox X=18 Y=126 Width=120 Height=100 Property=TARGETWEBCOMBO .. Control Id=AppPoolCombo Type=ComboBox X=210 Y=126 Width=120 Height=200 Property=TARGETAPPPOOLCOMBO If I use the reference to TARGETWEBCOMBO and TARGETAPPPOOLCOMBO after the user makes the selection form the combobox, I get the Value part and not the Text part of the combobox. What I really want to do is use something like this WebSite Id=Something Description=[TARGETWEBCOMBO] ... And have the package install itself under the given website. For the appPool: WebAppPool Id=Something Name=[TARGETAPPPOOLCOMBO] ... To get this to work in a not ideal way, I populated the Value field of the combobox with the site name to be able to use TARGETWEBCOMBO reference. Is there a way to select the Text field when one has the Value in the TARGETAPPPOOLCOMBO var? Also is it possible to reference the WebSite and WebAppPool in the manner I want to, so my website is installed under the one the user choose? Regards Morten - 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 - 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] Customizing the uninstall progress dialog.
Hi Bob, On 10/5/06, Bob Arnson [EMAIL PROTECTED] wrote: Alex Mendes da Costa wrote: I'm working on setting up an installer using WiX. When I uninstall my product, there's a dialog box displayed that just has a progress bar. I'd like to customize this uninstall dialog with some strings that explain to the user what's going on. Please would you let me know how to do that. I haven't found anything relevant in any of the documentation or in the examples that come with WiX. You can add ProgressText elements to add strings for each action but otherwise Add/Remove Programs runs uninstalls in basic UI mode so customization isn't possible. Thanks for your reply. I tried adding ProgressText elements in the UI section of my wxs, but it hasn't made any difference. Could you give me some more information about how I should set the attributes of the ProgressText element to get it to add strings to the uninstall dialog box? Here's the exact code I added: UI ... ProgressText Action='RemoveFiles' $(loc.UninstallProgressText) /ProgressText ProgressText Action='RemoveFolders' $(loc.UninstallProgressText) /ProgressText ProgressText Action='RemoveIniValues' $(loc.UninstallProgressText) /ProgressText ProgressText Action='RemoveRegistryValues' $(loc.UninstallProgressText) /ProgressText ProgressText Action='RemoveShortcuts' $(loc.UninstallProgressText) /ProgressText /UI where UninstallProgressText is the id of a string defined in my wxl file. Alex - 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
