Re: [WiX-users] Install .Net Framework 4
The bootstrapper instructions you supplied use a bootstrapper that creates a setup.exe file that runs the project-associated target file (your MSI file) after all other packages indicated in your build instructions are run. It is expected that the user will run the setup.exe, or that you will EXE-ZIP the entire resulting target directory and when double-clicked the self-extract exe will run the setup.exe. Bootstrappers run all installation packages one-by-one, with your MSI simply being one of the packages (usually the last one). -Original Message- From: Jason Ding [mailto:jas...@geo-slope.com] Sent: Thursday, June 17, 2010 9:05 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Install .Net Framework 4 I ran the Setup.msi because I think that is how user installs the product and then msi will execute the Setup.exe. Do you mean I should ran Setup.exe? If that is true, does Setup.exe then launch Setup.msi? Probably I misunderstood how wix and bootstrapper work, can you clarify please? Thank you! From: Blair [os...@live.com] Sent: June-17-10 7:13 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Install .Net Framework 4 The bootstrapper should run and install the indicated prerequisite packages before launching your MSI. Thus, your original launch condition looks appropriate. However, launching the MSI does not run the bootstrapper, as the MSI can't realistically install prerequisites. In your testing, are you launching the bootstrapper or the MSI? -Original Message- From: Jason Ding [mailto:jas...@geo-slope.com] Sent: Thursday, June 17, 2010 3:46 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Install .Net Framework 4 My launch condition in the .wxs file is: PropertyRef Id=NETFRAMEWORK40CLIENT/ Condition Message=[ProductName] requires Microsoft .NET Framework version 4.0 to run, click the OK button below to install. ![CDATA[Installed OR NETFRAMEWORK40CLIENT]] /Condition And in my wix project file, I ask Bootstrapper to install .NetFramework 4.0 Client, I think that is why the install fails because it checks if .NetFramework 4.0 Client exists, and it doesn't on my test machine, so the install fails before going ahead to instead .NetFramework 4.0 Client. I changed the launch condition to be NETFRAMEWORK20, now I can install successfully, but when I run the problem, it asks to install .NetFramework 4.0. So my questions are: 1. when I ask bootstrapper to install .NET Framework 4.0 Client, can I use .NET Framework 4.0 Client as the launch condition? 2. when I change launch condition to be an early version, like .NetFramewrok 2.0, why the install doesn't install .NetFramwork 4.0 Client, which is what Bootstrapper supposed to do? Below is the my code on Bootstrapper in the wixproj file. Many thanks for any help? ItemGroup BootstrapperPackage Include=.NETFramework,Version=v4.0,Profile=Client VisibleFalse/Visible ProductName.NET Framework 4.0 Client/ProductName InstallTrue/Install /BootstrapperPackage BootstrapperPackage Include=Microsoft.Windows.Installer.4.5 VisibleFalse/Visible ProductNameWindows Installer 4.5/ProductName Installtrue/Install /BootstrapperPackage /ItemGroup ... Target Name=AfterBuild GenerateBootstrapper ApplicationFile=$(TargetFileName) ApplicationName=My Application Name BootstrapperItems=@(BootstrapperPackage) ComponentsLocation=Relative CopyComponents=True OutputPath=$(OutputPath) Path=C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bootstrapper\/ /Target -Original Message- From: Blair [mailto:os...@live.com] Sent: June 17, 2010 4:33 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Install .Net Framework 4 What specifically is your LaunchCondition associated with that error text? -Original Message- From: Jason Ding [mailto:jas...@geo-slope.com] Sent: Thursday, June 17, 2010 2:24 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Install .Net Framework 4 Here is the log by using /L*vx options, i.e., all messages, it does indicate the LaunchConditions fails, but does anyone have a clue why it fails? Thanks. MSI (c) (6C:04) [15:18:29:270]: Doing action: LaunchConditions Action 15:18:29: LaunchConditions. Evaluating launch conditions Action start 15:18:29: LaunchConditions. GeoStudio 2010 requires Microsoft .NET Framework version 4.0 to run, click the OK button below to install. MSI (c) (6C:04) [15:18:30:996]: Product: GeoStudio 2010 -- GeoStudio 2010 requires Microsoft .NET Framework version 4.0 to run, click the OK button below to install.
Re: [WiX-users] Deferred custom action Impersonation.
if i have a deferr=red custom action with Impersonate=yes. then on Windows Vista with UAC enabled i get a prompt asking if the user wishes the allow the program to access your computer. now if the user presses allow in UAC prompt. Will my custom action be able to connect to SQL server on another machine using windows authentication. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Deferred-custom-action-Impersonation-tp5191516p5194260.html Sent from the wix-users mailing list archive at Nabble.com. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] ModuleInstallExecuteSequence
ModuleInstallExecuteSequence doesn't exist in an MSI, only an MSM - http://msdn.microsoft.com/en-us/library/aa370049(VS.85).aspx Even if you get your Custom Action into it, your MSI is still going to have the same problem once the merge module is consumed if the Custom Action is not Conditioned appropriately. Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Yuichi Kuroda [mailto:satellitek...@hotmail.com] Sent: 17 June 2010 19:52 To: wix-users@lists.sourceforge.net Subject: [WiX-users] ModuleInstallExecuteSequence Hello everyone,Does WIX support modifying the ModuleInstallExecuteSequence table in any way? It's obviously not in thedocumentation, and I thought I've seen it used somewhere in WIX before when I didn't need it, until now which I need to runCustom Actions only if the Merge Module (aka Feature) is to be installed. Giving conditions likeMyFeature 2 in the MM didn't work because it's not aware of the features. Thanks for any help in advance. _ Hotmail: Free, trusted and rich email service. https://signup.live.com/signup.aspx?id=60969 -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Deferred custom action Impersonation.
http://www.joyofsetup.com/2007/09/24/test-your-setups-virtually/ Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Sagar [mailto:sagarkavitak...@gmail.com] Sent: 18 June 2010 08:11 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Deferred custom action Impersonation. if i have a deferr=red custom action with Impersonate=yes. then on Windows Vista with UAC enabled i get a prompt asking if the user wishes the allow the program to access your computer. now if the user presses allow in UAC prompt. Will my custom action be able to connect to SQL server on another machine using windows authentication. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Deferred-c ustom-action-Impersonation-tp5191516p5194260.html Sent from the wix-users mailing list archive at Nabble.com. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Quiet Execution of an executable embedded within the MSI
Binary Elements are extracted to temporary directories using auto generated filenames (see a verbose log for an example). It's not possible to use an application in a Binary Element with QtExec (I looked at the same thing a while ago for a plug-in installer). You'll either need to change it to use a File Element modify the CustomAction to use [#fileid] instead of quot;myexec.exequot; or live without QtExec or as Blair says, write your own Custom Actions to write the Binary to disk in a known location so QtExec can run it. Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Leigh Wetmore [mailto:lwetm...@gmail.com] Sent: 17 June 2010 18:29 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Quiet Execution of an executable embedded within the MSI Hello, I'm trying to figure out how to quietly execute (QtExec) an executable that I include within my MSI yet do not want installed on the user's machine. I've been able to achieve this without using the quiet execute feature, but I don't like the command window popping up during installation. Here is the code for that: Binary Id=CfgUpdateExe SourceFile=..\bin\myexe.exe / CustomAction Id=LaunchCfgUpdateExe BinaryKey=CfgUpdateExe ExeCommand=quot;[TempFolder]UpdateLog.txtquot; UpdateAppConfig quot;[DASLocation]myexec.exe.Configquot; Execute=deferred Impersonate=no Return=asyncNoWait / InstallExecuteSequence Custom Action=LaunchCfgUpdateExe After=InstallInitializeOLDERVERSIONDETECTED/Custom /InstallExecuteSequence I use the binary element to bring the executable (myexe.exe) into the MSI, then launch a custom action with the necessary arguments. I have it executing as deferred with no impersonation as I need the admin privileges already captured by the installer to carry through to the executable. Again, this works fine. However, if I try to convert this to use QtExec, I'm unable to get it to work. Looking in the MSI install log, I see: CAQuietExec: Error 0x80070002: Command failed to execute. CAQuietExec: Error 0x80070002: CAQuietExec Failed Here is my code so far: Binary Id=CfgUpdateExe SourceFile=..\bin\myexec.exe / CustomAction Id=QtExecCommand Property=QtExecUserCfg Value=quot;myexec.exequot; quot;[TempFolder]UpdateLog.txtquot; quot;UpdateAppConfigquot; quot;[DASLocation]myexec.exe.Configquot; Execute=immediate / CustomAction Id=QtExecUserCfg BinaryKey=WixCA DllEntry=CAQuietExec Execute=deferred Impersonate=no Return=check/ InstallExecuteSequence Custom Action=QtExecCommand After=CostFinalizeOLDERVERSIONDETECTED/Custom Custom Action=QtExecUserCfg After=InstallInitializeOLDERVERSIONDETECTED/Custom /InstallExecuteSequence I've left the binary element there, but I don't think the custom actions know about it. It looks like QtExec can't find the executable which makes sense (I can have it run notepad.exe no problem). I'm thinking maybe the files in the MSI, including myexec.exe, get extracted to a temp directory during installation, and I can potentially reference it, like Value=quot;[MSITempDir]myexec.exe...? Thanks in advance for any help anyone can provide. Leigh -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Quiet Execution of an executable embedded within the MSI
Thanks for the responses - I've gone with the file element. I don't really want the executable written to disk (it serves no purpose to the end user), but there's no harm in it being there. On Fri, Jun 18, 2010 at 7:28 AM, Pally Sandher pally.sand...@iesve.comwrote: Binary Elements are extracted to temporary directories using auto generated filenames (see a verbose log for an example). It's not possible to use an application in a Binary Element with QtExec (I looked at the same thing a while ago for a plug-in installer). You'll either need to change it to use a File Element modify the CustomAction to use [#fileid] instead of quot;myexec.exequot; or live without QtExec or as Blair says, write your own Custom Actions to write the Binary to disk in a known location so QtExec can run it. Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Leigh Wetmore [mailto:lwetm...@gmail.com] Sent: 17 June 2010 18:29 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Quiet Execution of an executable embedded within the MSI Hello, I'm trying to figure out how to quietly execute (QtExec) an executable that I include within my MSI yet do not want installed on the user's machine. I've been able to achieve this without using the quiet execute feature, but I don't like the command window popping up during installation. Here is the code for that: Binary Id=CfgUpdateExe SourceFile=..\bin\myexe.exe / CustomAction Id=LaunchCfgUpdateExe BinaryKey=CfgUpdateExe ExeCommand=quot;[TempFolder]UpdateLog.txtquot; UpdateAppConfig quot;[DASLocation]myexec.exe.Configquot; Execute=deferred Impersonate=no Return=asyncNoWait / InstallExecuteSequence Custom Action=LaunchCfgUpdateExe After=InstallInitializeOLDERVERSIONDETECTED/Custom /InstallExecuteSequence I use the binary element to bring the executable (myexe.exe) into the MSI, then launch a custom action with the necessary arguments. I have it executing as deferred with no impersonation as I need the admin privileges already captured by the installer to carry through to the executable. Again, this works fine. However, if I try to convert this to use QtExec, I'm unable to get it to work. Looking in the MSI install log, I see: CAQuietExec: Error 0x80070002: Command failed to execute. CAQuietExec: Error 0x80070002: CAQuietExec Failed Here is my code so far: Binary Id=CfgUpdateExe SourceFile=..\bin\myexec.exe / CustomAction Id=QtExecCommand Property=QtExecUserCfg Value=quot;myexec.exequot; quot;[TempFolder]UpdateLog.txtquot; quot;UpdateAppConfigquot; quot;[DASLocation]myexec.exe.Configquot; Execute=immediate / CustomAction Id=QtExecUserCfg BinaryKey=WixCA DllEntry=CAQuietExec Execute=deferred Impersonate=no Return=check/ InstallExecuteSequence Custom Action=QtExecCommand After=CostFinalizeOLDERVERSIONDETECTED/Custom Custom Action=QtExecUserCfg After=InstallInitializeOLDERVERSIONDETECTED/Custom /InstallExecuteSequence I've left the binary element there, but I don't think the custom actions know about it. It looks like QtExec can't find the executable which makes sense (I can have it run notepad.exe no problem). I'm thinking maybe the files in the MSI, including myexec.exe, get extracted to a temp directory during installation, and I can potentially reference it, like Value=quot;[MSITempDir]myexec.exe...? Thanks in advance for any help anyone can provide. Leigh -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky
Re: [WiX-users] ModuleInstallExecuteSequence
Mergemod.dll takes the rows in the ModuleInstallExecuteSequence table and inserts them into the InstallExecuteSequence table. As I said in a previous post, the key is to use Component Action states not Feature Action states in the conditional expressions. Anything else creates an akward releationship between the module and the consumer ( msi ). Christopher Painter, Author of Deployment Engineering Blog Have a hot tip, know a secret or read a really good thread that deserves attention? E-Mail Me - Original Message From: Pally Sandher pally.sand...@iesve.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Fri, June 18, 2010 5:17:56 AM Subject: Re: [WiX-users] ModuleInstallExecuteSequence ModuleInstallExecuteSequence doesn't exist in an MSI, only an MSM - http://msdn.microsoft.com/en-us/library/aa370049(VS.85).aspx Even if you get your Custom Action into it, your MSI is still going to have the same problem once the merge module is consumed if the Custom Action is not Conditioned appropriately. Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Yuichi Kuroda [mailto:satellitek...@hotmail.com] Sent: 17 June 2010 19:52 To: wix-users@lists.sourceforge.net Subject: [WiX-users] ModuleInstallExecuteSequence Hello everyone,Does WIX support modifying the ModuleInstallExecuteSequence table in any way? It's obviously not in thedocumentation, and I thought I've seen it used somewhere in WIX before when I didn't need it, until now which I need to runCustom Actions only if the Merge Module (aka Feature) is to be installed. Giving conditions likeMyFeature 2 in the MM didn't work because it's not aware of the features. Thanks for any help in advance. _ Hotmail: Free, trusted and rich email service. https://signup.live.com/signup.aspx?id=60969 -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Install .Net Framework 4
Thanks Blair for clarification, my setup is now working as expected. Appreciate your help! -Original Message- From: Blair [mailto:os...@live.com] Sent: June 18, 2010 12:19 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Install .Net Framework 4 The bootstrapper instructions you supplied use a bootstrapper that creates a setup.exe file that runs the project-associated target file (your MSI file) after all other packages indicated in your build instructions are run. It is expected that the user will run the setup.exe, or that you will EXE-ZIP the entire resulting target directory and when double-clicked the self-extract exe will run the setup.exe. Bootstrappers run all installation packages one-by-one, with your MSI simply being one of the packages (usually the last one). -Original Message- From: Jason Ding [mailto:jas...@geo-slope.com] Sent: Thursday, June 17, 2010 9:05 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Install .Net Framework 4 I ran the Setup.msi because I think that is how user installs the product and then msi will execute the Setup.exe. Do you mean I should ran Setup.exe? If that is true, does Setup.exe then launch Setup.msi? Probably I misunderstood how wix and bootstrapper work, can you clarify please? Thank you! From: Blair [os...@live.com] Sent: June-17-10 7:13 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Install .Net Framework 4 The bootstrapper should run and install the indicated prerequisite packages before launching your MSI. Thus, your original launch condition looks appropriate. However, launching the MSI does not run the bootstrapper, as the MSI can't realistically install prerequisites. In your testing, are you launching the bootstrapper or the MSI? -Original Message- From: Jason Ding [mailto:jas...@geo-slope.com] Sent: Thursday, June 17, 2010 3:46 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Install .Net Framework 4 My launch condition in the .wxs file is: PropertyRef Id=NETFRAMEWORK40CLIENT/ Condition Message=[ProductName] requires Microsoft .NET Framework version 4.0 to run, click the OK button below to install. ![CDATA[Installed OR NETFRAMEWORK40CLIENT]] /Condition And in my wix project file, I ask Bootstrapper to install .NetFramework 4.0 Client, I think that is why the install fails because it checks if .NetFramework 4.0 Client exists, and it doesn't on my test machine, so the install fails before going ahead to instead .NetFramework 4.0 Client. I changed the launch condition to be NETFRAMEWORK20, now I can install successfully, but when I run the problem, it asks to install .NetFramework 4.0. So my questions are: 1. when I ask bootstrapper to install .NET Framework 4.0 Client, can I use .NET Framework 4.0 Client as the launch condition? 2. when I change launch condition to be an early version, like .NetFramewrok 2.0, why the install doesn't install .NetFramwork 4.0 Client, which is what Bootstrapper supposed to do? Below is the my code on Bootstrapper in the wixproj file. Many thanks for any help? ItemGroup BootstrapperPackage Include=.NETFramework,Version=v4.0,Profile=Client VisibleFalse/Visible ProductName.NET Framework 4.0 Client/ProductName InstallTrue/Install /BootstrapperPackage BootstrapperPackage Include=Microsoft.Windows.Installer.4.5 VisibleFalse/Visible ProductNameWindows Installer 4.5/ProductName Installtrue/Install /BootstrapperPackage /ItemGroup ... Target Name=AfterBuild GenerateBootstrapper ApplicationFile=$(TargetFileName) ApplicationName=My Application Name BootstrapperItems=@(BootstrapperPackage) ComponentsLocation=Relative CopyComponents=True OutputPath=$(OutputPath) Path=C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bootstrapper\/ /Target -Original Message- From: Blair [mailto:os...@live.com] Sent: June 17, 2010 4:33 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Install .Net Framework 4 What specifically is your LaunchCondition associated with that error text? -Original Message- From: Jason Ding [mailto:jas...@geo-slope.com] Sent: Thursday, June 17, 2010 2:24 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Install .Net Framework 4 Here is the log by using /L*vx options, i.e., all messages, it does indicate the LaunchConditions fails, but does anyone have a clue why it fails? Thanks. MSI (c) (6C:04) [15:18:29:270]: Doing action: LaunchConditions Action 15:18:29: LaunchConditions. Evaluating launch conditions Action start 15:18:29: LaunchConditions.
[WiX-users] GAC an assembly without embedding it within the MSI
I want to GAC an assembly already present on target machines, I know where this assembly is on every machine (you can assume, that path is static for all target machines and wont change) I do not want to include the assembly to be GAC'd in the MSI since it can change with each software deployment and we dont want our setup to be modified each time . I tried using the File tag with Assembly =.net File Id=Assembly.dll Name=Assembly.dll Assembly=.net Source=Assembly.dll KeyPath=yes /File but using File embeds my assembly in the MSI. Any ideas on how to just tell the MSI to just look for the assembly in a particular location and not include it? -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Quiet Execution of an executable embedded within the MSI
The traditional way to do this (discussed on this list a few times a few years ago) is a little hacky, but works well enough. 1) Put your executable in a self-extracting archive, using iexpress for example; 2) execute the self-extracting archive from the binary table in a 'quiet' mode, putting your executable in a well-known place (such as [TempFolder]); 3) use CAQuietExec to run your program from the well-known place; 4) use CAQuietExec to delete your program from the well-known place. -Original Message- From: Pally Sandher [mailto:pally.sand...@iesve.com] Sent: Friday, June 18, 2010 4:29 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Quiet Execution of an executable embedded within the MSI Binary Elements are extracted to temporary directories using auto generated filenames (see a verbose log for an example). It's not possible to use an application in a Binary Element with QtExec (I looked at the same thing a while ago for a plug-in installer). You'll either need to change it to use a File Element modify the CustomAction to use [#fileid] instead of quot;myexec.exequot; or live without QtExec or as Blair says, write your own Custom Actions to write the Binary to disk in a known location so QtExec can run it. Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Leigh Wetmore [mailto:lwetm...@gmail.com] Sent: 17 June 2010 18:29 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Quiet Execution of an executable embedded within the MSI Hello, I'm trying to figure out how to quietly execute (QtExec) an executable that I include within my MSI yet do not want installed on the user's machine. I've been able to achieve this without using the quiet execute feature, but I don't like the command window popping up during installation. Here is the code for that: Binary Id=CfgUpdateExe SourceFile=..\bin\myexe.exe / CustomAction Id=LaunchCfgUpdateExe BinaryKey=CfgUpdateExe ExeCommand=quot;[TempFolder]UpdateLog.txtquot; UpdateAppConfig quot;[DASLocation]myexec.exe.Configquot; Execute=deferred Impersonate=no Return=asyncNoWait / InstallExecuteSequence Custom Action=LaunchCfgUpdateExe After=InstallInitializeOLDERVERSIONDETECTED/Custom /InstallExecuteSequence I use the binary element to bring the executable (myexe.exe) into the MSI, then launch a custom action with the necessary arguments. I have it executing as deferred with no impersonation as I need the admin privileges already captured by the installer to carry through to the executable. Again, this works fine. However, if I try to convert this to use QtExec, I'm unable to get it to work. Looking in the MSI install log, I see: CAQuietExec: Error 0x80070002: Command failed to execute. CAQuietExec: Error 0x80070002: CAQuietExec Failed Here is my code so far: Binary Id=CfgUpdateExe SourceFile=..\bin\myexec.exe / CustomAction Id=QtExecCommand Property=QtExecUserCfg Value=quot;myexec.exequot; quot;[TempFolder]UpdateLog.txtquot; quot;UpdateAppConfigquot; quot;[DASLocation]myexec.exe.Configquot; Execute=immediate / CustomAction Id=QtExecUserCfg BinaryKey=WixCA DllEntry=CAQuietExec Execute=deferred Impersonate=no Return=check/ InstallExecuteSequence Custom Action=QtExecCommand After=CostFinalizeOLDERVERSIONDETECTED/Custom Custom Action=QtExecUserCfg After=InstallInitializeOLDERVERSIONDETECTED/Custom /InstallExecuteSequence I've left the binary element there, but I don't think the custom actions know about it. It looks like QtExec can't find the executable which makes sense (I can have it run notepad.exe no problem). I'm thinking maybe the files in the MSI, including myexec.exe, get extracted to a temp directory during installation, and I can potentially reference it, like Value=quot;[MSITempDir]myexec.exe...? Thanks in advance for any help anyone can provide. Leigh -- -- -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users --
[WiX-users] Can this be done with WiX?
Hi My name is Ivo Beltchev. I am working on the open source project Classic Shell: http://classicshell.sourceforge.net/ Currently I use a Visual Studio setup project to create my installer, but I'm hitting some of its limitations and I'm looking for a better solution. Here's what I need, please tell me which are possible with WiX: 1) I need a single EXE that can be installed on both 32-bit and 64-bit platforms (Vista and Windows 7). Most of the files (art assets, help files) are common between platforms. There are 32-bit and 64-bit executables, which need to register themselves in the registry (self-registered COM). There are some registry keys, which need to be set correctly (bypass the 32-bit redirection on 64-bit systems). I am told that (at least with Visual Studio) it is not possible to have a single MSI file that targets 32-bit and 64-bit platforms. I think the problem was that you can't run the 64-bit MSI on 32-bit OS, but a 32-bit MSI can't contain 64-bit modules. Can WiX do this in a single package? 2) I have 2 components. With few exceptions, every installed file belongs to one component or the other. I want to provide UI options for selecting the components to install, as well as command line options for silent install. I also want an option to specify the install folder, ideally with a command line option support too. 3) I want to create a shortcut in Program Files to one of the installed EXEs and set its command line arguments. The shortcut needs to be created by the installer dynamically because it depends on the install folder. 4) When the installer runs a second time I want to give the user the options to: Remove All, Add/Remove Components, and Repair. 5) As the last step of the install process I want to launch an executable, but I want to launch it as the currently logged-in user, not as SYSTEM. (Looks like msiexec runs as SYSTEM, so any child process is SYSTEM by default). 6) Since some components are shell extensions, it would be nice if the Explorer processes are killed and restarted during uninstall. Again, Explorer must be restarted as the current user, not as SYSTEM. Some other applications that use the shell can also load my DLLs, so it will be nice if the uninstaller at least shows a list of affected processes to the user and lets him close those apps. 7) There are some ini files, which the user can modify. During uninstall or upgrade I want to present the option to rename the files to ini.bak so the user modifications are not lost. Ideally the uninstaller can recognize which files are modified (by comparing the timestamp with the original). Less ideally the uninstaller renames all ini files. Least ideal, the uninstaller runs a separate executable that does the work. The uninstaller should provide the EXE with the installation path (like C:\Program Files\Classic Shell). 8) Of course the installer must work correctly with different levels of UAC. 9) Ideally the build process will be integrated into Visual Studio. 10) Ideally the installer will recognize the previously installed version (done with the older Visual Studio setup project) and will uninstall it first. Before I start going deeper into WiX, can somebody please tell me which of my requirements are possible? If there are some things that WiX can't do, but another free installer can, please point me to that other tool. Thanks Ivo Beltchev Classic Shell -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] creating a clustered share?
Has anyone created a clustered share using WiX before? I'm looking for an elegant way to do this. Best Regards, Andrew -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Can this be done with WiX?
1) This isn't a limitation of Visual Studio or WiX. This is a limitation with Windows Installer. You'll need to have two MSI packages. A bootstrapper might help you consolidate them so that it appears like one installer. 2) These sound like Features in Windows Installer parlance. As you organize Components and ComponentGroups you'll want to ultimately have only two root Features that aggregate the components correctly. 3) Windows Installer (and thus WiX) has shortcut support. 4) Windows Installer (and thus Wix) supports this too. 5) You should be able to author a CustomAction to do this, but it sounds like you want to restart Explorer.exe and that seems dangerous to me. 6) The Restart Manager should help here but I don't know much about how it works. 7) You should have per-user configuration files stored in the users profile. You can then do what all other installers do and leave them there. If the user reinstalls they'll have all their old configuration files available and ready to use. The %ProgramFiles% filesystem is supposed to be readonly so you don't want user-modifiable configuration files there. 8) Make sure to author any CustomActions that need to modify the system between InstallInitialize and InstallFinalize in the InstallExecuteSequence with the appropriate impersonation requirements. 9) WiX has Visual Studio integration. Automating some of the bits that it doesn't do automatically is not difficult if you learn/understand MSBuild. 10) Author your installer as a MajorUpgrade and include the previous UpgradeCode as one of the UpgradeCodes to upgrade. You might consider to continue using the old UpgradeCode in the new installer. In summary, you should be able to do most of everything you want to do. Some of your requirements are just not supported by Windows Installer so you'll need to change the requirement. Edwin G. Castro Software Developer - Staff Electronic Banking Services Fiserv Office: 503-746-0643 Fax: 503-617-0291 www.fiserv.com Please consider the environment before printing this e-mail -Original Message- From: Ivo Beltchev [mailto:i...@roadrunner.com] Sent: Friday, June 18, 2010 9:46 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Can this be done with WiX? Hi My name is Ivo Beltchev. I am working on the open source project Classic Shell: http://classicshell.sourceforge.net/ Currently I use a Visual Studio setup project to create my installer, but I'm hitting some of its limitations and I'm looking for a better solution. Here's what I need, please tell me which are possible with WiX: 1) I need a single EXE that can be installed on both 32-bit and 64-bit platforms (Vista and Windows 7). Most of the files (art assets, help files) are common between platforms. There are 32-bit and 64-bit executables, which need to register themselves in the registry (self-registered COM). There are some registry keys, which need to be set correctly (bypass the 32-bit redirection on 64-bit systems). I am told that (at least with Visual Studio) it is not possible to have a single MSI file that targets 32-bit and 64-bit platforms. I think the problem was that you can't run the 64-bit MSI on 32-bit OS, but a 32-bit MSI can't contain 64-bit modules. Can WiX do this in a single package? 2) I have 2 components. With few exceptions, every installed file belongs to one component or the other. I want to provide UI options for selecting the components to install, as well as command line options for silent install. I also want an option to specify the install folder, ideally with a command line option support too. 3) I want to create a shortcut in Program Files to one of the installed EXEs and set its command line arguments. The shortcut needs to be created by the installer dynamically because it depends on the install folder. 4) When the installer runs a second time I want to give the user the options to: Remove All, Add/Remove Components, and Repair. 5) As the last step of the install process I want to launch an executable, but I want to launch it as the currently logged-in user, not as SYSTEM. (Looks like msiexec runs as SYSTEM, so any child process is SYSTEM by default). 6) Since some components are shell extensions, it would be nice if the Explorer processes are killed and restarted during uninstall. Again, Explorer must be restarted as the current user, not as SYSTEM. Some other applications that use the shell can also load my DLLs, so it will be nice if the uninstaller at least shows a list of affected processes to the user and lets him close those apps. 7) There are some ini files, which the user can modify. During uninstall or upgrade I want to present the option to rename the files to ini.bak so the user modifications are not lost. Ideally the uninstaller can recognize which files are modified (by comparing the timestamp with the original). Less ideally the uninstaller renames all ini
Re: [WiX-users] Can this be done with WiX?
1) I need a single EXE that can be installed on both 32-bit and 64-bit platforms (Vista and Windows 7). Most of the files (art assets, help files) are common between platforms. There are 32-bit and 64-bit executables, which need to register themselves in the registry (self-registered COM). There are some registry keys, which need to be set correctly (bypass the 32-bit redirection on 64-bit systems). I am told that (at least with Visual Studio) it is not possible to have a single MSI file that targets 32-bit and 64-bit platforms. I think the problem was that you can't run the 64-bit MSI on 32-bit OS, but a 32-bit MSI can't contain 64-bit modules. Can WiX do this in a single package? 1) This isn't a limitation of Visual Studio or WiX. This is a limitation with Windows Installer. You'll need to have two MSI packages. A bootstrapper might help you consolidate them so that it appears like one installer. That's what I'm currently doing. I compile 2 MSI files and package them in a bootstrapper EXE. The EXE extracts the right MSI into the Temp folder and runs it. The problem is that the Repair action looks for that MSI but it's long gone. It doesn't help that I'm creating a unique temp file name, so even when the MSI exists, it will have a new name, so Repair can't recognize it. Is there a better solution? 2) I have 2 components. With few exceptions, every installed file belongs to one component or the other. I want to provide UI options for selecting the components to install, as well as command line options for silent install. I also want an option to specify the install folder, ideally with a command line option support too. 2) These sound like Features in Windows Installer parlance. As you organize Components and ComponentGroups you'll want to ultimately have only two root Features that aggregate the components correctly. Am I right to think that such components/groups are not possible to create with a Visual Studio setup project? 5) As the last step of the install process I want to launch an executable, but I want to launch it as the currently logged-in user, not as SYSTEM. (Looks like msiexec runs as SYSTEM, so any child process is SYSTEM by default). 5) You should be able to author a CustomAction to do this, but it sounds like you want to restart Explorer.exe and that seems dangerous to me. I'm not talking about Explorer.exe only, but for my own app. Is it possible for a CustomAction to launch my program as the logged-in user instead of SYSTEM? That's a limitation I'm having with my current installer. My solution is to do the launching in the bootstrapper, but that's not ideal. 7) There are some ini files, which the user can modify. During uninstall or upgrade I want to present the option to rename the files to ini.bak so the user modifications are not lost. Ideally the uninstaller can recognize which files are modified (by comparing the timestamp with the original). Less ideally the uninstaller renames all ini files. Least ideal, the uninstaller runs a separate executable that does the work. The uninstaller should provide the EXE with the installation path (like C:\Program Files\Classic Shell). 7) You should have per-user configuration files stored in the users profile. You can then do what all other installers do and leave them there. If the user reinstalls they'll have all their old configuration files available and ready to use. The %ProgramFiles% filesystem is supposed to be readonly so you don't want user-modifiable configuration files there. The thing is that every new version adds/removes features or changes the syntax of the ini files. So ini files from an older version are potentially incompatible. My project is a kind of system utility, so I think it is acceptable that only admins can edit the configuration files. I haven't had any complaints from the users about this, so I'd like to stick with the current design. Is it possible to do this through WiX scripting, or the custom action is the only way to go? 9) Ideally the build process will be integrated into Visual Studio. 9) WiX has Visual Studio integration. Automating some of the bits that it doesn't do automatically is not difficult if you learn/understand MSBuild. My code is all native C++, and in Visual Studio 2008 C++ doesn't use MSBuild. Is it going to be a problem to mix VCBuild and MSBuild projects together? -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Can this be done with WiX?
1) I need a single EXE that can be installed on both 32-bit and 64- bit platforms (Vista and Windows 7). Most of the files (art assets, help files) are common between platforms. There are 32-bit and 64-bit executables, which need to register themselves in the registry (self-registered COM). There are some registry keys, which need to be set correctly (bypass the 32-bit redirection on 64-bit systems). I am told that (at least with Visual Studio) it is not possible to have a single MSI file that targets 32-bit and 64-bit platforms. I think the problem was that you can't run the 64-bit MSI on 32-bit OS, but a 32-bit MSI can't contain 64-bit modules. Can WiX do this in a single package? 1) This isn't a limitation of Visual Studio or WiX. This is a limitation with Windows Installer. You'll need to have two MSI packages. A bootstrapper might help you consolidate them so that it appears like one installer. That's what I'm currently doing. I compile 2 MSI files and package them in a bootstrapper EXE. The EXE extracts the right MSI into the Temp folder and runs it. The problem is that the Repair action looks for that MSI but it's long gone. It doesn't help that I'm creating a unique temp file name, so even when the MSI exists, it will have a new name, so Repair can't recognize it. Is there a better solution? Windows Installer caches a copy of your MSI but it strips out any embedded cabinets. You'll need the original source for repairs. I'll let somebody with more knowledge provide advice. I have heard mentioned that Windows Installer requires that the MSI package filename does not change (probably for Repair scenarios). You may want to make sure the bootstrapper EXE extracts the MSI packages using consistent naming every time. 2) I have 2 components. With few exceptions, every installed file belongs to one component or the other. I want to provide UI options for selecting the components to install, as well as command line options for silent install. I also want an option to specify the install folder, ideally with a command line option support too. 2) These sound like Features in Windows Installer parlance. As you organize Components and ComponentGroups you'll want to ultimately have only two root Features that aggregate the components correctly. Am I right to think that such components/groups are not possible to create with a Visual Studio setup project? If I remember correctly, Visual Studio setup projects only allow a single Feature. Features and Components are a Windows Installer concepts. ComponentGroups and FeatureGroups are WiX concepts to help organization. Make sure to follow the Component Rules. 5) As the last step of the install process I want to launch an executable, but I want to launch it as the currently logged-in user, not as SYSTEM. (Looks like msiexec runs as SYSTEM, so any child process is SYSTEM by default). 5) You should be able to author a CustomAction to do this, but it sounds like you want to restart Explorer.exe and that seems dangerous to me. I'm not talking about Explorer.exe only, but for my own app. Is it possible for a CustomAction to launch my program as the logged-in user instead of SYSTEM? That's a limitation I'm having with my current installer. My solution is to do the launching in the bootstrapper, but that's not ideal. You should be able to set the impersonation appropriately to launch your exe as the user. 7) There are some ini files, which the user can modify. During uninstall or upgrade I want to present the option to rename the files to ini.bak so the user modifications are not lost. Ideally the uninstaller can recognize which files are modified (by comparing the timestamp with the original). Less ideally the uninstaller renames all ini files. Least ideal, the uninstaller runs a separate executable that does the work. The uninstaller should provide the EXE with the installation path (like C:\Program Files\Classic Shell). 7) You should have per-user configuration files stored in the users profile. You can then do what all other installers do and leave them there. If the user reinstalls they'll have all their old configuration files available and ready to use. The %ProgramFiles% filesystem is supposed to be readonly so you don't want user-modifiable configuration files there. The thing is that every new version adds/removes features or changes the syntax of the ini files. So ini files from an older version are potentially incompatible. My project is a kind of system utility, so I think it is acceptable that only admins can edit the configuration files. I haven't had any complaints from the users about this, so I'd like to stick with the current design. Is it possible to do this through WiX scripting, or the custom action is the only way to go? The %ProgramFiles% filesystem is readonly. If you
Re: [WiX-users] Deferred custom action Impersonation.
To Bob's list (which is a little out of date) I'll add that Server 2008 also has Hypervisor, Microsoft's newer VM technology. If you can get an x64 Server 2008 box you can have x64 and x86 VMs. VMs really are the best way to test setups when you can do your tests and then revert to an untarnished image. Phil Wilson -Original Message- From: Pally Sandher [mailto:pally.sand...@iesve.com] Sent: Friday, June 18, 2010 3:21 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Deferred custom action Impersonation. http://www.joyofsetup.com/2007/09/24/test-your-setups-virtually/ Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Sagar [mailto:sagarkavitak...@gmail.com] Sent: 18 June 2010 08:11 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Deferred custom action Impersonation. if i have a deferr=red custom action with Impersonate=yes. then on Windows Vista with UAC enabled i get a prompt asking if the user wishes the allow the program to access your computer. now if the user presses allow in UAC prompt. Will my custom action be able to connect to SQL server on another machine using windows authentication. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Deferred-c ustom-action-Impersonation-tp5191516p5194260.html Sent from the wix-users mailing list archive at Nabble.com. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users *** Confidentiality Notice: This e-mail, including any associated or attached files, is intended solely for the individual or entity to which it is addressed. This e-mail is confidential and may well also be legally privileged. If you have received it in error, you are on notice of its status. Please notify the sender immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person. This email comes from a division of the Invensys Group, owned by Invensys plc, which is a company registered in England and Wales with its registered office at Portland House, Bressenden Place, London, SW1E 5BF (Registered number 166023). For a list of European legal entities within the Invensys Group, please go to http://www.invensys.com/legal/default.asp?top_nav_id=77nav_id=80prev_id=77. You may contact Invensys plc on +44 (0)20 7821 3848 or e-mail inet.hqhelpd...@invensys.com. This e-mail and any attachments thereto may be subject to the terms of any agreements between Invensys (and/or its subsidiaries and affiliates) and the recipient (and/or its subsidiaries and affiliates). -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Can this be done with WiX?
Windows Installer caches a copy of your MSI but it strips out any embedded cabinets. You'll need the original source for repairs. I'll let somebody with more knowledge provide advice. I have heard mentioned that Windows Installer requires that the MSI package filename does not change (probably for Repair scenarios). You may want to make sure the bootstrapper EXE extracts the MSI packages using consistent naming every time. Burn and some other bootstrappers deal with this. Another solution I have seen is a custom action that caches the original MSI during the installation and adds the cached location to the Source List. If I remember correctly, Visual Studio setup projects only allow a single Feature. Features and Components are a Windows Installer concepts. ComponentGroups and FeatureGroups are WiX concepts to help organization. Make sure to follow the Component Rules. Just to add to this: Most of the time, you want a single file per component. You want to group your components into your features. You can select features to install via either the command-line or the UI. You should be able to set the impersonation appropriately to launch your exe as the user. For Vista and newer, the Restart Manager is integrated in with Windows Installer, and WiX exposes that integration to you to allow you to control it. For XP you would need a custom action. WiX already supplies a custom action that may possibly work for you. The %ProgramFiles% filesystem is readonly. If you want configuration that is *not* modified by the installer at install time then you should place those configuration files in writable filesystem. There is a place for such files at the system-level but I can't remember where it is. I believe the folder physically maps to C:\ProgramData but I forget what the FolderId is for it. Let's assume you copy the configuration files to C:\ProgramData\Classic Shell. The real question is How do you migrate values in the current configuration file to the new configuration file on upgrades? You may need a CustomAction (or more) to do this. You could possibly read the customizations from the INI files and write those out to the new INI files using built-in support in Windows Installer for writing INI files (the built in support for reading INI files applies only to INI files in the windows system directory) and a custom action that reads the customizations from the previous INI files that you will apply to the upgrades. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Deferred custom action Impersonation.
Microsoft Hyper-V Server 2008 R2 is free to download and use, if you don't have a Server 2008 license available. It requires an x64 box with certain CPUs that support hardware virtualization. -Original Message- From: Wilson, Phil [mailto:phil.wil...@invensys.com] Sent: Friday, June 18, 2010 11:35 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Deferred custom action Impersonation. To Bob's list (which is a little out of date) I'll add that Server 2008 also has Hypervisor, Microsoft's newer VM technology. If you can get an x64 Server 2008 box you can have x64 and x86 VMs. VMs really are the best way to test setups when you can do your tests and then revert to an untarnished image. Phil Wilson -Original Message- From: Pally Sandher [mailto:pally.sand...@iesve.com] Sent: Friday, June 18, 2010 3:21 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Deferred custom action Impersonation. http://www.joyofsetup.com/2007/09/24/test-your-setups-virtually/ Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Sagar [mailto:sagarkavitak...@gmail.com] Sent: 18 June 2010 08:11 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Deferred custom action Impersonation. if i have a deferr=red custom action with Impersonate=yes. then on Windows Vista with UAC enabled i get a prompt asking if the user wishes the allow the program to access your computer. now if the user presses allow in UAC prompt. Will my custom action be able to connect to SQL server on another machine using windows authentication. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Deferred-c ustom-action-Impersonation-tp5191516p5194260.html Sent from the wix-users mailing list archive at Nabble.com. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users *** Confidentiality Notice: This e-mail, including any associated or attached files, is intended solely for the individual or entity to which it is addressed. This e-mail is confidential and may well also be legally privileged. If you have received it in error, you are on notice of its status. Please notify the sender immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person. This email comes from a division of the Invensys Group, owned by Invensys plc, which is a company registered in England and Wales with its registered office at Portland House, Bressenden Place, London, SW1E 5BF (Registered number 166023). For a list of European legal entities within the Invensys Group, please go to http://www.invensys.com/legal/default.asp?top_nav_id=77nav_id=80prev_id=77 . You may contact Invensys plc on +44 (0)20 7821 3848 or e-mail inet.hqhelpd...@invensys.com. This e-mail and any attachments thereto may be subject to the terms of any agreements between Invensys (and/or its subsidiaries and affiliates) and the recipient (and/or its subsidiaries and affiliates). -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win:
Re: [WiX-users] Can this be done with WiX?
Forwarding to the list as it was accidentally removed from the TO line. -Original Message- From: i...@roadrunner.com [mailto:i...@roadrunner.com] Sent: Friday, June 18, 2010 11:47 AM To: Castro, Edwin G. (Hillsboro) Subject: RE: [WiX-users] Can this be done with WiX? I compile 2 MSI files and package them in a bootstrapper EXE. The EXE extracts the right MSI into the Temp folder and runs it. The problem is that the Repair action looks for that MSI but it's long gone. It doesn't help that I'm creating a unique temp file name, so even when the MSI exists, it will have a new name, so Repair can't recognize it. Is there a better solution? Windows Installer caches a copy of your MSI but it strips out any embedded cabinets. You'll need the original source for repairs. I'll let somebody with more knowledge provide advice. I have heard mentioned that Windows Installer requires that the MSI package filename does not change (probably for Repair scenarios). You may want to make sure the bootstrapper EXE extracts the MSI packages using consistent naming every time. Can somebody that has done this before explain what is the right way to use a bootstrapper with Repair? Should I extract the MSI to a permanent location instead of the temp folder? If so, what is the recommended location and how to deal with upgrading from one version to the next (do the MSI files need to have different names for each version)? BTW, I expect Add/Remove features to have the same problem. You should be able to set the impersonation appropriately to launch your exe as the user. Are you sure WiX can do this? When I was searching for a solution before I came across this: http://stackoverflow.com/questions/2206646/create-a-process-with- ordinary-rights-from-an-administrator-process Basically people say that it can be done through the scheduler service (which may be disabled), through piggybacking on Explorer (which may not be running) or some other hacky way. Because of the hacky nature of the solutions I am concerned if WiX has found a good way to do this. Thanks for your help. Other than the 2 questions above, looks like WiX can do everything I need so I will give it a shot. Ivo P.S. Is there a good forum that discusses MSI issues? I am pretty new to this and I don't want to bother the WiX community with noobish installer questions. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Can this be done with WiX?
You should be able to set the impersonation appropriately to launch your exe as the user. Are you sure WiX can do this? When I was searching for a solution before I came across this: http://stackoverflow.com/questions/2206646/create-a-process-with- ordinary-rights-from-an-administrator-process Basically people say that it can be done through the scheduler service (which may be disabled), through piggybacking on Explorer (which may not be running) or some other hacky way. Because of the hacky nature of the solutions I am concerned if WiX has found a good way to do this. The CustomAction/ element has an Impersonate attribute. The valid values are yes and no. When you use Impersonate=no the custom action is executed as an account that has rights to modify the system. These custom actions should be scheduled between InstallInitialize and InstallFinalize and probably needs to be deferred so it executes in the privileged process. When you use Impersonate=yes the custom action is executed as the user that started the MSI package. If you want to start an EXE at the end of the installer (and not fail the installer causing a rollback) then you should schedule that custom action _after_ InstallFinalize (after the install transaction has closed). There's a client component and server component to a Windows Installer install. http://blogs.msdn.com/b/rflaming/archive/2006/09/21/765452.aspx does a reasonable job of explaining the sequence with pretty pictures. Edwin G. Castro Software Developer - Staff Electronic Banking Services Fiserv Office: 503-746-0643 Fax: 503-617-0291 www.fiserv.com Please consider the environment before printing this e-mail -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] How to control windows reboot popup window?
Hi all, I created an installer that consists several dlls and exes. I also supports updates so the user can update our product instead of reinstalling our product. So far it's pretty good. However, when the user either updates or uninstall our product, windows display the message asking the user to reboot the machine. I know that mostly that's not really needed so I want to know how I can control that message windows so that I can suppress it when it's not needed. Could anyone give me some advice on this? Thank you very much. YEH -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Change media source/layout through property
Hi I'm trying to change the media layout through the command line when running msiexec. I thought it should be enough to have a property and set that to the Layout of the Media, but I cannot get it to work properly. I'm wondering if this is possible, as I've tried this, and it doesn't seem to work. It only looks for it at the location where the msi is located. When logging I can see the property beeing set, but it doesn't seem to affect the media layout. ?xml version=1.0 encoding=UTF-8? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; Product Id=PUT-GUID-HERE Name=Test media source Language=1044 Version=1.0.0.0 Manufacturer=test UpgradeCode=PUT-GUID-HERE Package InstallerVersion=200 Compressed=no Description=abc / Property id=PATH_TO_SOURCE secure=yes Media id=1 Layout=[PATH_TO_SOURCE] Directory Id=TARGETDIR Name=SourceDir Directory Id=ProgramFilesFolder Component Id=readme_comp Guid=PUT-GUID-HERE DiskId=1 File Id=readme_file Source=readme.txt / /Component /Directory /Directory Feature Id=test_feature Title=test ComponentRef=readme_comp / /Feature /Product /Wix Command line: msiexec /i test.msi PATH_TO_SOURCE=c:\somepath\ thanks, Leif -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to control windows reboot popup window?
There are some properties you can set, such as REBOOT=ReallySuppress. In your situation I'd do the update/uninstall and create a verbose MSI log to see why Windows wants to reboot, or if there is something like a spurious ScheduleReboot in there. You don't really want to suppress a reboot if there's a filesinuse situation where you don't actually get the update completed until after a reboot. Phil Wilson -Original Message- From: CP YEH [mailto:ntde...@gmail.com] Sent: Friday, June 18, 2010 12:38 PM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] How to control windows reboot popup window? Hi all, I created an installer that consists several dlls and exes. I also supports updates so the user can update our product instead of reinstalling our product. So far it's pretty good. However, when the user either updates or uninstall our product, windows display the message asking the user to reboot the machine. I know that mostly that's not really needed so I want to know how I can control that message windows so that I can suppress it when it's not needed. Could anyone give me some advice on this? Thank you very much. YEH -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users *** Confidentiality Notice: This e-mail, including any associated or attached files, is intended solely for the individual or entity to which it is addressed. This e-mail is confidential and may well also be legally privileged. If you have received it in error, you are on notice of its status. Please notify the sender immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person. This email comes from a division of the Invensys Group, owned by Invensys plc, which is a company registered in England and Wales with its registered office at Portland House, Bressenden Place, London, SW1E 5BF (Registered number 166023). For a list of European legal entities within the Invensys Group, please go to http://www.invensys.com/legal/default.asp?top_nav_id=77nav_id=80prev_id=77. You may contact Invensys plc on +44 (0)20 7821 3848 or e-mail inet.hqhelpd...@invensys.com. This e-mail and any attachments thereto may be subject to the terms of any agreements between Invensys (and/or its subsidiaries and affiliates) and the recipient (and/or its subsidiaries and affiliates). -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Password showing in text when installing custom user for AppPool
I have used the v3.5 version with VS2010 to create MSIs. I noticed that if I create a custom appPool and assign it a real user that this step in the basic logging displays the password in clear text: Property(S): WriteIIS7ConfigChange Can that line be encrypted or the password not be displayed for the property? I know that the password property itself is showing *'s Thanks Pierson -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Can this be done with WiX?
Also, most people starting an application at the end of an installation do so from the final UI screen of the installation, often with a checkbox selecting whether to start the installation or not. WiX has this functionality pretty much built in (such that it is only offered if the UI was used in the installation) which for most applications is what is preferred. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Password showing in text when installing custom user for AppPool
Property Id=WriteIIS7ConfigChange Hidden=yes/ It would hide the property, so if you need other parts of that property in the log for diagnosis you would need to set the Debug policy appropriately. http://msdn.microsoft.com/library/aa370308.aspx -Original Message- From: Pierson Lee (PIE) [mailto:pierson@microsoft.com] Sent: Friday, June 18, 2010 2:05 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Password showing in text when installing custom user for AppPool I have used the v3.5 version with VS2010 to create MSIs. I noticed that if I create a custom appPool and assign it a real user that this step in the basic logging displays the password in clear text: Property(S): WriteIIS7ConfigChange Can that line be encrypted or the password not be displayed for the property? I know that the password property itself is showing *'s Thanks Pierson -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Can this be done with WiX?
Blair os...@live.com wrote: Also, most people starting an application at the end of an installation do so from the final UI screen of the installation, often with a checkbox selecting whether to start the installation or not. WiX has this functionality pretty much built in (such that it is only offered if the UI was used in the installation) which for most applications is what is preferred. Got it. That's pretty much what I need, except I don't want a UI. The feature is a shell extension that is supposed to be running all the time. So there is no point to ask the user. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Can this be done with WiX?
Aren't most shell extensions DLLs that Explorer.exe loads when needed? I never had to run one I installed... -Original Message- From: i...@roadrunner.com [mailto:i...@roadrunner.com] Sent: Friday, June 18, 2010 2:39 PM To: General discussion for Windows Installer XML toolset. Cc: Blair Subject: Re: [WiX-users] Can this be done with WiX? Blair os...@live.com wrote: Also, most people starting an application at the end of an installation do so from the final UI screen of the installation, often with a checkbox selecting whether to start the installation or not. WiX has this functionality pretty much built in (such that it is only offered if the UI was used in the installation) which for most applications is what is preferred. Got it. That's pretty much what I need, except I don't want a UI. The feature is a shell extension that is supposed to be running all the time. So there is no point to ask the user. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Change media source/layout through property
med...@layout attribute is used during the build to facilitate placement of the files into your media layout (the way you transfer your build output onto your multiple CDs or whatever). The data in that attribute is not preserved in the MSI and is not available/doesn't alter the way that Windows Installer searches for the files it installs. You would need to change the source information in the Directory tree for what you are trying to do, and the location of the files must be relative to the location of the MSI file (it can't be absolute). -Original Message- From: Leif Ringstad [mailto:lei...@gmail.com] Sent: Friday, June 18, 2010 1:02 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Change media source/layout through property Hi I'm trying to change the media layout through the command line when running msiexec. I thought it should be enough to have a property and set that to the Layout of the Media, but I cannot get it to work properly. I'm wondering if this is possible, as I've tried this, and it doesn't seem to work. It only looks for it at the location where the msi is located. When logging I can see the property beeing set, but it doesn't seem to affect the media layout. ?xml version=1.0 encoding=UTF-8? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; Product Id=PUT-GUID-HERE Name=Test media source Language=1044 Version=1.0.0.0 Manufacturer=test UpgradeCode=PUT-GUID-HERE Package InstallerVersion=200 Compressed=no Description=abc / Property id=PATH_TO_SOURCE secure=yes Media id=1 Layout=[PATH_TO_SOURCE] Directory Id=TARGETDIR Name=SourceDir Directory Id=ProgramFilesFolder Component Id=readme_comp Guid=PUT-GUID-HERE DiskId=1 File Id=readme_file Source=readme.txt / /Component /Directory /Directory Feature Id=test_feature Title=test ComponentRef=readme_comp / /Feature /Product /Wix Command line: msiexec /i test.msi PATH_TO_SOURCE=c:\somepath\ thanks, Leif -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Can this be done with WiX?
This is not a proper shell extension. It is a DLL that is injected into the Explorer process. There is an EXE that does the injection and re-injects the DLL when Explorer is restarted (due to crash or other reason). For regular shell extensions the users will expect them to be automatically active after the installer is done. There is no run step or option. I am trying to get the same automatic behaviour for my non-traditional extension. Blair os...@live.com wrote: Aren't most shell extensions DLLs that Explorer.exe loads when needed? I never had to run one I installed... -Original Message- From: i...@roadrunner.com [mailto:i...@roadrunner.com] Sent: Friday, June 18, 2010 2:39 PM To: General discussion for Windows Installer XML toolset. Cc: Blair Subject: Re: [WiX-users] Can this be done with WiX? Blair os...@live.com wrote: Also, most people starting an application at the end of an installation do so from the final UI screen of the installation, often with a checkbox selecting whether to start the installation or not. WiX has this functionality pretty much built in (such that it is only offered if the UI was used in the installation) which for most applications is what is preferred. Got it. That's pretty much what I need, except I don't want a UI. The feature is a shell extension that is supposed to be running all the time. So there is no point to ask the user. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Localization - ProductCode property
Certificates are not based on ProductCode. So how do I make sure that my cert is not deleted during a major upgrade, but deleted during an uninstall? Also, my msi's functionality does not change from language to language, like it doesn't install any language specific packs etc... All my MSI does is to install a redist of a component that doesn't care about languages, talk to a webservice and get down a certificate. So, if we are to do a major upgrade, it should be a well planned act by us and we will change the ProductCode for all languages at that time. On Thu, Jun 17, 2010 at 11:08 AM, Blair os...@live.com wrote: Your certificates are based on ProductCode? There is no reason I can think of that a Major Upgrade can't retain/reuse files or configuration from a previous installation. -Original Message- From: Pratapa Reddy Sanaga [mailto:pratap.san...@gmail.com] Sent: Thursday, June 17, 2010 8:31 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Localization - ProductCode property It is kind of complicated in my case. The IT admin would be installing a package on the machine. During installation, it is going to talk to the server and take up one slot in the account(receives a cert). The next time either the IT admin or the local admin runs the package on this machine, it will see that it has already received a cert from the server and hence make this execution a NOOP. So, even if the system locale is changed and the package is run again, I want the package to verify that certificate is present and, if yes, make the execution a NOOP. I won't be able to have this functionality if I have a different ProductCode for each language, because it will then be considered a major upgrade, right? Looking at the previous year's thread on this - http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/When-to-change -Product-Id-ProductCode-two-editions-of-the-same-product-td3832979.html#a383 2979. I don't have a patching story for my installation package. The admin will just install it once. There is no repair story or upgrade story to it. The package would either enroll the client into the service or it fails. If it succeeds, then future runs of the same package(of any language) should be NOOP. If it fails, admin will fix the problem on the client machine and run the package again or get a new package from us and run it. As I said, my main scenario is that the package should never do a major upgrade, because it eats up an account slot, unnecessarily, for which the admin paid money. So, I'm trying to see if I'm missing anymore scenarios where I would get into trouble if I use the same productCode for all the languages. -Pratap. On Wed, Jun 16, 2010 at 6:56 PM, Sascha Beaumont sascha.beaum...@gmail.comwrote: Check the archives for more information, I asked a similar question sometime last year. I can't find the exact thread, but ended up being convinced to make the change. I did however find a list of pointers from Rob around localization - changing the PackageCode was important enough to be item 0 ;) 0. *Every* MSI should have a different PackageCode. Even two builds of the same MSI. Sascha On Thu, Jun 17, 2010 at 2:28 AM, Pratapa Reddy Sanaga pratap.san...@gmail.com wrote: Hi, I was going through an example for localization and came across this MSDN page http://msdn.microsoft.com/en-us/library/aa372369. It says that we must change the productCode for every localized package. Is this a necessary condition or just a good practice? I'm planning to create MSIs for different languages, create transforms with english as base package, embed these transforms into the base package and have a bootstrapper that would apply the right transform and install the package. So, for this scenario, do I need to create different ProductCodes for different language MSIs? If I have the same product code for all the language MSIs and tomorrow if I find a localization bug in one language, will there be any implications in this servicing process because of the same productCode used in the first place? Thanks, Pratap. -- Vote for loksatta = vote for a better future -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
Re: [WiX-users] Wix V2.0 sourcecode?
I somehow couldn't find the sources in that folder. Downloaded from this location - http://wix.sourceforge.net/releases/. Hope it would be helpful for others. On Tue, Jun 8, 2010 at 8:41 PM, Rob Mensching r...@robmensching.com wrote: WiX v2.0 source code is on CodePlex in the wix20 branch. The WiX 2.0 MSI is at http://wix.codeplex.com/releases/view/44406, Look at the right. On Tue, Jun 8, 2010 at 5:30 PM, Pratapa Reddy Sanaga pratap.san...@gmail.com wrote: Hi, I'm trying to download the source code for Wix V2.0, but I'm getting redirected from http://wix.sourceforge.net/downloadv2.html to this link for V3.0 download - http://wix.codeplex.com/. Can someone give me a pointer to V2.0 pointer? Thanks, Pratap. -- Vote for loksatta = vote for a better future -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Vote for loksatta = vote for a better future -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Transforms in Wix 2.0
Thank you very much. This helped me a lot! On Mon, Jun 7, 2010 at 1:20 PM, Blair os...@live.com wrote: In v2 it was $(loc.StringId). That was changed to !(loc.StringId) in v3 (IMHO to make it more obvious when the replacement happens [precompile vs. late-stage linking/binding]). V2 users must use MSI-SDK tools for creating transforms. See MSDN for examples. -Original Message- From: Pratapa Reddy Sanaga [mailto:pratap.san...@gmail.com] Sent: Monday, June 07, 2010 12:22 PM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Transforms in Wix 2.0 Hi, Does Wix 2.0 have support for creating transforms? I see that Torch tool has been introduced in Wix 3.0. How did Wix 2.0 users create transforms? Also, !(loc.StringIdForError) format for custom error message localization doesn't work when the MSI is created with Wix 2.0 tools. Maybe Wix 2.0 had some other syntax for string localization? Can someone help me with that? We use Wix 2.0 toolset at work and I am trying to figure out if we must upgrade to Wix 3.0 tools to do that above tasks. Thanks, Pratap. -- Vote for loksatta = vote for a better future -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Vote for loksatta = vote for a better future -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Change media source/layout through property
Thanks for the reply. I was afraid it was so. I ended up packaging the msi's + files into a nsis installer which unpacks to temp and then installs. cheers, Leif On Fri, Jun 18, 2010 at 11:56 PM, Blair os...@live.com wrote: med...@layout attribute is used during the build to facilitate placement of the files into your media layout (the way you transfer your build output onto your multiple CDs or whatever). The data in that attribute is not preserved in the MSI and is not available/doesn't alter the way that Windows Installer searches for the files it installs. You would need to change the source information in the Directory tree for what you are trying to do, and the location of the files must be relative to the location of the MSI file (it can't be absolute). -Original Message- From: Leif Ringstad [mailto:lei...@gmail.com] Sent: Friday, June 18, 2010 1:02 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Change media source/layout through property Hi I'm trying to change the media layout through the command line when running msiexec. I thought it should be enough to have a property and set that to the Layout of the Media, but I cannot get it to work properly. I'm wondering if this is possible, as I've tried this, and it doesn't seem to work. It only looks for it at the location where the msi is located. When logging I can see the property beeing set, but it doesn't seem to affect the media layout. ?xml version=1.0 encoding=UTF-8? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; Product Id=PUT-GUID-HERE Name=Test media source Language=1044 Version=1.0.0.0 Manufacturer=test UpgradeCode=PUT-GUID-HERE Package InstallerVersion=200 Compressed=no Description=abc / Property id=PATH_TO_SOURCE secure=yes Media id=1 Layout=[PATH_TO_SOURCE] Directory Id=TARGETDIR Name=SourceDir Directory Id=ProgramFilesFolder Component Id=readme_comp Guid=PUT-GUID-HERE DiskId=1 File Id=readme_file Source=readme.txt / /Component /Directory /Directory Feature Id=test_feature Title=test ComponentRef=readme_comp / /Feature /Product /Wix Command line: msiexec /i test.msi PATH_TO_SOURCE=c:\somepath\ thanks, Leif -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Can this be done with WiX?
(keeping the thread on the list so future generations can benefit) The source list is described here: http://msdn.microsoft.com/library/aa369795.aspx and here: http://msdn.microsoft.com/library/aa371859.aspx along with a few other places. It is the list of directories that Windows Installer will search to find the non-stripped version of the MSI for each installed product whenever it needs it (you get a ResolveSource prompt when that search fails). The list contains just the directories: the MSI's name is separately stored and can't be changed. When a product is uninstalled, the associated source list is automatically removed (along with all other metadata related to that product). The content of that source list, however, is not (so you would need to remove your cached MSI when your product is removed). A component is Windows Installer's atomic unit of installation: it consists of resource(s) (files, registry values, etc.) that assume one identity (the keypath of the component) and one name (a GUID for cross-package use and an identifier for use within a given database) and the identity is used to determine the entire component's health and status: for that reason it is generally encouraged that you have only one file per component. Search for Component Rules to get a feeling for what you need to know to avoid creating packages that can't be upgraded/serviced/cleanly removed. A feature is the fundamental user selection grouping of what is or isn't installed (in MSWord, for instance, a spell-check for any arbitrary language dictionary is a feature, as the program can run with or without it). That appears analogous to your use of the term component in your first email in this thread. A product is a collection of features and components (any given component may be a member of more than one feature but must be a member of at least one or it could never be installed, removed, or even maintained) that can exist independently of any other product, is instanced such that only one can be on any given computer at a time. Products can be tied together in a family via an UpgradeCode which is typically used to remove old versions and prevent downgrading (overwriting a newer version by replacing it with an older one). Products are supplied via a package (an MSI database file) which provides the complete definition of an arbitrary instance of a product. MSI can copy or move files (which includes renames) but typically it moves them after overwriting them. You can extend MSI via custom actions which you can use to rename your .ini files. WiX provides for the use of just about every feature available in Windows Installer (in fact, if one were so inclined, you could reauthor every other MSI file in WiX). -Original Message- From: i...@roadrunner.com [mailto:i...@roadrunner.com] Sent: Friday, June 18, 2010 12:11 PM To: Blair Subject: RE: [WiX-users] Can this be done with WiX? Blair os...@live.com wrote: Windows Installer caches a copy of your MSI but it strips out any embedded cabinets. You'll need the original source for repairs. I'll let somebody with more knowledge provide advice. I have heard mentioned that Windows Installer requires that the MSI package filename does not change (probably for Repair scenarios). You may want to make sure the bootstrapper EXE extracts the MSI packages using consistent naming every time. Burn and some other bootstrappers deal with this. Another solution I have seen is a custom action that caches the original MSI during the installation and adds the cached location to the Source List. I'll check out Burn. But I would prefer to write my own bootstrapper. So I just need to know where to put the MSIs, how do I name them, and will the uninstaller know to delete them in the end? Where can I read more about that Source List? If I remember correctly, Visual Studio setup projects only allow a single Feature. Features and Components are a Windows Installer concepts. ComponentGroups and FeatureGroups are WiX concepts to help organization. Make sure to follow the Component Rules. Just to add to this: Most of the time, you want a single file per component. You want to group your components into your features. You can select features to install via either the command-line or the UI. Silly terminology question - I know what a file is, I'm guessing a feature is something that the user can select/deselect, but then what's a component? Can I have features, with files inside? You could possibly read the customizations from the INI files and write those out to the new INI files using built-in support in Windows Installer for writing INI files (the built in support for reading INI files applies only to INI files in the windows system directory) and a custom action that reads the customizations from the previous INI files that you will apply to the upgrades. It is not that simple.
Re: [WiX-users] Localization - ProductCode property
Typically Windows Installer will only delete what it writes. You have to do extra work to delete other things (like stuff generated during an installation). You can easily condition that extra work to only operate when a removal is NOT part of an upgrade. (See the UPGRADINGPRODUCTCODE property). Functionality change is not related to the degree of upgrading. The difference between Major Upgrades and other scales of upgrades/updates is the freedom allowed during the upgrade and whether it can be accomplished without bootstrapping. For most use cases (virtually all those that don't involve MSP files), major upgrade all-the-time becomes the most sensible way to do upgrades (see Bob's blog on paying for upgrades for one discussion on the whys and costs). -Original Message- From: Pratapa Reddy Sanaga [mailto:pratap.san...@gmail.com] Sent: Friday, June 18, 2010 3:13 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Localization - ProductCode property Certificates are not based on ProductCode. So how do I make sure that my cert is not deleted during a major upgrade, but deleted during an uninstall? Also, my msi's functionality does not change from language to language, like it doesn't install any language specific packs etc... All my MSI does is to install a redist of a component that doesn't care about languages, talk to a webservice and get down a certificate. So, if we are to do a major upgrade, it should be a well planned act by us and we will change the ProductCode for all languages at that time. On Thu, Jun 17, 2010 at 11:08 AM, Blair os...@live.com wrote: Your certificates are based on ProductCode? There is no reason I can think of that a Major Upgrade can't retain/reuse files or configuration from a previous installation. -Original Message- From: Pratapa Reddy Sanaga [mailto:pratap.san...@gmail.com] Sent: Thursday, June 17, 2010 8:31 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Localization - ProductCode property It is kind of complicated in my case. The IT admin would be installing a package on the machine. During installation, it is going to talk to the server and take up one slot in the account(receives a cert). The next time either the IT admin or the local admin runs the package on this machine, it will see that it has already received a cert from the server and hence make this execution a NOOP. So, even if the system locale is changed and the package is run again, I want the package to verify that certificate is present and, if yes, make the execution a NOOP. I won't be able to have this functionality if I have a different ProductCode for each language, because it will then be considered a major upgrade, right? Looking at the previous year's thread on this - http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/When-to-change -Product-Id-ProductCode-two-editions-of-the-same-product-td3832979.html#a383 2979. I don't have a patching story for my installation package. The admin will just install it once. There is no repair story or upgrade story to it. The package would either enroll the client into the service or it fails. If it succeeds, then future runs of the same package(of any language) should be NOOP. If it fails, admin will fix the problem on the client machine and run the package again or get a new package from us and run it. As I said, my main scenario is that the package should never do a major upgrade, because it eats up an account slot, unnecessarily, for which the admin paid money. So, I'm trying to see if I'm missing anymore scenarios where I would get into trouble if I use the same productCode for all the languages. -Pratap. On Wed, Jun 16, 2010 at 6:56 PM, Sascha Beaumont sascha.beaum...@gmail.comwrote: Check the archives for more information, I asked a similar question sometime last year. I can't find the exact thread, but ended up being convinced to make the change. I did however find a list of pointers from Rob around localization - changing the PackageCode was important enough to be item 0 ;) 0. *Every* MSI should have a different PackageCode. Even two builds of the same MSI. Sascha On Thu, Jun 17, 2010 at 2:28 AM, Pratapa Reddy Sanaga pratap.san...@gmail.com wrote: Hi, I was going through an example for localization and came across this MSDN page http://msdn.microsoft.com/en-us/library/aa372369. It says that we must change the productCode for every localized package. Is this a necessary condition or just a good practice? I'm planning to create MSIs for different languages, create transforms with english as base package, embed these transforms into the base package and have a bootstrapper that would apply the right transform and install the package. So, for this scenario, do I need to create different ProductCodes for different language MSIs? If I
Re: [WiX-users] Password showing in text when installing custom user for AppPool
Will making that change affect the property itself? It isn't a property I create, its from the IIS custom action. -Original Message- From: Blair [mailto:os...@live.com] Sent: Friday, June 18, 2010 2:35 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Password showing in text when installing custom user for AppPool Property Id=WriteIIS7ConfigChange Hidden=yes/ It would hide the property, so if you need other parts of that property in the log for diagnosis you would need to set the Debug policy appropriately. http://msdn.microsoft.com/library/aa370308.aspx -Original Message- From: Pierson Lee (PIE) [mailto:pierson@microsoft.com] Sent: Friday, June 18, 2010 2:05 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Password showing in text when installing custom user for AppPool I have used the v3.5 version with VS2010 to create MSIs. I noticed that if I create a custom appPool and assign it a real user that this step in the basic logging displays the password in clear text: Property(S): WriteIIS7ConfigChange Can that line be encrypted or the password not be displayed for the property? I know that the password property itself is showing *'s Thanks Pierson -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Can this be done with WiX?
Blair os...@live.com wrote: (keeping the thread on the list so future generations can benefit) The source list is described here: http://msdn.microsoft.com/library/aa369795.aspx and here: http://msdn.microsoft.com/library/aa371859.aspx along with a few other places. It is the list of directories that Windows Installer will search to find the non-stripped version of the MSI for each installed product whenever it needs it (you get a ResolveSource prompt when that search fails). The list contains just the directories: the MSI's name is separately stored and can't be changed. When a product is uninstalled, the associated source list is automatically removed (along with all other metadata related to that product). The content of that source list, however, is not (so you would need to remove your cached MSI when your product is removed). I see. So as I understand it, I have to keep the MSI around while the software is installed. Is there a recommended location for such cached MSIs? And is it even possible for the MSI to delete itself during uninstall? How does Burn handle this? A component is Windows Installer's atomic unit of installation: it consists of resource(s) (files, registry values, etc.) that assume one identity (the keypath of the component) and one name (a GUID for cross-package use and an identifier for use within a given database) and the identity is used to determine the entire component's health and status: for that reason it is generally encouraged that you have only one file per component. Search for Component Rules to get a feeling for what you need to know to avoid creating packages that can't be upgraded/serviced/cleanly removed. A feature is the fundamental user selection grouping of what is or isn't installed (in MSWord, for instance, a spell-check for any arbitrary language dictionary is a feature, as the program can run with or without it). That appears analogous to your use of the term component in your first email in this thread. A product is a collection of features and components (any given component may be a member of more than one feature but must be a member of at least one or it could never be installed, removed, or even maintained) that can exist independently of any other product, is instanced such that only one can be on any given computer at a time. Products can be tied together in a family via an UpgradeCode which is typically used to remove old versions and prevent downgrading (overwriting a newer version by replacing it with an older one). Products are supplied via a package (an MSI database file) which provides the complete definition of an arbitrary instance of a product. MSI can copy or move files (which includes renames) but typically it moves them after overwriting them. You can extend MSI via custom actions which you can use to rename your .ini files. WiX provides for the use of just about every feature available in Windows Installer (in fact, if one were so inclined, you could reauthor every other MSI file in WiX). Thanks, that was very detailed and clear explanation. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] getting a list of properties from an already-build MSI?
Is there a way to get a list of properties from an MSI? I can install it if necessary. A -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Password showing in text when installing custom user for AppPool
It doesn't create the property itself (although it does create a record for the linker of that property). It simply and only adds that property's name to the property described in the MSDN page I provided. However, after glancing in the WiX sources, are you sure it isn't WriteIIS7ConfigChanges? -Original Message- From: Pierson Lee (PIE) [mailto:pierson@microsoft.com] Sent: Friday, June 18, 2010 4:00 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Password showing in text when installing custom user for AppPool Will making that change affect the property itself? It isn't a property I create, its from the IIS custom action. -Original Message- From: Blair [mailto:os...@live.com] Sent: Friday, June 18, 2010 2:35 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Password showing in text when installing custom user for AppPool Property Id=WriteIIS7ConfigChange Hidden=yes/ It would hide the property, so if you need other parts of that property in the log for diagnosis you would need to set the Debug policy appropriately. http://msdn.microsoft.com/library/aa370308.aspx -Original Message- From: Pierson Lee (PIE) [mailto:pierson@microsoft.com] Sent: Friday, June 18, 2010 2:05 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Password showing in text when installing custom user for AppPool I have used the v3.5 version with VS2010 to create MSIs. I noticed that if I create a custom appPool and assign it a real user that this step in the basic logging displays the password in clear text: Property(S): WriteIIS7ConfigChange Can that line be encrypted or the password not be displayed for the property? I know that the password property itself is showing *'s Thanks Pierson -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] getting a list of properties from an already-build MSI?
There are properties that are defined by the system, properties that are defined by the package (initial values are in the Property table), and properties that are created while the installation transaction proceeds (whether by searches or custom actions). To see final values for all custom actions (as well as property creations and value changes) generate a verbose log in your transaction. -Original Message- From: Andrew Hammond [mailto:andrew.george.hamm...@gmail.com] Sent: Friday, June 18, 2010 4:31 PM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] getting a list of properties from an already-build MSI? Is there a way to get a list of properties from an MSI? I can install it if necessary. A -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Can this be done with WiX?
I see. So as I understand it, I have to keep the MSI around while the software is installed. Is there a recommended location for such cached MSIs? And is it even possible for the MSI to delete itself during uninstall? How does Burn handle this? If the MSI is installed per-user, it would be recommended to cache it somewhere in the user's roaming profile (since per-user installations can roam). In the case of per-machine installation, it should be place somewhere outside of all user profiles that only someone with admin privileges can change (to prevent using your software being a vector for an escalation of privilege virus attack). Don't use private\system directories (such as the C:\Installer folder) as those are not managed by you and there is no guarantee that the contents won't be cleaned out underneath you. For this same reason, it is not recommended to cache it in any temporary location, such as under %TEMP%. There is some software that has cached MSI files in the C:\Windows\Downloaded Installations folder, but that location may be subject to cleanup by the disk cleanup tool. Other locations I have seen include under the Common Files folder of the Program Files folder, in a hidden folder of the program's own installation folder, and in custom hidden folders off the system drive's root folder. I'm not sure where burn caches, I would have to look in through the source code, although I believe it is under the control of the UI you add to burn, so it could potentially be anywhere. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Can this be done with WiX?
Blair os...@live.com wrote: I see. So as I understand it, I have to keep the MSI around while the software is installed. Is there a recommended location for such cached MSIs? And is it even possible for the MSI to delete itself during uninstall? How does Burn handle this? If the MSI is installed per-user, it would be recommended to cache it somewhere in the user's roaming profile (since per-user installations can roam). In the case of per-machine installation, it should be place somewhere outside of all user profiles that only someone with admin privileges can change (to prevent using your software being a vector for an escalation of privilege virus attack). Don't use private\system directories (such as the C:\Installer folder) as those are not managed by you and there is no guarantee that the contents won't be cleaned out underneath you. For this same reason, it is not recommended to cache it in any temporary location, such as under %TEMP%. There is some software that has cached MSI files in the C:\Windows\Downloaded Installations folder, but that location may be subject to cleanup by the disk cleanup tool. Other locations I have seen include under the Common Files folder of the Program Files folder, in a hidden folder of the program's own installation folder, and in custom hidden folders off the system drive's root folder. I'm not sure where burn caches, I would have to look in through the source code, although I believe it is under the control of the UI you add to burn, so it could potentially be anywhere. Hmm... I see a problem. I don't want my bootstrapper to run as admin, so it won't have access to the protected areas like Program Files. The reason I don't want to run as admin is because then it won't be able to launch stuff on behalf of the logged in user (which may be different from the admin). This is getting hairier and hairier. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] getting a list of properties from an already-build MSI?
My goal is to take an msi and find out what properties I can pass it on the command line when I run msiexec. I see a number of entries from the log when I install it that look like the following: MSI (s) (D8:D0) [17:07:48:626]: PROPERTY CHANGE: Adding BIN property. Its value is 'redacted'. MSI (s) (D8:D0) [17:07:48:626]: PROPERTY CHANGE: Adding CONFIGS property. Its value is 'redacted'. MSI (s) (D8:D0) [17:07:48:626]: PROPERTY CHANGE: Adding INSTALLDIR property. Its value is 'redacted'. MSI (s) (D8:D0) [17:07:48:626]: PROPERTY CHANGE: Adding TARGETDIR property. Its value is 'redacted'. MSI (s) (D8:D0) [17:07:48:626]: PROPERTY CHANGE: Adding CURRENTDIRECTORY property. Its value is 'redacted'. Are these the properties? Andrew On Fri, Jun 18, 2010 at 4:49 PM, Blair os...@live.com wrote: There are properties that are defined by the system, properties that are defined by the package (initial values are in the Property table), and properties that are created while the installation transaction proceeds (whether by searches or custom actions). To see final values for all custom actions (as well as property creations and value changes) generate a verbose log in your transaction. -Original Message- From: Andrew Hammond [mailto:andrew.george.hamm...@gmail.com] Sent: Friday, June 18, 2010 4:31 PM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] getting a list of properties from an already-build MSI? Is there a way to get a list of properties from an MSI? I can install it if necessary. A -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Can this be done with WiX?
Two solutions I have seen to deal with this: 1- Use a custom action to cache the MSI and add the cache directory to the source list. 2- Use a bootstrapper that launches asInvoker, then relaunches either itself or some extracted code as administrator. You then have elevated code for installing things, and non-elevated code for launching things. -Original Message- From: i...@roadrunner.com [mailto:i...@roadrunner.com] Sent: Friday, June 18, 2010 5:25 PM To: 'General discussion for Windows Installer XML toolset.'; Blair Subject: RE: [WiX-users] Can this be done with WiX? Blair os...@live.com wrote: I see. So as I understand it, I have to keep the MSI around while the software is installed. Is there a recommended location for such cached MSIs? And is it even possible for the MSI to delete itself during uninstall? How does Burn handle this? If the MSI is installed per-user, it would be recommended to cache it somewhere in the user's roaming profile (since per-user installations can roam). In the case of per-machine installation, it should be place somewhere outside of all user profiles that only someone with admin privileges can change (to prevent using your software being a vector for an escalation of privilege virus attack). Don't use private\system directories (such as the C:\Installer folder) as those are not managed by you and there is no guarantee that the contents won't be cleaned out underneath you. For this same reason, it is not recommended to cache it in any temporary location, such as under %TEMP%. There is some software that has cached MSI files in the C:\Windows\Downloaded Installations folder, but that location may be subject to cleanup by the disk cleanup tool. Other locations I have seen include under the Common Files folder of the Program Files folder, in a hidden folder of the program's own installation folder, and in custom hidden folders off the system drive's root folder. I'm not sure where burn caches, I would have to look in through the source code, although I believe it is under the control of the UI you add to burn, so it could potentially be anywhere. Hmm... I see a problem. I don't want my bootstrapper to run as admin, so it won't have access to the protected areas like Program Files. The reason I don't want to run as admin is because then it won't be able to launch stuff on behalf of the logged in user (which may be different from the admin). This is getting hairier and hairier. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Set package name dynamically
Is there any way to set the packa...@description property dynamically? It does
seem to accept bracket-style properties, but it only uses the values that those
properties are initialized to on startup. If I change the value during
install, I still get the original value displayed in Add/Remove Programs.
Basically, my application is cobranded with different names and I'm building a
generic installer. I read the brand name from a license key in a custom action
before the first UI dialog. I use that to decide what to set the ProductName
property to and what graphics to load in to the UI.
It works great, except I can't get the name in add/remove programs updated. I
tried changing the
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{guid}\DisplayName
value, but it seems to have no effect.
The docs say that that packa...@description ends up in the summary information
stream. Is there a way to write to the summary information stream dynamically
at runtime? Or is this hardcoded into the MSI? Perhaps there's a way to write
to the cached MSI that Add/Remove programs is looking at? I'm not sure where
it's cached to. Please help.
Thanks,
Matt Johnson MCPD, MCTS, MCSD, MCDBA
Director of Application Development
Time America, Inc.
ma...@timeamerica.commailto:ma...@timeamerica.com |
www.timeamerica.comhttp://www.timeamerica.com/
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Can this be done with WiX?
Two solutions I have seen to deal with this: 1- Use a custom action to cache the MSI and add the cache directory to the source list. 2- Use a bootstrapper that launches asInvoker, then relaunches either itself or some extracted code as administrator. You then have elevated code for installing things, and non-elevated code for launching things. #1 looks ideal. I'll extract into %ALLUSERSPROFILE% and will add that to the source list. Thanks -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Set package name dynamically
The summary information stream is MSI metadata outside of the MSI SQL
database (but inside of the MSI file) and uses a different set of APIs to
access than the rest of the data in the file. Changing it would have to
occur before you start an installation transaction, and if you codesign your
MSIs to prove to your customers that no tampering has occurred, changing the
summary info stream will invalidate your signature (the system will treat it
as if it had never been signed, including the scarier UAC-related prompt
used with unsigned files vs. the one used with signed files).
The data in the registry related to display in ARP is used only for legacy
installations (those that are non-MSI based). The only way to, at runtime,
change that data is to use the ARPSYSTEMCOMPONENT property and then write an
entirely new legacy registry entry for ARP. However, there are downsides
to that: for one - you lose the Repair button in ARP.
A discussion on using that property, including some dangers and some
mitigations, can be found by checking the posts on this page:
http://blogs.msdn.com/b/heaths/archive/tags/arpsystemcomponent/. I recommend
reading the blogs in the order they were written, which would mean oldest
first (bottom of page?).
-Original Message-
From: Matt Johnson [mailto:ma...@timeamerica.com]
Sent: Friday, June 18, 2010 5:46 PM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Set package name dynamically
Is there any way to set the packa...@description property dynamically? It
does seem to accept bracket-style properties, but it only uses the values
that those properties are initialized to on startup. If I change the value
during install, I still get the original value displayed in Add/Remove
Programs.
Basically, my application is cobranded with different names and I'm building
a generic installer. I read the brand name from a license key in a custom
action before the first UI dialog. I use that to decide what to set the
ProductName property to and what graphics to load in to the UI.
It works great, except I can't get the name in add/remove programs updated.
I tried changing the
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{guid}\DisplayName
value, but it seems to have no effect.
The docs say that that packa...@description ends up in the summary
information stream. Is there a way to write to the summary information
stream dynamically at runtime? Or is this hardcoded into the MSI? Perhaps
there's a way to write to the cached MSI that Add/Remove programs is looking
at? I'm not sure where it's cached to. Please help.
Thanks,
Matt Johnson MCPD, MCTS, MCSD, MCDBA
Director of Application Development
Time America, Inc.
ma...@timeamerica.commailto:ma...@timeamerica.com |
www.timeamerica.comhttp://www.timeamerica.com/
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] getting a list of properties from an already-build MSI?
Those would be some, yes. Depending on how the MSI and the various custom actions in it work, some subset of all the properties that are in all CAPS may be set from the commandline. However, it is possible for custom actions to override any of those properties you set with values of its own. Further, any of those properties not found in the list on this page: http://msdn.microsoft.com/library/aa371243.aspx or those in the SecureCustomProperties property may be ignored by the server-side of the installation (but not the client side). -Original Message- From: Andrew Hammond [mailto:andrew.george.hamm...@gmail.com] Sent: Friday, June 18, 2010 5:16 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] getting a list of properties from an already-build MSI? My goal is to take an msi and find out what properties I can pass it on the command line when I run msiexec. I see a number of entries from the log when I install it that look like the following: MSI (s) (D8:D0) [17:07:48:626]: PROPERTY CHANGE: Adding BIN property. Its value is 'redacted'. MSI (s) (D8:D0) [17:07:48:626]: PROPERTY CHANGE: Adding CONFIGS property. Its value is 'redacted'. MSI (s) (D8:D0) [17:07:48:626]: PROPERTY CHANGE: Adding INSTALLDIR property. Its value is 'redacted'. MSI (s) (D8:D0) [17:07:48:626]: PROPERTY CHANGE: Adding TARGETDIR property. Its value is 'redacted'. MSI (s) (D8:D0) [17:07:48:626]: PROPERTY CHANGE: Adding CURRENTDIRECTORY property. Its value is 'redacted'. Are these the properties? Andrew On Fri, Jun 18, 2010 at 4:49 PM, Blair os...@live.com wrote: There are properties that are defined by the system, properties that are defined by the package (initial values are in the Property table), and properties that are created while the installation transaction proceeds (whether by searches or custom actions). To see final values for all custom actions (as well as property creations and value changes) generate a verbose log in your transaction. -Original Message- From: Andrew Hammond [mailto:andrew.george.hamm...@gmail.com] Sent: Friday, June 18, 2010 4:31 PM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] getting a list of properties from an already-build MSI? Is there a way to get a list of properties from an MSI? I can install it if necessary. A -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] GAC an assembly without embedding it within the MSI
How does that file get on customers' machines and why didn't the original author have it GAC'd in their distribution of that file? Could it possibly not be intended for use from the GAC? Might that create a security issue? What if the original installation needs to remove or upgrade that file, and doesn't know about its entry in the GAC? It won't be upgraded, which could then present a separate security risk caused by the now-false believe that applying updates fixed all copies of the bad code. Also, your setup should be regenerated every time any of its inputs change. Otherwise a repair could very well undo your updates performed outside of MSI. -Original Message- From: Sajo Jacob [mailto:spja...@gmail.com] Sent: Friday, June 18, 2010 9:11 AM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] GAC an assembly without embedding it within the MSI I want to GAC an assembly already present on target machines, I know where this assembly is on every machine (you can assume, that path is static for all target machines and wont change) I do not want to include the assembly to be GAC'd in the MSI since it can change with each software deployment and we dont want our setup to be modified each time . I tried using the File tag with Assembly =.net File Id=Assembly.dll Name=Assembly.dll Assembly=.net Source=Assembly.dll KeyPath=yes /File but using File embeds my assembly in the MSI. Any ideas on how to just tell the MSI to just look for the assembly in a particular location and not include it? -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
