Re: [WiX-users] Component Level Versioning?
Only PE binary files (normally .EXE, .DLL, .OCX, .SYS, etc.) files carry version resources that Windows Installer knows about. Other file types (.TXT, .INI, .XML, .CAB, etc.) files that are not PE binary files can't have the version resource Windows Installer knows how to read and have to use the rules that the documentation describes It all depends on the content of file you are upgrading. The links I supplied to you supply the documentation regarding how Windows Installer makes file upgrade determinations. If you lie to Windows Installer about a file that can't supply its own version information to Windows Installer, you may be able to force a particular behavior during initial installation, but you will get repairs and possible prompts for source whenever a health check occurs for any feature your files components are in, which leads to a terrible user experience, a bunch of missing component system log entries, and pop-up Windows Installer repair dialogs, and the same behavior you intended for installation will be repeated during repairs. Using the DefaultVersion attribute is usually ill-advised. Usually it is considered best practice to have written installers such that they either refuse to install or exit with a success code without actually installing when an installation package with a higher version and the same UpgradeCode is already installed. Of course, that requires that the package already installed on the box was coded that way, so if it is re-presented for installation it won't overwrite a future package. Otherwise, you should always replace every file no matter what on every installation (allowing complete downgrades) to prevent mixed version installations. Blair -Original Message- From: Miller, Craig [mailto:craig.mil...@spatialminds.com] Sent: Tuesday, July 06, 2010 9:16 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Component Level Versioning? Anyone know how I can set a file version? I read through the links that Blair provided and I believe setting the file version of my new files is the best way to move forward. My understanding is that I need to specify the file version in my new installers. This will: 1. Insure that the existing files with a hash but no version are upgraded 2. More importantly, insure that these upgraded files aren't overwritten when an older installer w/o file version info is run after the new installer. I could use the DefaultVersion attribute of the file element and use the suppress files option in light, but this would suppress the file version of all files. It seems like the best way to move forward is to specifically set the file version of my updated files. Unfortunately, I can't figure out how to do that, which leads me to the question Anyone know how I can set a file version? Thanks, Craig On Wed, Jun 30, 2010 at 2:08 PM, Blair os...@live.com wrote: With regards to files that don't have Version resources (since WiX's binder by default does populate the file hash for files that don't contain version resources) the following pages are of use to help you understand what is expected. The default behavior for your case is described on this page: http://msdn.microsoft.com/library/aa370532.aspx REINSTALLMODE is described here: http://msdn.microsoft.com/library/aa371182.aspx The default value for REINSTALLMODE is documented as omus. Additional information about file replacement rules (versioning) covering additional cases is found in the same area of the MSDN library. -Original Message- From: Miller, Craig [mailto:craig.mil...@spatialminds.com] Sent: Wednesday, June 30, 2010 11:55 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Component Level Versioning? Thanks Peter and Pally for the replies. I don't make a lot of installers, but I did read and follow the component rules very carefully when I created the original installer. What I'm unclear on is if I have the same component snippet in two MSI files (same GUID), but one snippet contains a newer version of the underlying file, how does the windows installer know that the newer version is in fact a newer version? E.g. Version 1 created in 2008 and Version 2 created in 2010 are identical except the Source attribute of the File element points to an updated version of the file ..\USGS Topographic\250k\NY\c43078a1.tif. Since components don't appear to have any version info, if I run the version 2 installer, followed by the version 1 installer, what prevents the old file from overwriting the newer file? Component Id='c43078a1.tif' Guid='784351B6-50BC-43B3-B668-F5248B4A4B90' File Id='c43078a1.tif' Name='c43078a1.tif' DiskId='1' KeyPath='yes' Source='..\USGS Topographic\250k\NY\c43078a1.tif' / /Component Agreed, VMs are very helpful for this sort of thing. Craig
Re: [WiX-users] Component Level Versioning?
Regarding paragraph three... I don't have any trouble with my product/upgrade codes working. They are all set and upgrades to specific products work great. The trouble is that I need to upgrade a file that is shared between about 30 *different* installers. It's a common dependency between these different products and my most recent product (not an upgrade to an existing product) has an updated, but backward compatible version of this file. As you said, if this was a Dll it would be possible via versioning. It's a bit frustrating that I can't do this with a non PE binary file... not sure how I'm going to move forward since I have a ton of the products containing the version 1.0 files in the field already. Anyway, thanks for taking the time to explain it to me. At least I understand the limitations of the Windows installer now. Craig On Tue, Jul 6, 2010 at 11:00 PM, Blair os...@live.com wrote: Only PE binary files (normally .EXE, .DLL, .OCX, .SYS, etc.) files carry version resources that Windows Installer knows about. Other file types (.TXT, .INI, .XML, .CAB, etc.) files that are not PE binary files can't have the version resource Windows Installer knows how to read and have to use the rules that the documentation describes It all depends on the content of file you are upgrading. The links I supplied to you supply the documentation regarding how Windows Installer makes file upgrade determinations. If you lie to Windows Installer about a file that can't supply its own version information to Windows Installer, you may be able to force a particular behavior during initial installation, but you will get repairs and possible prompts for source whenever a health check occurs for any feature your files components are in, which leads to a terrible user experience, a bunch of missing component system log entries, and pop-up Windows Installer repair dialogs, and the same behavior you intended for installation will be repeated during repairs. Using the DefaultVersion attribute is usually ill-advised. Usually it is considered best practice to have written installers such that they either refuse to install or exit with a success code without actually installing when an installation package with a higher version and the same UpgradeCode is already installed. Of course, that requires that the package already installed on the box was coded that way, so if it is re-presented for installation it won't overwrite a future package. Otherwise, you should always replace every file no matter what on every installation (allowing complete downgrades) to prevent mixed version installations. Blair -Original Message- From: Miller, Craig [mailto:craig.mil...@spatialminds.com] Sent: Tuesday, July 06, 2010 9:16 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Component Level Versioning? Anyone know how I can set a file version? I read through the links that Blair provided and I believe setting the file version of my new files is the best way to move forward. My understanding is that I need to specify the file version in my new installers. This will: 1. Insure that the existing files with a hash but no version are upgraded 2. More importantly, insure that these upgraded files aren't overwritten when an older installer w/o file version info is run after the new installer. I could use the DefaultVersion attribute of the file element and use the suppress files option in light, but this would suppress the file version of all files. It seems like the best way to move forward is to specifically set the file version of my updated files. Unfortunately, I can't figure out how to do that, which leads me to the question Anyone know how I can set a file version? Thanks, Craig On Wed, Jun 30, 2010 at 2:08 PM, Blair os...@live.com wrote: With regards to files that don't have Version resources (since WiX's binder by default does populate the file hash for files that don't contain version resources) the following pages are of use to help you understand what is expected. The default behavior for your case is described on this page: http://msdn.microsoft.com/library/aa370532.aspx REINSTALLMODE is described here: http://msdn.microsoft.com/library/aa371182.aspx The default value for REINSTALLMODE is documented as omus. Additional information about file replacement rules (versioning) covering additional cases is found in the same area of the MSDN library. -Original Message- From: Miller, Craig [mailto:craig.mil...@spatialminds.com] Sent: Wednesday, June 30, 2010 11:55 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Component Level Versioning? Thanks Peter and Pally for the replies. I don't make a lot of installers, but I did read and follow the component rules very carefully when I created the original installer. What I'm unclear on is if I have the same
Re: [WiX-users] services stops at logoff
Hi Blair, I got the issue in my service itself. Thanks for your reply. -Sanjay Blair wrote: Default value is no. On a test computer, if you use the sc create command to register the service, and then start it, does it still stop upon logoff? If so, that would rule out Windows Installer/WiX as a cause. There's nothing that appears odd in the registration that would cause that, so I'm wondering about code in the service itself. -Original Message- From: Sanjay Rao [mailto:s...@noida.interrasystems.com] Sent: Monday, July 05, 2010 10:50 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] services stops at logoff ServiceInstall Id='serviceId' DisplayName='ServiceDisplayName' Name='ServiceName' Start='auto' ErrorControl='normal' Type='ownProcess' Vital = 'yes' Explicitally I did not marked the service as interactive. I do not have idea, what is default value of Interacive in this element. Type='ownProcess' makes any difference ? Thanks for your reply. Blair wrote: Do the services happen to be marked Interactive? -Original Message- From: Sanjay Rao [mailto:s...@noida.interrasystems.com] Sent: Monday, July 05, 2010 10:18 PM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] services stops at logoff Hi All, I have a installer which installs 3 services(auto-start). services stops when user logoff. Can I install services in such a way that services won;t stop at logout. Regards, Sanjay Rao -- 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] WixUILicenseRtf broken when binding sources into wixpdb
Now we might be getting somewhere. When binding source files into a wixout the field values associated with wix extensions are missing extra properties/decorations. Wixout from a working version contains this table name=WixControl xmlns=http://schemas.microsoft.com/wix/2006/objects; row sectionId=wix.section.27 sourceLineNumber=C:\delivery\Dev\wix30_public\src\ext\UIExtension\wixlib\LicenseAgreementDlg.wxs*28 fieldLicenseAgreementDlg/field fieldLicenseText/field field cabinetFileId=3!(wix.WixUILicenseRtf=C:\delivery\Dev\wix30_public\src\ext\UIExtension\wixlib\license.rtf)/field /row /table Vs this in the broken version: table name=WixControl xmlns=http://schemas.microsoft.com/wix/2006/objects; row sectionId=wix.section.27 sourceLineNumber=C:\delivery\Dev\wix30_public\src\ext\UIExtension\wixlib\LicenseAgreementDlg.wxs*28 fieldLicenseAgreementDlg/field fieldLicenseText/field field cabinetFileId=53C:\delivery\Dev\wix30_public\src\ext\UIExtension\wixlib\license.rtf/field /row /table I don't understand what the '!(wix.WixUILicenseRtf' syntax means, but it's obviously related. In both instances the referenced fileId (3 53 respectively,) is the common license file, not the file I'm trying to use. I tried manually editing the wixout file before generating the msi and I think it worked although I haven't tested it properly yet. Is that enough to find the source of the bug? Can you think of a workaround that would build the wixout correctly? ATM my workaround is to build my msi twice, using the msi from the unbound wixout and the pdb from the bound version to create patches against. Thanks, Matt -Original Message- From: Blair [mailto:os...@live.com] Sent: Wednesday, 7 July 2010 10:11 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] WixUILicenseRtf broken when binding sources into wixpdb Caveat: the following description of intermediate files is subject to change any time and shouldn't be relied upon to stay the same. There are routines publicly available from wix.dll that manipulate these file formats and ONLY those routines are supported when manipulating these files. Given that caveat, however, the following may prove useful in determining where the values set via WixVariables are getting lost in your build scenario. In WiX v3.x, bound or binary intermediate files (wixlib, wixout, wixpdb) consist of a CAB with XML appended to the end. For investigative purposes you can split them (open, search for the literal ?xml and split the two files right before the string you searched for). A wixpdb wraps a wixout. A wixlib is a different kind of wixout. Even wixobj files are a different variant, except they are never bound (at least in v3.x). The content of one of these XML files is a collection of tables, including definitions, some of which represent unreal tables (tables that are never directly written to a Windows Installer file). field elements with an attribute named cabinetFileId should access the correspondingly indexed file from the cabinet you separated out. Verify if those files are correct or not, as well as what the values of the field element contain (they should have been replaced by the values of the WixVariable as you set them). Please report what you found, as it can help determine where to look for the code flaw. -Original Message- From: Matt Sullivan [mailto:msulli...@zaptechnology.com] Sent: Tuesday, July 06, 2010 3:01 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] WixUILicenseRtf broken when binding sources into wixpdb Thanks for your help Blair, however excluding the extensions while linking the msi doesn't seem to make an difference. The only error or warning I get is this: C:\TFS\CustomizationWizard\Releases\2.2 SP1\Customization Wizard\Setup\Setup.wxs(136) : warning LGHT1076 : ICE03: String overflow (greater than length permitted in column); Table: Shortcut, Column: Target, Key(s): StartMenuInstallGuideShortcut And I see that regardless of whether I link directly to msi, or via an intermediate wixout. Is there any way to disassemble the wixout and anything specific I could look for to give a hint about what the UI extension is doing? -Original Message- From: Blair [mailto:os...@live.com] Sent: Wednesday, 7 July 2010 3:11 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] WixUILicenseRtf broken when binding sources into wixpdb I am the Blair from that email thread you referenced for the call light twice technique. That technique was tested without any WixVariable usage. However, I believe the wixout file should have all required fragments from the extensions, so I would hope that the extensions could be dropped from the second time you call light. Are there any errors in your build if you don't include any extensions when you do the binding (the second call to
[WiX-users] Directory xxx is in the user profile but is not listed in the RemoveFile table
When iam trying to create the installer i am getting the following error. The directory ProgramMenuDir is in the user profile but is not listed in the RemoveFile table. How do i resolve this issue? below is the directory structure i am using. Directory Id='TARGETDIR' Name='SourceDir' Directory Id='ProgramFilesFolder' Name='PFiles' Directory Id='EFI' Name='EFI' /Directory /Directory Directory Id=ProgramMenuFolder Name=Programs Directory Id=ProgramMenuDir Name=EFI Directory Id=ProgramMenuDirMonarch Name=EFI Monarch Component Id=ProgramMenuDirMonarch Guid=E510F3DA-82AA-11DF-8814-8970DFD72085 Shortcut Id=UninstallProduct Name=Uninstall EFI Monarch V2 Description=Uninstalls EFI Monarch V2 Target=[System64Folder]msiexec.exe Arguments=/x [ProductCode]/ RemoveFolder Id='ProgramMenuDirMonarch' On='uninstall' / RegistryValue Root='HKCU' Key='Software\[Manufacturer]\[ProductName]' Type='string' Value='' KeyPath='yes' / /Component /Directory /Directory /Directory Directory Id=DesktopFolder Name=Desktop / /Directory -- 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] Directory xxx is in the user profile but is not listed in the RemoveFile table
Add an additional RemoveFolder element targeting ProgramMenuDir in your ProgramMenuDirMonarch component. There is no limit to the number of RemoveFolder elements you can have in the same component. -Original Message- From: subrat agasti [mailto:subrat.w...@gmail.com] Sent: Wednesday, July 07, 2010 1:05 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Directory xxx is in the user profile but is not listed in the RemoveFile table When iam trying to create the installer i am getting the following error. The directory ProgramMenuDir is in the user profile but is not listed in the RemoveFile table. How do i resolve this issue? below is the directory structure i am using. Directory Id='TARGETDIR' Name='SourceDir' Directory Id='ProgramFilesFolder' Name='PFiles' Directory Id='EFI' Name='EFI' /Directory /Directory Directory Id=ProgramMenuFolder Name=Programs Directory Id=ProgramMenuDir Name=EFI Directory Id=ProgramMenuDirMonarch Name=EFI Monarch Component Id=ProgramMenuDirMonarch Guid=E510F3DA-82AA-11DF-8814-8970DFD72085 Shortcut Id=UninstallProduct Name=Uninstall EFI Monarch V2 Description=Uninstalls EFI Monarch V2 Target=[System64Folder]msiexec.exe Arguments=/x [ProductCode]/ RemoveFolder Id='ProgramMenuDirMonarch' On='uninstall' / RegistryValue Root='HKCU' Key='Software\[Manufacturer]\[ProductName]' Type='string' Value='' KeyPath='yes' / /Component /Directory /Directory /Directory Directory Id=DesktopFolder Name=Desktop / /Directory -- 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] WixUILicenseRtf broken when binding sources into wixpdb
It gives me some good clues. I like your workaround idea, BTW. There is a benefit to only shipping an RTM version of an MSI and only releasing updates to that via MSP (it can simplify to some extent your testing and deployment matrix). -Original Message- From: Matt Sullivan [mailto:msulli...@zaptechnology.com] Sent: Wednesday, July 07, 2010 12:56 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] WixUILicenseRtf broken when binding sources into wixpdb Now we might be getting somewhere. When binding source files into a wixout the field values associated with wix extensions are missing extra properties/decorations. Wixout from a working version contains this table name=WixControl xmlns=http://schemas.microsoft.com/wix/2006/objects; row sectionId=wix.section.27 sourceLineNumber=C:\delivery\Dev\wix30_public\src\ext\UIExtension\wixlib\Li censeAgreementDlg.wxs*28 fieldLicenseAgreementDlg/field fieldLicenseText/field field cabinetFileId=3!(wix.WixUILicenseRtf=C:\delivery\Dev\wix30_public\src\ext \UIExtension\wixlib\license.rtf)/field /row /table Vs this in the broken version: table name=WixControl xmlns=http://schemas.microsoft.com/wix/2006/objects; row sectionId=wix.section.27 sourceLineNumber=C:\delivery\Dev\wix30_public\src\ext\UIExtension\wixlib\Li censeAgreementDlg.wxs*28 fieldLicenseAgreementDlg/field fieldLicenseText/field field cabinetFileId=53C:\delivery\Dev\wix30_public\src\ext\UIExtension\wixlib\l icense.rtf/field /row /table I don't understand what the '!(wix.WixUILicenseRtf' syntax means, but it's obviously related. In both instances the referenced fileId (3 53 respectively,) is the common license file, not the file I'm trying to use. I tried manually editing the wixout file before generating the msi and I think it worked although I haven't tested it properly yet. Is that enough to find the source of the bug? Can you think of a workaround that would build the wixout correctly? ATM my workaround is to build my msi twice, using the msi from the unbound wixout and the pdb from the bound version to create patches against. Thanks, Matt -Original Message- From: Blair [mailto:os...@live.com] Sent: Wednesday, 7 July 2010 10:11 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] WixUILicenseRtf broken when binding sources into wixpdb Caveat: the following description of intermediate files is subject to change any time and shouldn't be relied upon to stay the same. There are routines publicly available from wix.dll that manipulate these file formats and ONLY those routines are supported when manipulating these files. Given that caveat, however, the following may prove useful in determining where the values set via WixVariables are getting lost in your build scenario. In WiX v3.x, bound or binary intermediate files (wixlib, wixout, wixpdb) consist of a CAB with XML appended to the end. For investigative purposes you can split them (open, search for the literal ?xml and split the two files right before the string you searched for). A wixpdb wraps a wixout. A wixlib is a different kind of wixout. Even wixobj files are a different variant, except they are never bound (at least in v3.x). The content of one of these XML files is a collection of tables, including definitions, some of which represent unreal tables (tables that are never directly written to a Windows Installer file). field elements with an attribute named cabinetFileId should access the correspondingly indexed file from the cabinet you separated out. Verify if those files are correct or not, as well as what the values of the field element contain (they should have been replaced by the values of the WixVariable as you set them). Please report what you found, as it can help determine where to look for the code flaw. -Original Message- From: Matt Sullivan [mailto:msulli...@zaptechnology.com] Sent: Tuesday, July 06, 2010 3:01 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] WixUILicenseRtf broken when binding sources into wixpdb Thanks for your help Blair, however excluding the extensions while linking the msi doesn't seem to make an difference. The only error or warning I get is this: C:\TFS\CustomizationWizard\Releases\2.2 SP1\Customization Wizard\Setup\Setup.wxs(136) : warning LGHT1076 : ICE03: String overflow (greater than length permitted in column); Table: Shortcut, Column: Target, Key(s): StartMenuInstallGuideShortcut And I see that regardless of whether I link directly to msi, or via an intermediate wixout. Is there any way to disassemble the wixout and anything specific I could look for to give a hint about what the UI extension is doing? -Original Message- From: Blair [mailto:os...@live.com] Sent: Wednesday, 7 July 2010 3:11 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users]
Re: [WiX-users] Setting environment variable: PATH
This is an old thread now, but I thought I'd update to mention that I've just seen this on Windows 7. The PATH var is updated and can be verified in the env var management window, but a new command prompt does not see the update. Opening the env var management window and clicking OK fixes things. I'm still none the wiser as to the cause. Rob On 04/03/2009 14:27, Reddy, Mallikarjun (GWM-CAI) wrote: Yes Rob. It is on Win2k3. -Original Message- From: Rob Hamflett [mailto:r...@snsys.com] Sent: Wednesday, March 04, 2009 3:43 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Setting environment variable: PATH Was this on a server version of Windows? I had a problem like this once, and so did another poster, but I don't think we ever got to the bottom of it. Rob Reddy, Mallikarjun (GWM-CAI) wrote: Hello All, appreciate your help on this as I tried everything possible. I am setting PATH variable with a path. It is getting set. But I am not able to run an exe present in the path using Start--Run. However when I open the environment variable window manually and click OK without making any change after the installation, then it works. The path is not being recognized until I make a visit to the env window from computer properties, advanced tab and env button. I don't make any change, it works. Weird. Please let me know if I should be doing anything else ? Thanks in advance Component Id=PathEnv Guid=2DFDBB7D-292E-462c-A3E3-2FA14FFCD05D KeyPath=yes Environment Id=Path Name=PATH Value=[sym_configmgmt] Permanent=yes Part=last Action=set System=yes Separator=; / CreateFolder / /Component -- This message w/attachments (message) may be privileged, confidential or proprietary, and if you are not an intended recipient, please notify the sender, do not use or share it and delete it. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may monitor, review and retain e-communications (EC) traveling through its networks/systems. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secur e or error-free. References to Merrill Lynch are references to any company in the Merrill Lynch Co., Inc. group of companies, which are wholly-owned by Bank of America Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not Insured by Any Federal Government Agency. Attachments that are part of this E-communication may have additional important disclosures and disclaimers, which you should read. This message is subject to terms available at the following link: http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you consent to the foregoing. -- -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H -- This SF.net email
Re: [WiX-users] wix generated installer dialogs and Narrator
Hi, Thanks for the reply. However, I already have a structure similar to the one outlined by you: Control Id=BannerBitmap Type=Bitmap Text=WixUI_Bmp_Banner ../ Control Id=SomeText Type=Text Text=Enter the ..: .. / Control Id=SomeEditBox Type=Edit Property=SOMEPROPERTY Text=[SOMEPROPERTY] ToolTip=Some tooltip ../ I would expect the value read out by Narrator/UISpy when selecting SomeEditBox read out Enter the ..: from the SomeText text item, but it reads out WixUI_Bmp_Banner for some reason. And I have around 5 sets of Text+Edit fields, and all of the edit fields get the name WixUI_Bmp_Banner. Thanks, Rendijs S. -Original Message- Date: Tue, 6 Jul 2010 10:37:52 -0700 From: Blair os...@live.com Subject: Re: [WiX-users] wix generated installer dialogs and Narrator To: 'General discussion for Windows Installer XML toolset.' wix-users@lists.sourceforge.net Message-ID: blu111-ds127af72aaa3daa64408a23cd...@phx.gbl Content-Type: text/plain; charset=us-ascii The platform support for products such as Narrator is called Accessibility by Microsoft. This page gives the guidelines for that support for Windows Installer UI: http://msdn.microsoft.com/library/aa367454.aspx Basically, you need to have a Text type control that provides the caption for each of your Edit type controls be immediately right before the respective edit field in your authoring (position doesn't matter for the reader). Then Narrator will get the caption from that static text. ... Control Type=Text Text=Caption A .../ Control Type=Edit Property=PROPERTYA .../ ... Control Type=Text Text=Caption B .../ Control Type=Edit Property=PROPERTYB .../ ... -Original Message- From: Rendijs Smukulis [mailto:luuse...@gmail.com] Sent: Tuesday, July 06, 2010 7:55 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] wix generated installer dialogs and Narrator Hello, wix-users! Been googling this for ages, to no avail. The basic problem is this: I have an installer form with a couple of editable text fields (type=Edit). I need to add a caption to them which would be readable by Narrator, UI Spy and such. Adding a ToolTip or Help elements did not work. For some odd reason, when I have an element Control Id=BannerBitmap Type=Bitmap X=0 Y=0 Width=370 Height=44 TabSkip=no Text=WixUI_Bmp_Banner/ in the form, the names of the editable text fields become WixUI_Bmp_Banner, and are read out by Narrator as such. The version of wix is 3.0.5419 I believe. Any ideas how to get this working? Thanks in advance, Rendijs S. (sorry if the mail is sub-standard, my first mail to the list) -- 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] Error 2920 when applying a patch
Hi everybody, I'm trying to use WIX to generate a patch for an installer created using Visual Studio 2008. It's a simple patch that updates a single file. I started with an all-wix approach using pyro. After some trial and error I managed to create a patch. When I install it however I get an error: 2920. If I open the original MSI in Orca and view the transformation applied by the patch then everything looks honky dory until I get to the Media table. The LastSequence number is negative and the cabinet name appears in the VolumeLabel column. I've managed to create a working patch using MSIMSP but it is not as focused as the other patch since it's not possible to target a single component (or at least I haven't found a way to do so) using MSIMSP. Does this problem ring a bell? Is pyro expecting the schema to be of a scpecific version (the MSI I have uses the 200 schema) ? Bestu kveðjur / Best Regards / Venlig hilsen Eiríkur Fannar Torfason Microsoft Certified Solution Developer Sími / Phone: +354 510 3100 Skype: gopro-eirikur Fax: +354 510 3110 email: eiri...@gopro.net www.gopro.net / www.hugvit.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
[WiX-users] wix installer is very slow.
Hi All, I have a installer which installs large number of files(~5 files). It takes a lot of time to install. However it's installation time is tolerable. But while upgrading it takes intolerable amount of time(more than 1 hour sometimes). It also takes lot of time(1 hour) in un installation. - I want make this time down to around 10-15 minutes. What are possible schemes for that ? - Is there any mechanism to define force upgrade for each component ? Regards, Sanjay Rao -- 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] Go back to previous version
Hi, We use msi installer for our software and we are using WIX toolset for that. After upgrading to newer version of our software sometimes users of our software does not find themselves convenient with new version and they want to go back to previous version. Is there any mechanism in WIX for go back to previously installed version of software. Regards, Sanjay Rao -- 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] Editing config files after installation
Hello, I suppose this question was asked before, but i couldn't find a clear answer for it: When an installer runs on the target machine, and installs all the files in the InstallDir, i would like to carry some extra actions. -Get a config file that was installed, i.e foo.config. -Modify that file (which is in xml format), by adding some values in the key/value pairs. Now as far as i know from the search i've done, i can only do this after InstallFinalize, because that is when the files are showing in the InstallDir.? What is the ideal way of doing this? i.e: -are there built in wix methods to grab foo.config? -should i use the util:XmlFile tag for the editing? -what are the general steps for doing this process? e.g put all the steps in a custom action and call it after InstallFinalize? Thanks in advance, Stelios -- Stelios Kyprou Systems Engineer Formicary - delivering quality financial technology solutions(TM) www.formicary.net This message is confidential and may be privileged. It is intended solely for the named addressee. If you are not the intended recipient, please inform us. Any unauthorised dissemination, distribution or copying hereof is prohibited. Formicary Limited registered office in England and Wales, address 1 Taillar Road, Hedon, East Yorkshire HU12 8GU, registration number 3894343, VAT number 747644304, does not guarantee that the integrity of this communication has been maintained nor that this communication is free of viruses, interceptions or interference. -- 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] Unresolved reference to symbol 'Directory:SystemFolder'in section 'fragment:'
Hi,
I am very new to WIX. When i am trying to create an msi i am getting the
following error.
Unresolved reference to symbol 'Directory:SystemFolder'in section
'fragment:'
I have created the .wxs file using heat.exe. I know that there is no
systemFolder diretory in my directory structure.
But why did Heat generated this folder and how do i resolve this error?
Below is the fragment that is causing the problem
Fragment
DirectoryRef Id=dir07B00FE80C030860241E2DB3BAF7AE7D
Component Id=cmp40CE54724631208ADA05F65F4A51 Guid=
{0C99C0B5-F531-4AA0-8E18-F5FCA74793DA}
Class Id={D5DE8D20-5BB8-11D1-A1E3-00A0C90F2731} Context=InprocServer32
Description=VBPropertyBag ThreadingModel=apartment ForeignServer=
msvbvm60.dll /
File Id=filC9B10037678695297E47AA93580CE72C KeyPath=yes Source=
..\..\Monarch.Client\EFI.Binaries\SetMonarchWin.dll
TypeLib Id={60AD7F4B-F1E9-47B5-B6D5-C4373D5F9C2B} Description=
SetMonarchWin HelpDirectory=dir07B00FE80C030860241E2DB3BAF7AE7D Language=
0 MajorVersion=17 MinorVersion=0
Class Id={5BA8949F-EE19-4FD9-B4D1-99A842DA5C0F} Context=InprocServer32
Description=SetMonarchWin.SetWinProp ThreadingModel=apartment Version=
17.0 Programmable=yes
ProgId Id=SetMonarchWin.SetWinProp Description=SetMonarchWin.SetWinProp/
/Class
Interface Id={B863F088-9246-420E-8570-06BBD57C0866} Name=SetWinProp
ProxyStubClassId={00020424---C000-0046} ProxyStubClassId32
={00020424---C000-0046} /
/TypeLib
TypeLib Id={000204EF---C000-0046} Description=Visual
Basic For Applications HelpDirectory=SystemFolder Language=9
MajorVersion=6 MinorVersion=0
Interface Id={A4C466B8-499F-101B-BB78-00AA00383CBB} Name=_ErrObject
ProxyStubClassId={00020424---C000-0046} ProxyStubClassId32
={00020424---C000-0046} /
Interface Id={A4C46780-499F-101B-BB78-00AA00383CBB} Name=_Collection
ProxyStubClassId={00020424---C000-0046} ProxyStubClassId32
={00020424---C000-0046} /
/TypeLib
TypeLib Id={EA544A21-C82D-11D1-A3E4-00A0C90AEA82} Description=Visual
Basic runtime objects and procedures HelpDirectory=SystemFolder Hidden=
yes Language=9 MajorVersion=6 MinorVersion=0
Interface Id={14E469E0-BF61-11CF-8385-8F69D8F1350B} Name=
AsyncProperty_VB5 ProxyStubClassId={00020424---C000-0046}
ProxyStubClassId32={00020424---C000-0046} /
Interface Id={2CE46480-1A08-11CF-AD63-00AA00614F3E} Name=
SelectedControls ProxyStubClassId={00020424---C000-0046}
ProxyStubClassId32={00020424---C000-0046} /
Interface Id={41A7D760-6018-11CF-9016-00AA0068841E} Name=DataObject
ProxyStubClassId={00020424---C000-0046} ProxyStubClassId32
={00020424---C000-0046} /
Interface Id={41A7D761-6018-11CF-9016-00AA0068841E} Name=DataObjectFiles
ProxyStubClassId={00020424---C000-0046}
ProxyStubClassId32={00020424---C000-0046} /
Interface Id={4495AD01-C993-11D1-A3E4-00A0C90AEA82} Name=_PropertyBag
ProxyStubClassId={00020424---C000-0046} ProxyStubClassId32
={00020424---C000-0046} /
Interface Id={45046D60-08CA-11CF-A90F-00AA0062BB4C} Name=PropertyBag_VB5
ProxyStubClassId={00020424---C000-0046}
ProxyStubClassId32={00020424---C000-0046} /
Interface Id={737361EC-467F-11D1-810F-F87557AA} Name=Licenses
ProxyStubClassId={00020424---C000-0046} ProxyStubClassId32
={00020424---C000-0046} /
Interface Id={7500A6BA-EB65-11D1-938D-F87557C9} Name=DataBinding
ProxyStubClassId={00020424---C000-0046} ProxyStubClassId32
={00020424---C000-0046} /
Interface Id={8284B8A2-A8A8-11D1-A3D2-00A0C90AEA82} Name=LicenseInfo
ProxyStubClassId={00020424---C000-0046} ProxyStubClassId32
={00020424---C000-0046} /
Interface Id={83C49FF0-B294-11D0-9488-00A0C91110ED} Name=DataMembers
ProxyStubClassId={00020424---C000-0046} ProxyStubClassId32
={00020424---C000-0046} /
Interface Id={888A5A60-B283-11CF-8AD5-00A0C90AEA82} Name=Hyperlink
ProxyStubClassId={00020424---C000-0046} ProxyStubClassId32
={00020424---C000-0046} /
Interface Id={B28FA150-0FF0-11CF-A911-00AA0062BB4C} Name=
AmbientProperties ProxyStubClassId={00020424---C000-0046}
ProxyStubClassId32={00020424---C000-0046} /
Interface Id={BE8F9800-2AAA-11CF-AD67-00AA00614F3E} Name=ParentControls
ProxyStubClassId={00020424---C000-0046} ProxyStubClassId32
={00020424---C000-0046} /
Interface Id={C0324960-2AAA-11CF-AD67-00AA00614F3E} Name=
ContainedControls ProxyStubClassId={00020424---C000-0046}
ProxyStubClassId32={00020424---C000-0046} /
Interface Id={C4D651F0-7697-11D1-A1E9-00A0C90F2731} Name=EventParameter
ProxyStubClassId={00020424---C000-0046} ProxyStubClassId32
Re: [WiX-users] Go back to previous version
WiX != Windows Installer. You would do well not to confuse them or use them interchangeably. If you're using Major Upgrade functionality remove the Upgrade table entries and/or your Launch Condition which block installing an older version. If you're not using Major Upgrade functionality, educate your users on the use of Add/Remove Control Panel (Programs Features in Vista Win7). Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Sanjay Rao [mailto:s...@noida.interrasystems.com] Sent: 07 July 2010 11:34 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Go back to previous version Hi, We use msi installer for our software and we are using WIX toolset for that. After upgrading to newer version of our software sometimes users of our software does not find themselves convenient with new version and they want to go back to previous version. Is there any mechanism in WIX for go back to previously installed version of software. Regards, Sanjay Rao -- 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] Go back to previous version
but my newer version of application generates/modifies some files in installation directory at target machine which may not be appropriate for older version. These files not present in installer. these files are generated when application runs after installation. I want these files also in previous state. I want to go to the previous state of the installation directory. Pally Sandher wrote: WiX != Windows Installer. You would do well not to confuse them or use them interchangeably. If you're using Major Upgrade functionality remove the Upgrade table entries and/or your Launch Condition which block installing an older version. If you're not using Major Upgrade functionality, educate your users on the use of Add/Remove Control Panel (Programs Features in Vista Win7). Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Sanjay Rao [mailto:s...@noida.interrasystems.com] Sent: 07 July 2010 11:34 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Go back to previous version Hi, We use msi installer for our software and we are using WIX toolset for that. After upgrading to newer version of our software sometimes users of our software does not find themselves convenient with new version and they want to go back to previous version. Is there any mechanism in WIX for go back to previously installed version of software. Regards, Sanjay Rao -- 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] Editing config files after installation
If the file is installed as part of your installation you can simply use it's Id as a Property e.g. [#foo.config] if you set Id=foo.config in it's File element (see - http://msdn.microsoft.com/en-us/library/aa368609.aspx). Use that Property as the path for either XMLConfig or XMLFile to make your changes to the file. If it's put on the target machine by some other means you can locate the file using normal methods such as RegistrySearch (http://wix.sourceforge.net/manual-wix3/wix_xsd_registrysearch.htm), DirectorySearch (http://wix.sourceforge.net/manual-wix3/wix_xsd_directorysearch.htm) or FileSearch (http://wix.sourceforge.net/manual-wix3/wix_xsd_filesearch.htm) then do so to set your Property for XMLConfig/XMLFile. You will need no Custom Actions in either of these cases which should make your code much more resilient. If you can't locate the file using normal methods then a Custom Action which sets a Property containing the path to the file is your only option. How is this file installed on the target system initially? If it's by another product you can usually use a RegistrySearch to find something like the InstallLocation extrapolate the rest of the path from there. If you're really lucky the other products authors thought about this ahead of time there may be a standard registry key set by their installer for you to grab the location from. Avoid using Custom Actions unless you have no other option. Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Stelios Kyprou [mailto:stelios.kyp...@formicary.net] Sent: 07 July 2010 11:34 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Editing config files after installation Hello, I suppose this question was asked before, but i couldn't find a clear answer for it: When an installer runs on the target machine, and installs all the files in the InstallDir, i would like to carry some extra actions. -Get a config file that was installed, i.e foo.config. -Modify that file (which is in xml format), by adding some values in the key/value pairs. Now as far as i know from the search i've done, i can only do this after InstallFinalize, because that is when the files are showing in the InstallDir.? What is the ideal way of doing this? i.e: -are there built in wix methods to grab foo.config? -should i use the util:XmlFile tag for the editing? -what are the general steps for doing this process? e.g put all the steps in a custom action and call it after InstallFinalize? Thanks in advance, Stelios -- Stelios Kyprou Systems Engineer Formicary - delivering quality financial technology solutions(TM) www.formicary.net This message is confidential and may be privileged. It is intended solely for the named addressee. If you are not the intended recipient, please inform us. Any unauthorised dissemination, distribution or copying hereof is prohibited. Formicary Limited registered office in England and Wales, address 1 Taillar Road, Hedon, East Yorkshire HU12 8GU, registration number 3894343, VAT number 747644304, does not guarantee that the integrity of this communication has been maintained nor that this communication is free of viruses, interceptions or interference. -- 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] Go back to previous version
Then your installer should've been written with cleaning up those files in mind before you released it and/or those files which need modified after install shouldn't be held in the installation directory if it's a per-machine installation, they should be in CommonAppData or somewhere similar as per Microsoft's guidelines. Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Sanjay Rao [mailto:s...@noida.interrasystems.com] Sent: 07 July 2010 12:40 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Go back to previous version but my newer version of application generates/modifies some files in installation directory at target machine which may not be appropriate for older version. These files not present in installer. these files are generated when application runs after installation. I want these files also in previous state. I want to go to the previous state of the installation directory. Pally Sandher wrote: WiX != Windows Installer. You would do well not to confuse them or use them interchangeably. If you're using Major Upgrade functionality remove the Upgrade table entries and/or your Launch Condition which block installing an older version. If you're not using Major Upgrade functionality, educate your users on the use of Add/Remove Control Panel (Programs Features in Vista Win7). Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Sanjay Rao [mailto:s...@noida.interrasystems.com] Sent: 07 July 2010 11:34 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Go back to previous version Hi, We use msi installer for our software and we are using WIX toolset for that. After upgrading to newer version of our software sometimes users of our software does not find themselves convenient with new version and they want to go back to previous version. Is there any mechanism in WIX for go back to previously installed version of software. Regards, Sanjay Rao -- -- -- 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
[WiX-users] 64 bit app installing in Program Files (x86) folder
I modified WixAdvancedSample.wxs to build for 64 bit arch. Unfortunately, it's installing on the 32 Program files folder: ?xml version=1.0 encoding=utf-8? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; Product Id=49d75c41-17e3-48ed-9f4f-e65cedd3285e UpgradeCode=5b2d91c2-6c8f-4224-87af-71766b037ae4 Name=Acme Sample Application Language=1033 Version=1.0.0.0 Manufacturer=Acme Software Ltd. Package InstallerVersion=200 Compressed=yes Platform=x64 / Media Id=1 Cabinet=WixAdvancedSample.cab EmbedCab=yes / Directory Id=TARGETDIR Name=SourceDir Directory Id=ProgramFiles64Folder !-- must be named APPLICATIONFOLDER -- Directory Id=APPLICATIONFOLDER Name=[ApplicationFolderName] FileSource=.\ Component Id=ProductComponent Guid=70bcba1f-19a8-41b3-bc25-15a2648907e6 Win64=yes File Id=f1 Name=SampleFile.txt / /Component /Directory /Directory /Directory Feature Id=ProductFeature Title=Main Feature Level=1 ComponentRef Id=ProductComponent / /Feature Property Id=ApplicationFolderName Value=Acme Sample Application / Property Id=WixAppFolder Value=WixPerUserFolder / UIRef Id=WixUI_Advanced / UI / /Product /Wix What is missing? Cordialement / Best regards, Gernot -- 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] Go back to previous version
If I put files in CommonAppData, In that case also files generated by newer version are not valid for older version. Is there any way to backup older files/setting up a restore point for a particular directory. Pally Sandher wrote: Then your installer should've been written with cleaning up those files in mind before you released it and/or those files which need modified after install shouldn't be held in the installation directory if it's a per-machine installation, they should be in CommonAppData or somewhere similar as per Microsoft's guidelines. Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Sanjay Rao [mailto:s...@noida.interrasystems.com] Sent: 07 July 2010 12:40 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Go back to previous version but my newer version of application generates/modifies some files in installation directory at target machine which may not be appropriate for older version. These files not present in installer. these files are generated when application runs after installation. I want these files also in previous state. I want to go to the previous state of the installation directory. Pally Sandher wrote: WiX != Windows Installer. You would do well not to confuse them or use them interchangeably. If you're using Major Upgrade functionality remove the Upgrade table entries and/or your Launch Condition which block installing an older version. If you're not using Major Upgrade functionality, educate your users on the use of Add/Remove Control Panel (Programs Features in Vista Win7). Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Sanjay Rao [mailto:s...@noida.interrasystems.com] Sent: 07 July 2010 11:34 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Go back to previous version Hi, We use msi installer for our software and we are using WIX toolset for that. After upgrading to newer version of our software sometimes users of our software does not find themselves convenient with new version and they want to go back to previous version. Is there any mechanism in WIX for go back to previously installed version of software. Regards, Sanjay Rao -- -- -- 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
Re: [WiX-users] Unresolved reference to symbol'Directory:SystemFolder'in section 'fragment:'
Change the HelpDirectory attributes for the TypeLibs in the pasted code
which point at SystemFolder to point somewhere else such as
dir07B00FE80C030860241E2DB3BAF7AE7D (that's an example, might not be
correct for your COM DLL's).
heat.exe generates sample code, you shouldn't expect to be able to use
it blindly without checking it's generating something sensible (even
though many people do on a regular basis).
Also you may want to run heat.exe with the -suid flag so you get more
readable directory file identifiers than
dir07B00FE80C030860241E2DB3BAF7AE7D.
Palbinder Sandher
Software Deployment IT Administrator
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
http://www.iesve.com
**Design, Simulate + Innovate with the Virtual Environment**
Integrated Environmental Solutions Limited. Registered in Scotland No.
SC151456 Registered Office - Helix Building, West Of Scotland Science
Park, Glasgow G20 0SP Email Disclaimer
-Original Message-
From: subrat agasti [mailto:subrat.w...@gmail.com]
Sent: 07 July 2010 12:16
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Unresolved reference to
symbol'Directory:SystemFolder'in section 'fragment:'
Hi,
I am very new to WIX. When i am trying to create an msi i am getting the
following error.
Unresolved reference to symbol 'Directory:SystemFolder'in section
'fragment:'
I have created the .wxs file using heat.exe. I know that there is no
systemFolder diretory in my directory structure.
But why did Heat generated this folder and how do i resolve this error?
Below is the fragment that is causing the problem
Fragment
DirectoryRef Id=dir07B00FE80C030860241E2DB3BAF7AE7D
Component Id=cmp40CE54724631208ADA05F65F4A51 Guid=
{0C99C0B5-F531-4AA0-8E18-F5FCA74793DA}
Class Id={D5DE8D20-5BB8-11D1-A1E3-00A0C90F2731}
Context=InprocServer32
Description=VBPropertyBag ThreadingModel=apartment ForeignServer=
msvbvm60.dll /
File Id=filC9B10037678695297E47AA93580CE72C KeyPath=yes Source=
..\..\Monarch.Client\EFI.Binaries\SetMonarchWin.dll
TypeLib Id={60AD7F4B-F1E9-47B5-B6D5-C4373D5F9C2B} Description=
SetMonarchWin HelpDirectory=dir07B00FE80C030860241E2DB3BAF7AE7D
Language= 0 MajorVersion=17 MinorVersion=0
Class Id={5BA8949F-EE19-4FD9-B4D1-99A842DA5C0F}
Context=InprocServer32
Description=SetMonarchWin.SetWinProp ThreadingModel=apartment
Version=
17.0 Programmable=yes
ProgId Id=SetMonarchWin.SetWinProp
Description=SetMonarchWin.SetWinProp/
/Class
Interface Id={B863F088-9246-420E-8570-06BBD57C0866} Name=SetWinProp
ProxyStubClassId={00020424---C000-0046}
ProxyStubClassId32 ={00020424---C000-0046} /
/TypeLib
TypeLib Id={000204EF---C000-0046} Description=Visual
Basic For Applications HelpDirectory=SystemFolder Language=9
MajorVersion=6 MinorVersion=0
Interface Id={A4C466B8-499F-101B-BB78-00AA00383CBB} Name=_ErrObject
ProxyStubClassId={00020424---C000-0046}
ProxyStubClassId32 ={00020424---C000-0046} /
Interface Id={A4C46780-499F-101B-BB78-00AA00383CBB}
Name=_Collection
ProxyStubClassId={00020424---C000-0046}
ProxyStubClassId32 ={00020424---C000-0046} /
/TypeLib
TypeLib Id={EA544A21-C82D-11D1-A3E4-00A0C90AEA82} Description=Visual
Basic runtime objects and procedures HelpDirectory=SystemFolder
Hidden=
yes Language=9 MajorVersion=6 MinorVersion=0
Interface Id={14E469E0-BF61-11CF-8385-8F69D8F1350B} Name=
AsyncProperty_VB5
ProxyStubClassId={00020424---C000-0046}
ProxyStubClassId32={00020424---C000-0046} /
Interface Id={2CE46480-1A08-11CF-AD63-00AA00614F3E} Name=
SelectedControls
ProxyStubClassId={00020424---C000-0046}
ProxyStubClassId32={00020424---C000-0046} /
Interface Id={41A7D760-6018-11CF-9016-00AA0068841E} Name=DataObject
ProxyStubClassId={00020424---C000-0046}
ProxyStubClassId32 ={00020424---C000-0046} /
Interface Id={41A7D761-6018-11CF-9016-00AA0068841E}
Name=DataObjectFiles
ProxyStubClassId={00020424---C000-0046}
ProxyStubClassId32={00020424---C000-0046} /
Interface Id={4495AD01-C993-11D1-A3E4-00A0C90AEA82}
Name=_PropertyBag
ProxyStubClassId={00020424---C000-0046}
ProxyStubClassId32 ={00020424---C000-0046} /
Interface Id={45046D60-08CA-11CF-A90F-00AA0062BB4C}
Name=PropertyBag_VB5
ProxyStubClassId={00020424---C000-0046}
ProxyStubClassId32={00020424---C000-0046} /
Interface Id={737361EC-467F-11D1-810F-F87557AA} Name=Licenses
ProxyStubClassId={00020424---C000-0046}
ProxyStubClassId32 ={00020424---C000-0046} /
Interface Id={7500A6BA-EB65-11D1-938D-F87557C9}
Name=DataBinding
ProxyStubClassId={00020424---C000-0046}
ProxyStubClassId32 ={00020424---C000-0046} /
Interface Id={8284B8A2-A8A8-11D1-A3D2-00A0C90AEA82}
Name=LicenseInfo
Re: [WiX-users] Problems launching an application on finish
So what is the conclusion? That what I am trying is basically impossible? I tried setting the action to Impersonate=No and Execute=Commit. I got this for my trouble: --- Action start 13:54:36: LaunchConfig. MSI (c) (AC:A8) [13:54:36:027]: Note: 1: 2762 DEBUG: Error 2762: Unable to schedule operation. The action must be scheduled between InstallInitialize and InstallFinalize. The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2762. The arguments are: , , MSI (c) (AC:A8) [13:54:42:205]: Product: ScanX.NET -- The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2762. The arguments are: , , Action ended 13:54:42: LaunchConfig. Return value 3. DEBUG: Error 2896: Executing action LaunchConfig failed. The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2896. The arguments are: LaunchConfig, , --- Is there any way to solve this issue, without having to start the entire msi as administrator, or launching the application through obscure custom actions? In any event, thank you all so far for your help. /Thomas Due -Original Message- From: Blair [mailto:os...@live.com] Sent: 5. juli 2010 17:26 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Problems launching an application on finish You can't run a deferred action from a Publish. If you use cmd.exe (or QAQuietExec) you may be able to launch the executable in such a way as to let UAC prompt you for elevation. The failure is because CustomAction FileKey/ launches in such a way as to not allow UAC to be invoked, and the application's elevation manifest prevents execution. -Original Message- From: Pally Sandher [mailto:pally.sand...@iesve.com] Sent: Monday, July 05, 2010 4:01 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Problems launching an application on finish Try adding the Impersonate attribute with value no to your CustomAction element. You may also want to change the Execute attribute to commit or deferred. See - http://wix.sourceforge.net/manual-wix3/wix_xsd_customaction.htm Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Thomas Due [mailto:t...@scanvaegt.dk] Sent: 05 July 2010 11:38 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Problems launching an application on finish Hello, I have a rather simple installer which among other things registers and starts some windows services. As such, the installer requires admin privileges from the UAC on Vista and Win7. It runs beautifully on Windows XP, Windows Vista and Windows 7, so not problems with the installer. However, I need to launch an application when the user clicks the Finish button on the last dialog. Since the application needs to restart the services, it needs to run with administrative privileges. I have as a result included a manifest in the application requesting admin rights. This also works beautifully, when executed separately. On Windows XP the installer launches the application as it should, but on Windows 7 (I haven't tested on Vista yet) it doesn't start. I suspect it has to do with the installer running as normal user, while the application requires admin privileges, and I am missing something for making the installer able to launch the application. My launch code looks like this: Product .. Publish Dialog=ExitDialog Control=Finish Event=DoAction Value=LaunchConfig Order=999NOT Installed/Publish CustomAction Id=LaunchConfig FileKey=MasterConfig Return=asyncNoWait / Where the MasterConfig points correctly to an application being installed. So, what am I missing? Med venlig hilsen / Best regards, Thomas Due - Software Developer Tel: +45 8678 5500 Fax: +45 8678 5210 Johann Gutenbergs vej 5-9, Aarhus N, Denmark t...@scanvaegt.dk | www.scanvaegt.dk This e-mail and its attachments are intended for the named addressee only and may contain information that is confidential and privileged. Unauthorized use can instigate a claim for damages and constitute a criminal offence. If you received this in error, please contact the sender and delete the material. -Original Message- From: wix-users-requ...@lists.sourceforge.net [mailto:wix-users-requ...@lists.sourceforge.net] Sent: 4. juli 2010 03:48 To: wix-users@lists.sourceforge.net Subject: WiX-users Digest, Vol 50, Issue 14 Send WiX-users mailing list
Re: [WiX-users] 64 bit app installing in Program Files (x86) folder
Check a verbose log? Is your MSI built for the x64 platform? Open it in InstEd/Orca check the Summary Info. The Platform property should be set to x64 or AMD64 (both are the same thing, latter is deprecated by the former). Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Gernot Kerger [mailto:gernot.ker...@entropysoft.net] Sent: 07 July 2010 12:50 To: wix-users@lists.sourceforge.net Subject: [WiX-users] 64 bit app installing in Program Files (x86) folder I modified WixAdvancedSample.wxs to build for 64 bit arch. Unfortunately, it's installing on the 32 Program files folder: ?xml version=1.0 encoding=utf-8? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; Product Id=49d75c41-17e3-48ed-9f4f-e65cedd3285e UpgradeCode=5b2d91c2-6c8f-4224-87af-71766b037ae4 Name=Acme Sample Application Language=1033 Version=1.0.0.0 Manufacturer=Acme Software Ltd. Package InstallerVersion=200 Compressed=yes Platform=x64 / Media Id=1 Cabinet=WixAdvancedSample.cab EmbedCab=yes / Directory Id=TARGETDIR Name=SourceDir Directory Id=ProgramFiles64Folder !-- must be named APPLICATIONFOLDER -- Directory Id=APPLICATIONFOLDER Name=[ApplicationFolderName] FileSource=.\ Component Id=ProductComponent Guid=70bcba1f-19a8-41b3-bc25-15a2648907e6 Win64=yes File Id=f1 Name=SampleFile.txt / /Component /Directory /Directory /Directory Feature Id=ProductFeature Title=Main Feature Level=1 ComponentRef Id=ProductComponent / /Feature Property Id=ApplicationFolderName Value=Acme Sample Application / Property Id=WixAppFolder Value=WixPerUserFolder / UIRef Id=WixUI_Advanced / UI / /Product /Wix What is missing? Cordialement / Best regards, Gernot -- 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] 64 bit app installing in Program Files (x86) folder
Thanks Palbinder. On the summary info, the platform property is set to x64. The verbose log doesn't show any errors: Generating database. Merging modules. Validating database. ICE01: ICE01 - Simple ICE that doesn't test anything ICE01: Created 04/29/1998. Last Modified 08/17/1998. ICE01: Called at 14:16:00. ICE02: ICE02 - ICE to test circular references in File and Component tables ICE02: Created 05/18/1998. Last Modified 10/12/1998. ICE03: ICE03 - ICE to perform data validation and foreign key references ICE03: Created 05/19/1998. Last Modified 10/03/2001. ICE04: ICE04 - ICE to validate File table sequences according to Media table ICE04: Created 05/19/1998. Last Modified 09/24/1998. ICE04: Max Sequence in Media Table is 1 ICE05: ICE05 - ICE to validate that required data exists in certain tables. ICE05: Created 05/20/1998. Last Modified 01/26/1999. ICE06: ICE06 - ICE that looks for missing columns in database tables ICE06: Created 05/20/1998. Last Modified 02/18/1999. ICE07: ICE07 - ICE that ensures that fonts are installed to the fonts folder. Only checked if you have a Font table ICE07: Created 05/21/1998. Last Modified 02/18/1999. ICE08: ICE08 - Checks for duplicate GUIDs in Component table ICE08: Created 05/21/98. Last Modified 10/08/98. ICE09: ICE09 - Checks for components whose Directory is the System directory but aren't set as system components ICE09: Created 05/21/98. Last Modified 10/09/2000. ICE10: ICE10 - ICE that ensures that advertise states of feature childs and parents match ICE10: Created 05/22/1998. Last Modified 10/02/2000. ICE11: ICE11 - ICE that validates the Product Code of a nested install (advertised MSI) custom action type ICE11: Created 05/22/1998. Last Modified 08/17/1998. ICE12: ICE12 - ICE that validates the Property type custom actions ICE12: Created 05/29/1998. Last Modified 01/14/2000. ICE13: ICE13 - ICE that validates that no dialogs are listed in the *ExecuteSequence tables ICE13: Created 06/08/1998. Last Modified 08/17/1998. ICE14: ICE14 - ICE that ensures that Feature_Parents do not have the ifrsFavorParent attribute set ICE14: Created 06/08/1998. Last Modified 01/27/1999. ICE15: ICE15 - ICE that ensures that a circular reference exists between the Mime and Extension tables ICE15: Created 06/11/1998. Last Modified 01/05/1999. ICE16: ICE16 - ICE that ensures that the ProductName in the Property table is less than 64 characters ICE16: Created 06/11/1998. Last Modified 10/03/2001. ICE17: ICE17 - ICE that validates foreign key dependencies based upon control types in the Control table. ICE17: Created 06/16/1998. Last Modified 12/21/2004. ICE18: ICE18 - ICE that validates the nulled KeyPath columns of the Component table. ICE18: Created 06/18/1998. Last Modified 03/24/1999. ICE19: ICE19 - ICE that validates that ComponentIDs and KeyPaths for advertising. ICE19: Created 06/18/1998. Last Modified 01/21/1999. ICE20: ICE20 - ICE that validates for Standard Dialogs if UI is authored. ICE20: Created 06/25/1998. Last Modified 10/04/1998. ICE21: ICE21 - ICE that validates that all components reference a feature. ICE21: Created 06/29/1998. Last Modified 03/02/1999. ICE22: ICE22 - ICE that validates that the feature and component referenced by a PublishedComponent actually map. ICE22: Created 06/29/1998. Last Modified 03/02/1999. ICE23: ICE23 - ICE that validates the tab order of all dialogs. ICE23: Created 07/02/1998. Last Modified 01/17/2000. ICE24: ICE24 - ICE that validates specific properties in the Property table. ICE24: Created 07/15/1998. Last Modified 01/15/2004. ICE25: ICE25 - ICE that validates module dependencies/exclusions. ICE25: Created 07/20/1998. Last Modified 08/31/1998. ICE26: ICE26 - ICE that validates required and prohibited actions in the Sequence tables. ICE26: Created 08/13/1998. Last Modified 04/06/1999. ICE27: ICE27 - ICE that validates sequence table organization and sequence table dependencies. ICE27: Created 08/04/1998. Last Modified 04/22/1999. ICE27: AdminExecuteSequence TABLE: Validating organization. . . ICE27: AdminExecuteSequence TABLE: Validating sequence of actions and dependencies. . . ICE27: AdminUISequence TABLE: Validating organization. . . ICE27: AdminUISequence TABLE: Validating sequence of actions and dependencies. . . ICE27: AdvtExecuteSequence TABLE: Validating organization. . . ICE27: AdvtExecuteSequence TABLE: Validating sequence of actions and dependencies. . . ICE27: AdvtUISequence table not found, skipping. . . ICE27: InstallExecuteSequence TABLE: Validating organization. . . ICE27: InstallExecuteSequence TABLE: Validating sequence of actions and dependencies. . . ICE27: InstallUISequence TABLE: Validating organization. . . ICE27: InstallUISequence TABLE: Validating sequence of actions and dependencies. . . ICE28: ICE28 - ICE that validates actions that can't be separated by ForceReboot. ICE28: Created 08/13/1998. Last Modified 10/27/1998. ICE29: ICE29 - ICE that validates stream names. ICE29: Created
Re: [WiX-users] wix installer is very slow.
This is a known issue with *Windows Installer* patching upgrades. Windows Installer WiX are not the same thing. I'm guessing you're using Major Upgrades to upgrade (correct me if I'm wrong). Take a look at a verbose log when upgrading or uninstalling see where it's taking so long. My guess will be between CostInitialize CostFinalize since it checks what is installed before it does anything. - I want make this time down to around 10-15 minutes. What are possible schemes for that ? Install fewer files. A couple of years ago I separated our company's main product into 2 MSI's, one installs most of the files (5000+, approx 1 GB installed) but changes very very rarely. The other installs the actual application binaries other things which change with each release (1600+ files, 220 MB installed). This makes patching upgrading work much faster since there are a lot less things for Windows Installer to have to check every time a user runs a patch or upgrade. - Is there any mechanism to define force upgrade for each component ? What do you mean by force upgrade? Major Upgrades can force every component to be reinstalled regardless of the current state if you schedule RemoveExistingProducts before InstallInitialize rather than after but this brings additional considerations with regards to the Component Rules. Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Sanjay Rao [mailto:s...@noida.interrasystems.com] Sent: 07 July 2010 11:20 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] wix installer is very slow. Hi All, I have a installer which installs large number of files(~5 files). It takes a lot of time to install. However it's installation time is tolerable. But while upgrading it takes intolerable amount of time(more than 1 hour sometimes). It also takes lot of time(1 hour) in un installation. - I want make this time down to around 10-15 minutes. What are possible schemes for that ? - Is there any mechanism to define force upgrade for each component ? Regards, Sanjay Rao -- 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] Problems launching an application on finish
Try using QTExec as per the example at http://wix.sourceforge.net/manual-wix3/run_program_after_install.htm but ignore the parts about adding the checkbox text to the ExitDialog if you don't want them (and modify the Condition of the example Publish accordingly). Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Thomas Due [mailto:t...@scanvaegt.dk] Sent: 07 July 2010 13:05 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Problems launching an application on finish So what is the conclusion? That what I am trying is basically impossible? I tried setting the action to Impersonate=No and Execute=Commit. I got this for my trouble: --- Action start 13:54:36: LaunchConfig. MSI (c) (AC:A8) [13:54:36:027]: Note: 1: 2762 DEBUG: Error 2762: Unable to schedule operation. The action must be scheduled between InstallInitialize and InstallFinalize. The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2762. The arguments are: , , MSI (c) (AC:A8) [13:54:42:205]: Product: ScanX.NET -- The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2762. The arguments are: , , Action ended 13:54:42: LaunchConfig. Return value 3. DEBUG: Error 2896: Executing action LaunchConfig failed. The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2896. The arguments are: LaunchConfig, , --- Is there any way to solve this issue, without having to start the entire msi as administrator, or launching the application through obscure custom actions? In any event, thank you all so far for your help. /Thomas Due -Original Message- From: Blair [mailto:os...@live.com] Sent: 5. juli 2010 17:26 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Problems launching an application on finish You can't run a deferred action from a Publish. If you use cmd.exe (or QAQuietExec) you may be able to launch the executable in such a way as to let UAC prompt you for elevation. The failure is because CustomAction FileKey/ launches in such a way as to not allow UAC to be invoked, and the application's elevation manifest prevents execution. -Original Message- From: Pally Sandher [mailto:pally.sand...@iesve.com] Sent: Monday, July 05, 2010 4:01 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Problems launching an application on finish Try adding the Impersonate attribute with value no to your CustomAction element. You may also want to change the Execute attribute to commit or deferred. See - http://wix.sourceforge.net/manual-wix3/wix_xsd_customaction.htm Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Thomas Due [mailto:t...@scanvaegt.dk] Sent: 05 July 2010 11:38 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Problems launching an application on finish Hello, I have a rather simple installer which among other things registers and starts some windows services. As such, the installer requires admin privileges from the UAC on Vista and Win7. It runs beautifully on Windows XP, Windows Vista and Windows 7, so not problems with the installer. However, I need to launch an application when the user clicks the Finish button on the last dialog. Since the application needs to restart the services, it needs to run with administrative privileges. I have as a result included a manifest in the application requesting admin rights. This also works beautifully, when executed separately. On Windows XP the installer launches the application as it should, but on Windows 7 (I haven't tested on Vista yet) it doesn't start. I suspect it has to do with the installer running as normal user, while the application requires admin privileges, and I am missing something for making the installer able to launch the application. My launch code looks like this: Product .. Publish Dialog=ExitDialog Control=Finish Event=DoAction Value=LaunchConfig Order=999NOT Installed/Publish CustomAction Id=LaunchConfig FileKey=MasterConfig
Re: [WiX-users] 64 bit app installing in Program Files (x86) folder
Thanks Pally, On the summary info, the platform property is set to x64 and the verbose log doesn't show any errors. Cordialement / Best regards, Gernot -Message d'origine- De : Pally Sandher [mailto:pally.sand...@iesve.com] Envoyé : Wednesday, July 07, 2010 2:03 PM À : General discussion for Windows Installer XML toolset. Objet : Re: [WiX-users] 64 bit app installing in Program Files (x86) folder Check a verbose log? Is your MSI built for the x64 platform? Open it in InstEd/Orca check the Summary Info. The Platform property should be set to x64 or AMD64 (both are the same thing, latter is deprecated by the former). Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Gernot Kerger [mailto:gernot.ker...@entropysoft.net] Sent: 07 July 2010 12:50 To: wix-users@lists.sourceforge.net Subject: [WiX-users] 64 bit app installing in Program Files (x86) folder I modified WixAdvancedSample.wxs to build for 64 bit arch. Unfortunately, it's installing on the 32 Program files folder: ?xml version=1.0 encoding=utf-8? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; Product Id=49d75c41-17e3-48ed-9f4f-e65cedd3285e UpgradeCode=5b2d91c2-6c8f-4224-87af-71766b037ae4 Name=Acme Sample Application Language=1033 Version=1.0.0.0 Manufacturer=Acme Software Ltd. Package InstallerVersion=200 Compressed=yes Platform=x64 / Media Id=1 Cabinet=WixAdvancedSample.cab EmbedCab=yes / Directory Id=TARGETDIR Name=SourceDir Directory Id=ProgramFiles64Folder !-- must be named APPLICATIONFOLDER -- Directory Id=APPLICATIONFOLDER Name=[ApplicationFolderName] FileSource=.\ Component Id=ProductComponent Guid=70bcba1f-19a8-41b3-bc25-15a2648907e6 Win64=yes File Id=f1 Name=SampleFile.txt / /Component /Directory /Directory /Directory Feature Id=ProductFeature Title=Main Feature Level=1 ComponentRef Id=ProductComponent / /Feature Property Id=ApplicationFolderName Value=Acme Sample Application / Property Id=WixAppFolder Value=WixPerUserFolder / UIRef Id=WixUI_Advanced / UI / /Product /Wix What is missing? Cordialement / Best regards, Gernot -- 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] 64 bit app installing in Program Files (x86) folder
On 7/7/2010 7:50 AM, Gernot Kerger wrote: I modified WixAdvancedSample.wxs to build for 64 bit arch. Unfortunately, it's installing on the 32 Program files folder: Known bug with workaround: https://sourceforge.net/tracker/?func=detailaid=2793021group_id=105970atid=642714 -- sig://boB http://joyofsetup.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
Re: [WiX-users] Check if a certain program running during installation.
On 7/4/2010 11:30 AM, Adi Sashkis wrote: I read that theutil:CloseApplication / might be what i need but I am not quit sure how it's works. Use the property you give it as a condition, either a dialog or an error custom action to prevent installation when set (i.e., when the process is running). -- sig://boB http://joyofsetup.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
Re: [WiX-users] 64 bit app installing in Program Files (x86) folder
Try a verbose log from when you *install* the product not build it. Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Gernot Kerger [mailto:gernot.ker...@entropysoft.net] Sent: 07 July 2010 13:24 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] 64 bit app installing in Program Files (x86) folder Thanks Palbinder. On the summary info, the platform property is set to x64. The verbose log doesn't show any errors: Generating database. Merging modules. Validating database. ICE01: ICE01 - Simple ICE that doesn't test anything ICE01: Created 04/29/1998. Last Modified 08/17/1998. ICE01: Called at 14:16:00. ICE02: ICE02 - ICE to test circular references in File and Component tables ICE02: Created 05/18/1998. Last Modified 10/12/1998. ICE03: ICE03 - ICE to perform data validation and foreign key references ICE03: Created 05/19/1998. Last Modified 10/03/2001. ICE04: ICE04 - ICE to validate File table sequences according to Media table ICE04: Created 05/19/1998. Last Modified 09/24/1998. ICE04: Max Sequence in Media Table is 1 ICE05: ICE05 - ICE to validate that required data exists in certain tables. ICE05: Created 05/20/1998. Last Modified 01/26/1999. ICE06: ICE06 - ICE that looks for missing columns in database tables ICE06: Created 05/20/1998. Last Modified 02/18/1999. ICE07: ICE07 - ICE that ensures that fonts are installed to the fonts folder. Only checked if you have a Font table ICE07: Created 05/21/1998. Last Modified 02/18/1999. ICE08: ICE08 - Checks for duplicate GUIDs in Component table ICE08: Created 05/21/98. Last Modified 10/08/98. ICE09: ICE09 - Checks for components whose Directory is the System directory but aren't set as system components ICE09: Created 05/21/98. Last Modified 10/09/2000. ICE10: ICE10 - ICE that ensures that advertise states of feature childs and parents match ICE10: Created 05/22/1998. Last Modified 10/02/2000. ICE11: ICE11 - ICE that validates the Product Code of a nested install (advertised MSI) custom action type ICE11: Created 05/22/1998. Last Modified 08/17/1998. ICE12: ICE12 - ICE that validates the Property type custom actions ICE12: Created 05/29/1998. Last Modified 01/14/2000. ICE13: ICE13 - ICE that validates that no dialogs are listed in the *ExecuteSequence tables ICE13: Created 06/08/1998. Last Modified 08/17/1998. ICE14: ICE14 - ICE that ensures that Feature_Parents do not have the ifrsFavorParent attribute set ICE14: Created 06/08/1998. Last Modified 01/27/1999. ICE15: ICE15 - ICE that ensures that a circular reference exists between the Mime and Extension tables ICE15: Created 06/11/1998. Last Modified 01/05/1999. ICE16: ICE16 - ICE that ensures that the ProductName in the Property table is less than 64 characters ICE16: Created 06/11/1998. Last Modified 10/03/2001. ICE17: ICE17 - ICE that validates foreign key dependencies based upon control types in the Control table. ICE17: Created 06/16/1998. Last Modified 12/21/2004. ICE18: ICE18 - ICE that validates the nulled KeyPath columns of the Component table. ICE18: Created 06/18/1998. Last Modified 03/24/1999. ICE19: ICE19 - ICE that validates that ComponentIDs and KeyPaths for advertising. ICE19: Created 06/18/1998. Last Modified 01/21/1999. ICE20: ICE20 - ICE that validates for Standard Dialogs if UI is authored. ICE20: Created 06/25/1998. Last Modified 10/04/1998. ICE21: ICE21 - ICE that validates that all components reference a feature. ICE21: Created 06/29/1998. Last Modified 03/02/1999. ICE22: ICE22 - ICE that validates that the feature and component referenced by a PublishedComponent actually map. ICE22: Created 06/29/1998. Last Modified 03/02/1999. ICE23: ICE23 - ICE that validates the tab order of all dialogs. ICE23: Created 07/02/1998. Last Modified 01/17/2000. ICE24: ICE24 - ICE that validates specific properties in the Property table. ICE24: Created 07/15/1998. Last Modified 01/15/2004. ICE25: ICE25 - ICE that validates module dependencies/exclusions. ICE25: Created 07/20/1998. Last Modified 08/31/1998. ICE26: ICE26 - ICE that validates required and prohibited actions in the Sequence tables. ICE26: Created 08/13/1998. Last Modified 04/06/1999. ICE27: ICE27 - ICE that validates sequence table organization and sequence table dependencies. ICE27: Created 08/04/1998. Last Modified 04/22/1999. ICE27: AdminExecuteSequence TABLE: Validating organization. . . ICE27: AdminExecuteSequence TABLE: Validating sequence of actions and dependencies. . . ICE27: AdminUISequence TABLE: Validating organization. . . ICE27: AdminUISequence TABLE: Validating sequence of actions and dependencies. . . ICE27:
Re: [WiX-users] Editing config files after installation
The file is installed by the installer, so i can use [#foo.config]. When i thought of doing this approach (XMLConfig || XMLFile), i got stuck because: I want to do the foo.config editing after a specific dialog, i.e EnterConfigurationDlg, so that i can grab the PROPERTIES from that dialog and put them in foo.config. Following the WiX tutorial at: http://www.tramontana.co.hu/wix/lesson6.php#6.10 did not really help with my senario... Any ideas? Stelios Pally Sandher wrote: If the file is installed as part of your installation you can simply use it's Id as a Property e.g. [#foo.config] if you set Id=foo.config in it's File element (see - http://msdn.microsoft.com/en-us/library/aa368609.aspx). Use that Property as the path for either XMLConfig or XMLFile to make your changes to the file. If it's put on the target machine by some other means you can locate the file using normal methods such as RegistrySearch (http://wix.sourceforge.net/manual-wix3/wix_xsd_registrysearch.htm), DirectorySearch (http://wix.sourceforge.net/manual-wix3/wix_xsd_directorysearch.htm) or FileSearch (http://wix.sourceforge.net/manual-wix3/wix_xsd_filesearch.htm) then do so to set your Property for XMLConfig/XMLFile. You will need no Custom Actions in either of these cases which should make your code much more resilient. If you can't locate the file using normal methods then a Custom Action which sets a Property containing the path to the file is your only option. How is this file installed on the target system initially? If it's by another product you can usually use a RegistrySearch to find something like the InstallLocation extrapolate the rest of the path from there. If you're really lucky the other products authors thought about this ahead of time there may be a standard registry key set by their installer for you to grab the location from. Avoid using Custom Actions unless you have no other option. Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Stelios Kyprou [mailto:stelios.kyp...@formicary.net] Sent: 07 July 2010 11:34 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Editing config files after installation Hello, I suppose this question was asked before, but i couldn't find a clear answer for it: When an installer runs on the target machine, and installs all the files in the InstallDir, i would like to carry some extra actions. -Get a config file that was installed, i.e foo.config. -Modify that file (which is in xml format), by adding some values in the key/value pairs. Now as far as i know from the search i've done, i can only do this after InstallFinalize, because that is when the files are showing in the InstallDir.? What is the ideal way of doing this? i.e: -are there built in wix methods to grab foo.config? -should i use the util:XmlFile tag for the editing? -what are the general steps for doing this process? e.g put all the steps in a custom action and call it after InstallFinalize? Thanks in advance, Stelios -- Stelios Kyprou Systems Engineer Formicary - delivering quality financial technology solutions(TM) www.formicary.net This message is confidential and may be privileged. It is intended solely for the named addressee. If you are not the intended recipient, please inform us. Any unauthorised dissemination, distribution or copying hereof is prohibited. Formicary Limited registered office in England and Wales, address 1 Taillar Road, Hedon, East Yorkshire HU12 8GU, registration number 3894343, VAT number 747644304, does not guarantee that the integrity of this communication has been maintained nor that this communication is free of viruses, interceptions or interference. -- 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
Re: [WiX-users] Editing config files after installation
The file is installed by the installer, so i can use [#foo.config]. When i thought of doing this approach (XMLConfig || XMLFile), i got stuck because: I want to do the foo.config editing after a specific dialog, i.e EnterConfigurationDlg, so that i can grab the PROPERTIES from that dialog and put them in foo.config. Following the WiX tutorial at: http://www.tramontana.co.hu/wix/lesson6.php#6.10 did not really help with my senario... Any ideas? Stelios Pally Sandher wrote: If the file is installed as part of your installation you can simply use it's Id as a Property e.g. [#foo.config] if you set Id=foo.config in it's File element (see - http://msdn.microsoft.com/en-us/library/aa368609.aspx). Use that Property as the path for either XMLConfig or XMLFile to make your changes to the file. If it's put on the target machine by some other means you can locate the file using normal methods such as RegistrySearch (http://wix.sourceforge.net/manual-wix3/wix_xsd_registrysearch.htm), DirectorySearch (http://wix.sourceforge.net/manual-wix3/wix_xsd_directorysearch.htm) or FileSearch (http://wix.sourceforge.net/manual-wix3/wix_xsd_filesearch.htm) then do so to set your Property for XMLConfig/XMLFile. You will need no Custom Actions in either of these cases which should make your code much more resilient. If you can't locate the file using normal methods then a Custom Action which sets a Property containing the path to the file is your only option. How is this file installed on the target system initially? If it's by another product you can usually use a RegistrySearch to find something like the InstallLocation extrapolate the rest of the path from there. If you're really lucky the other products authors thought about this ahead of time there may be a standard registry key set by their installer for you to grab the location from. Avoid using Custom Actions unless you have no other option. Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Stelios Kyprou [mailto:stelios.kyp...@formicary.net] Sent: 07 July 2010 11:34 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Editing config files after installation Hello, I suppose this question was asked before, but i couldn't find a clear answer for it: When an installer runs on the target machine, and installs all the files in the InstallDir, i would like to carry some extra actions. -Get a config file that was installed, i.e foo.config. -Modify that file (which is in xml format), by adding some values in the key/value pairs. Now as far as i know from the search i've done, i can only do this after InstallFinalize, because that is when the files are showing in the InstallDir.? What is the ideal way of doing this? i.e: -are there built in wix methods to grab foo.config? -should i use the util:XmlFile tag for the editing? -what are the general steps for doing this process? e.g put all the steps in a custom action and call it after InstallFinalize? Thanks in advance, Stelios -- Stelios Kyprou Systems Engineer Formicary - delivering quality financial technology solutions(TM) www.formicary.net This message is confidential and may be privileged. It is intended solely for the named addressee. If you are not the intended recipient, please inform us. Any unauthorised dissemination, distribution or copying hereof is prohibited. Formicary Limited registered office in England and Wales, address 1 Taillar Road, Hedon, East Yorkshire HU12 8GU, registration number 3894343, VAT number 747644304, does not guarantee that the integrity of this communication has been maintained nor that this communication is free of viruses, interceptions or interference. -- 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
Re: [WiX-users] wix installer is very slow.
-I changes product code everytime. I do not changes upgradecode. after splitting it into two msi files is there any way to combine them into single file, so that user do not need to download two files and install them separately. suppose I have two msi files 1. constant.msi 2. variable.msi I want to make a single file containing these two, which detects whether constant.msi installed or not. - if yes, do not install constant.msi. install variable.msi only. - if no install both msi files. Pally Sandher wrote: This is a known issue with *Windows Installer* patching upgrades. Windows Installer WiX are not the same thing. I'm guessing you're using Major Upgrades to upgrade (correct me if I'm wrong). Take a look at a verbose log when upgrading or uninstalling see where it's taking so long. My guess will be between CostInitialize CostFinalize since it checks what is installed before it does anything. - I want make this time down to around 10-15 minutes. What are possible schemes for that ? Install fewer files. A couple of years ago I separated our company's main product into 2 MSI's, one installs most of the files (5000+, approx 1 GB installed) but changes very very rarely. The other installs the actual application binaries other things which change with each release (1600+ files, 220 MB installed). This makes patching upgrading work much faster since there are a lot less things for Windows Installer to have to check every time a user runs a patch or upgrade. - Is there any mechanism to define force upgrade for each component ? What do you mean by force upgrade? Major Upgrades can force every component to be reinstalled regardless of the current state if you schedule RemoveExistingProducts before InstallInitialize rather than after but this brings additional considerations with regards to the Component Rules. Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Sanjay Rao [mailto:s...@noida.interrasystems.com] Sent: 07 July 2010 11:20 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] wix installer is very slow. Hi All, I have a installer which installs large number of files(~5 files). It takes a lot of time to install. However it's installation time is tolerable. But while upgrading it takes intolerable amount of time(more than 1 hour sometimes). It also takes lot of time(1 hour) in un installation. - I want make this time down to around 10-15 minutes. What are possible schemes for that ? - Is there any mechanism to define force upgrade for each component ? Regards, Sanjay Rao -- 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] Dynamic directory creation
Hi, I am faced with a problem of building an MSI that requires a set of directories to be created during installation. These directories are all prefixed with a common string (eg folder) followed by a sequence number (eg 01) so that their final construction might be something like folder01, folder02, etc. I need to place the same executable in each of these generated directories, but the number of directories isn't known until install time. I would like to prompt the user for that number during the setup and then dynamically build the directories. My original assumption was that WiX simply couldn't do this task because of the dynamic nature of the problem. I assumed that I'd have to write a batch script that would do this work for me: my approach was to always generate 1 directory, and then use a CA to invoke a batch script that would copy the directory as many times as was needed. I thought I'd post this problem to this list to see if there were other solutions (using WiX or otherwise) that might be cleaner or more effective. Keith -- 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] Editing config files after installation
XMLConfig XMLFile don't make changes in the InstallUISequence, only in the InstallExecuteSequence so using the contents of Properties from the UI sequence should be fine. Are you setting your Properties to be Secure? If you want to pass information in Properties from the InstallUISequence to the InstallExecuteSequence you need to set Secure=yes on those Properties. If you're using XMLFile with Action=SetValue you should be able to use Properties in the Value attribute as it is of the Formatted type according to the documentation. Personally I prefer to use XMLConfig for modifying files I'm putting on the target machine but if you paste your code for your XMLFile Element the appropriate Properties (and what you expect them to contain) myself or others on the list may be able to see where the problem lies or give suggestions on using XMLConfig. Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Stelios Kyprou [mailto:stelios.kyp...@formicary.net] Sent: 07 July 2010 13:23 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Editing config files after installation The file is installed by the installer, so i can use [#foo.config]. When i thought of doing this approach (XMLConfig || XMLFile), i got stuck because: I want to do the foo.config editing after a specific dialog, i.e EnterConfigurationDlg, so that i can grab the PROPERTIES from that dialog and put them in foo.config. Following the WiX tutorial at: http://www.tramontana.co.hu/wix/lesson6.php#6.10 did not really help with my senario... Any ideas? Stelios Pally Sandher wrote: If the file is installed as part of your installation you can simply use it's Id as a Property e.g. [#foo.config] if you set Id=foo.config in it's File element (see - http://msdn.microsoft.com/en-us/library/aa368609.aspx). Use that Property as the path for either XMLConfig or XMLFile to make your changes to the file. If it's put on the target machine by some other means you can locate the file using normal methods such as RegistrySearch (http://wix.sourceforge.net/manual-wix3/wix_xsd_registrysearch.htm), DirectorySearch (http://wix.sourceforge.net/manual-wix3/wix_xsd_directorysearch.htm) or FileSearch (http://wix.sourceforge.net/manual-wix3/wix_xsd_filesearch.htm) then do so to set your Property for XMLConfig/XMLFile. You will need no Custom Actions in either of these cases which should make your code much more resilient. If you can't locate the file using normal methods then a Custom Action which sets a Property containing the path to the file is your only option. How is this file installed on the target system initially? If it's by another product you can usually use a RegistrySearch to find something like the InstallLocation extrapolate the rest of the path from there. If you're really lucky the other products authors thought about this ahead of time there may be a standard registry key set by their installer for you to grab the location from. Avoid using Custom Actions unless you have no other option. Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Stelios Kyprou [mailto:stelios.kyp...@formicary.net] Sent: 07 July 2010 11:34 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Editing config files after installation Hello, I suppose this question was asked before, but i couldn't find a clear answer for it: When an installer runs on the target machine, and installs all the files in the InstallDir, i would like to carry some extra actions. -Get a config file that was installed, i.e foo.config. -Modify that file (which is in xml format), by adding some values in the key/value pairs. Now as far as i know from the search i've done, i can only do this after InstallFinalize, because that is when the files are showing in the InstallDir.? What is the ideal way of doing this? i.e: -are there built in wix methods to grab foo.config? -should i use the util:XmlFile tag for the editing? -what are the general steps for doing this process? e.g put all the steps in a custom action and call it after InstallFinalize? Thanks in advance, Stelios -- Stelios Kyprou Systems Engineer Formicary - delivering quality financial technology
[WiX-users] installer for both platforms(32 bit and 64 bit)
Can we use a single MSI installer on both platform(32 bit and 64 bit) ? -- 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] Problems launching an application on finish
On 7/7/2010 8:05 AM, Thomas Due wrote: So what is the conclusion? That what I am trying is basically impossible? MSI will not launch an elevated process except as a deferred custom action and you can't use those from the UI. -- sig://boB http://joyofsetup.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
Re: [WiX-users] wix installer is very slow.
You'd need to use a bootstrapper for that. Until Burn is done WiX doesn't have any support for this. I would recommend dotnetinstaller (http://dotnetinstaller.codeplex.com/) but other bootstrappers are widely available. Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Sanjay Rao [mailto:s...@noida.interrasystems.com] Sent: 07 July 2010 14:02 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] wix installer is very slow. -I changes product code everytime. I do not changes upgradecode. after splitting it into two msi files is there any way to combine them into single file, so that user do not need to download two files and install them separately. suppose I have two msi files 1. constant.msi 2. variable.msi I want to make a single file containing these two, which detects whether constant.msi installed or not. - if yes, do not install constant.msi. install variable.msi only. - if no install both msi files. Pally Sandher wrote: This is a known issue with *Windows Installer* patching upgrades. Windows Installer WiX are not the same thing. I'm guessing you're using Major Upgrades to upgrade (correct me if I'm wrong). Take a look at a verbose log when upgrading or uninstalling see where it's taking so long. My guess will be between CostInitialize CostFinalize since it checks what is installed before it does anything. - I want make this time down to around 10-15 minutes. What are possible schemes for that ? Install fewer files. A couple of years ago I separated our company's main product into 2 MSI's, one installs most of the files (5000+, approx 1 GB installed) but changes very very rarely. The other installs the actual application binaries other things which change with each release (1600+ files, 220 MB installed). This makes patching upgrading work much faster since there are a lot less things for Windows Installer to have to check every time a user runs a patch or upgrade. - Is there any mechanism to define force upgrade for each component ? What do you mean by force upgrade? Major Upgrades can force every component to be reinstalled regardless of the current state if you schedule RemoveExistingProducts before InstallInitialize rather than after but this brings additional considerations with regards to the Component Rules. Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Sanjay Rao [mailto:s...@noida.interrasystems.com] Sent: 07 July 2010 11:20 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] wix installer is very slow. Hi All, I have a installer which installs large number of files(~5 files). It takes a lot of time to install. However it's installation time is tolerable. But while upgrading it takes intolerable amount of time(more than 1 hour sometimes). It also takes lot of time(1 hour) in un installation. - I want make this time down to around 10-15 minutes. What are possible schemes for that ? - Is there any mechanism to define force upgrade for each component ? Regards, Sanjay Rao -- -- -- 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
Re: [WiX-users] installer for both platforms(32 bit and 64 bit)
An x86 MSI will install on x86 x64 platforms. An x64 MSI will only install on x64 platforms. You cannot write to x64 locations in an x86 MSI. Windows Installer simply does not support it will stop you in your tracks if you even try it. Essentially your question is far too vague for a simple answer. Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Sanjay Rao [mailto:s...@noida.interrasystems.com] Sent: 07 July 2010 14:08 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] installer for both platforms(32 bit and 64 bit) Can we use a single MSI installer on both platform(32 bit and 64 bit) ? -- 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] wix installer is very slow.
after splitting it into two msi files is there any way to combine them into single file You'll need to use a bootstrapper program to achieve this. The bootstrapper would package up both MSIs, check to see if constant.msi is already installed (and install it if not), then install variable.msi. Kind regards Alastair Smith -Original Message- From: Sanjay Rao [mailto:s...@noida.interrasystems.com] Sent: 07 July 2010 14:02 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] wix installer is very slow. -I changes product code everytime. I do not changes upgradecode. after splitting it into two msi files is there any way to combine them into single file, so that user do not need to download two files and install them separately. suppose I have two msi files 1. constant.msi 2. variable.msi I want to make a single file containing these two, which detects whether constant.msi installed or not. - if yes, do not install constant.msi. install variable.msi only. - if no install both msi files. Pally Sandher wrote: This is a known issue with *Windows Installer* patching upgrades. Windows Installer WiX are not the same thing. I'm guessing you're using Major Upgrades to upgrade (correct me if I'm wrong). Take a look at a verbose log when upgrading or uninstalling see where it's taking so long. My guess will be between CostInitialize CostFinalize since it checks what is installed before it does anything. - I want make this time down to around 10-15 minutes. What are possible schemes for that ? Install fewer files. A couple of years ago I separated our company's main product into 2 MSI's, one installs most of the files (5000+, approx 1 GB installed) but changes very very rarely. The other installs the actual application binaries other things which change with each release (1600+ files, 220 MB installed). This makes patching upgrading work much faster since there are a lot less things for Windows Installer to have to check every time a user runs a patch or upgrade. - Is there any mechanism to define force upgrade for each component ? What do you mean by force upgrade? Major Upgrades can force every component to be reinstalled regardless of the current state if you schedule RemoveExistingProducts before InstallInitialize rather than after but this brings additional considerations with regards to the Component Rules. Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Sanjay Rao [mailto:s...@noida.interrasystems.com] Sent: 07 July 2010 11:20 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] wix installer is very slow. Hi All, I have a installer which installs large number of files(~5 files). It takes a lot of time to install. However it's installation time is tolerable. But while upgrading it takes intolerable amount of time(more than 1 hour sometimes). It also takes lot of time(1 hour) in un installation. - I want make this time down to around 10-15 minutes. What are possible schemes for that ? - Is there any mechanism to define force upgrade for each component ? Regards, Sanjay Rao -- -- -- 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 --
Re: [WiX-users] installer for both platforms(32 bit and 64 bit)
Okie... simple and direct question what is the default value of 'platform' attribute in Package element ? Thanks for all your help. Pally Sandher wrote: An x86 MSI will install on x86 x64 platforms. An x64 MSI will only install on x64 platforms. You cannot write to x64 locations in an x86 MSI. Windows Installer simply does not support it will stop you in your tracks if you even try it. Essentially your question is far too vague for a simple answer. Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Sanjay Rao [mailto:s...@noida.interrasystems.com] Sent: 07 July 2010 14:08 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] installer for both platforms(32 bit and 64 bit) Can we use a single MSI installer on both platform(32 bit and 64 bit) ? -- 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] Tools to generate WiX installer from a snapshot of an installation
Are there tools to monitor an installation and then generate a WiX-compatible project/wxs? An example of the need for this is to monitor the execution of an old installer that is not in MSI format with a goal to convert that installation to a WiX project which can be used to generate an MSI installer. This would be especially helpful in the conversion from old installer technologies to the latest MSI. I'm not thinking about probing the installer (there are probably hundreds of different installers out there), but actually monitoring the target system for registry changes, file drops, COM registrations, etc. -- 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] installer for both platforms(32 bit and 64 bit)
Short answer.no. But if you just need a single installer, look into using a bootstrapper which can run either your 32-bit or your 64-bit MSI depending on the environment it's being installed into. On 07/07/2010 09:07 AM, Sanjay Rao wrote: Can we use a single MSI installer on both platform(32 bit and 64 bit) ? -- 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] installer for both platforms(32 bit and 64 bit)
Depends what you select for platform when you build your MSI. Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Sanjay Rao [mailto:s...@noida.interrasystems.com] Sent: 07 July 2010 15:09 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] installer for both platforms(32 bit and 64 bit) Okie... simple and direct question what is the default value of 'platform' attribute in Package element ? Thanks for all your help. Pally Sandher wrote: An x86 MSI will install on x86 x64 platforms. An x64 MSI will only install on x64 platforms. You cannot write to x64 locations in an x86 MSI. Windows Installer simply does not support it will stop you in your tracks if you even try it. Essentially your question is far too vague for a simple answer. Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Sanjay Rao [mailto:s...@noida.interrasystems.com] Sent: 07 July 2010 14:08 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] installer for both platforms(32 bit and 64 bit) Can we use a single MSI installer on both platform(32 bit and 64 bit) ? -- -- -- 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] 64 bit app installing in Program Files (x86) folder
Thanks Bob, How would I have to set APPLICATIONDIR then? I tried: SetDirectory Id=APPLICATIONFOLDER Value=[ProgramFiles64Folder] / Cordialement / Best regards, Gernot -Message d'origine- De : Bob Arnson [mailto:b...@joyofsetup.com] Envoyé : Wednesday, July 07, 2010 2:42 PM À : wix-users@lists.sourceforge.net Objet : Re: [WiX-users] 64 bit app installing in Program Files (x86) folder On 7/7/2010 7:50 AM, Gernot Kerger wrote: I modified WixAdvancedSample.wxs to build for 64 bit arch. Unfortunately, it's installing on the 32 Program files folder: Known bug with workaround: https://sourceforge.net/tracker/?func=detailaid=2793021group_id=105970atid=642714 -- sig://boB http://joyofsetup.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] Tools to generate WiX installer from a snapshot of aninstallation
dark.exe can decompile an existing MSI but the output from it is overly complex includes everything in every table in the MSI (including UI which often you don't want/need as the WiX UI will be more than sufficient). It also doesn't clean up the code it decompiles so you will find a lot of RegistryKey/RegistryValue entries for stuff which is done in other ways in WiX which you'll need to do yourself. Another way you could decompile an MSI would be to run an administrative install then use heat.exe on the extracted binaries. You'd still need to look at the MSI somehow to find out what the non-file related changes it makes to the system are. If it's not an MSI then you need some way of either converting it to an MSI or harvesting the information. If I had to, I would get a clean VM, install the app then diff system against your known baseline. You can diff the registry using regshot (see - http://sourceforge.net/projects/regshot/) to see what changes it makes to the registry as normal diff tools tend to only concern themselves with files folders. Stuff like COM Registration you don't want to know about from the installer, heat.exe will generate code for you far quicker cleaner. Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Thorpe, Alan [mailto:atho...@bottomline.com] Sent: 07 July 2010 14:39 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Tools to generate WiX installer from a snapshot of aninstallation Are there tools to monitor an installation and then generate a WiX-compatible project/wxs? An example of the need for this is to monitor the execution of an old installer that is not in MSI format with a goal to convert that installation to a WiX project which can be used to generate an MSI installer. This would be especially helpful in the conversion from old installer technologies to the latest MSI. I'm not thinking about probing the installer (there are probably hundreds of different installers out there), but actually monitoring the target system for registry changes, file drops, COM registrations, etc. -- 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] Recursively install directory and subdirs/files to a folder
Hi, I have an installer that is supposed to include installing a group of customer specific documents. I would like to install the root directory of this document tree, which will copy all subdirectories and files to a specific folder on the target device. I do not want to itemize each file and subdir in my wxs file. Is there a way to recursively install a directory? I found a few references to using heat. I tried that out, which seems to generate a wxs fragment with the proper list of files and subdirs. So perhaps that can be integrated into my automated build, but how are builds are setup, using heat doesn't quite fit into our scheme. I'd rather just be able to specify, in the wxs file to install RootDirectory\*.* to DestDirectory. Can I do this? I'm using Wix 3.0.5419.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
Re: [WiX-users] Component Level Versioning?
You can use companion files to force your non-versioned files to update properly. http://msdn.microsoft.com/en-us/library/aa367997(VS.85).aspx You'll have to manage the companion relationship between the non-versioned files you want to update and the versioned file you are referencing. This allows you to update your non-versioned files and follow component rules/file versioning rules. -Mike -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Component-Level-Versioning-tp5233488p5265808.html Sent from the wix-users mailing list archive at Nabble.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
Re: [WiX-users] error 2725 installer patch using binary diff
On 7/6/2010 2:51 AM, Matt Sullivan wrote: Does anyone know why building a patch that uses a binary diff would fail with error 2725 (invalid database tables) when the exact same patch built without works fine? There was a bug in delta patching recently fixed in WiX v3.5. Try the latest drop and see if the problem still repros. -- sig://boB http://joyofsetup.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
Re: [WiX-users] Recursively install directory and subdirs/files to afolder
Doesn't matter which version of WiX you're using, it's not possible using Windows Installer. heat.exe or some other custom solution in your build process will be required. If you're using Windows Installer, you have to explicitly list each file directory you want to create on the target machine. Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Beth Hechanova [mailto:bhechan...@imsco-us.com] Sent: 07 July 2010 16:21 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Recursively install directory and subdirs/files to afolder Hi, I have an installer that is supposed to include installing a group of customer specific documents. I would like to install the root directory of this document tree, which will copy all subdirectories and files to a specific folder on the target device. I do not want to itemize each file and subdir in my wxs file. Is there a way to recursively install a directory? I found a few references to using heat. I tried that out, which seems to generate a wxs fragment with the proper list of files and subdirs. So perhaps that can be integrated into my automated build, but how are builds are setup, using heat doesn't quite fit into our scheme. I'd rather just be able to specify, in the wxs file to install RootDirectory\*.* to DestDirectory. Can I do this? I'm using Wix 3.0.5419.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] Recursively install directory and subdirs/files to a folder
-Original Message- From: Beth Hechanova [mailto:bhechan...@imsco-us.com] I found a few references to using heat. I tried that out, which seems to generate a wxs fragment with the proper list of files and subdirs. So perhaps that can be integrated into my automated build, but how are builds are setup, using heat doesn't quite fit into our scheme. What is your scheme? I use heat all the time by simply integrating its use directly into the *.wixproj file since it's just a MSBuild file. I typically override the BeforeCompileAndLink target and use the HeatDirectory task provided by WiX. Unfortunately, the HeatDirectory task is not documented so I usually use reflector to determine what the available properties are. If you can provide some details of your build scheme then I can try to help automate the execution of heat in your scheme. 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 -- 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] Recursively install directory and subdirs/files toa folder
My automated build uses cruisecontrol.net, nant, and candle/light to build my installer via the .wxs file. I do not have a .wixproj file. My application has two different installs - one for the application code (executable, dlls), which will be used by all customers. The other installer is not the application code, but miscellaneous files (docs, icons/images, configuration data, and perhaps other applications) - this is customer specific. Right now, we manage all this customer specific data, but outside the realm of our application, so it has a separate installer. The short answer on the build scheme is prior to a build, all source (this includes the .wxs file) is tagged (svn is our source control), then extracted to a new directory for the build. If our build dynamically generates the wxs file, then it is no longer a static source file to be tagged at the beginning of the build, but instead more of a build product. This might be ok, I just have to determine if this is what we want to do. The goal is to be able to recreate the build products at any time from our source control for a given version, so as long as that goal is met, perhaps we don't need to specifically tag the wxs file. But it seems like we wouldn't want a mixture of specifying some files in the wxs file, and dynamically generating others. I don't really know too much about heat - I just tried a quick test as I found references to using it to do what I want. I'm wondering though if this data (at least some of it), belongs in an installer. At least for the document tree, upon an uninstall, we want to remove the root directory and everything below, regardless of whether or not it was contained in the original install. This may seem incorrect, but those are the requirements. From a previous post, it does not seem like this is possible, at least via the .wxs file - I need to use heat to generate the file list, or copy these files outside of using wix. Thanks, Beth -Original Message- From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com] Sent: Wednesday, July 07, 2010 9:44 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Recursively install directory and subdirs/files toa folder -Original Message- From: Beth Hechanova [mailto:bhechan...@imsco-us.com] I found a few references to using heat. I tried that out, which seems to generate a wxs fragment with the proper list of files and subdirs. So perhaps that can be integrated into my automated build, but how are builds are setup, using heat doesn't quite fit into our scheme. What is your scheme? I use heat all the time by simply integrating its use directly into the *.wixproj file since it's just a MSBuild file. I typically override the BeforeCompileAndLink target and use the HeatDirectory task provided by WiX. Unfortunately, the HeatDirectory task is not documented so I usually use reflector to determine what the available properties are. If you can provide some details of your build scheme then I can try to help automate the execution of heat in your scheme. 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 -- 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 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
Re: [WiX-users] Unresolved reference to symbol'Directory:SystemFolder'in section 'fragment:'
Actually I think what needs to be done is to add the -svb6 option to
heat's command line. The items that are asking for the SystemFolder happen
to be related to the VB6 runtime.
-Original Message-
From: Pally Sandher [mailto:pally.sand...@iesve.com]
Sent: Wednesday, July 07, 2010 4:57 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Unresolved reference to
symbol'Directory:SystemFolder'in section 'fragment:'
Change the HelpDirectory attributes for the TypeLibs in the pasted code
which point at SystemFolder to point somewhere else such as
dir07B00FE80C030860241E2DB3BAF7AE7D (that's an example, might not be
correct for your COM DLL's).
heat.exe generates sample code, you shouldn't expect to be able to use
it blindly without checking it's generating something sensible (even
though many people do on a regular basis).
Also you may want to run heat.exe with the -suid flag so you get more
readable directory file identifiers than
dir07B00FE80C030860241E2DB3BAF7AE7D.
Palbinder Sandher
Software Deployment IT Administrator
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
http://www.iesve.com
**Design, Simulate + Innovate with the Virtual Environment**
Integrated Environmental Solutions Limited. Registered in Scotland No.
SC151456 Registered Office - Helix Building, West Of Scotland Science
Park, Glasgow G20 0SP Email Disclaimer
-Original Message-
From: subrat agasti [mailto:subrat.w...@gmail.com]
Sent: 07 July 2010 12:16
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Unresolved reference to
symbol'Directory:SystemFolder'in section 'fragment:'
Hi,
I am very new to WIX. When i am trying to create an msi i am getting the
following error.
Unresolved reference to symbol 'Directory:SystemFolder'in section
'fragment:'
I have created the .wxs file using heat.exe. I know that there is no
systemFolder diretory in my directory structure.
But why did Heat generated this folder and how do i resolve this error?
Below is the fragment that is causing the problem
Fragment
DirectoryRef Id=dir07B00FE80C030860241E2DB3BAF7AE7D
Component Id=cmp40CE54724631208ADA05F65F4A51 Guid=
{0C99C0B5-F531-4AA0-8E18-F5FCA74793DA}
Class Id={D5DE8D20-5BB8-11D1-A1E3-00A0C90F2731}
Context=InprocServer32
Description=VBPropertyBag ThreadingModel=apartment ForeignServer=
msvbvm60.dll /
File Id=filC9B10037678695297E47AA93580CE72C KeyPath=yes Source=
..\..\Monarch.Client\EFI.Binaries\SetMonarchWin.dll
TypeLib Id={60AD7F4B-F1E9-47B5-B6D5-C4373D5F9C2B} Description=
SetMonarchWin HelpDirectory=dir07B00FE80C030860241E2DB3BAF7AE7D
Language= 0 MajorVersion=17 MinorVersion=0
Class Id={5BA8949F-EE19-4FD9-B4D1-99A842DA5C0F}
Context=InprocServer32
Description=SetMonarchWin.SetWinProp ThreadingModel=apartment
Version=
17.0 Programmable=yes
ProgId Id=SetMonarchWin.SetWinProp
Description=SetMonarchWin.SetWinProp/
/Class
Interface Id={B863F088-9246-420E-8570-06BBD57C0866} Name=SetWinProp
ProxyStubClassId={00020424---C000-0046}
ProxyStubClassId32 ={00020424---C000-0046} /
/TypeLib
TypeLib Id={000204EF---C000-0046} Description=Visual
Basic For Applications HelpDirectory=SystemFolder Language=9
MajorVersion=6 MinorVersion=0
Interface Id={A4C466B8-499F-101B-BB78-00AA00383CBB} Name=_ErrObject
ProxyStubClassId={00020424---C000-0046}
ProxyStubClassId32 ={00020424---C000-0046} /
Interface Id={A4C46780-499F-101B-BB78-00AA00383CBB}
Name=_Collection
ProxyStubClassId={00020424---C000-0046}
ProxyStubClassId32 ={00020424---C000-0046} /
/TypeLib
TypeLib Id={EA544A21-C82D-11D1-A3E4-00A0C90AEA82} Description=Visual
Basic runtime objects and procedures HelpDirectory=SystemFolder
Hidden=
yes Language=9 MajorVersion=6 MinorVersion=0
Interface Id={14E469E0-BF61-11CF-8385-8F69D8F1350B} Name=
AsyncProperty_VB5
ProxyStubClassId={00020424---C000-0046}
ProxyStubClassId32={00020424---C000-0046} /
Interface Id={2CE46480-1A08-11CF-AD63-00AA00614F3E} Name=
SelectedControls
ProxyStubClassId={00020424---C000-0046}
ProxyStubClassId32={00020424---C000-0046} /
Interface Id={41A7D760-6018-11CF-9016-00AA0068841E} Name=DataObject
ProxyStubClassId={00020424---C000-0046}
ProxyStubClassId32 ={00020424---C000-0046} /
Interface Id={41A7D761-6018-11CF-9016-00AA0068841E}
Name=DataObjectFiles
ProxyStubClassId={00020424---C000-0046}
ProxyStubClassId32={00020424---C000-0046} /
Interface Id={4495AD01-C993-11D1-A3E4-00A0C90AEA82}
Name=_PropertyBag
ProxyStubClassId={00020424---C000-0046}
ProxyStubClassId32 ={00020424---C000-0046} /
Interface Id={45046D60-08CA-11CF-A90F-00AA0062BB4C}
Name=PropertyBag_VB5
ProxyStubClassId={00020424---C000-0046}
ProxyStubClassId32={00020424---C000-0046} /
Interface
Re: [WiX-users] Require reboot before re-installation
Hi, Does the driver uninstall put an entry into PendingFileRenameOperations in the registry? http://technet.microsoft.com/en-us/library/cc960241.aspx If so you could check this key is clean before running the install, I have implmemented this in the past. Dave -Original Message- From: Samuel Larsen [mailto:slar...@vmware.com] Sent: 07 July 2010 17:55 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Require reboot before re-installation Could someone suggest a method for forcing a reboot after an uninstall before another install is permitted? I have the following problem: My installer installs a device driver. An uninstall correctly removes the driver from the filesystem. If I re-install before rebooting, the re-installation seems to go smoothly and the driver is re-installed. On the next reboot, however, it looks like the driver is removed from the filesystem, which ultimately causes a crash. I don't understand the mechanism for this deletion. It seems that the uninstall marks the file for delete on the next boot and this 'flag' is not cleared when the file is replaced during the installation. One workaround would be to prevent re-installation after uninstall until there is a reboot. Can anyone offer any advice? thanks, - Sam -- 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 /pre BR style=font-size:4px; a href = http://www.sdl.com;img src=http://www.sdl.com/images/email logo_150dpi-01.png alt=www.sdl.com border=0//a BR font face=arial size=2 a href = http://www.sdl.com; style=color:005740; font-weight: boldwww.sdl.com/a BR BR font face=arial size=1 color=#736F6E bSDL PLC confidential, all rights reserved./b If you are not the intended recipient of this mail SDL requests and requires that you delete it without acting upon or copying any of its contents, and we further request that you advise us.BR SDL PLC is a public limited company registered in England and Wales. Registered number: 02675207.BR Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK. /font -- 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] Recursively install directory and subdirs/files toa folder
When I generate wxs sources using heat I treat it as a build product. I do not keep the generated file in source control. I dynamically add the generated file to the ItemGroup that contains the wxs source files to compile. An ItemGroup is similar in concept to a fileset in NAnt. I personally believe that tagging should be performed _after_ a successful build especially when you have a source control system that only allows atomic commits (such as subversion). You can always track back to the specific commit you checked out and tag that specific commit upon successful builds if you need a different way to refer to the source code used in a particular build... but that's unrelated to WiX so I'll just leave it at that. If you guys decide that heat generation is consistent enough for your purposes then I would simply recommend that you do not keep the generated wxs source in source control as it really is a build product. As long as the contents of the directory that is getting harvested can be reproduced exactly then you can generate the corresponding wxs source correctly. 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: Beth Hechanova [mailto:bhechan...@imsco-us.com] Sent: Wednesday, July 07, 2010 10:13 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Recursively install directory and subdirs/files toa folder My automated build uses cruisecontrol.net, nant, and candle/light to build my installer via the .wxs file. I do not have a .wixproj file. My application has two different installs - one for the application code (executable, dlls), which will be used by all customers. The other installer is not the application code, but miscellaneous files (docs, icons/images, configuration data, and perhaps other applications) - this is customer specific. Right now, we manage all this customer specific data, but outside the realm of our application, so it has a separate installer. The short answer on the build scheme is prior to a build, all source (this includes the .wxs file) is tagged (svn is our source control), then extracted to a new directory for the build. If our build dynamically generates the wxs file, then it is no longer a static source file to be tagged at the beginning of the build, but instead more of a build product. This might be ok, I just have to determine if this is what we want to do. The goal is to be able to recreate the build products at any time from our source control for a given version, so as long as that goal is met, perhaps we don't need to specifically tag the wxs file. But it seems like we wouldn't want a mixture of specifying some files in the wxs file, and dynamically generating others. I don't really know too much about heat - I just tried a quick test as I found references to using it to do what I want. I'm wondering though if this data (at least some of it), belongs in an installer. At least for the document tree, upon an uninstall, we want to remove the root directory and everything below, regardless of whether or not it was contained in the original install. This may seem incorrect, but those are the requirements. From a previous post, it does not seem like this is possible, at least via the .wxs file - I need to use heat to generate the file list, or copy these files outside of using wix. Thanks, Beth -Original Message- From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com] Sent: Wednesday, July 07, 2010 9:44 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Recursively install directory and subdirs/files toa folder -Original Message- From: Beth Hechanova [mailto:bhechan...@imsco-us.com] I found a few references to using heat. I tried that out, which seems to generate a wxs fragment with the proper list of files and subdirs. So perhaps that can be integrated into my automated build, but how are builds are setup, using heat doesn't quite fit into our scheme. What is your scheme? I use heat all the time by simply integrating its use directly into the *.wixproj file since it's just a MSBuild file. I typically override the BeforeCompileAndLink target and use the HeatDirectory task provided by WiX. Unfortunately, the HeatDirectory task is not documented so I usually use reflector to determine what the available properties are. If you can provide some details of your build scheme then I can try to help automate the execution of heat in your scheme. 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
Re: [WiX-users] Dynamic directory creation
My recommendation would be to add an immediate custom action in the InstallExecuteSequence table before CostInitialize that adds temporary rows to the DuplicateFile table and temporary rows to the Directory table. You would also need the following authoring: InstallExecuteSequence DuplicateFiles/ /InstallExecuteSequence EnsureTable Id=DuplicateFile/ You should also save the parameters for your custom action so that they can be retrieved when repairing or uninstalling so your dynamic directories can be cleaned up/upgraded as appropriate. See http://www.joyofsetup.com/2007/07/01/semi-custom-actions/ for the concept of using native functionality to do non-native things. This tends to be much more authorable and reliable than trying to implement deferred actions and getting rollback, etc. working in every case of repair, install, removal, both kinds of upgrade, etc. Such an immediate action can be tested using Lux as well, so you get testability as a bonus. -Original Message- From: Keith Hassen [mailto:keith.has...@gmail.com] Sent: Wednesday, July 07, 2010 6:03 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Dynamic directory creation Hi, I am faced with a problem of building an MSI that requires a set of directories to be created during installation. These directories are all prefixed with a common string (eg folder) followed by a sequence number (eg 01) so that their final construction might be something like folder01, folder02, etc. I need to place the same executable in each of these generated directories, but the number of directories isn't known until install time. I would like to prompt the user for that number during the setup and then dynamically build the directories. My original assumption was that WiX simply couldn't do this task because of the dynamic nature of the problem. I assumed that I'd have to write a batch script that would do this work for me: my approach was to always generate 1 directory, and then use a CA to invoke a batch script that would copy the directory as many times as was needed. I thought I'd post this problem to this list to see if there were other solutions (using WiX or otherwise) that might be cleaner or more effective. Keith -- 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] DTF limit on number of CA EntryPoints?
I ran into the following error today with a DTF Custom Action assembly I am working on. The custom action assembly has 17 entrypoints, which is more than the maximum (16). Refactor the custom actions or add more entrypoint slots in SfxCA\EntryPoints.h. I grabbed the latest copy of the 3.5 source code and was able to fix this by adding 16 more entries, but I wanted to see if the limit of 16 was a random choice, or is there a reason behind it? Would there be any problem upping the limit to something much higher like 128? I'd prefer to not have to maintain our own fork of the DTF tools just for this, but having to split out multiple projects to provide custom actions doesn't make much sense to me unless I'm missing a real problem with having too many in one assembly. Thanks, Rob. _ The New Busy is not the too busy. Combine all your e-mail accounts with Hotmail. http://www.windowslive.com/campaign/thenewbusy?tile=multiaccountocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_4 -- 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] Setting permissions on a Directory element
Is there a way to set permissions on a Directory element. I know there's a CreateFolder element, but the folder will be created already as part of the installation. It doesn't seem like there's an obvious way to do this... (Basically my scenario is that I need to set some permissions on my web root to allow write access.) Thanks, Alec -- 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] DTF limit on number of CA EntryPoints?
If you write an immediate custom action to schedule deferred and rollback actions, then you've already used up 3 slots right there for one logical custom action. Add an equivalent set of 3 actions for uninstall and you've consumed a total of 6 slots for a single logical operation pair. I personally hope that 16 was only an arbitrary choice and that it can be increased to a much higher number. Luckily I've been fortunate enough to get away with much simpler one-off custom actions thus far... 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: Rob McCready [mailto:rmccready...@hotmail.com] Sent: Wednesday, July 07, 2010 2:30 PM To: WiX-users Subject: [WiX-users] DTF limit on number of CA EntryPoints? I ran into the following error today with a DTF Custom Action assembly I am working on. The custom action assembly has 17 entrypoints, which is more than the maximum (16). Refactor the custom actions or add more entrypoint slots in SfxCA\EntryPoints.h. I grabbed the latest copy of the 3.5 source code and was able to fix this by adding 16 more entries, but I wanted to see if the limit of 16 was a random choice, or is there a reason behind it? Would there be any problem upping the limit to something much higher like 128? I'd prefer to not have to maintain our own fork of the DTF tools just for this, but having to split out multiple projects to provide custom actions doesn't make much sense to me unless I'm missing a real problem with having too many in one assembly. Thanks, Rob. _ The New Busy is not the too busy. Combine all your e-mail accounts with Hotmail. http://www.windowslive.com/campaign/thenewbusy?tile=multiaccountocid=PID28326 ::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_4 -- 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] Setting permissions on a Directory element
Use CreateFolder. It doesn't hurt anything to ask for a folder to be created that will be created anyway. -Original Message- From: Alec Siu [mailto:alec@microsoft.com] Sent: Wednesday, July 07, 2010 2:37 PM To: WiX Users List (wix-users@lists.sourceforge.net) Subject: [WiX-users] Setting permissions on a Directory element Is there a way to set permissions on a Directory element. I know there's a CreateFolder element, but the folder will be created already as part of the installation. It doesn't seem like there's an obvious way to do this... (Basically my scenario is that I need to set some permissions on my web root to allow write access.) Thanks, Alec -- 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] Applying transform from a Custom Action
Hi All, Is there a way to apply a transform during package installation (using custom action, for example). Or how can I change msi tables during runtime (during installation). p.s. I understand this is not directly a wix related question, I will appreciate any response. Thanks. Best Regards, Gulfam Murad -- 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] Applying transform from a Custom Action
You can add temporary rows with a custom action. That and setting Properties are the only mutations allowed that I'm aware of. On Wed, Jul 7, 2010 at 8:15 PM, gulfam murad gulfam.mu...@gmail.com wrote: Hi All, Is there a way to apply a transform during package installation (using custom action, for example). Or how can I change msi tables during runtime (during installation). p.s. I understand this is not directly a wix related question, I will appreciate any response. Thanks. Best Regards, Gulfam Murad -- 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 -- virtually, Rob Mensching - http://RobMensching.com LLC -- 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] Go back to previous version
Any body have any idea about this ? Sanjay Rao wrote: If I put files in CommonAppData, In that case also files generated by newer version are not valid for older version. Is there any way to backup older files/setting up a restore point for a particular directory. Pally Sandher wrote: Then your installer should've been written with cleaning up those files in mind before you released it and/or those files which need modified after install shouldn't be held in the installation directory if it's a per-machine installation, they should be in CommonAppData or somewhere similar as per Microsoft's guidelines. Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Sanjay Rao [mailto:s...@noida.interrasystems.com] Sent: 07 July 2010 12:40 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Go back to previous version but my newer version of application generates/modifies some files in installation directory at target machine which may not be appropriate for older version. These files not present in installer. these files are generated when application runs after installation. I want these files also in previous state. I want to go to the previous state of the installation directory. Pally Sandher wrote: WiX != Windows Installer. You would do well not to confuse them or use them interchangeably. If you're using Major Upgrade functionality remove the Upgrade table entries and/or your Launch Condition which block installing an older version. If you're not using Major Upgrade functionality, educate your users on the use of Add/Remove Control Panel (Programs Features in Vista Win7). Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Sanjay Rao [mailto:s...@noida.interrasystems.com] Sent: 07 July 2010 11:34 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Go back to previous version Hi, We use msi installer for our software and we are using WIX toolset for that. After upgrading to newer version of our software sometimes users of our software does not find themselves convenient with new version and they want to go back to previous version. Is there any mechanism in WIX for go back to previously installed version of software. Regards, Sanjay Rao -- -- -- 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
Re: [WiX-users] Applying transform from a Custom Action
Thanks Rob! So, if we used embedded language transforms to support MUI ( http://www.installsite.org/pages/en/msi/articles/embeddedlang/). And there is a bug in one of the language transforms (e.g. ServiceInstall table has some wrong information), what are my options to resolve this issue? Thanks a lot. Best Regards, Gulfam Murad On Thu, Jul 8, 2010 at 12:45 AM, Rob Mensching r...@robmensching.com wrote: You can add temporary rows with a custom action. That and setting Properties are the only mutations allowed that I'm aware of. On Wed, Jul 7, 2010 at 8:15 PM, gulfam murad gulfam.mu...@gmail.com wrote: Hi All, Is there a way to apply a transform during package installation (using custom action, for example). Or how can I change msi tables during runtime (during installation). p.s. I understand this is not directly a wix related question, I will appreciate any response. Thanks. Best Regards, Gulfam Murad -- 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 -- virtually, Rob Mensching - http://RobMensching.com LLC -- 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 -- HasbonAllah hu wa nae'mal wakeel -- 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
