[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
[WiX-users] DownloadUrl with variable
Hello, is there any way how to insert variable value into DownloadUrl string in run time of bootstrap? I'm starting bootstrapper from command line like "bootstrapper.exe ServerAddress=192.168.0.11" and I want result on DownloadUrl line something like: DownloadUrl="http://192.168.0.11:8000/Prerequisites/vcredist_x86_sp1.exe"/> Thanks a lot for any suggestions or ideas. Example: --- http://[ServerAddress]:8000/Prerequisites/vcredist_x86_sp1.exe"/> -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] unsubscribe
-- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ 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
[WiX-users] Uninstaller breaks the registry
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
Re: [WiX-users] Include an optional file in installer during compile/link
How about using the preprocessor for it? Something like: You can control the condition through command line parameters to candle. Ivo Beth Hechanova wrote: > I'm trying to optionally include a file in my installer at compile/link time. > If the file is included, then the installer will copy it to the appropriate > location (thus it is not optional for the user to install it). If the file > is NOT included in the installer, then it the installer skips it, and it is > not an error. > > Is there a way to conditionally include a file in the installer? My > automated build system will takes care of the logic of determining whether or > not the file should be included. > > As an example, I have a single feature called "Configuration": > > > > > In the component description, I have a config file that is required. I've > tried to add a second file (weather.lnk) that is optional: > > > > > > > Guid="175F0351-F122-4c64-92B6-BED06F22E195"> >Source="$(var.SourceRoot)\MyApp.exe.config" > > > >Source="$(var.SourceRoot)\Weather.lnk> > > > > > > > > > If the Weather.lnk file does not exist in the given location, the linker > gives a LGHT0083 error (file not found). I'd like to annotate this file (if > possible) as optional, or somehow put a conditional around it so if it is not > found in the given location, it is not an error and is just skipped when the > installer is compiled and linked. And then assuming the successful build of > the installer, when the installer is run, it will just skip this file. > > Do I need to make a separate component or feature for this particular file? > I've looked around at the descriptions of the File, Component, Feature items > and didn't see anything that was obvious to me to make it optional. I did > find the "Vital" attribute for the File - I tried setting this to "no", but > still got the link error. > > Is this possible? > I'm using Wix 3.0 > Thanks, > Beth > > > > --- > This email and any files transmitted with it are confidential & proprietary > to Systems and > Software Enterprises, Inc. (dba IMS). This information is intended solely for > the use of > the individual or entity to which it is addressed. Access or transmittal of > the information > contained in this e-mail, in full or in part, to any other organization or > persons is not > authorized. > --- > > -- > 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] Restart Manager (reboot after uninstall)
Right. So basically the Windows Installer/Restart Manager combo don't work very well for shell extensions that can be loaded in various processes. Probably the best thing I can do is try to detect the user's response to the Restart Manager prompt run a ScheduleReboot action if the user has selected to not close the offending processes. Also if running in basic UI mode and the shell feature is installed. Looking at the sources, I think I can do something like: WixUIRMOption="DontUseRM" OR (UILevel=2 AND !MyFeature=3) Blair wrote: > Believe it or not, there is a saying oft repeated in the hallways at > Microsoft: "Reboots are evil". The current design in Windows Installer is to > request a reboot only when under no reasonable scenario can the reboot be > avoided (such as an upgrade of a running program when the program won't "die" > during the upgrade). > > If a running program is holding a file in use, Windows Installer will > move/rename that file and mark it for removal upon the next reboot (the move > is into a hidden directory). If the move happens as a result of a removal > attempt, the file is considered to be "safe" for the program to continue to > use until it is shutdown by the user at their convenience (it is up to each > program to fail gracefully if some other file they didn't hold open is > suddenly missing or who's version/content suddenly changes). If, on the other > hand, the developer of the program knows that the program can't safely > continue to use the file(s), it is up to the developer to stop the running > instances of the program(s) or force a reboot, since Windows Installer cannot > possibly know who is good at defensive programming and who is not (even when > the program comes from the Windows team). > > -Original Message- > From: i...@roadrunner.com [mailto:i...@roadrunner.com] > Sent: Wednesday, July 14, 2010 12:16 PM > To: General discussion for Windows Installer XML toolset. > Cc: Blair > Subject: Re: [WiX-users] Restart Manager (reboot after uninstall) > > OK, so basically you are saying that the restart prompt is only supposed to > appear during an upgrade when a file is being replaced. > In my case I'm always using a major upgrade, so the old version is > uninstalled first, then the new one is installed. No file is directly > "overwritten". > > It is a bit weird that the system doesn't handle uninstalls or major > upgrades, but I can live with that. I don't have a problem if I'm getting the > intended behavior. My only concern is that I'm somehow breaking a feature I'm > supposed to get out of the box. > > > Blair wrote: > > In scenario #1, Windows Installer will not by default [prompt for] reboot. > > In scenario #2, there are two possibilities: > > 2.1 - RemoveExistingProducts is scheduled early and this is a major upgrade: > > Removal of the old file occurs before writing of the new file: no [prompt > > for] reboot (same as scenario #1). > > 2.2 - all other cases (RemoveExistingProducts scheduled late or non-major > > upgrade): File is overwritten (assuming that the component rules were > > followed) and a prompt for reboot occurs. > > > > For any other possibility you have to detect the situation yourself and ask > > for the reboot prompt. The simplest way is to always ask for reboot except > > for clean initial installation, or ask for reboot always (I assume that the > > shell has to be restarted no matter what to start using a new shell > > extension). The next simplest is to change your MsiRMFilesInUse dialog such > > that the ignore button is either disabled, hidden or removed (thus the user > > has no choice but to use the restart manager), although that won't help with > > basic or silent installations. The third option is to add an embedded UI > > (assuming your minimum MSI version is 4.5) or ensure that your transactions > > are always under the control of a bootstrapper (hard to do, under the best > > circumstances) and capture the MsiRMFilesInUse call to always return a code > > for using the restart manager without ever showing the option to the user. > > Next harder is to duplicate the files-in-use logic yourself and set a > > property. > > > > There may be some property that gets set when a file-in-use is detected, but > > I have never seen it. > > > > -Original Message- > > From: Ivo Beltchev [mailto:i...@roadrunner.com] > > Sent: Wednesday, July 14, 2010 9:27 AM > > To: General discussion for Windows Installer XML toolset. > > Subject: Re: [WiX-users] Restart Mana
Re: [WiX-users] Restart Manager (reboot after uninstall)
OK, so basically you are saying that the restart prompt is only supposed to appear during an upgrade when a file is being replaced. In my case I'm always using a major upgrade, so the old version is uninstalled first, then the new one is installed. No file is directly "overwritten". It is a bit weird that the system doesn't handle uninstalls or major upgrades, but I can live with that. I don't have a problem if I'm getting the intended behavior. My only concern is that I'm somehow breaking a feature I'm supposed to get out of the box. Blair wrote: > In scenario #1, Windows Installer will not by default [prompt for] reboot. > In scenario #2, there are two possibilities: > 2.1 - RemoveExistingProducts is scheduled early and this is a major upgrade: > Removal of the old file occurs before writing of the new file: no [prompt > for] reboot (same as scenario #1). > 2.2 - all other cases (RemoveExistingProducts scheduled late or non-major > upgrade): File is overwritten (assuming that the component rules were > followed) and a prompt for reboot occurs. > > For any other possibility you have to detect the situation yourself and ask > for the reboot prompt. The simplest way is to always ask for reboot except > for clean initial installation, or ask for reboot always (I assume that the > shell has to be restarted no matter what to start using a new shell > extension). The next simplest is to change your MsiRMFilesInUse dialog such > that the ignore button is either disabled, hidden or removed (thus the user > has no choice but to use the restart manager), although that won't help with > basic or silent installations. The third option is to add an embedded UI > (assuming your minimum MSI version is 4.5) or ensure that your transactions > are always under the control of a bootstrapper (hard to do, under the best > circumstances) and capture the MsiRMFilesInUse call to always return a code > for using the restart manager without ever showing the option to the user. > Next harder is to duplicate the files-in-use logic yourself and set a > property. > > There may be some property that gets set when a file-in-use is detected, but > I have never seen it. > > -Original Message- > From: Ivo Beltchev [mailto:i...@roadrunner.com] > Sent: Wednesday, July 14, 2010 9:27 AM > To: General discussion for Windows Installer XML toolset. > Subject: 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: > >
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] Windows 7 Custom Action Registry problem
Here's one example how to do it with P/Invoke: http://www.roelvanlisdonk.nl/?p=915 Kurt Jensen wrote: > That's it! > > So far I cannot find an equivalent in .NET but at least now I can track down > the communication breakdown... > > Thanks to all! > > > -Original Message- > From: i...@roadrunner.com [mailto:i...@roadrunner.com] > Sent: Thursday, July 01, 2010 11:23 AM > To: General discussion for Windows Installer XML toolset. > Cc: Kurt Jensen > Subject: Re: [WiX-users] Windows 7 Custom Action Registry problem > > > also, this solution was developed by another less install oriented > > programmer for the original vsproj under VS2008. I moved the code > > as-is over to WiX on a 32-bit install and it worked. now we are > > adding a 64-bit install. if I change to having Windows Installer do > > the job then I really am reinventing the wheel from our perspective. > > Maybe your keys get redirected? Check > HKLM\SOFTWARE\Wow6432Node\Spiricon\Version5. Maybe your values are there. > If so, you need to add KEY_WOW64_64KEY to RegOpenKey (or whatever the .NET > equivalent is). > > ** > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they > are addressed. If you have received this email in error please notify > the system manager. > > This footnote also confirms that this email message has been swept by > MIMEsweeper for the presence of computer viruses. > > www.clearswift.com > ** > > > -- > 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] Windows 7 Custom Action Registry problem
> also, this solution was developed by another less install oriented > programmer for the original vsproj under VS2008. I moved the code as-is > over to WiX on a 32-bit install and it worked. now we are adding a > 64-bit install. if I change to having Windows Installer do the job then > I really am reinventing the wheel from our perspective. Maybe your keys get redirected? Check HKLM\SOFTWARE\Wow6432Node\Spiricon\Version5. Maybe your values are there. If so, you need to add KEY_WOW64_64KEY to RegOpenKey (or whatever the .NET equivalent is). -- 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
[WiX-users] Using Restart Manager during uninstall
Hi As I mentioned in my prvious thread, I'm trying to get the Restart Manager to show up during uninstall from the Control Panel. Here's what I know so far: A) If I run the MSI directly then I get options like "Change" and "Remove". When I pick Remove everything works fine and I do get the Restart Manager popup. B) If I pick Uninstall from the Control Panel I don't get the Restart Manager. Same thing happens when I run "msiexec /x setup.msi". C) If I run "msiexec /x setup.msi /qf" I do get the Restart Manager. One problem is that the welcome screen says "Install" instead of "Remove". D) If I go to the registry and set the WindowsInstaller value to 0, then uninstalling from the Control Panel uses the full UI and everything is good. However then the icon in the Control Panel gets busted. I'm hoping that's fixable through the DisplayIcon value. All of this makes me certain that the only problem is that the uninstaller doesn't run in full UI mode. So here are my questions: 1) Do you think it is a good idea to modify the registry and change the WindowsInstaller and DisplayIcon values? What potential problems can it cause? 2) What is the best way to do that? With a registry component or a custom action? If it's a custom action, what is the right time to invoke it? The action must be elevated because it writes to HKLM, but must be after the original value of WindowsInstaller is set. 3) Why does "msiexec /x setup.msi /qf" show "Install" button in the welcome screen? Not only that, but the message above the progress says "please wait while INSTALLING...". Any way to fix this? Basically I need a command line for msiexec that removes the package with full UI (and correct UI too). 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
Re: [WiX-users] Customizing WixUI_FeatureTree
> Um using the "How To: Run the Installed Application After Setup" > requires no changing of the ExitDialog what so ever. You set a few > public properties & the already built in code makes the text & checkbox > appear due to the conditions on the controls. There's no "new" dialog > needed, you're simply making the existing one do some work for you. Yeah, that will work for my case, even though it is not intuitive (using the "launch the app" functionality to show the readme instead). This works for me because I don't need a separate checkbox to launch the app. There is one little glitch, as described here: http://www.dizzymonkeydesign.com/blog/misc/adding-and-customizing-dlgs-in-wix-3/ and here: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Option-checkbox-in-ExitDialog-isn-t-transparent-td3196746.html The checkbox shows up on top of the background bitmap, which is kind of ugly. So I'll have to make a custom ExitDialog anyway. BTW, it would be nice if the How To topic mentions this issue and offers possible solutions - move the checkbox, make the bitmap smaller, use a static text (bleh! I hate when installers do that, but at least now I know why :) ). -- 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: > 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
Re: [WiX-users] Customizing WixUI_FeatureTree
Two problems with that: - the ExitDialog is part of the UI_FeatureTree set, so I can't change it from my project alone. I'll have to either modify the UI_FeatureTree set and rebuild WiX, or copy the whole set into my project and modify the copy - after looking at the source for ExitDialog I'm still not sure how it is invoked, or how to make it not run after the "progress" stage Blair wrote: > You set your ReadmeDlg the way that ExitDialog is currently invoked, then > have ReadmeDlg's Next button go to ExitDialog. You can then enable/add back > in ExitDialog's Back button and set it to return to ReadmeDlg. > > -Original Message- > From: i...@roadrunner.com [mailto:i...@roadrunner.com] > Sent: Monday, June 21, 2010 5:29 PM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Customizing WixUI_FeatureTree > > >> 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). > > > 1 - > > http://neilsleightholm.blogspot.com/2008/08/customised-uis-for-wix.html > > However from looking at the sources WiXUI_FeatureTree already has > > LicenseAgreementDlg after the WelcomeDlg. If you want a second one > > showing a different RTF you'll need to write it (or copy & paste from > > the LicenseAgreementDlg.wxs in the WiX sources). > > This turns out to be harder than expected. I want to show my Readme dialog > after the install progress but before ExitDialog. However the ExitDialog > doesn't follow the standard Prev/Next navigation, so it's not > straight-forward to include something before it. Let's say I already have > this: > > > > ... > >Value="ExitDialog">1 > > > I'm assuming this will create a dialog and its Next button will go to > ExitDialog. > What do I need to do to get ReadmeDlg to show after the progress instead of > ExitDialog (but only after a successful install)? > > > > -- > 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] Customizing WixUI_FeatureTree
>> 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). > 1 - > http://neilsleightholm.blogspot.com/2008/08/customised-uis-for-wix.html > However from looking at the sources WiXUI_FeatureTree already has > LicenseAgreementDlg after the WelcomeDlg. If you want a second one > showing a different RTF you'll need to write it (or copy & paste from > the LicenseAgreementDlg.wxs in the WiX sources). This turns out to be harder than expected. I want to show my Readme dialog after the install progress but before ExitDialog. However the ExitDialog doesn't follow the standard Prev/Next navigation, so it's not straight-forward to include something before it. Let's say I already have this: ... 1 I'm assuming this will create a dialog and its Next button will go to ExitDialog. What do I need to do to get ReadmeDlg to show after the progress instead of ExitDialog (but only after a successful install)? -- 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 wrote: > Yes. However, if the bootsrapper (A) runs silently any prerequisite > installations that are not launched with ShellExecute or that are > incorrectly manifested for elevation or that are MSI they may fail if as a > result the UAC prompt for them never appears. Yeah, I see now what you mean. But that's not going to be a problem. The purpose of the bootstrapper (my bootstrapper) is to extract the correct MSI file (there's one for 32 and one for 64-bit) and then launch msiexec. It does some other tasks too: - provide a nice icon for the package (since plain MSI files can't have a custom icon) - check if you are running on Vista and up - check if an older version is already installed and warn about potential upgrade incompatibilities - launch the app after it is installed Basically nothing that requires elevation. Also the last two steps are going to be moved to the MSI now that I know how to do it. I still want to keep the Vista check in the bootstrapper because there is no guarantee what Windows Installer version is available for older environments like XP or Win2000 (or god forbid Windows 95!). > I don't know enough about the bootstrapper that comes with Visual Studio to > know one way or the other (if it uses ShellExecute or not, the quality of > whatever packages you are consuming, etc.) I am not using the Visual Studio bootstrapper. As far as I know it ensures the right Windows Installer is present before it launches the MSI. It may also install the Windows Installer if it's missing, not sure about that part. -- 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?
"Castro wrote: > > 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. > > Don't worry about launching a program as the logged in user. This can be done > in Windows Installer (and thus WiX) fairly easily. When a MSI is launched the > Windows Installer engine executes the InstallUISequence and the > InstallExecuteSequence in the context of the logged on user. The purpose of > the InstallUISequence is to gather information from the user. The purpose of > the InstallExecuteSequence is to schedule the actions that will change the > system (producing an install script). The Windows Installer engine then gives > the generated install script to a server-side process that runs under the > appropriately elevated privileges to change the system. You can specify > whether you want custom actions to impersonate the logged on user. When you > specify the program to launch at the end of your install, you'll just need to > specify that you do want it to be impersonated. The standard WiX UI provides > a built-in mechanism to launch programs in this fashion at the end of the UI. Yes, I understand that now. Before I was using a Visual Studio setup project, which doesn't give you the "impersonation" option for custom actions. Because of that my program got launched as SYSTEM, and was unable to work with the normal Explorer process. > What bothers me is that you are deciding whether your installer will need > admin privileges or not based on your decision to launch an executable. The > installer should dictate whether you need admin privileges or not depending > on whether you _need_ to modify protected system resources (such as > ProgramFiles). If the program should be installed on a per-user basis (ie, > multiple times per system, if there are multiple users on the system) then > you should install the application in the user's profile _and_ maintain > per-user configuration. If you need to install only once per system, and > maintain only a single system-wide configuration, and the program should be > available to all users, then you should install in ProgramFiles (requiring > admin privileges). I'm talking about the bootstrapper, not the installer. Correct me if I'm wrong: If the bootstrapper A runs as admin, then the installer B (as a child process) will run as admin. If the installer B runs as admin, then it won't be able to launch my application C as non-admin. So I want to run A as the current user to make sure that C runs as the current user. Does that make sense? -- 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
> If you have some budget, I can be hired to provide a CA that performs that > task for you. It would be up to you if you wished that to be contributed back > to the community or to have it licensed to you. Email me directly if you are > interested. Sorry, no budget here :) This is an open source tool that I'm developing in my spare time: http://sourceforge.net/projects/classicshell/ The current solution (full Restart Manager UI during upgrade, and a simple restart prompt during uninstall) is usable, but I was hoping it can be made more user-friendly. I'm just surprised that there isn't a more "out of the box" solution to this problem. I'm still hoping somebody that has done shell extensions with WiX can share their experience. -- 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
> "Basic UI or Reduced UI level installations give the user the option of > using the Restart Manager to reduce system restarts even if the > MsiRMFilesInUse dialog box is not present. Silent UI level installations > always shut down applications and services, and on Windows Vista, always use > Restart Manager." > > >From my previous interactions with Windows Installer, if a file isn't > replaced, Windows Installer doesn't bother with requesting a reboot (it just > moves the files it couldn't delete to a hidden directory and marks them to > be deleted on the next system boot). Thus, it may not be engaging RM to > stop/restart a process that is holding onto a file it doesn't feel requires > a reboot. I see, that may explain what's happening. It is still a problem though, because the component in question needs other files to function correctly, and they get deleted during uninstall. A specific example: The component is a toolbar for Explorer. It gets its configuration (what buttons to show) from an ini file. Once the ini file is uninstalled, the toolbar will revert to the default buttons, which (while not critical) is not nice. Same goes for the localization files. Without them the toolbar reverts to English when they are gone. > CloseApplication may do the job you need. If it doesn't, either it should be > extended to join processes to the RM session, or another CA would need to be > used for that task. Correct me if I'm wrong, but CloseApplication is specifically for EXEs that are part of the package, right? I don't know in advance what EXEs will load my DLL. > Alternately, if you add an embedded UI you could add any processes holding > files found to be in use to the RM session yourself right from the embedded > UI (which ironically doesn't have to show any UI at all, and can be run no > matter what UI level is in play). Of course, embedded UI requires MSI 4.5 or > higher, which not everyone has (The latest Service Pack for both Vista and > 2008 have 4.5, but XP SP3 doesn't, although 4.5 is available for XP. > However, XP doesn't have Restart Manager, so that may be a moot point). I'm not sure I understand, but are you suggesting I re-implement the Restart Manager? (locate all processes that use the DLL, then show a list to the user, or try to restart them). BTW, I am targeting Vista and up, and I don't mind if the uninstaller does its best on SP2, as long as it works somehow on lower service packs. -- 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
>> 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). >> > 2 - No idea. Never used Restart Manager as it's only supported in > Windows Installer 4.0 and later. Are you using Util:CloseApplication > (http://wix.sourceforge.net/manual-wix3/util_xsd_closeapplication.htm) > or relying on Windows Installer alone? I don't use Util:CloseApplication. The package is a shell extension, so the processes that need to be restarted are Explorer.exe and any other process that loads the shell extension. I think I have an idea what's happening: It says here (http://msdn.microsoft.com/en-us/library/aa370379.aspx) that the MsiRMFilesInUse dialog only shows up if "The Full UI user interface level is used.". When uninstalling from the Control Panel the interface level is "basic" or "reduced". Is there a way around that limitation? Like force "full UI" when running from the Control Panel? -- 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
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] Can this be done with WiX?
Blair 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] Can this be done with WiX?
Blair 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
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 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 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] Can this be done with WiX?
Blair 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?
> > 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
[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] How to create web app/service on IIS 7 with WiX 3.0
I spent hours trying to add web feature to my wix project. Once it failed with wrong web site created - after that all attempts fail and nothing is being created. My attempt looks like this Can somebody share working snippet? I am using latest 3.5 on IIS 7.5 -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Adding multiple files to component
You can try this - simple GUI http://flexsetup.codeplex.com/ WiXFileTool: generates WiX file definitions and component definitions for a collection of files From: "Kerber, Cameron" To: General discussion for Windows Installer XML toolset. Sent: Tue, March 16, 2010 8:43:52 AM Subject: Re: [WiX-users] Adding multiple files to component Yes, I understand that you can put multiple files in a component, but that means I have to write the Source for each of the files, and spell out each file xml element. I basically just want to set the Source to a directory and include all files under that directory. Or some process that converts a directory to I can't be typing this each and everytime. Heat tool. I'll look into it. Do you know of any websites with tutorial on it? Any way to integrate into MSBuild? -Original Message- From: Kristoffer Danielsson [mailto:kristoffer.daniels...@live.se] Sent: Tuesday, March 16, 2010 11:36 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Adding multiple files to component I'm also a newbie, so my solution below could be "wrong". However, it works: Something like that. However, I do remember that this technique is not recommended - for some reason I don't know... > From: cameron.ker...@philips.com > To: WiX-users@lists.sourceforge.net > Date: Tue, 16 Mar 2010 16:27:31 +0100 > Subject: [WiX-users] Adding multiple files to component > > I'm sure this question has been asked before in some variety but searching > the mail archives on SourceForge is awful. I am also new to WIX > > Anyways, in my build process I am outputting a bunch of files to a directory. > I want all those files added to a component in my WIX project. To build my > WIX project, during my build process I just build my WIX installer solution > and it creates the setup package. So besides manually adding all these files > (~50) to my component by hand, I don't understand how to accomplish this. All > the tutorials just use one file in there examples. No one uses adding files > from a source directory. > > Thanks! > > > The information contained in this message may be confidential and legally > protected under applicable law. The message is intended solely for the > addressee(s). If you are not the intended recipient, you are hereby notified > that any use, forwarding, dissemination, or reproduction of this message is > strictly prohibited and may be unlawful. If you are not the intended > recipient, please contact the sender by return e-mail and destroy all copies > of the original message. > -- > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users _ Mejla i busskön! Hotmail i mobilen http://new.windowslivemobile.msn.com/SE-SE/windows-live-hotmail/default.aspx -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] how to install .net4 (or .net 3.5) with latest wix 3.5?
I am using latest wix 3.5 with vs.2010 rc. I want to create bootstrap for .net 4 but can't figure out how to do it. I found some blog samples how to edit wixproj in order to create .net 3.5 bootstrapper - no luck with that either. I have win sdk 6.0 and latest win 7 sdk and configured paths properly. I am getting errors about missing bin files. Is this working yet or I should wait for wix 3.5 to be out of beta? -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] heat website throws exception
Hi, I'm trying to harvest website info using the following command: heat website DefaultWebSite -out c:\testje2.wxs I'm getting the error: heat.exe : error HEAT0001 : The directory cannot report the number of properties . Exception Type: System.NotSupportedException Stack Trace: at System.DirectoryServices.PropertyCollection.get_Count() at System.DirectoryServices.PropertyCollection.ValuesEnumerator.MoveNext() at Microsoft.Tools.WindowsInstallerXml.Extensions.IIsWebSiteHarvester.Harvest WebSite(DirectoryEntry webSiteEntry) at Microsoft.Tools.WindowsInstallerXml.Extensions.IIsWebSiteHarvester.Harvest WebSite(String name) at Microsoft.Tools.WindowsInstallerXml.Extensions.IIsWebSiteHarvester.Harvest (String argument) at Microsoft.Tools.WindowsInstallerXml.Harvester.Harvest(String argument) at Microsoft.Tools.WindowsInstallerXml.Tools.Heat.Run(String[] args) D:\source\AFM\Client\Wta\Web>heat website DefaultWebSite -out c:\testje2.wxs The name of my iiswebsite is DefaultWebSite when i enter a different website name i get "the website could not be found" so heat can find the DefaultWebSite. My DefaultWebSite contains 6 virtual directories, 1 aspnet_client directory and 1 _vti_pvt directory. Is this a bug or am i doing something wrong? TIA Regards, Ivo Grootjes Disclaimer: http://www.afm.nl/disclaimer http://www.afm.nl/disclaimer_english/ Indien u de link niet kunt openen, neemt u dan contact op met telefoonnummer +31 (0)20 5535200. Meer informatie vindt u op de website http://www.afm.nl. If you are unable to access the link, please dial +31 (0)20 5535200 Additional information is available on the website http://www.afm.nl. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
