[WiX-users] Mixing radio buttons and checkboxes
Hi I am trying to achieve this UI in my installer page: (*) Choice1 [ ] Check1 [ ] Check2 ( ) Choice2 [ ] Check3 [ ] Check4 Here's my code: While it looks OK, I am unable to click on Check1 or Check2 because the radio group overlaps them. The radio group spans from the top of Choice1 to the bottom of Choice2. I tried declaring the checkboxes before the radio group, and then it kind of works, except that the checkboxes are hidden until I mouse over them. It also doesn't give me the tab order I want. So is there a way to have checkboxes between two radio buttons in Windows Installer? Thanks Ivo -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Authenticode signatures
Hi I have a digital certificate and I signed my MSI with it. When I view the properties of the file in Explorer it shows the certificate correctly. So far so good. Then I modified the MSI file in a binary editor (changed one byte). Now when I run the signtool I get an error that the verification failed. So far so good. But when I view the file properties I still see the certificate. I was able to run the MSI and install it. I was expecting Explorer to detect the file as corrupted and for the MSI to fail to install. What am I missing? Is there an extra step during the WiX pipeline that I need to do, or were my expectations wrong that a file modification will be caught by Windows? Thanks Ivo -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Multi-platform installer with WiX
I see. That's a good point. So I wrote me a quick program to compare the two full MSIs (the 32-bit and 64-bit) and to search for the longest chunk that's common between the two. It finds a piece that is about the size of the shared cab. It happens to be at the same offset in both files, which was not entirely unexpected. Now I can have my EXE contain 5 individual chunks - 2 unique for each MSI and the common piece in the middle, and then assemble them during the extraction. The final extracted file should be identical to the original MSI. I am doing my testing without an Authenticode signature though, because I don't have a certificate yet. I'm hoping that signing the MSI will not scramble the innards of the files too much and I will still be able to locate a large enough chunk that is shared between the two files. It is my understanding that the signature is just embedded somehow into the file and does not encrypt or compress of the contents. -Original Message- From: Bob Arnson [mailto:b...@joyofsetup.com] Sent: Monday, June 24, 2013 8:51 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Multi-platform installer with WiX On 24-Jun-13 23:32, Ivo Beltchev wrote: > Which part is the problem? The embedding of the CAB or the mucking > with the Media table? Any change invalidates the signature. -- sig://boB http://joyofsetup.com/ -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Multi-platform installer with WiX
Which part is the problem? The embedding of the CAB or the mucking with the Media table? If it is the second part, maybe I can build the MSIs initially with embedded CABs, then delete them from the streams. This way the Media table will stay unchanged. -Original Message- From: Bob Arnson [mailto:b...@joyofsetup.com] Sent: Monday, June 24, 2013 8:25 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Multi-platform installer with WiX On 24-Jun-13 14:44, Ivo Beltchev wrote: > When the installer runs it extracts one of the MSIs and the shared > cab. Then with some database voodoo from msi.dll I embed the shared > cab into the MSI and change the Cabinet field in the Media table to > start with #. This marks it as internal. That breaks Authenticode signatures, which is a problem if you want to ship externally. -- sig://boB http://joyofsetup.com/ -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Multi-platform installer with WiX
No, my bootstrapper is an EXE, not MSI. If you call it directly it will create the correct MSI and then launch it. You can also call it with "extract32" or "extract64", which will just extract the correct MSI and you can do whatever you want with it. The EXE does other things as well, like calculate checksum for the files to detect corrupted downloads, warn if you are installing on a unsupported OS, etc. BTW, I'm still using WiX 3.0 (basically the version that came with WiX Edit) and I think Burn was not an option back then. -Original Message- From: Nick Ramirez [mailto:nickra...@hotmail.com] Sent: Monday, June 24, 2013 12:05 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Multi-platform installer with WiX You're embedding an MSI inside an MSI? Wouldn't Burn work out better? A Burn bundle can embed all of its resources into a setup executable. Will upgrades still function correctly using an embedded MSI? -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Multi-platform -installer-with-WiX-tp7586785p7586810.html Sent from the wix-users mailing list archive at Nabble.com. -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Multi-platform installer with WiX
I think I found a solution that works. For both MSIs I split the files into 2 media elements - one embedded and one external (for the shared files). Then I build both MSIs and compare the external CABs to verify they are identical. When the installer runs it extracts one of the MSIs and the shared cab. Then with some database voodoo from msi.dll I embed the shared cab into the MSI and change the Cabinet field in the Media table to start with #. This marks it as internal. Thanks for your help Ivo -Original Message- From: Bob Arnson [mailto:b...@joyofsetup.com] Sent: Sunday, June 23, 2013 7:59 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Multi-platform installer with WiX On 23-Jun-13 15:13, Ivo Beltchev wrote: > I need an installer that can work for both 32-bit and 64-bit OS. > Currently I build 2 separate MSIs and bundle them together in a > bootstrapper EXE. The problem is that 90% of the files are common > between the two platforms and my installer is almost double of what it can be. Build your packages so that the 32-bit package installs on both x86 and x64 OSes and the 64-bit package installs only necessary 64-bit components. > Another solution I'm looking at is to create 2 MSI files with a shared CAB. > I can't find any instructions how to create such CAB though. If the > 32-bit and the 64-bit MSIs produce their own CABs, how do I combine > them into one file that has no duplicate resources? Use multiple Media elements to create multiple .cabs. -- sig://boB http://joyofsetup.com/ -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Multi-platform installer with WiX
It is a shell extension. I need to register both 32-bit and 64-bit DLLs when I install on 64-bit OS. Also I would prefer on 64-bit systems to install in the main Program Files, where all self-respected applications supporting 64 bits should go. -Original Message- From: Nick Ramirez [mailto:nickra...@hotmail.com] Sent: Sunday, June 23, 2013 4:18 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Multi-platform installer with WiX I'm often curious to learn more about 64-bit vs. 32-bit applications. What are your reasons for targeting both architectures? Is it not possible, in your case, to only target 32-bit? You say that there are 10% of files that are different between the two installers? Can you say more about that? Does your applications use a lot of RAM or PInvoke into some 64-bit unmanaged code? These questions may not immediately solve your own problem, but others like me would benefit from learning from your specific install scenario. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Multi-platform -installer-with-WiX-tp7586785p7586789.html Sent from the wix-users mailing list archive at Nabble.com. -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Multi-platform installer with WiX [P]
What I meant by this is I create 2 separate MSIs then use torch to create MST that transforms one into the other. I found this suggestion when searching for a solution to my problem (might have been on stackoverflow). I am still not 100% sure if this is indeed not possible or I did something wrong. -Original Message- From: Steven Ogilvie [mailto:steven.ogil...@titus.com] Sent: Sunday, June 23, 2013 12:40 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Multi-platform installer with WiX [P] Classification: Public Hi Ivo, I am not really sure on your overall question... However, you cannot create 1 MSI for both 32 and 64 Bit OS's there must be 1 MSI for each bitness (32/64). So this paragraph is not possible: " One solution I tried is to create a transform that converts one MSI into the other. However it looks like a transform can't modify the Package.Platform setting. If my main MSI is 64-bit, it won't even start on 32-bit Windows. If I make the 32-bit MSI the main, even after the transformation it still can't access the 64-bit OS folders like Program Files or System32. Another smaller problem is that since MSTs can't contain resources, I have to put all my files into the main MSI. This gives me warnings that I have files with the same target name. It is fine though, because I have mutually-exclusive conditions for each of the components." I am not sure about the cabs... Steve -----Original Message- From: Ivo Beltchev [mailto:i...@ibeltchev.com] Sent: June-23-13 3:13 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Multi-platform installer with WiX Hi. I need an installer that can work for both 32-bit and 64-bit OS. Currently I build 2 separate MSIs and bundle them together in a bootstrapper EXE. The problem is that 90% of the files are common between the two platforms and my installer is almost double of what it can be. One solution I tried is to create a transform that converts one MSI into the other. However it looks like a transform can't modify the Package.Platform setting. If my main MSI is 64-bit, it won't even start on 32-bit Windows. If I make the 32-bit MSI the main, even after the transformation it still can't access the 64-bit OS folders like Program Files or System32. Another smaller problem is that since MSTs can't contain resources, I have to put all my files into the main MSI. This gives me warnings that I have files with the same target name. It is fine though, because I have mutually-exclusive conditions for each of the components. Another solution I'm looking at is to create 2 MSI files with a shared CAB. I can't find any instructions how to create such CAB though. If the 32-bit and the 64-bit MSIs produce their own CABs, how do I combine them into one file that has no duplicate resources? Also ideally my bootstrapper should be able to extract one of the MSIs and the CAB and then merge the two on the user's machine. This way the user will get a single file to deal with. Is this possible? I've seen some scripts that can do the merging, but I'm not sure if they require the Windows SDK to be installed. Also I'd rather do this in C++ because my bootstrapper is in C++. So, to recap: What is the recommended way to create one installer that supports both platforms? How do I create a shared CAB that contains files from multiple MSIs? How do I merge the MSI and the CAB on the user machine? Regards Ivo -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users This message has been marked as Public by Steven Ogilvie on June-23-13 3:40:04 PM. The above classification labels were added to the message by TITUS Message Classification. For more information visit www.titus.com. -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Multi-platform installer with WiX
Hi. I need an installer that can work for both 32-bit and 64-bit OS. Currently I build 2 separate MSIs and bundle them together in a bootstrapper EXE. The problem is that 90% of the files are common between the two platforms and my installer is almost double of what it can be. One solution I tried is to create a transform that converts one MSI into the other. However it looks like a transform can't modify the Package.Platform setting. If my main MSI is 64-bit, it won't even start on 32-bit Windows. If I make the 32-bit MSI the main, even after the transformation it still can't access the 64-bit OS folders like Program Files or System32. Another smaller problem is that since MSTs can't contain resources, I have to put all my files into the main MSI. This gives me warnings that I have files with the same target name. It is fine though, because I have mutually-exclusive conditions for each of the components. Another solution I'm looking at is to create 2 MSI files with a shared CAB. I can't find any instructions how to create such CAB though. If the 32-bit and the 64-bit MSIs produce their own CABs, how do I combine them into one file that has no duplicate resources? Also ideally my bootstrapper should be able to extract one of the MSIs and the CAB and then merge the two on the user's machine. This way the user will get a single file to deal with. Is this possible? I've seen some scripts that can do the merging, but I'm not sure if they require the Windows SDK to be installed. Also I'd rather do this in C++ because my bootstrapper is in C++. So, to recap: What is the recommended way to create one installer that supports both platforms? How do I create a shared CAB that contains files from multiple MSIs? How do I merge the MSI and the CAB on the user machine? Regards Ivo -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Logging while uninstalling from Control Panel
I think you can edit the registry (via custom action or another way) to
set WindowsInstaller to 0, and change UninstallString to "MsiExec.exe /x
{blah} /l*v C:\q.txt".
I don't know what is the best way to achieve this, or if there won't be
any ill effects.
Castro, Edwin G. (Hillsboro) wrote:
> I don't think it's possible to enable logging at uninstall time from the
> control panel to a custom location for a very specific package.
> _As I understand it_ the control panel simply does the equivalent of
>
> Msiexec.exe /x [productcode]
>
> That's it. Your only option is to enable logging for all installers *OR*
> uninstall from the command line.
>
> 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: Sai Kodi [mailto:saik...@hotmail.com]
> Sent: Friday, August 06, 2010 9:50 AM
> To: 'General discussion for Windows Installer XML toolset.'
> Subject: Re: [WiX-users] Logging while uninstalling from Control Panel
>
> Hi Pally,
>
> That's not what I am looking for. I have already done that search and I know
> how that works.
>
> I want to be able to create a log file during uninstallation only at a custom
> location with a custom file name. I don't want to enable logging for all the
> installers. I just want to log the uninstallation of my application.
> Using msiexec, I can do that using:
>
> Msiexec.exe /x [productcode] /l*v uninstall.log
>
> How can I achieve a similar behavior while uninstalling from Control Panel?
>
> Thanks,
> Sai Kodi
>
> -Original Message-
> From: Pally Sandher [mailto:pally.sand...@iesve.com]
> Sent: Friday, August 06, 2010 4:05 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Logging while uninstalling from Control Panel
>
> http://lmgtfy.com/?q=how+to+enable+windows+installer+logging
>
> 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 ** 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: saikodi [mailto:saik...@hotmail.com]
> Sent: 06 August 2010 07:51
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Logging while uninstalling from Control Panel
>
>
> Hello All,
>
> If the user uninstalls an application from Control Panel, is it possible to
> provide an uninstallation log file somehow for the uninstallation process?
> If so, how would I provide that log file name and location?
>
> Please advise.
>
> Thanks,
> Sai Kodi
> --
> View this message in context:
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Logging-wh
> ile-uninstalling-from-Control-Panel-tp5379515p5379515.html
> Sent from the wix-users mailing list archive at Nabble.com.
>
>
> --
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
>
>
> --
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> --
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> --
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
--
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
___
WiX-users
Re: [WiX-users] Uninstaller breaks the registry
What is the easiest way to write from a custom action into the Registry table? I'll try to avoid doing patches because of a few reasons: 1) I will need 4 of them - there are 2 bad versions in the wild, and each has 32 and 64 bit variations 2) I will need to keep the patches around for a long time (basically any new version needs to include them) 3) Installing a patch will require a separate elevation prompt The patches will be my plan B if the registry table trick fails. Blair wrote: > Can't you "read" and serialize the key into temporary rows in the Registry > table? That wouldn't have to run after InstallInitialize. > > The "canonical" way to deal with your situation is to use a bootstrapper > that forces an update to the broken installation that changes the registry > action value, and a new MSI that doesn't allow the upgrade if an unpatched > old version is detected. You can then build a one-off MSP file that fixes > just that issue in our broken MSI that you package into your bootstrapper. > > The correct action would be "none". The key will be created if needed, and > will be removed if it (and all of its subkeys) are discovered to be empty > during uninstall. > > -Original Message- > From: Ivo Beltchev [mailto:i...@roadrunner.com] > Sent: Monday, July 26, 2010 9:46 PM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Uninstaller breaks the registry > > Please help, guys. > > I screwed up badly and need to fix this before the problem gets worse. > > My current idea is to run a custom action before upgrade that stores the > registry key in a file and then another action after the uninstall to > restore the key. I have implemented the custom actions, but I'm having a > problem scheduling the "store" action at the right time. It must be after > InstallInitialize (because it needs to run elevated), and must be before > RemoveExistingProducts (because it needs to capture the registry before the > old version is removed). But I'm getting a build warning "ICE63 - Some > action falls between InstallInitialize and RemoveExistingProducts". I > ignored the warning but then the upgrade fails with "error 2613: > RemoveExistingProducts action sequenced incorrectly". > > So is there a way to run an elevated custom action before the old version is > uninstalled? And can you suggest a better way to solve my problem? > > Thanks > Ivo > > P.S. BTW, what is the right action to use with the Run key - "create" or > "none"? > > > > i...@roadrunner.com wrote: > >> Hi >> >> In my installer I add a value to >> > HKLM\Software\Microsoft\Windows\CurrentVersion\Run. > >> By mistake I set the action to "createAndRemoveOnUninstall", so now when >> > you uninstall or upgrade my program it removes the Run key. Very bad. > >> Is there anything I can do in the next version, so when you upgrade it >> > won't destroy the Run key? > >> Thanks >> Ivo >> >> >> >> > > -- > >> The Palm PDK Hot Apps Program offers developers who use the >> Plug-In Development Kit to bring their C/C++ apps to Palm for a share >> of $1 Million in cash or HP Products. Visit us here for more details: >> http://ad.doubleclick.net/clk;226879339;13503038;l? >> http://clk.atdmt.com/CRS/go/247765532/direct/01/ >> ___ >> WiX-users mailing list >> WiX-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/wix-users >> >> >> > > > -- > The Palm PDK Hot Apps Program offers developers who use the > Plug-In Development Kit to bring their C/C++ apps to Palm for a share > of $1 Million in cash or HP Products. Visit us here for more details: > http://ad.doubleclick.net/clk;226879339;13503038;l? > http://clk.atdmt.com/CRS/go/247765532/direct/01/ > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > > -- > The Palm PDK Hot Apps Program offers developers who use the > Plug-In Development Kit to bring their C/C++ apps to Palm for a share > of $1 Million in cash or HP Products. Visit us here for more details: > http://ad.doubleclick.net/clk;226879339;13503038;l? >
Re: [WiX-users] Uninstaller breaks the registry
Please help, guys. I screwed up badly and need to fix this before the problem gets worse. My current idea is to run a custom action before upgrade that stores the registry key in a file and then another action after the uninstall to restore the key. I have implemented the custom actions, but I'm having a problem scheduling the "store" action at the right time. It must be after InstallInitialize (because it needs to run elevated), and must be before RemoveExistingProducts (because it needs to capture the registry before the old version is removed). But I'm getting a build warning "ICE63 - Some action falls between InstallInitialize and RemoveExistingProducts". I ignored the warning but then the upgrade fails with "error 2613: RemoveExistingProducts action sequenced incorrectly". So is there a way to run an elevated custom action before the old version is uninstalled? And can you suggest a better way to solve my problem? Thanks Ivo P.S. BTW, what is the right action to use with the Run key - "create" or "none"? i...@roadrunner.com wrote: > Hi > > In my installer I add a value to > HKLM\Software\Microsoft\Windows\CurrentVersion\Run. > By mistake I set the action to "createAndRemoveOnUninstall", so now when you > uninstall or upgrade my program it removes the Run key. Very bad. > Is there anything I can do in the next version, so when you upgrade it won't > destroy the Run key? > > Thanks > Ivo > > > -- > The Palm PDK Hot Apps Program offers developers who use the > Plug-In Development Kit to bring their C/C++ apps to Palm for a share > of $1 Million in cash or HP Products. Visit us here for more details: > http://ad.doubleclick.net/clk;226879339;13503038;l? > http://clk.atdmt.com/CRS/go/247765532/direct/01/ > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://ad.doubleclick.net/clk;226879339;13503038;l? http://clk.atdmt.com/CRS/go/247765532/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Restart Manager (reboot after uninstall)
This is a shell extension and the DLL is used by the Explorer process. There are two scenarios: 1) Uninstall - no file is actually "replaced", simply deleted. 2) Upgrade - the DLL is replaced by a new version. The Restart Manager correctly identifies that the DLL is in use by Explorer and offers to close it. If I choose to close it, everything works fine - The Explorer is closed, then restarted at the end of the install process. If I choose not to close it at this time I expect a prompt to reboot the machine at the end. I don't get one. So the old version of the DLL is still loaded by Explorer, preventing the new version from showing up. The thing gets a bit more complicated because the shell extension gets loaded in other processes that use the shell (pretty much every app that has a FileOpen box). That's why I want to rely on the Restart Manager to do its thing instead of trying to make a custom solution specifically for Explorer.exe. Blair wrote: > If you didn't replace one of the files that were discovered to be in use, > then no, you won't get an automatic reboot prompt. Which file did you > replace when you uninstalled your application? > > -----Original Message- > From: Ivo Beltchev [mailto:i...@roadrunner.com] > Sent: Wednesday, July 14, 2010 9:04 AM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Restart Manager (reboot after uninstall) > > But I don't want to restart unconditionally. Only when the user chooses > to stop the Restart Manager from closing the offending applications. Is > there a way to detect that? > > I'm reading the documentation for the REBOOT property here: > http://msdn.microsoft.com/en-us/library/aa371101(VS.85).aspx > It says "For example, the installer automatically prompts for a restart > if it needs to replace any files in use during the installation." So I'm > thinking that I should get a reboot prompt at the end of the uninstall > or upgrade. But there isn't one. Am I reading the documentation correctly? > > Blair wrote: > >> If you have code that causes the application(s) detected to shutdown >> (including using the built-in actions to stop services you install) the >> restart manager-related detection code doesn't always acknowledge that. As >> > a > >> result the user is often told of a need for reboots that ultimately are >> never required. >> >> If files-in-use are not replaced (just moved/marked for removal on next >> reboot) then Windows Installer doesn't ask for a reboot unless a >> reboot-related action or property are set indicating otherwise. In >> uninstallations, that is often the case. >> >> You could try setting REBOOT=Force when you detect that you will be >> uninstalling. That should cause a reboot prompt. >> >> The reason for reboot instead of logoff is that the system that removes >> marked files system boot during isn't activated during logoff or logon, so >> the marked files are never actually removed until an actual reboot. >> >> -Original Message- >> From: Ivo Beltchev [mailto:i...@roadrunner.com] >> Sent: Tuesday, July 13, 2010 8:55 PM >> To: General discussion for Windows Installer XML toolset. >> Subject: [WiX-users] Restart Manager (reboot after uninstall) >> >> Hi >> >> I have an uninstaller that uses the Restart Manager. When it detects >> that files are in use it shows one of two messages: >> >> 1) When uninstalling in quiet mode, there is a popup saying ".. a >> reboot will be required to complete the setup" >> >> 2) When uninstalling in UI mode, there is a list of processes with 2 >> options: A) restart applications, B) Do not close applications. A reboot >> will be required. >> >> I am expecting that after the uninstaller is finished there will be a >> prompt to restart the computer, but I don't get one. >> >> Reading about MsiRMFilesInUse here: >> http://wix.sourceforge.net/manual-wix3/WixUI_dialogs.htm, I see "It >> allows the user to attempt to automatically close applications or ignore >> the prompt and result in the setup requiring a reboot after it >> completes." What does "result in requiring a reboot" mean? That the >> setup will ask the user to reboot, or that the user must remember to >> reboot manually? >> >> If there is no reboot prompt built in, how do I make one (basically how >> do I detect if the user has chosen not to close the applications)? And >> even better, if I can customize the prompt to do a log off
Re: [WiX-users] Restart Manager (reboot after uninstall)
But I don't want to restart unconditionally. Only when the user chooses to stop the Restart Manager from closing the offending applications. Is there a way to detect that? I'm reading the documentation for the REBOOT property here: http://msdn.microsoft.com/en-us/library/aa371101(VS.85).aspx It says "For example, the installer automatically prompts for a restart if it needs to replace any files in use during the installation." So I'm thinking that I should get a reboot prompt at the end of the uninstall or upgrade. But there isn't one. Am I reading the documentation correctly? Blair wrote: > If you have code that causes the application(s) detected to shutdown > (including using the built-in actions to stop services you install) the > restart manager-related detection code doesn't always acknowledge that. As a > result the user is often told of a need for reboots that ultimately are > never required. > > If files-in-use are not replaced (just moved/marked for removal on next > reboot) then Windows Installer doesn't ask for a reboot unless a > reboot-related action or property are set indicating otherwise. In > uninstallations, that is often the case. > > You could try setting REBOOT=Force when you detect that you will be > uninstalling. That should cause a reboot prompt. > > The reason for reboot instead of logoff is that the system that removes > marked files system boot during isn't activated during logoff or logon, so > the marked files are never actually removed until an actual reboot. > > -Original Message- > From: Ivo Beltchev [mailto:i...@roadrunner.com] > Sent: Tuesday, July 13, 2010 8:55 PM > To: General discussion for Windows Installer XML toolset. > Subject: [WiX-users] Restart Manager (reboot after uninstall) > > Hi > > I have an uninstaller that uses the Restart Manager. When it detects > that files are in use it shows one of two messages: > > 1) When uninstalling in quiet mode, there is a popup saying ".. a > reboot will be required to complete the setup" > > 2) When uninstalling in UI mode, there is a list of processes with 2 > options: A) restart applications, B) Do not close applications. A reboot > will be required. > > I am expecting that after the uninstaller is finished there will be a > prompt to restart the computer, but I don't get one. > > Reading about MsiRMFilesInUse here: > http://wix.sourceforge.net/manual-wix3/WixUI_dialogs.htm, I see "It > allows the user to attempt to automatically close applications or ignore > the prompt and result in the setup requiring a reboot after it > completes." What does "result in requiring a reboot" mean? That the > setup will ask the user to reboot, or that the user must remember to > reboot manually? > > If there is no reboot prompt built in, how do I make one (basically how > do I detect if the user has chosen not to close the applications)? And > even better, if I can customize the prompt to do a log off instead of > reboot. > > > Thanks > Ivo > > > > > -- > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > > -- > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Restart Manager (reboot after uninstall)
Hi I have an uninstaller that uses the Restart Manager. When it detects that files are in use it shows one of two messages: 1) When uninstalling in quiet mode, there is a popup saying ".. a reboot will be required to complete the setup" 2) When uninstalling in UI mode, there is a list of processes with 2 options: A) restart applications, B) Do not close applications. A reboot will be required. I am expecting that after the uninstaller is finished there will be a prompt to restart the computer, but I don't get one. Reading about MsiRMFilesInUse here: http://wix.sourceforge.net/manual-wix3/WixUI_dialogs.htm, I see "It allows the user to attempt to automatically close applications or ignore the prompt and result in the setup requiring a reboot after it completes." What does "result in requiring a reboot" mean? That the setup will ask the user to reboot, or that the user must remember to reboot manually? If there is no reboot prompt built in, how do I make one (basically how do I detect if the user has chosen not to close the applications)? And even better, if I can customize the prompt to do a log off instead of reboot. Thanks Ivo -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Problem with "Close App" condition
I think I know what is going on. Lets say I have 2 versions 1.0 and 2.0. The first one is installed and I'm upgrading to the second. Here's what I think happens: - installer 2.0 starts up - installer 2.0 checks the condition for CloseMyApp. !MyAppFeature is 2, &MyAppFeature is 3. Nothing happens, because the condition is false - installer 2.0 runs the Restart Manager. It detects that the EXE is in use and asks me to close it - installer 2.0 runs uninstaller 1.0 - uninstaller 1.0 checks the condition for CloseMyApp. !MyAppFeature is 3, &MyAppFeature is 2 and the action runs. However the EXE is already gone - uninstaller 1.0 runs the Restart Manager, but there is nothing to restart So looks like I'm barking up the wrong tree. I was thinking that the EXE should be closed as part of the uninstall process of 1.0. But instead, it should be done even before uninstaller 1.0 is launched. What's worse - the installer 2.0 has no idea where the EXE is located, since the previous version can be installed in a different folder. My solution is to add a new helper tool, whose purpose is to look for the EXE that needs closing and shut it down if it exists. It looks in the registry to find the install folder of the previous version. I also changed my condition to this: ((!MyAppFeature=3) AND (&MyAppFeature=2)) OR PREVIOUSVERSIONSINSTALLED This way it will be triggered during uninstall if the feature is present, and on upgrade no matter what. The action may run in some cases when it shouldn't, but no harm done since the helper tool will not find the EXE and quit silently. The solution works, but it's a bit hacky. This makes me think there must be a better way. Any ideas? I doubt I'm the first person to hit this problem. Ivo Ivo Beltchev wrote: > OK, so now my condition is "(!MyAppFeature=3) AND (&MyAppFeature<>3) AND > (&MyAppFeature<>-1)". It works fine during install, uninstall, change or > repair. > But it doesn't seem to work during an upgrade (it's a major upgrade). I > changed it to: > > (!MyAppFeature=3) AND ((&MyAppFeature=2) OR UPGRADINGPRODUCTCODE) > > Basically what I mean is "if the feature is present, and it is being > uninstalled or upgraded". But the action doesn't run. My guess is > UPGRADINGPRODUCTCODE is not set yet, since the action is before > InstallValidate. Is there another way to detect an upgrade before > InstallValidate? > > Ivo > > > Blair wrote: > >> &MyAppFeature is documented to be -1 when MyAppFeature will be left alone by >> the installation transaction. >> >> From: http://msdn.microsoft.com/library/aa368012.aspx >> >> INSTALLSTATE_UNKNOWN -1 No action to be taken on the feature or component. >> >> -Original Message- >> From: Ivo Beltchev [mailto:i...@roadrunner.com] >> Sent: Saturday, June 26, 2010 2:23 PM >> To: General discussion for Windows Installer XML toolset. >> Subject: Re: [WiX-users] Problem with "Close App" condition >> >> Hmm... could be. >> Is it possible that &MyAppFeature is not initialized yet because I'm >> running before "InstallValidate"? I have to run before InstallValidate, >> because I want to run before the Restart Manager pops up and asks to >> close the app for me. >> >> What is the recommended way to debug such problems? Is there a tool that >> can trace through the install process? >> >> Blair wrote: >> >> >>> If your feature won't be affected at all by the transaction (such as when >>> removing a different feature) &MyAppFeature may very well be -1, which >>> >>> >> would >> >> >>> make your condition be true. >>> >>> -Original Message- >>> From: Ivo Beltchev [mailto:i...@roadrunner.com] >>> Sent: Saturday, June 26, 2010 8:11 AM >>> To: General discussion for Windows Installer XML toolset. >>> Subject: [WiX-users] Problem with "Close App" condition >>> >>> Hi >>> >>> I have a custom action that closes my app when its feature is being >>> uninstalled. Here's my code: >>> >>> >> Before="InstallValidate"> >>> >>> For some reason the action gets triggered during "Repair" and also when >>> ANOTHER feature is being uninstalled. Why is this happening? Doesn't my >>> condition mean "if MyAppFeature is installed, and about to be >>> >>> >> uninstalled"? >> >> >>> Thanks >>> Ivo >>> >&
Re: [WiX-users] Problem with "Close App" condition
OK, so now my condition is "(!MyAppFeature=3) AND (&MyAppFeature<>3) AND (&MyAppFeature<>-1)". It works fine during install, uninstall, change or repair. But it doesn't seem to work during an upgrade (it's a major upgrade). I changed it to: (!MyAppFeature=3) AND ((&MyAppFeature=2) OR UPGRADINGPRODUCTCODE) Basically what I mean is "if the feature is present, and it is being uninstalled or upgraded". But the action doesn't run. My guess is UPGRADINGPRODUCTCODE is not set yet, since the action is before InstallValidate. Is there another way to detect an upgrade before InstallValidate? Ivo Blair wrote: > &MyAppFeature is documented to be -1 when MyAppFeature will be left alone by > the installation transaction. > > From: http://msdn.microsoft.com/library/aa368012.aspx > > INSTALLSTATE_UNKNOWN -1 No action to be taken on the feature or component. > > -Original Message- > From: Ivo Beltchev [mailto:i...@roadrunner.com] > Sent: Saturday, June 26, 2010 2:23 PM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Problem with "Close App" condition > > Hmm... could be. > Is it possible that &MyAppFeature is not initialized yet because I'm > running before "InstallValidate"? I have to run before InstallValidate, > because I want to run before the Restart Manager pops up and asks to > close the app for me. > > What is the recommended way to debug such problems? Is there a tool that > can trace through the install process? > > Blair wrote: > >> If your feature won't be affected at all by the transaction (such as when >> removing a different feature) &MyAppFeature may very well be -1, which >> > would > >> make your condition be true. >> >> -Original Message- >> From: Ivo Beltchev [mailto:i...@roadrunner.com] >> Sent: Saturday, June 26, 2010 8:11 AM >> To: General discussion for Windows Installer XML toolset. >> Subject: [WiX-users] Problem with "Close App" condition >> >> Hi >> >> I have a custom action that closes my app when its feature is being >> uninstalled. Here's my code: >> >> > Before="InstallValidate"> >> >> For some reason the action gets triggered during "Repair" and also when >> ANOTHER feature is being uninstalled. Why is this happening? Doesn't my >> condition mean "if MyAppFeature is installed, and about to be >> > uninstalled"? > >> Thanks >> Ivo >> >> >> >> > > >> -- >> This SF.net email is sponsored by Sprint >> What will you do first with EVO, the first 4G phone? >> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first >> ___ >> WiX-users mailing list >> WiX-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/wix-users >> >> >> >> > > -- > >> This SF.net email is sponsored by Sprint >> What will you do first with EVO, the first 4G phone? >> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first >> ___ >> WiX-users mailing list >> WiX-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/wix-users >> >> >> > > > -- > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > > -- > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Question about Start Menu shortcuts
Thanks. That worked perfectly! Blair wrote: > If you are willing to suppress a couple of ICE tests during your build (I > once imposed a rule that every MSI that my team had any responsibility for > must have ALLUSERS set to 1 and no references to HKCU could exist in the > Registry table) you can accomplish both items in your list by doing the > following: > > > > > > > > > > > > Installed OR > ALLUSERS=1 > > >Directory="INSTALLDIR" Guid="*"> > > > >Directory="ProgramMenuDir" KeyPath="yes" > Guid="----"> > STARTMENU > > > Target="[INSTALLDIR]MyProgram.exe" Name="My Program" /> > > > > Then, in your project settings (or your light.exe commandline, depending on > your build system) you suppress ICE38 and ICE43. > > Here's the rational: Both ICE38 and ICE43 (along with a lot of others) make > some (often invalid) assumptions. One of those assumptions is that any > system-defined directory that COULD be in the user profile WILL BE in the > user profile. This is because you can override the ALLUSERS setting from the > Property table (including removing it) using the commandline and/or some > custom action, and the ProgramMenuFolder directory CAN be in the user > profile (when ALLUSERS isn't set [to 1]). ICE43 specifically tests > components containing non-advertized shortcuts for HKCU keypaths (which is > only a valid [IMHO] requirement when installing to a user's Start menu), and > ICE38 looks at components that make use of (in various specific ways) > subfolders of known folders that could be in the user profile. > > If you suppress these ICE tests, it is always a good idea to periodically > review (using either smoke or orca, or some other validation tool) your MSIs > making sure that there are not issues with other components relative to > those ICE tests. Note that the WiX toolset routinely suppresses/ignores > ICE33 and ICE66 (for various historical or other reasons). > > The code I illustrate is safe for per-machine installations (which is why > the ICE tests can be ignored for the MyStartMenu component). If your code > differs materially from my example, you will need to understand what your > code is doing and what effects it will have under different > situations/platforms/etc. You should also always prevent things you > explicitly don't support (such as attempted per-user installations of > per-machine packages) by blocking installation (such as testing for ALLUSERS > being overridden as I have in the example code above). > > Blair > > -Original Message- > From: Ivo Beltchev [mailto:i...@roadrunner.com] > Sent: Saturday, July 03, 2010 7:29 PM > To: General discussion for Windows Installer XML toolset. > Subject: [WiX-users] Question about Start Menu shortcuts > > Hi > > I have an installer with 2 features. Each feature has an EXE. I only > allow per-machine installation, and not per-user. > I want to create a folder in All Users\Start Menu\Programs, which > contains shortcuts to both EXEs. I also want to make that folder > optional, with a property controlled by a checkbox in the CustomizeDlg. > > I am faced with 2 problems: > > 1) I added a Directory "ProgramMenuFolder", another Directory inside it > "ProgramMenuDir" and a Component with a RemoveFolder item (on > uninstall). I followed the instructions in the tutorial, with the > exception that I didn't copy the RegistryValue member of the Component. > Light is giving me an error "ProgramMenuDir installs to user profile. It > must use a registry key under HKCU as its KeyPath". But the thing is I > want to install to the global Programs menu, not the user-specific (my > ALLUSERS is set to 1). Why is it asking to write to HKCU? Maybe instead > of ProgramMenuFolder I should be using something like > CommonProgramMenuFolder? > BTW, even if I add the HKCU key path, I get an error later in the > component that contains the shortcut: "ICE43: Component Blah has > non-advertised shortcuts. It should use a registry key under HKCU as > its KeyPath, not a file.". So again with the registry key paths. > > > 2) I want the shortcut to be installed only if certain property is set > (from the checkbox). I can do that by creating a separate component with > just the shortcut in it, and add a condition to the component. However > it looks like I can't have a component with just a shortcut. The > Shortcut element has no KeyPath property and I get an error about the > missing KeyPath. So ho
Re: [WiX-users] Question about the upgrade code
That was it. The upgrade code is in two places - under Product and under Upgrade. When I was changing the GUID I missed the second location. BTW, I tried posting to this thread 3 times already, but my responses got lost. I think it is because I was using HTML mail. This one is plain text and I hope it makes it through. Thanks Ivo Rob Mensching wrote: > The Upgrade table needs to be authored correctly as well. What does the > verbose log file say? > > On Thu, Jul 1, 2010 at 11:28 PM, Ivo Beltchev wrote: > > >> Hi >> >> I am upgrading my product from a Visual Studio setup project (version >> 1.9.8) to WiX (version 2.7.5). I want the new WiX version to be able to >> upgrade the old one. I also have 2 builds - 32 and 64 bits. >> >> For 32 bits there are no problems. I install version 1.9.8 first, then >> upgrade to 2.7.5 and the upgrade works fine. The old files are removed >> correctly. >> >> For 64 bits the old version is not removed. Both sets of files are >> installed, and I see both versions in the Control Panel -> Programs and >> Features. >> >> I triple-checked the upgrade code, and the code for WiX matches the one >> from Visual Studio. Is the upgrade code the only thing that needs to >> match so that the new version replaces the old one? >> >> And another question - where is the upgrade code stored? I can't find >> that GUID anywhere in the registry. I want to know how the upgrade code >> works so I can troubleshoot this problem. >> >> >> Thanks >> Ivo >> >> >> -- >> This SF.net email is sponsored by Sprint >> What will you do first with EVO, the first 4G phone? >> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first >> ___ >> WiX-users mailing list >> WiX-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/wix-users >> >> >> > > > -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Question about Start Menu shortcuts
Hi I have an installer with 2 features. Each feature has an EXE. I only allow per-machine installation, and not per-user. I want to create a folder in All Users\Start Menu\Programs, which contains shortcuts to both EXEs. I also want to make that folder optional, with a property controlled by a checkbox in the CustomizeDlg. I am faced with 2 problems: 1) I added a Directory "ProgramMenuFolder", another Directory inside it "ProgramMenuDir" and a Component with a RemoveFolder item (on uninstall). I followed the instructions in the tutorial, with the exception that I didn't copy the RegistryValue member of the Component. Light is giving me an error "ProgramMenuDir installs to user profile. It must use a registry key under HKCU as its KeyPath". But the thing is I want to install to the global Programs menu, not the user-specific (my ALLUSERS is set to 1). Why is it asking to write to HKCU? Maybe instead of ProgramMenuFolder I should be using something like CommonProgramMenuFolder? BTW, even if I add the HKCU key path, I get an error later in the component that contains the shortcut: "ICE43: Component Blah has non-advertised shortcuts. It should use a registry key under HKCU as its KeyPath, not a file.". So again with the registry key paths. 2) I want the shortcut to be installed only if certain property is set (from the checkbox). I can do that by creating a separate component with just the shortcut in it, and add a condition to the component. However it looks like I can't have a component with just a shortcut. The Shortcut element has no KeyPath property and I get an error about the missing KeyPath. So how do I create a component with just a single shortcut inside? Any ideas how to do what I need, and is it even possible? Thanks Ivo -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Question about the upgrade code
Hi I am upgrading my product from a Visual Studio setup project (version 1.9.8) to WiX (version 2.7.5). I want the new WiX version to be able to upgrade the old one. I also have 2 builds - 32 and 64 bits. For 32 bits there are no problems. I install version 1.9.8 first, then upgrade to 2.7.5 and the upgrade works fine. The old files are removed correctly. For 64 bits the old version is not removed. Both sets of files are installed, and I see both versions in the Control Panel -> Programs and Features. I triple-checked the upgrade code, and the code for WiX matches the one from Visual Studio. Is the upgrade code the only thing that needs to match so that the new version replaces the old one? And another question - where is the upgrade code stored? I can't find that GUID anywhere in the registry. I want to know how the upgrade code works so I can troubleshoot this problem. Thanks Ivo -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Problem with "Close App" condition
Hmm... could be. Is it possible that &MyAppFeature is not initialized yet because I'm running before "InstallValidate"? I have to run before InstallValidate, because I want to run before the Restart Manager pops up and asks to close the app for me. What is the recommended way to debug such problems? Is there a tool that can trace through the install process? Blair wrote: > If your feature won't be affected at all by the transaction (such as when > removing a different feature) &MyAppFeature may very well be -1, which would > make your condition be true. > > -Original Message- > From: Ivo Beltchev [mailto:i...@roadrunner.com] > Sent: Saturday, June 26, 2010 8:11 AM > To: General discussion for Windows Installer XML toolset. > Subject: [WiX-users] Problem with "Close App" condition > > Hi > > I have a custom action that closes my app when its feature is being > uninstalled. Here's my code: > > Before="InstallValidate"> > > For some reason the action gets triggered during "Repair" and also when > ANOTHER feature is being uninstalled. Why is this happening? Doesn't my > condition mean "if MyAppFeature is installed, and about to be uninstalled"? > > Thanks > Ivo > > > > -- > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > > -- > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Problem with "Close App" condition
Hi I have a custom action that closes my app when its feature is being uninstalled. Here's my code: For some reason the action gets triggered during "Repair" and also when ANOTHER feature is being uninstalled. Why is this happening? Doesn't my condition mean "if MyAppFeature is installed, and about to be uninstalled"? Thanks Ivo -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Customizing WixUI_FeatureTree
Pally Sandher wrote: > If it's a readme why not use the "Launch an Application after install" > functionality described at > http://wix.sourceforge.net/manual-wix3/run_program_after_install.htm to > simply ShellExecute the RTF? That way you can give the user the option > to see your RTF using the checkbox (if you want to). At least then > they're not limited to the extent of your Windows Installer dialog & get > a richer experience using a proper RTF application. I don't think your > original intent was lost, you just never explained it. > Yes, you are right and I'm certainly considering this. But it's irrelevant to the discussion, because both ways involve inserting a new dialog after installation and before exit. What I have in that dialog - a checkbox or a full RTF window - is easy to change. > Modifying the WiXUI_FeatureTree in your WiX code is a lot easier than > your earlier suggestion of rebuilding the whole WiX UI library from > scratch as shown by Neil S's blog. You don't even have to copy the > entire thing, only the dialogs you wish to change, everything else you > just reference from the WiX UI library. > Yes, you are right again. It was probably a bad choice of words on my part. I was not considering replacing all UI (the "UI library"), just the "UI set" (the WiXUI_FeatureTree file). Of course I'll reuse as many of the original dialogs as I can. > Also a lot of the stuff you've asked in the last week would've been > answered by a perusal through the manual and/or tutorial. > My first thread was intended to give me an idea if WiX is even the right tool for my needs. I didn't want to read through all the docs just to figure out I was in the wrong place. I'm sorry - I was lazy. In my second thread (this one) I was basically asking if I can insert a dialog before Exit without replacing WiXUI_FeatureTree. The tutorials don't cover that - they only cover the regular sequence of dialogs that are connected by Back/Next buttons. Yes, that's easy, but not what I need. I was also asking how to get better integration with the Restart Manager. The tutorials also don't cover this topic. It is true that both threads strayed a bit off-topic, and I'll be more careful about that in the future. Ivo -- 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] Customizing WixUI_FeatureTree
Pally Sandher wrote: > Answer to problem 1: I already posted a link to yesterday on this very > thread (in fact I can see it on my screen as I type this further down > the thread). Between Neil S's blog & the WiX UI pages in the WiX manual > you should have all you need to make the changes required. > Yes, the blog mentions to copy and modify the UI_FeatureTree file, which is what I was afraid of. I'm not any more, since it seems to be the only way. I have another reason I want to edit some of the default dialogs - the [Back] and [Next] buttons don't line up between dialogs and I want to fix that. > I still don't get why you need a second License Agreement displayed > though. Also at that point the user doesn't need to accept your License > Agreement. Your software is already installed on their machine & you > can't initiate a rollback to remove it since the InstallExecuteSequence > has finished. At best you could try some method of forcing an uninstall > if the user doesn't accept the terms. > I think my original intent was lost earlier in the thread. This is not a second license agreement. It is a Readme file. The dialog I want to create is similar to the EULA dialog in a way that it displays an RTF file (but has no "I accept" checkbox). As for "why" - I don't have a good reason besides that my current setup has it. And it has it because Visual Studio makes one by default in its installers. Thanks, guys. I think I have all I need to tweak the UI. If not, you'll hear from me again :) Ivo -- 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] Customizing WixUI_FeatureTree
Hi, WixUI_FeatureTree is almost exactly what I need. I just want to change 2 things: 1) Add a Readme.rtf file at the end of the install. This can either be in a dialog similar to EULA (that's what Visual Studio setup projects do), or a checkbox to execute the RTF when the installer closes. Given the choice between the two I would prefer the first option (embed the Readme text in a dialog). 2) Currently when I upgrade from one version to the next I get a popup from the Restart Manager asking to restart the programs that use my DLL. That's good. But during uninstall I only get a simple message box saying "Some files are in use, you should reboot afterwards". I want to use the Restart Manager in all cases (even during "Change" when the offending feature is being uninstalled). What is the easiest way to do what I need? Thanks Ivo -- 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
