Re: [WiX-users] Validation on UI dialogs
It is not really related to your question, but I had a question about popup message box from custom action and I got an answer from Bob Arnson: Set a property in the CA and use that property as the condition in a SpawnDialog control event to show a message box. Never show UI from a CA; there's no way to get the same UI level information that MSI uses to determine whether UI should be shown. So probably try to change not to popup message box from CA, but SpawnDialog (new dialog?) from installer UI and maybe after closing it, you will have a correct focus. -Original Message- From: Richard [mailto:legal...@xmission.com] Sent: Thursday, December 10, 2009 12:12 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Validation on UI dialogs In article 481222.60726...@web30401.mail.mud.yahoo.com, Sankaranarayanan loony...@yahoo.com writes: For validating the fields in Custom UI for empty / null values - I am calling a Custom action on DoAction event of the Next Button and spawing a new dialo g if all the input values are correctly entered. Incase of any blank values - I popup a message box from the custom action cod e to notify the user but I am not able to set the focus back to the erroring fi eld. Is there a way to set the focus from the Next Button to the erroring field fr om the Custom action code. You have several choices. First, you can rearrange things with one required field per dialog so that its always clear which field needs a value. Second, you can keep all the fields on the same dialog, but not enable the Next button until all the requirements are met (control properties are not empty) and use a text control (initially showing no text) that holds the error message. An additional text control can be placed next to the offending fields so that an asterisk or other marker can be displayed next to fields needing attention. Your DoAction on the next button will probably need to work around the fact that Windows Installer doesn't recognize property changes correctly inside a DoAction attached to a button. See my blog post on UI custom action guidelines: http://legalizeadulthood.wordpress.com/2009/10/23/ui-custom-action-guid elines/ -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/ Legalize Adulthood! http://legalizeadulthood.wordpress.com -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users SDL PLC confidential, all rights reserved. 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. SDL PLC is a public limited company registered in England and Wales. Registered number: 02675207. Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to specify files in Installer package
Hi Rob! Do you mean, that you use xslt to modify the heat-generated wxs files in an automated way? Can you give me an example for that? br, Markus On Dec 9, Rob Mensching r...@robmensching.com wrote: I usually just write an XSL transform. heat supports that. On Wed, Dec 9, 2009 at 9:45 PM, Blair os...@live.com wrote: Two ideas that come to mind: One is to use msbuild to call heat (or some other system that can calculate a list of files given an exclusion pattern) and the other is to write an extension to heat. -Original Message- From: Markus Gaugusch [mailto:w...@gaugusch.at] Sent: Wednesday, December 09, 2009 12:56 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] How to specify files in Installer package Hi Blair! Those directories contain many files and I don't want to specify them by hand. And if I want to ignore .svn directories, I'm fully out of luck. Additionally, I tried to split up my project into several trees like that: - framework\bin (common binary files, xml schema, ...) - framework\config (common config files) - frameworkexe\bin (common executables) - project\bin (project specific xml files, config files ...) - project\config (project specific configuration files) - projectexe\bin (project specific exe files) They should all go into ...\bin and ...\config on the destination machine. Unfortunately, the bin and config directories would conflict when I run light.exe because they have the same name and heat generates the same component id for both of them (which is ok because they are he same directory on the destination machine). If I could tell heat to use an existing reference for some directories and create the others, it might also work, but I think this is not a clean solution. So, if I want to use heat.exe, I need to use a single tree of source files or split my project into parts that have no common directories at all (which does not meet my requirements). To solve my problems I can only imagine to use a single source tree for the installer package and tell heat to ignore certain files and take all others. Or do you have a better idea? Thanks! Markus On Dec 9, Blair os...@live.com wrote: Can you call heat per-file instead of per-dir for those directories? -Original Message- From: Markus Gaugusch [mailto:w...@gaugusch.at] Sent: Wednesday, December 09, 2009 1:47 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] How to specify files in Installer package Hi, I'm using WIX3 and try to make an installer package for our software. The software contains lots of files and folders, and some of them have to be treated specially (one for installing a Windows Service, several config files which should be preserved). Now I'm using heat to generate the list of files for my package, but I don't want to edit the generated content in order to specify my service or config files. At the moment I remove those files from heat generated code and have them in another file. But this is a manual and error-prone process. I'd like to tell heat to ignore some files and generate the wxs file for everything else. This is especially interesting because I'm using subversion and I can't checkout the files for my installer packages in the usual way, because heat would include the .svn directories. I've added a tracker entry, but there was no reaction yet. https://sourceforge.net/tracker/?func=detailaid=2900555group_id=105970ati d=642717 Comments? thanks, Markus -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- __/\ Markus Gaugusch \ /ASCII Ribbon Campaign markus(at)gaugusch.at X Against HTML Mail / \ -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to specify files in Installer package
Markus, The heat.exe has a switch -t:transform.xsl. If you specify this switch running heat, the 'transform.xsl' will be applied to the regular output of you heat command. The final resulting wxs file will contain transformed xml. There are no special requirements for that XSL transform. Hope this helps, -- Yan -Original Message- From: Markus Gaugusch [mailto:w...@gaugusch.at] Sent: Thursday, December 10, 2009 10:22 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How to specify files in Installer package Hi Rob! Do you mean, that you use xslt to modify the heat-generated wxs files in an automated way? Can you give me an example for that? br, Markus On Dec 9, Rob Mensching r...@robmensching.com wrote: I usually just write an XSL transform. heat supports that. On Wed, Dec 9, 2009 at 9:45 PM, Blair os...@live.com wrote: Two ideas that come to mind: One is to use msbuild to call heat (or some other system that can calculate a list of files given an exclusion pattern) and the other is to write an extension to heat. -Original Message- From: Markus Gaugusch [mailto:w...@gaugusch.at] Sent: Wednesday, December 09, 2009 12:56 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] How to specify files in Installer package Hi Blair! Those directories contain many files and I don't want to specify them by hand. And if I want to ignore .svn directories, I'm fully out of luck. Additionally, I tried to split up my project into several trees like that: - framework\bin (common binary files, xml schema, ...) - framework\config (common config files) - frameworkexe\bin (common executables) - project\bin (project specific xml files, config files ...) - project\config (project specific configuration files) - projectexe\bin (project specific exe files) They should all go into ...\bin and ...\config on the destination machine. Unfortunately, the bin and config directories would conflict when I run light.exe because they have the same name and heat generates the same component id for both of them (which is ok because they are he same directory on the destination machine). If I could tell heat to use an existing reference for some directories and create the others, it might also work, but I think this is not a clean solution. So, if I want to use heat.exe, I need to use a single tree of source files or split my project into parts that have no common directories at all (which does not meet my requirements). To solve my problems I can only imagine to use a single source tree for the installer package and tell heat to ignore certain files and take all others. Or do you have a better idea? Thanks! Markus On Dec 9, Blair os...@live.com wrote: Can you call heat per-file instead of per-dir for those directories? -Original Message- From: Markus Gaugusch [mailto:w...@gaugusch.at] Sent: Wednesday, December 09, 2009 1:47 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] How to specify files in Installer package Hi, I'm using WIX3 and try to make an installer package for our software. The software contains lots of files and folders, and some of them have to be treated specially (one for installing a Windows Service, several config files which should be preserved). Now I'm using heat to generate the list of files for my package, but I don't want to edit the generated content in order to specify my service or config files. At the moment I remove those files from heat generated code and have them in another file. But this is a manual and error-prone process. I'd like to tell heat to ignore some files and generate the wxs file for everything else. This is especially interesting because I'm using subversion and I can't checkout the files for my installer packages in the usual way, because heat would include the .svn directories. I've added a tracker entry, but there was no reaction yet. https://sourceforge.net/tracker/?func=detailaid=2900555group_id=105970 ati d=642717 Comments? thanks, Markus -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- __/\ Markus Gaugusch \ /ASCII Ribbon Campaign markus(at)gaugusch.at X Against HTML Mail
Re: [WiX-users] Reserved directory Id names?
On 09/12/2009 17:55, Wilson, Phil wrote: All the CommonFilesFolder values in merge modules are by convention appended with a mangled guid, but as far as I can tell the mechanism that rationalizes all the folder name properties from merge modules (such as CommonFilesFolder.guid) at merge time is indiscriminate. If the folder name from the merge module *starts* with a standard folder property then the merge generates a CA to set it to the actual CommonFilesFolder. So when it gets merged into the MSI file it generates that type 51 custom action to set CommonFilesFolderanything at all to [CommonFilesFolder]. So yes, you're right, it is a really bad thing to use folder names in merge modules that start exactly like an actual folder name. Is there a case, then, for WiX giving a warning (or even an error) message if a Directory/@Id is used which starts with a predefined folder name? -- Cheers, John -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Conditions with properties through UI
Hi All, I've got a problem with my condition using a property. I set this property in the UI with my own dialog buttons which have the following code. !--The DEPLOYMENTTYPE buttons-- Control Id=AllInOne Type=PushButton Height=41 Width=41 X=72 Y=80 Bitmap=yes Text=AllInOneImg Publish Property=DEPLOYMENTTYPE Value=AllInOne1/Publish /Control Control Id=DedicatedServer Type=PushButton Height=41 Width=41 X=72 Y=155 Bitmap=yes Text=DedicatedServerImg Publish Property=DEPLOYMENTTYPE Value=DedicatedServer1/Publish /Control On the fragment of the feature I set the property to a default: Property Id=DEPLOYMENTTYPE Value=DedicatedServer Secure=yes/ On my feature I have the following condition: Condition Level=1![CDATA[DEPLOYMENTTYPE = AllInOne) OR Installed]]/Condition In the logfile I see that the property is set on the UI and the INSTALL (no typo's either), but my condition still evaluates to false while DEPLOYMENTTYPE is AllInOne. What am I doing wrong here? Regards, Jeffrey Bindinga -- View this message in context: http://n2.nabble.com/Conditions-with-properties-through-UI-tp4144437p4144437.html Sent from the wix-users mailing list archive at Nabble.com. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] multiple entries in add remove programs.
Hello Again The Allusers were not the same. I set them both to Allusers = 1. I received the following results: In Major Update: - in case that the OnlyDetect='yes' : There are two entries in the Add Remove Programs - in case that the OnlyDetect='no' : There are is one entry in the Add Remove Programs But all the files of the original installation are deleted. (only the two components that are part of the upgrade are installed). In Minor Update: No change - the upgrade works, there is one entry in the Add remove programs, the problem is that when I remove the program, only the upgrade is removed. In the Minor mode I tried to debug using a log file and the MSIENFORCEUPGRADECOMPONENTROULES=1. its stops the installation with error 2771. Looking at the log file the msiexec is looking for a component that is part of the original installation but not part of the upgrade. I am using the same feature name in both setup and upgrade. Thanks Giora Wilson, Phil wrote: Assuming you did all that, and corrected the OnlyDetect value, then all I can think of now is that the Allusers value is not the same between the old version and the newer one. If you install and take an MSI log: Msiexec /I path to msi file /l*v path to a log file What does the log say, looking at all the FindRelatedProducts data? Phil Wilson -Original Message- From: Giora keinan [mailto:grkei...@gmail.com] Sent: Wednesday, December 09, 2009 6:43 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] multiple entries in add remove programs. Hello All After playing two more days I made no progress. I tried all the advises I got, including rewriting the wxs file following the example in Neil Sleightholm's blog. I got the same two results: Major upgrade: (Using '*') every thing works but I got two entries in the Add Remove Programs. One for the original installation and one for the Upgrade. Minor Upgrade. (using the original component and product key). I have only one Entry in the Add Remove Program but when I Uninstall this entry only the components that are part of the upgrade are removed. I tried every combination of Keys automatic GUID and msiexec command line argument (including running directly the Upgrade.msi). The application should be upgrade frequently, so we can't have an entry for each upgrade. Thanks Giora Neil Sleightholm wrote: Goira, your Product/@UpgradeCode doesn't match Upgrade/@Id that is why you get the duplicate. Take a look at my sample again you will see I use ?define UpgradeCode to stop this happening. Neil -Original Message- From: Giora keinan [mailto:grkei...@gmail.com] Sent: 07 December 2009 09:35 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] multiple entries in add remove programs. Hello Thanks Sascha, Asker and Neil. I tried your ideas and still have no idea what is the problem I am using only 3 digits version (trying to upgrade 1.0.7 to 1.0.8) following in my upgrade code, maybe you will found what is the problem: ?xml version='1.0' encoding='windows-1252'? ?define Version = 1.0.8 ? Wix xmlns='http://schemas.microsoft.com/wix/2006/wi' Product Name='CapsCake' Id='*' UpgradeCode='2638A59D-5047-4E78-87A6-A665B98FA131' Language='1033' Codepage='1252' Version='$(var.Version)' Manufacturer='Gakay' Package Id='*' Keywords='Installer' Description=CapCake $(var.Version) Updater Comments='CapsCake is a trademark of Gakay.' Manufacturer='Gakay' InstallerVersion='100' Languages='1033' Compressed='yes' SummaryCodepage='1252' / Property Id=INSTALLDIR RegistrySearch Id='CapsCakeRegistry' Type='raw' Root='HKLM' Key='Software\Gakay\CapsCake' Name='InstallDir' / /Property Upgrade Id=474E4E86-1153-4A4D-8ECE-6B1F4D423B24 UpgradeVersion OnlyDetect=yes Property=OLDERVERSIONBEINGUPGRADED Minimum=1.0.0 IncludeMinimum=yes Maximum=$(var.Version) IncludeMaximum=no / UpgradeVersion OnlyDetect=yes Property=NEWERVERSIONDETECTED Minimum=$(var.Version) IncludeMinimum=no / /Upgrade CustomAction Id=AlreadyUpdated Error=[ProductName] is alreadyinstalled. / CustomAction Id=NoDowngrade Error=A later version of [ProductName] is already installed. / Media Id='1' Cabinet='CapsCake.cab' EmbedCab='yes' / !-- Property Id='DiskPrompt' Value=CapCake $(var.Version) Updater [1] / -- Directory Id='TARGETDIR' Name='SourceDir' Directory Id='ProgramFilesFolder' Name='PFiles' Directory Id='INSTALLDIR' Name='.' Component Id='MainExecutable' Guid='*' File Id='CpasCakeEXE' Name='CapsCake.exe' DiskId='1' Source='CapsCake.exe' KeyPath='yes' /File /Component /Directory /Directory Component
[WiX-users] Restart Manager/FileInUse behaviour
A little while ago I was having some problems when uninstalling our application. I managed to get round this by defining the MSIRESTARTMANAGERCONTROL property as disable to revert back to the FilesInUse dialog. This works perfectly fine in Server 2008. However I have encountered an issue when uninstalling under Server 2008 R2. If our application is open while uninstalling, the FilesInUse dialog will appear. On Server 2008, if I press the retry button the behaviour is correct (i.e. if the application is still open the dialog will be displayed once again; if it has been closed then the uninstall continues.) Under Server 2008 R2, pressing Retry proceeds with the uninstall whether or not the application has been closed. One of the obvious differences is that Server 2008 uses Windows Installer 4.5 and Server 2008 R2 uses Windows Installer 5.0. Whether this is making the difference or whether it is some difference at the OS level I cannot say. In light of this I decided to have another look at the Restart Manager behaviour. It seems to me that if I could somehow register the fact that EdgeTransport.exe is a dependency of a service I could eliminate the reboot warning. I've been experimenting with a custom action that registers the path to the EdgeTransport executable using the Restart Manager API (using RmJoinSession, RmRegisterResources and RmEndSession). As far as I can tell, the calls register correctly but has no effect (I still get the reboot warning). So to summarize: The Restart Manager method seems to erroneously warn of a reboot. The FilesInUse method works correctly on Server 2008 but not on Server 2008 R2 in a Retry scenario. I'm presuming that this is Windows Installer behaviour rather than Wix behaviour but hopefully someone might have some insights into this. Thanks in advance, Nick Hall -Original Message- From: Nick Hall Sent: 26 June 2009 18:44 To: 'wix-users@lists.sourceforge.net' Subject: Uninstall and the Restart Manager Our application installs a Microsoft Exchange agent (Exchange 2007, Windows Server 2008). The dll gets loaded by the Exchange Transport Service. I've added a ServiceControl element to stop and start the service which seems to work OK. The problem is that when the application is being uninstalled I get a dialog telling me that a reboot will be required. If I OK this, the uninstall functions correctly without the reboot (as by the time the files are uninstalled the service has been stopped). I believe that the problem is due to the way that the Exchange service is implemented. The service executable is called MSExchangeTransport.exe which then uses a process called EdgeTransport.exe to host our dll. Because the dll is not being hosted directly by the service, Restart Manager is not correctly recognizing that there is not a problem. This is the contents of the uninstall log pertaining to the reboot request: - MSI (s) (78:0C) [18:28:22:904]: RESTART MANAGER: Did detect that a critical application holds file[s] in use, so a reboot will be necessary. MSI (s) (78:0C) [18:28:22:904]: Note: 1: 1610 MSI (s) (78:0C) [18:29:08:864]: RESTART MANAGER: The user chose to go on with the installation, although a reboot will be required. How can I handle this situation? Thanks, Nick Hall -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] install previous version when service major upgrade fails
Hi, I have the following scenario. - MSI installs a service. - MSI makes MAJOR upgrade to this installed service (uninstalls old version and installs new version) - During the major upgrade if it fails, it makes rollback and the service uninstalls completely. Is it possible to tell MSI that if service major upgrade fails, uninstall the upgrade and install the previous version of the service? And how? This is my code: CustomAction Id=SetCustomActionDataValue Return=check Property=RunCmdRollback Value=[INSTALLDIR], [UPGRADINGPRODUCTCODE], [OLDFOUND] / CustomAction Id=RunCmdRollback BinaryKey=OPGInstallerCA2.dll DllEntry=CustomAction1 Execute='rollback' Return=ignore Impersonate='no'/ CustomAction Id='InstallServiceSetProp' Property='InstallService' Value='/installtype=notransaction /action=install /LogFile= [#WindowsService] [#ConfigFile]' / CustomAction Id='InstallService' BinaryKey='InstallUtil' DllEntry='ManagedInstall' Execute='deferred' Return='ignore' Impersonate='no' / CustomAction Id='UnInstallServiceSetProp' Property='UnInstallService' Value='/installtype=notransaction /action=uninstall /LogFile= [#WindowsService] [#ConfigFile]' / CustomAction Id='UnInstallService' BinaryKey='InstallUtil' DllEntry='ManagedInstall' Execute='deferred' Return='ignore' Impersonate='no'/ CustomAction Id='CommitServiceSetProp' Property='CommitService' Value='/installtype=notransaction /action=commit /LogFile= [#WindowsService] [#ConfigFile]' / CustomAction Id='CommitService' BinaryKey='InstallUtil' DllEntry='ManagedInstall' Execute='commit' Return='ignore' Impersonate='no' / CustomAction Id='RollbackServiceSetProp' Property='RollbackService' Value='/installtype=notransaction /action=rollback /LogFile= [#WindowsService] [#ConfigFile]' / CustomAction Id='RollbackService' BinaryKey='InstallUtil' DllEntry='ManagedInstall' Execute='rollback' Return='ignore' Impersonate='no' / CustomAction Id='ConfigurePort' Execute='deferred' Return='ignore' BinaryKey='HTTPCFG' ExeCommand='set urlacl -u http://+:5/OPGatewayService/ -a D:(A;;GA;;;NS)' Impersonate='no'/ CustomAction Id='UnConfigurePort' Execute='deferred' Return='ignore' BinaryKey='HTTPCFG' ExeCommand='delete urlacl -u http://+:5/OPGatewayService/' Impersonate='no'/ CustomAction Id='RollbackConfigurePort' Execute='rollback' Return='ignore' BinaryKey='HTTPCFG' ExeCommand='delete urlacl -u http://+:5/OPGatewayService/' Impersonate='no'/ CustomAction Id=StopVCA Execute='rollback' Return='ignore' ExeCommand=net stop OPGatewayService Directory=TARGETDIR Impersonate='no' / InstallExecuteSequence InstallValidate Sequence=1400 / RemoveExistingProducts Sequence=1402OLDFOUND/RemoveExistingProducts InstallInitialize Sequence=1500 / Custom Action=ConfigurePort After='InstallService'$OPGatewayComponent2/Custom Custom Action=UnConfigurePort After='UnInstallService'$OPGatewayComponent=2/Custom Custom Action='InstallServiceSetProp' Before='StartServices'$OPGatewayComponent2/Custom Custom Action='InstallService' After='InstallServiceSetProp'$OPGatewayComponent2/Custom Custom Action='UnInstallServiceSetProp' After='StopServices'$OPGatewayComponent=2/Custom Custom Action='UnInstallService' After='UnInstallServiceSetProp'$OPGatewayComponent=2/Custom Custom Action='CommitServiceSetProp' After='RollbackService'$OPGatewayComponent2/Custom Custom Action='CommitService' After='CommitServiceSetProp'$OPGatewayComponent2/Custom Custom Action='RollbackServiceSetProp' After='InstallService'$OPGatewayComponent2/Custom Custom Action='RollbackService' After='RollbackServiceSetProp'$OPGatewayComponent2/Custom Custom Action=StopVCA After='RollbackService'$OPGatewayComponent2/Custom Custom Action='RollbackConfigurePort' After='StopVCA'$OPGatewayComponent2/Custom Custom Action='SetCustomActionDataValue' After='RollbackConfigurePort'$OPGatewayComponent2/Custom Custom Action=RunCmdRollback After='SetCustomActionDataValue' $OPGatewayComponent2/Custom Custom Action='AlreadyUpdated' After='FindRelatedProducts'SELFFOUND/Custom Custom Action='NoDowngrade' After='FindRelatedProducts'NEWERFOUND/Custom /InstallExecuteSequence Another question. How can i make rollback action (RunCmdRollback) not to execute on failed upgrade, only on failed new install? Thank you very much, Adriana -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Multiple installed instances and maintenance mode
Ha ya, good idea. It looks like I need to read up on how to make a bootstrapper. If anyone has any tips/urls that would help me that'd be great. Thanks guys for your help :) On Thu, 2009-12-10 at 09:14 +1100, Sascha Beaumont wrote: One file? Then use a self-extracting bootstrapper :) On Thu, Dec 10, 2009 at 6:19 AM, Kevin Garman gar...@scadaware.com wrote: Well ya...I'm really trying to keep everything contained in a single file (ie. the msi). Thanks though. On Wed, 2009-12-09 at 10:38 -0800, Blair wrote: Bootstrapper. -Original Message- From: Kevin Garman [mailto:gar...@scadaware.com] Sent: Wednesday, December 09, 2009 8:30 AM To: wix-users Subject: [WiX-users] Multiple installed instances and maintenance mode Hi, I've used the information contained in the following posts: http://n2.nabble.com/Multiple-Instance-Transforms-Walkthrough-Proposed-Simpl e-Addition-to-WiX-to-Make-Them-Easier-td708828.html The functionality that I'm after is as follows: -user installs instances by choosing from a list of available instances in the installer (WORKING) -user can modify the installed components of a given instance from it's entry in 'Add/Remove Programs' (WORKING) -user can modify the installed components of a given instance by launching the installer and choosing an installed instance to modify (NOT WORKING) My question is basically, 'How can I launch the installer, show a window where the instance is selected, and then go into maintenance mode for that instance?' Thanks, Kevin -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Multiple installed instances and maintenance mode
You can use http://dotnetinstaller.codeplex.com for this. The installer becomes two things: - a new application that you write that prompts which instance to modify and invokes the right msiexec command - your msi You can condition the first to appear when you have at least one instance and the second to appear when there's none. Everything is packaged in a single setup.exe so the user doesn't see this. Hope this helps. -dB. dB. @ dblock.org Moscow|Geneva|Seattle|New York -Original Message- From: Kevin Garman [mailto:gar...@scadaware.com] Sent: Thursday, December 10, 2009 8:29 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Multiple installed instances and maintenance mode Ha ya, good idea. It looks like I need to read up on how to make a bootstrapper. If anyone has any tips/urls that would help me that'd be great. Thanks guys for your help :) On Thu, 2009-12-10 at 09:14 +1100, Sascha Beaumont wrote: One file? Then use a self-extracting bootstrapper :) On Thu, Dec 10, 2009 at 6:19 AM, Kevin Garman gar...@scadaware.com wrote: Well ya...I'm really trying to keep everything contained in a single file (ie. the msi). Thanks though. On Wed, 2009-12-09 at 10:38 -0800, Blair wrote: Bootstrapper. -Original Message- From: Kevin Garman [mailto:gar...@scadaware.com] Sent: Wednesday, December 09, 2009 8:30 AM To: wix-users Subject: [WiX-users] Multiple installed instances and maintenance mode Hi, I've used the information contained in the following posts: http://n2.nabble.com/Multiple-Instance-Transforms-Walkthrough-Proposed-Simpl e-Addition-to-WiX-to-Make-Them-Easier-td708828.html The functionality that I'm after is as follows: -user installs instances by choosing from a list of available instances in the installer (WORKING) -user can modify the installed components of a given instance from it's entry in 'Add/Remove Programs' (WORKING) -user can modify the installed components of a given instance by launching the installer and choosing an installed instance to modify (NOT WORKING) My question is basically, 'How can I launch the installer, show a window where the instance is selected, and then go into maintenance mode for that instance?' Thanks, Kevin -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to specify files in Installer package
Hi Yan! I tried an example found at http://www.mail-archive.com/wix-users@lists.sourceforge.net/msg27515.html -- but I'm unable to get it going :( I want to ignore Component Id=cmp20CFFB2FF46488AF2CD00E2C9543E202 Directory=INSTALLDIR Guid=* (which includes one file) I used the aforementioned example and tried with xsl:template match=@id[.='cmp20CFFB2FF46488AF2CD00E2C9543E202'] / But the filter doesn't seem to apply (my component is still in the output) can you help me? thanks, Markus On Dec 10, Yan Sklyarenko y...@sitecore.net wrote: Markus, The heat.exe has a switch -t:transform.xsl. If you specify this switch running heat, the 'transform.xsl' will be applied to the regular output of you heat command. The final resulting wxs file will contain transformed xml. There are no special requirements for that XSL transform. Hope this helps, -- Yan -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patching problems with alternate directories
Hey Blair-2, I'd be happy to share a log of the installation but unfortunately I'm doing this for a company and I'm not allowed to post the information for a log. I've studied the logs myself during patching and it looks like it doesn't recognize that the install path is different from C:\Program Files\Appname\etc. What it ends up outputting is a list of the files being installed by the patch but each one specifies To be installed; Won't patch; No existing file. If you're interested in a particular portion of the log file I might be able to show you by replacing the product and path information with fictional data so you could see what might be the problem without my violating my company's policies. Thank for all your help so far! Blair-2 wrote: The location that the components you are patching are already installed. Could you share a log that shows it not working in that circumstance? -Original Message- From: XorPtr [mailto:reaper4...@gmail.com] Sent: Wednesday, December 09, 2009 1:55 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Patching problems with alternate directories When you refer to the currently installed location, are you referring to the location that my product installs to by default or the location selected by the user. If the latter, then the patch should be installing to that location. Blair-2 wrote: Are your patches MSP files performing either small updates or minor upgrades? If so, the patch application won't let you patch anywhere other than the currently installed location since the keypath of the components can't be changed without a major upgrade. -Original Message- From: XorPtr [mailto:reaper4...@gmail.com] Sent: Wednesday, December 02, 2009 1:12 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Patching problems with alternate directories I've been having an issue with my WiX patch which I haven't been able to find any information for. The company I work for wants to give users the freedom to install our product in a directory of their choice. We've given the installer a default directory which can be changed at install time by the user. This has worked fine up until attempting to patch the package. I successfully made a patch which patches the package without problem if it's installed to the default location, however if users choose to install the product in an alternate location and then patch the patch fails because it's still trying to change files on the default location. Any ideas on how I can dynamically set up the patch install location based on where the user installs our product? Thanks in advance. Big Jim. -- View this message in context: http://n2.nabble.com/Patching-problems-with-alternate-directories-tp4102386p 4102386.html Sent from the wix-users mailing list archive at Nabble.com. -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- View this message in context: http://n2.nabble.com/Patching-problems-with-alternate-directories-tp4102386p 4142265.html Sent from the wix-users mailing list archive at Nabble.com. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- View this message in context: http://n2.nabble.com/Patching-problems-with-alternate-directories-tp4102386p4145621.html Sent from the wix-users mailing list archive at Nabble.com.
Re: [WiX-users] sql database sql:SqlDatabase creation and Users
I'm writing an install that will create a sql database. I've got my server set to Windows and Sql Authenication mode. When I run the install and ask for a user with permission to install the database, I've got two scenarios: 1) Using a windows network based user. This user is a sql user (inside the sql server management studio) as well. I type in MYDOMAIN\myusername (generically speaking) as a user and then type in the password. The install can not create my database. It throws an error. 2) When I use a sql based user, that is a user present inside the sql server management studio but this user is not a registered windows network user, the database creation works. If both users have the same sql rights, why would a network based user be unable to create the database where the purely Sql user can. I've also tried using myusername (vs. MYDOMAIN\myusername) and I get the same results. Rob Hermann Senior Software Developer Niceware International, LLC 10437 Innovation Drive Suite 147 Milwaukee, WI 53226 Tel: 414-476-6423 x110 Fax: 414-476-7955 Email: rob.herm...@nicewareintl.com http://www.nicewareintl.com http://healthcare.nicewareintl.com December 4th - 10:30AM CST - 11:30AM CST - Benefits of Upgrading from NiceLabel v3 to NiceLabel v5 - Register Today! December 11th - 10:30AM CST - 11:30AM CST - A Complete Introduction to LabelClinic CT - Register Today! December 18th - 10:30AM CST - 11:30AM CST - A Complete Introduction to NiceLabel SDK and WebSDK - Register Today! The information in this e-mail and any attachments is confidential and may be subject to legal professional privilege. It is intended solely for the attention and use of the named addressee(s). If you are not the intended recipient or person responsible for delivering this information to the intended recipient, please notify the sender immediately. Unless you are the intended recipient or his/her representative you are not authorized to, and must not, read, copy, distribute, use or retain this message or any part of it -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to specify files in Installer package
You want to match the component element [with a given ID] in order to omit it, not match the Id attribute: xsl:template match=compone...@id='cmp20CFFB2FF46488AF2CD00E2C9543E202'] / Also be careful to match the exact case of the element and attribute names. If it still doesnt work, check that the wix namesapce is the default namespace. -Original Message- From: Markus Gaugusch [mailto:w...@gaugusch.at] Sent: 10 December 2009 14:26 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How to specify files in Installer package Hi Yan! I tried an example found at http://www.mail-archive.com/wix-users@lists.sourceforge.net/msg27515.htm l -- but I'm unable to get it going :( I want to ignore Component Id=cmp20CFFB2FF46488AF2CD00E2C9543E202 Directory=INSTALLDIR Guid=* (which includes one file) I used the aforementioned example and tried with xsl:template match=@id[.='cmp20CFFB2FF46488AF2CD00E2C9543E202'] / But the filter doesn't seem to apply (my component is still in the output) can you help me? thanks, Markus On Dec 10, Yan Sklyarenko y...@sitecore.net wrote: Markus, The heat.exe has a switch -t:transform.xsl. If you specify this switch running heat, the 'transform.xsl' will be applied to the regular output of you heat command. The final resulting wxs file will contain transformed xml. There are no special requirements for that XSL transform. Hope this helps, -- Yan -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users SDL PLC confidential, all rights reserved. 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. SDL PLC is a public limited company registered in England and Wales. Registered number: 02675207. Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] sql database sql:SqlDatabase creation and Users
We've dealt with this extensively. It's because Windows authentication doesn't work by supplying a username/password (that's SQL auth). The calling process must be running as that user, so what you need is impersonation. You need to ask the user whether he wants to do SQL or Windows auth. If he wants SQL auth, that's what you need to create your database with, make it a separate component conditioned on that. If the user wants to do Windows auth, don't ask him to enter credentials, he's installing as the current user. If you want him to enter windows auth credentials, the deferred CA needs to impersonate, which is not implemented in the wix extensions. In http://msiext.codeplex.com you have reusable dialogs with test connection buttons, advanced parameters for SQL server like where to put LDF/MDF files (recommend path), DMO list of available SQL databases, etc., so you can skip reinventing the wheel. I am not 100% whether we dealt with the scenario of windows impersonation for creating the database, but if we didn't, it's something that wouldn't be too hard to contribute. cheers dB. dB. @ dblock.org Moscow|Geneva|Seattle|New York -Original Message- From: Robert Hermann [mailto:rob.herm...@nicewareintl.com] Sent: Thursday, December 10, 2009 9:35 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] sql database sql:SqlDatabase creation and Users I'm writing an install that will create a sql database. I've got my server set to Windows and Sql Authenication mode. When I run the install and ask for a user with permission to install the database, I've got two scenarios: 1) Using a windows network based user. This user is a sql user (inside the sql server management studio) as well. I type in MYDOMAIN\myusername (generically speaking) as a user and then type in the password. The install can not create my database. It throws an error. 2) When I use a sql based user, that is a user present inside the sql server management studio but this user is not a registered windows network user, the database creation works. If both users have the same sql rights, why would a network based user be unable to create the database where the purely Sql user can. I've also tried using myusername (vs. MYDOMAIN\myusername) and I get the same results. Rob Hermann Senior Software Developer Niceware International, LLC 10437 Innovation Drive Suite 147 Milwaukee, WI 53226 Tel: 414-476-6423 x110 Fax: 414-476-7955 Email: rob.herm...@nicewareintl.com http://www.nicewareintl.com http://healthcare.nicewareintl.com December 4th - 10:30AM CST - 11:30AM CST - Benefits of Upgrading from NiceLabel v3 to NiceLabel v5 - Register Today! December 11th - 10:30AM CST - 11:30AM CST - A Complete Introduction to LabelClinic CT - Register Today! December 18th - 10:30AM CST - 11:30AM CST - A Complete Introduction to NiceLabel SDK and WebSDK - Register Today! The information in this e-mail and any attachments is confidential and may be subject to legal professional privilege. It is intended solely for the attention and use of the named addressee(s). If you are not the intended recipient or person responsible for delivering this information to the intended recipient, please notify the sender immediately. Unless you are the intended recipient or his/her representative you are not authorized to, and must not, read, copy, distribute, use or retain this message or any part of it -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] install previous version when service major upgrade fails
You will increase your success rate by doing these things: - Get rid of your self-registration and use the built-in Windows platform support for services (the Service* elements in WiX). * the above will require that you perform all your registration using Registry entries, etc. in the MSI itself instead of using the stuff only intended for developers debugging their code builds (self-registration) without doing the smart thing which is remote debugging using a virtual image. - Move RemoveExistingProducts to either right before or right after InstallFinalize. With the way you have your installation authored your previous version should be reinstalled when the removal is rolled back. Your new package shouldn't care if this is an upgrade or a fresh install since you currently remove-before-install your upgrade. -Original Message- From: Adriana Rodean [mailto:adrya1...@gmail.com] Sent: Thursday, December 10, 2009 3:41 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] install previous version when service major upgrade fails Hi, I have the following scenario. - MSI installs a service. - MSI makes MAJOR upgrade to this installed service (uninstalls old version and installs new version) - During the major upgrade if it fails, it makes rollback and the service uninstalls completely. Is it possible to tell MSI that if service major upgrade fails, uninstall the upgrade and install the previous version of the service? And how? This is my code: CustomAction Id=SetCustomActionDataValue Return=check Property=RunCmdRollback Value=[INSTALLDIR], [UPGRADINGPRODUCTCODE], [OLDFOUND] / CustomAction Id=RunCmdRollback BinaryKey=OPGInstallerCA2.dll DllEntry=CustomAction1 Execute='rollback' Return=ignore Impersonate='no'/ CustomAction Id='InstallServiceSetProp' Property='InstallService' Value='/installtype=notransaction /action=install /LogFile= [#WindowsService] [#ConfigFile]' / CustomAction Id='InstallService' BinaryKey='InstallUtil' DllEntry='ManagedInstall' Execute='deferred' Return='ignore' Impersonate='no' / CustomAction Id='UnInstallServiceSetProp' Property='UnInstallService' Value='/installtype=notransaction /action=uninstall /LogFile= [#WindowsService] [#ConfigFile]' / CustomAction Id='UnInstallService' BinaryKey='InstallUtil' DllEntry='ManagedInstall' Execute='deferred' Return='ignore' Impersonate='no'/ CustomAction Id='CommitServiceSetProp' Property='CommitService' Value='/installtype=notransaction /action=commit /LogFile= [#WindowsService] [#ConfigFile]' / CustomAction Id='CommitService' BinaryKey='InstallUtil' DllEntry='ManagedInstall' Execute='commit' Return='ignore' Impersonate='no' / CustomAction Id='RollbackServiceSetProp' Property='RollbackService' Value='/installtype=notransaction /action=rollback /LogFile= [#WindowsService] [#ConfigFile]' / CustomAction Id='RollbackService' BinaryKey='InstallUtil' DllEntry='ManagedInstall' Execute='rollback' Return='ignore' Impersonate='no' / CustomAction Id='ConfigurePort' Execute='deferred' Return='ignore' BinaryKey='HTTPCFG' ExeCommand='set urlacl -u http://+:5/OPGatewayService/ -a D:(A;;GA;;;NS)' Impersonate='no'/ CustomAction Id='UnConfigurePort' Execute='deferred' Return='ignore' BinaryKey='HTTPCFG' ExeCommand='delete urlacl -u http://+:5/OPGatewayService/' Impersonate='no'/ CustomAction Id='RollbackConfigurePort' Execute='rollback' Return='ignore' BinaryKey='HTTPCFG' ExeCommand='delete urlacl -u http://+:5/OPGatewayService/' Impersonate='no'/ CustomAction Id=StopVCA Execute='rollback' Return='ignore' ExeCommand=net stop OPGatewayService Directory=TARGETDIR Impersonate='no' / InstallExecuteSequence InstallValidate Sequence=1400 / RemoveExistingProducts Sequence=1402OLDFOUND/RemoveExistingProducts InstallInitialize Sequence=1500 / Custom Action=ConfigurePort After='InstallService'$OPGatewayComponent2/Custom Custom Action=UnConfigurePort After='UnInstallService'$OPGatewayComponent=2/Custom Custom Action='InstallServiceSetProp' Before='StartServices'$OPGatewayComponent2/Custom Custom Action='InstallService' After='InstallServiceSetProp'$OPGatewayComponent2/Custom Custom Action='UnInstallServiceSetProp' After='StopServices'$OPGatewayComponent=2/Custom Custom Action='UnInstallService' After='UnInstallServiceSetProp'$OPGatewayComponent=2/Custom Custom Action='CommitServiceSetProp' After='RollbackService'$OPGatewayComponent2/Custom Custom Action='CommitService' After='CommitServiceSetProp'$OPGatewayComponent2/Custom Custom Action='RollbackServiceSetProp' After='InstallService'$OPGatewayComponent2/Custom Custom Action='RollbackService' After='RollbackServiceSetProp'$OPGatewayComponent2/Custom Custom Action=StopVCA After='RollbackService'$OPGatewayComponent2/Custom Custom Action='RollbackConfigurePort' After='StopVCA'$OPGatewayComponent2/Custom Custom
Re: [WiX-users] How to specify files in Installer package
If you want to omit that component completely, try the following XSL template: xsl:template match=wix:ComponentGroup/wix:compone...@id='cmp034A7A0245A16CFBB38E35D5 1794CF21'] !-- JUST DO NOTHING HERE -- /xsl:template This should find the mentioned component and write nothing to the output. Don't forget to exclude the appropriate ComponentRef if it is referenced from anywhere. Hope this helps, -- Yan -Original Message- From: Markus Gaugusch [mailto:w...@gaugusch.at] Sent: Thursday, December 10, 2009 17:10 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How to specify files in Installer package I can feel that I'm nearly there, but it doesn't work yet. This is my XSLT: ?xml version=1.0 ? xsl:transform version=1.0 xmlns:xsl=http://www.w3.org/1999/XSL/Transform; xmlns:wix=http://schemas.microsoft.com/wix/2006/wi; !-- By default, copy all attributes and elements to the output. -- xsl:template match=@*|* xsl:copy xsl:apply-templates select=@* / xsl:apply-templates select=* / /xsl:copy /xsl:template !-- Override copy (do nothing) for elements with this Id, so they are omitted from the output. -- xsl:template match=compone...@id='cmp20CFFB2FF46488AF2CD00E2C9543E202'] / /xsl:transform And my xml looks like that: ?xml version=1.0 encoding=utf-8? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; Fragment ComponentGroup Id=MyClient Component Id=cmp034A7A0245A16CFBB38E35D51794CF21 Directory=INSTALLDIR Guid=* File ... So, do I have to specify ComponentGroup, Fragment or Wix in the xslt file? How? thanks! Markus On Dec 10, Peter Shirtcliffe pshirtcli...@sdl.com wrote: You want to match the component element [with a given ID] in order to omit it, not match the Id attribute: xsl:template match=compone...@id='cmp20CFFB2FF46488AF2CD00E2C9543E202'] / Also be careful to match the exact case of the element and attribute names. If it still doesnt work, check that the wix namesapce is the default namespace. -Original Message- From: Markus Gaugusch [mailto:w...@gaugusch.at] Sent: 10 December 2009 14:26 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How to specify files in Installer package Hi Yan! I tried an example found at http://www.mail-archive.com/wix-users@lists.sourceforge.net/msg27515.htm l -- but I'm unable to get it going :( I want to ignore Component Id=cmp20CFFB2FF46488AF2CD00E2C9543E202 Directory=INSTALLDIR Guid=* (which includes one file) I used the aforementioned example and tried with xsl:template match=@id[.='cmp20CFFB2FF46488AF2CD00E2C9543E202'] / But the filter doesn't seem to apply (my component is still in the output) can you help me? thanks, Markus On Dec 10, Yan Sklyarenko y...@sitecore.net wrote: Markus, The heat.exe has a switch -t:transform.xsl. If you specify this switch running heat, the 'transform.xsl' will be applied to the regular output of you heat command. The final resulting wxs file will contain transformed xml. There are no special requirements for that XSL transform. Hope this helps, -- Yan -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users SDL PLC confidential, all rights reserved. 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. SDL PLC is a public limited company registered in England and Wales. Registered number: 02675207. Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- __/\ Markus Gaugusch \ /ASCII Ribbon Campaign markus(at)gaugusch.at X Against HTML Mail / \ -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Return on Information: Google
Re: [WiX-users] How to specify files in Installer package
Hoorryy! That's doing it :-) I wonder how complicated something as simple as grep -v can be ... Anyway, I'm going to wix now :) Thanks a lot, Yan! (and also Peter) Markus On Dec 10, Yan Sklyarenko y...@sitecore.net wrote: If you want to omit that component completely, try the following XSL template: xsl:template match=wix:ComponentGroup/wix:compone...@id='cmp034A7A0245A16CFBB38E35D5 1794CF21'] !-- JUST DO NOTHING HERE -- /xsl:template This should find the mentioned component and write nothing to the output. Don't forget to exclude the appropriate ComponentRef if it is referenced from anywhere. Hope this helps, -- Yan -Original Message- From: Markus Gaugusch [mailto:w...@gaugusch.at] Sent: Thursday, December 10, 2009 17:10 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How to specify files in Installer package I can feel that I'm nearly there, but it doesn't work yet. This is my XSLT: ?xml version=1.0 ? xsl:transform version=1.0 xmlns:xsl=http://www.w3.org/1999/XSL/Transform; xmlns:wix=http://schemas.microsoft.com/wix/2006/wi; !-- By default, copy all attributes and elements to the output. -- xsl:template match=@*|* xsl:copy xsl:apply-templates select=@* / xsl:apply-templates select=* / /xsl:copy /xsl:template !-- Override copy (do nothing) for elements with this Id, so they are omitted from the output. -- xsl:template match=compone...@id='cmp20CFFB2FF46488AF2CD00E2C9543E202'] / /xsl:transform And my xml looks like that: ?xml version=1.0 encoding=utf-8? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; Fragment ComponentGroup Id=MyClient Component Id=cmp034A7A0245A16CFBB38E35D51794CF21 Directory=INSTALLDIR Guid=* File ... So, do I have to specify ComponentGroup, Fragment or Wix in the xslt file? How? thanks! Markus On Dec 10, Peter Shirtcliffe pshirtcli...@sdl.com wrote: You want to match the component element [with a given ID] in order to omit it, not match the Id attribute: xsl:template match=compone...@id='cmp20CFFB2FF46488AF2CD00E2C9543E202'] / Also be careful to match the exact case of the element and attribute names. If it still doesnt work, check that the wix namesapce is the default namespace. -Original Message- From: Markus Gaugusch [mailto:w...@gaugusch.at] Sent: 10 December 2009 14:26 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How to specify files in Installer package Hi Yan! I tried an example found at http://www.mail-archive.com/wix-users@lists.sourceforge.net/msg27515.htm l -- but I'm unable to get it going :( I want to ignore Component Id=cmp20CFFB2FF46488AF2CD00E2C9543E202 Directory=INSTALLDIR Guid=* (which includes one file) I used the aforementioned example and tried with xsl:template match=@id[.='cmp20CFFB2FF46488AF2CD00E2C9543E202'] / But the filter doesn't seem to apply (my component is still in the output) can you help me? thanks, Markus On Dec 10, Yan Sklyarenko y...@sitecore.net wrote: Markus, The heat.exe has a switch -t:transform.xsl. If you specify this switch running heat, the 'transform.xsl' will be applied to the regular output of you heat command. The final resulting wxs file will contain transformed xml. There are no special requirements for that XSL transform. Hope this helps, -- Yan -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users SDL PLC confidential, all rights reserved. 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. SDL PLC is a public limited company registered in England and Wales. Registered number: 02675207. Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- __/\ Markus Gaugusch \ /ASCII Ribbon Campaign markus(at)gaugusch.at X Against HTML Mail / \ -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev
Re: [WiX-users] Multiple installed instances and maintenance mode
A cursory look suggests that dotNetInstaller will be a fantastic solution. Thanks much! On Thu, 2009-12-10 at 09:15 -0500, dB. wrote: You can use http://dotnetinstaller.codeplex.com for this. The installer becomes two things: - a new application that you write that prompts which instance to modify and invokes the right msiexec command - your msi You can condition the first to appear when you have at least one instance and the second to appear when there's none. Everything is packaged in a single setup.exe so the user doesn't see this. Hope this helps. -dB. dB. @ dblock.org Moscow|Geneva|Seattle|New York -Original Message- From: Kevin Garman [mailto:gar...@scadaware.com] Sent: Thursday, December 10, 2009 8:29 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Multiple installed instances and maintenance mode Ha ya, good idea. It looks like I need to read up on how to make a bootstrapper. If anyone has any tips/urls that would help me that'd be great. Thanks guys for your help :) On Thu, 2009-12-10 at 09:14 +1100, Sascha Beaumont wrote: One file? Then use a self-extracting bootstrapper :) On Thu, Dec 10, 2009 at 6:19 AM, Kevin Garman gar...@scadaware.com wrote: Well ya...I'm really trying to keep everything contained in a single file (ie. the msi). Thanks though. On Wed, 2009-12-09 at 10:38 -0800, Blair wrote: Bootstrapper. -Original Message- From: Kevin Garman [mailto:gar...@scadaware.com] Sent: Wednesday, December 09, 2009 8:30 AM To: wix-users Subject: [WiX-users] Multiple installed instances and maintenance mode Hi, I've used the information contained in the following posts: http://n2.nabble.com/Multiple-Instance-Transforms-Walkthrough-Proposed-Simpl e-Addition-to-WiX-to-Make-Them-Easier-td708828.html The functionality that I'm after is as follows: -user installs instances by choosing from a list of available instances in the installer (WORKING) -user can modify the installed components of a given instance from it's entry in 'Add/Remove Programs' (WORKING) -user can modify the installed components of a given instance by launching the installer and choosing an installed instance to modify (NOT WORKING) My question is basically, 'How can I launch the installer, show a window where the instance is selected, and then go into maintenance mode for that instance?' Thanks, Kevin -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev
Re: [WiX-users] How to specify files in Installer package
You dont need to specify wix or component group. The component element will be matched when the matching algorithm reaches it and component is not used in any other contexts so specifying Component by itself is fine. However, since it appears wix is not your default namespace, you will need to prefix Component with wix: like this xsl:template match=wix:Component[ When you do this, its also useful to add exclude-result-prefixes=wix to your xsl:stylesheet element. (Yan also just replied with much the same advice. You dont need the component group in the match but theres no harm in having it either. You will need to write a template to remove the componentref element too, as mentioned there.) -Original Message- From: Markus Gaugusch [mailto:w...@gaugusch.at] Sent: 10 December 2009 15:10 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How to specify files in Installer package I can feel that I'm nearly there, but it doesn't work yet. This is my XSLT: ?xml version=1.0 ? xsl:transform version=1.0 xmlns:xsl=http://www.w3.org/1999/XSL/Transform; xmlns:wix=http://schemas.microsoft.com/wix/2006/wi; !-- By default, copy all attributes and elements to the output. -- xsl:template match=@*|* xsl:copy xsl:apply-templates select=@* / xsl:apply-templates select=* / /xsl:copy /xsl:template !-- Override copy (do nothing) for elements with this Id, so they are omitted from the output. -- xsl:template match=compone...@id='cmp20CFFB2FF46488AF2CD00E2C9543E202'] / /xsl:transform And my xml looks like that: ?xml version=1.0 encoding=utf-8? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; Fragment ComponentGroup Id=MyClient Component Id=cmp034A7A0245A16CFBB38E35D51794CF21 Directory=INSTALLDIR Guid=* File ... So, do I have to specify ComponentGroup, Fragment or Wix in the xslt file? How? thanks! Markus On Dec 10, Peter Shirtcliffe pshirtcli...@sdl.com wrote: You want to match the component element [with a given ID] in order to omit it, not match the Id attribute: xsl:template match=compone...@id='cmp20CFFB2FF46488AF2CD00E2C9543E202'] / Also be careful to match the exact case of the element and attribute names. If it still doesnt work, check that the wix namesapce is the default namespace. -Original Message- From: Markus Gaugusch [mailto:w...@gaugusch.at] Sent: 10 December 2009 14:26 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How to specify files in Installer package Hi Yan! I tried an example found at http://www.mail-archive.com/wix-users@lists.sourceforge.net/msg27515.h tm l -- but I'm unable to get it going :( I want to ignore Component Id=cmp20CFFB2FF46488AF2CD00E2C9543E202 Directory=INSTALLDIR Guid=* (which includes one file) I used the aforementioned example and tried with xsl:template match=@id[.='cmp20CFFB2FF46488AF2CD00E2C9543E202'] / But the filter doesn't seem to apply (my component is still in the output) can you help me? thanks, Markus On Dec 10, Yan Sklyarenko y...@sitecore.net wrote: Markus, The heat.exe has a switch -t:transform.xsl. If you specify this switch running heat, the 'transform.xsl' will be applied to the regular output of you heat command. The final resulting wxs file will contain transformed xml. There are no special requirements for that XSL transform. Hope this helps, -- Yan -- -- -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users SDL PLC confidential, all rights reserved. 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. SDL PLC is a public limited company registered in England and Wales. Registered number: 02675207. Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- __/\ Markus Gaugusch \ /ASCII Ribbon Campaign markus(at)gaugusch.at X Against HTML Mail / \ -- Return on Information: Google Enterprise Search pays you back Get the facts.
[WiX-users] Install path best practices...
The best practice for install path is %ProgramFiles%\company\product, correct? We allow the customer to (optionally) change the install path during install. This is where I get confused. Do we allow them to change the whole path including product? Or just %ProgramFiles% portion? Just the %ProgramFiles\company? Thoughts? Links? Thanks, Tony -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Install path best practices...
On Dec 10, Tony yellowjacketl...@gmail.com wrote: The best practice for install path is %ProgramFiles%\company\product, correct? Although I've seen this sometimes, it doesn't seem to be used generally. If I look at my Program Files folder, most seem to be product or company product. Personally, I prefer a flat structure, and especially if your company is not widely known, it's easier for the user to spot the installation folder if you just call it product. We allow the customer to (optionally) change the install path during install. This is where I get confused. Do we allow them to change the whole path including product? Or just %ProgramFiles% portion? Just the %ProgramFiles\company? I'd print out the whole path and let the use modify whatever he wants. It might be just the foldername, or the entire Drive. Markus -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patching problems with alternate directories
What does the log say about the component statuses? -Original Message- From: XorPtr [mailto:reaper4...@gmail.com] Sent: Thursday, December 10, 2009 6:27 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Patching problems with alternate directories Hey Blair-2, I'd be happy to share a log of the installation but unfortunately I'm doing this for a company and I'm not allowed to post the information for a log. I've studied the logs myself during patching and it looks like it doesn't recognize that the install path is different from C:\Program Files\Appname\etc. What it ends up outputting is a list of the files being installed by the patch but each one specifies To be installed; Won't patch; No existing file. If you're interested in a particular portion of the log file I might be able to show you by replacing the product and path information with fictional data so you could see what might be the problem without my violating my company's policies. Thank for all your help so far! Blair-2 wrote: The location that the components you are patching are already installed. Could you share a log that shows it not working in that circumstance? -Original Message- From: XorPtr [mailto:reaper4...@gmail.com] Sent: Wednesday, December 09, 2009 1:55 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Patching problems with alternate directories When you refer to the currently installed location, are you referring to the location that my product installs to by default or the location selected by the user. If the latter, then the patch should be installing to that location. Blair-2 wrote: Are your patches MSP files performing either small updates or minor upgrades? If so, the patch application won't let you patch anywhere other than the currently installed location since the keypath of the components can't be changed without a major upgrade. -Original Message- From: XorPtr [mailto:reaper4...@gmail.com] Sent: Wednesday, December 02, 2009 1:12 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Patching problems with alternate directories I've been having an issue with my WiX patch which I haven't been able to find any information for. The company I work for wants to give users the freedom to install our product in a directory of their choice. We've given the installer a default directory which can be changed at install time by the user. This has worked fine up until attempting to patch the package. I successfully made a patch which patches the package without problem if it's installed to the default location, however if users choose to install the product in an alternate location and then patch the patch fails because it's still trying to change files on the default location. Any ideas on how I can dynamically set up the patch install location based on where the user installs our product? Thanks in advance. Big Jim. -- View this message in context: http://n2.nabble.com/Patching-problems-with-alternate-directories-tp4102386p 4102386.html Sent from the wix-users mailing list archive at Nabble.com. -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- View this message in context: http://n2.nabble.com/Patching-problems-with-alternate-directories-tp4102386p 4142265.html Sent from the wix-users mailing list archive at Nabble.com. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net
Re: [WiX-users] Patching problems with alternate directories
All of the components are listed as: Installed: Local; Request: Local; Action: Local. Blair-2 wrote: What does the log say about the component statuses? -Original Message- From: XorPtr [mailto:reaper4...@gmail.com] Sent: Thursday, December 10, 2009 6:27 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Patching problems with alternate directories Hey Blair-2, I'd be happy to share a log of the installation but unfortunately I'm doing this for a company and I'm not allowed to post the information for a log. I've studied the logs myself during patching and it looks like it doesn't recognize that the install path is different from C:\Program Files\Appname\etc. What it ends up outputting is a list of the files being installed by the patch but each one specifies To be installed; Won't patch; No existing file. If you're interested in a particular portion of the log file I might be able to show you by replacing the product and path information with fictional data so you could see what might be the problem without my violating my company's policies. Thank for all your help so far! Blair-2 wrote: The location that the components you are patching are already installed. Could you share a log that shows it not working in that circumstance? -Original Message- From: XorPtr [mailto:reaper4...@gmail.com] Sent: Wednesday, December 09, 2009 1:55 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Patching problems with alternate directories When you refer to the currently installed location, are you referring to the location that my product installs to by default or the location selected by the user. If the latter, then the patch should be installing to that location. Blair-2 wrote: Are your patches MSP files performing either small updates or minor upgrades? If so, the patch application won't let you patch anywhere other than the currently installed location since the keypath of the components can't be changed without a major upgrade. -Original Message- From: XorPtr [mailto:reaper4...@gmail.com] Sent: Wednesday, December 02, 2009 1:12 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Patching problems with alternate directories I've been having an issue with my WiX patch which I haven't been able to find any information for. The company I work for wants to give users the freedom to install our product in a directory of their choice. We've given the installer a default directory which can be changed at install time by the user. This has worked fine up until attempting to patch the package. I successfully made a patch which patches the package without problem if it's installed to the default location, however if users choose to install the product in an alternate location and then patch the patch fails because it's still trying to change files on the default location. Any ideas on how I can dynamically set up the patch install location based on where the user installs our product? Thanks in advance. Big Jim. -- View this message in context: http://n2.nabble.com/Patching-problems-with-alternate-directories-tp4102386p 4102386.html Sent from the wix-users mailing list archive at Nabble.com. -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- View this message in context: http://n2.nabble.com/Patching-problems-with-alternate-directories-tp4102386p 4142265.html Sent from the wix-users mailing list archive at Nabble.com. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Return on Information: Google Enterprise Search pays you back Get the facts.
Re: [WiX-users] How to specify files in Installer package
And yes, we need to make this experience better. There just wasn't time to get all the way there in WiX v3.0. On Thu, Dec 10, 2009 at 7:35 AM, Peter Shirtcliffe pshirtcli...@sdl.comwrote: You dont need to specify wix or component group. The component element will be matched when the matching algorithm reaches it and component is not used in any other contexts so specifying Component by itself is fine. However, since it appears wix is not your default namespace, you will need to prefix Component with wix: like this xsl:template match=wix:Component[ When you do this, its also useful to add exclude-result-prefixes=wix to your xsl:stylesheet element. (Yan also just replied with much the same advice. You dont need the component group in the match but theres no harm in having it either. You will need to write a template to remove the componentref element too, as mentioned there.) -Original Message- From: Markus Gaugusch [mailto:w...@gaugusch.at] Sent: 10 December 2009 15:10 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How to specify files in Installer package I can feel that I'm nearly there, but it doesn't work yet. This is my XSLT: ?xml version=1.0 ? xsl:transform version=1.0 xmlns:xsl=http://www.w3.org/1999/XSL/Transform; xmlns:wix=http://schemas.microsoft.com/wix/2006/wi; !-- By default, copy all attributes and elements to the output. -- xsl:template match=@*|* xsl:copy xsl:apply-templates select=@* / xsl:apply-templates select=* / /xsl:copy /xsl:template !-- Override copy (do nothing) for elements with this Id, so they are omitted from the output. -- xsl:template match=compone...@id='cmp20CFFB2FF46488AF2CD00E2C9543E202'] / /xsl:transform And my xml looks like that: ?xml version=1.0 encoding=utf-8? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; Fragment ComponentGroup Id=MyClient Component Id=cmp034A7A0245A16CFBB38E35D51794CF21 Directory=INSTALLDIR Guid=* File ... So, do I have to specify ComponentGroup, Fragment or Wix in the xslt file? How? thanks! Markus On Dec 10, Peter Shirtcliffe pshirtcli...@sdl.com wrote: You want to match the component element [with a given ID] in order to omit it, not match the Id attribute: xsl:template match=compone...@id='cmp20CFFB2FF46488AF2CD00E2C9543E202'] / Also be careful to match the exact case of the element and attribute names. If it still doesnt work, check that the wix namesapce is the default namespace. -Original Message- From: Markus Gaugusch [mailto:w...@gaugusch.at] Sent: 10 December 2009 14:26 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How to specify files in Installer package Hi Yan! I tried an example found at http://www.mail-archive.com/wix-users@lists.sourceforge.net/msg27515.h tm l -- but I'm unable to get it going :( I want to ignore Component Id=cmp20CFFB2FF46488AF2CD00E2C9543E202 Directory=INSTALLDIR Guid=* (which includes one file) I used the aforementioned example and tried with xsl:template match=@id[.='cmp20CFFB2FF46488AF2CD00E2C9543E202'] / But the filter doesn't seem to apply (my component is still in the output) can you help me? thanks, Markus On Dec 10, Yan Sklyarenko y...@sitecore.net wrote: Markus, The heat.exe has a switch -t:transform.xsl. If you specify this switch running heat, the 'transform.xsl' will be applied to the regular output of you heat command. The final resulting wxs file will contain transformed xml. There are no special requirements for that XSL transform. Hope this helps, -- Yan -- -- -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users SDL PLC confidential, all rights reserved. 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. SDL PLC is a public limited company registered in England and Wales. Registered number: 02675207. Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users --
Re: [WiX-users] Reserved directory Id names?
Yes, there definitely is. Feel free to file a bug then use .wixlibs instead of Merge Modules. wink/ On Thu, Dec 10, 2009 at 1:03 AM, John Aldridge j...@jjdash.demon.co.ukwrote: On 09/12/2009 17:55, Wilson, Phil wrote: All the CommonFilesFolder values in merge modules are by convention appended with a mangled guid, but as far as I can tell the mechanism that rationalizes all the folder name properties from merge modules (such as CommonFilesFolder.guid) at merge time is indiscriminate. If the folder name from the merge module *starts* with a standard folder property then the merge generates a CA to set it to the actual CommonFilesFolder. So when it gets merged into the MSI file it generates that type 51 custom action to set CommonFilesFolderanything at all to [CommonFilesFolder]. So yes, you're right, it is a really bad thing to use folder names in merge modules that start exactly like an actual folder name. Is there a case, then, for WiX giving a warning (or even an error) message if a Directory/@Id is used which starts with a predefined folder name? -- Cheers, John -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Question on updating GAC assemblies
We develop multiple applications using the same framwork, hence we put some DLL files in the GAC. Now I’m trying to patch an assembly in the GAC to a new version. I’m giving it a new strong name by increasing the build number and are then updating my application by reinstalling the MSI (minor upgrade) with the new assembly in it. So fooCore.dll is increased from version 1.0.0.0 = 1.0.1.0 After the upgrade both the old and the new version of the fooCore.dll assembly are placed in the GAC. When does the old assembly gets removed from the GAC? Does it ever? Since, on this particular test-computer, I have but one of our products installed, hence no other product is using/referencing version 1.0.0.0 of the fooCore.dll. Shouldn’t that one then be removed automaticly during the upgrade? Of course, if there were other products using fooCore.dll I understand why the first version would still be there, but now the 1.0.1.0 version is the only one in use. regards Daniel -- View this message in context: http://n2.nabble.com/Question-on-updating-GAC-assemblies-tp4146652p4146652.html Sent from the wix-users mailing list archive at Nabble.com. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patching problems with alternate directories
Hello, You may have already tried this but sometimes opening the msi and applying the patch with Orca can point out things that are buried in a verbose log like removing a component from a feature during a patch etc. Thanks, Tom -Original Message- From: XorPtr [mailto:reaper4...@gmail.com] Sent: Thursday, December 10, 2009 12:00 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Patching problems with alternate directories All of the components are listed as: Installed: Local; Request: Local; Action: Local. Blair-2 wrote: What does the log say about the component statuses? -Original Message- From: XorPtr [mailto:reaper4...@gmail.com] Sent: Thursday, December 10, 2009 6:27 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Patching problems with alternate directories Hey Blair-2, I'd be happy to share a log of the installation but unfortunately I'm doing this for a company and I'm not allowed to post the information for a log. I've studied the logs myself during patching and it looks like it doesn't recognize that the install path is different from C:\Program Files\Appname\etc. What it ends up outputting is a list of the files being installed by the patch but each one specifies To be installed; Won't patch; No existing file. If you're interested in a particular portion of the log file I might be able to show you by replacing the product and path information with fictional data so you could see what might be the problem without my violating my company's policies. Thank for all your help so far! Blair-2 wrote: The location that the components you are patching are already installed. Could you share a log that shows it not working in that circumstance? -Original Message- From: XorPtr [mailto:reaper4...@gmail.com] Sent: Wednesday, December 09, 2009 1:55 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Patching problems with alternate directories When you refer to the currently installed location, are you referring to the location that my product installs to by default or the location selected by the user. If the latter, then the patch should be installing to that location. Blair-2 wrote: Are your patches MSP files performing either small updates or minor upgrades? If so, the patch application won't let you patch anywhere other than the currently installed location since the keypath of the components can't be changed without a major upgrade. -Original Message- From: XorPtr [mailto:reaper4...@gmail.com] Sent: Wednesday, December 02, 2009 1:12 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Patching problems with alternate directories I've been having an issue with my WiX patch which I haven't been able to find any information for. The company I work for wants to give users the freedom to install our product in a directory of their choice. We've given the installer a default directory which can be changed at install time by the user. This has worked fine up until attempting to patch the package. I successfully made a patch which patches the package without problem if it's installed to the default location, however if users choose to install the product in an alternate location and then patch the patch fails because it's still trying to change files on the default location. Any ideas on how I can dynamically set up the patch install location based on where the user installs our product? Thanks in advance. Big Jim. -- View this message in context: http://n2.nabble.com/Patching-problems-with-alternate-directories-tp4102 386p 4102386.html Sent from the wix-users mailing list archive at Nabble.com. -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- View this message in context: http://n2.nabble.com/Patching-problems-with-alternate-directories-tp4102 386p 4142265.html Sent from the wix-users mailing list archive at Nabble.com.
[WiX-users] RES: failed while processing WebDirs
Ok, but this localization is for generic errors while processing virtual dirs? If is, I can't edit it to show specific error. -Mensagem original- De: Rob Mensching [mailto:r...@robmensching.com] Enviada em: quinta-feira, 10 de dezembro de 2009 05:35 Para: General discussion for Windows Installer XML toolset. Assunto: Re: [WiX-users] failed while processing WebDirs Yes, you can override the localization String/@Id=msierrIISFailedReadWebDirs On Wed, Dec 9, 2009 at 8:03 AM, Tales Aguiar tales.agu...@brseg.com wrote: Hello, My first version of my installer has created a duplicated 'Default Web Site' on client server. I made changes to use Web Site locator, but now throw error (Failed while processing WebDirs). After some attempts I found that the error occurred because the IP Address was not set to 'All Unassigned'. OK, perfect, but there is a way to change the error message? Att., Tales Aguiar. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patching problems with alternate directories
I definitely reviewed the tables for both my installer msi as well as my patch msp while trying to figure out this problem. I've never heard of applying a patch using orca before though, I took at look but didn't see an obvious way of doing this. Could you let me know how to use orca to apply the patch? Also the issue extends beyond patching to include repairs and uninstalls so I think the problem runs deeper than just how the patch is applied. Thomas Svare wrote: Hello, You may have already tried this but sometimes opening the msi and applying the patch with Orca can point out things that are buried in a verbose log like removing a component from a feature during a patch etc. Thanks, Tom -Original Message- From: XorPtr [mailto:reaper4...@gmail.com] Sent: Thursday, December 10, 2009 12:00 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Patching problems with alternate directories All of the components are listed as: Installed: Local; Request: Local; Action: Local. Blair-2 wrote: What does the log say about the component statuses? -Original Message- From: XorPtr [mailto:reaper4...@gmail.com] Sent: Thursday, December 10, 2009 6:27 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Patching problems with alternate directories Hey Blair-2, I'd be happy to share a log of the installation but unfortunately I'm doing this for a company and I'm not allowed to post the information for a log. I've studied the logs myself during patching and it looks like it doesn't recognize that the install path is different from C:\Program Files\Appname\etc. What it ends up outputting is a list of the files being installed by the patch but each one specifies To be installed; Won't patch; No existing file. If you're interested in a particular portion of the log file I might be able to show you by replacing the product and path information with fictional data so you could see what might be the problem without my violating my company's policies. Thank for all your help so far! Blair-2 wrote: The location that the components you are patching are already installed. Could you share a log that shows it not working in that circumstance? -Original Message- From: XorPtr [mailto:reaper4...@gmail.com] Sent: Wednesday, December 09, 2009 1:55 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Patching problems with alternate directories When you refer to the currently installed location, are you referring to the location that my product installs to by default or the location selected by the user. If the latter, then the patch should be installing to that location. Blair-2 wrote: Are your patches MSP files performing either small updates or minor upgrades? If so, the patch application won't let you patch anywhere other than the currently installed location since the keypath of the components can't be changed without a major upgrade. -Original Message- From: XorPtr [mailto:reaper4...@gmail.com] Sent: Wednesday, December 02, 2009 1:12 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Patching problems with alternate directories I've been having an issue with my WiX patch which I haven't been able to find any information for. The company I work for wants to give users the freedom to install our product in a directory of their choice. We've given the installer a default directory which can be changed at install time by the user. This has worked fine up until attempting to patch the package. I successfully made a patch which patches the package without problem if it's installed to the default location, however if users choose to install the product in an alternate location and then patch the patch fails because it's still trying to change files on the default location. Any ideas on how I can dynamically set up the patch install location based on where the user installs our product? Thanks in advance. Big Jim. -- View this message in context: http://n2.nabble.com/Patching-problems-with-alternate-directories-tp4102 386p 4102386.html Sent from the wix-users mailing list archive at Nabble.com. -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth
[WiX-users] Adding Files Using Patch
I cannot for the life of me work out how to add files when using a delta patch. It works easily enough without the delta flag even when not creating a new component for the new files (just adding them to an exisiting one). However with the delta patch i always get Info 1334. The file 'SampleFile' cannot be installed because the file cannot be found in cabinet file 'RTM.cab'. This could indicate a network error, an error reading from the CD-ROM, or a problem with this package. I am adding the files within a new component and updating the major version number of the product. I am building using wixpdbs. I am running msiexec with REINSTALL=ALL REINSTALLMODE=amus REBOOT=Supress /qb /p I tried doing it in two patches, first non-delta just adding the files and then second doing the delta on everything else but still got the same error. What else can I do to make this work? This must be a very common operation isn't it? -- View this message in context: http://n2.nabble.com/Adding-Files-Using-Patch-tp4146882p4146882.html Sent from the wix-users mailing list archive at Nabble.com. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] AdvanceUI for the default installation being [ProgramFilesFolder]
Yes, that is what I wanted. Why? well, the default installation will be C:\PF\ProductName\VX.Y where we do not expose the ProductName\VX.Y (to make sure we control that path on SxS installations) But if the user selects the advance installation, we only want to show C:\PF for them to see and change, and hence the quiestion about this change, even if they do not change anythign on the advance installation it will always attach ProductName\VX.Y to the installation path, so we really do not install on PF, but that is what I want to show. Thanks ANdres From: r...@robmensching.com Date: Wed, 9 Dec 2009 23:38:25 -0800 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] AdvanceUI for the default installation being [ProgramFilesFolder] The APPLCIATIONFOLDER Directory will end up resolving to ProgramFilesFolder with this code. Why do you want to install straight into ProgamFilesFolder? That seems odd. On Wed, Dec 9, 2009 at 6:06 PM, Andres Juarez andresj_...@hotmail.comwrote: Hi All, In the exemple in the SDK to use the AdvanceUI: Directory Id=TARGETDIR Name=SourceDir Directory Id=ProgramFilesFolder Name=PFiles Directory Id=APPLICATIONFOLDER Name=My Application Folder ... /Directory /Directory /Directory Property Id=ApplicationFolderName Value=My Application Folder / For a per-machine installation, the default installation location will be [ProgramFilesFolder][ApplicationFolderName] What would it be the approach if I want to use the AdvanceUI but the default installation being [ProgramFilesFolder] I have tried the below and it seems to work, (ICE pass too) but I am not sure if that property will be used anywhere else: Directory Id=TARGETDIR Name=SourceDir Directory Id=ProgramFilesFolder Name=PFiles Directory Id=APPLICATIONFOLDER ... /Directory /Directory /Directory !--Property Id=ApplicationFolderName Value=ProgramFilesFolder/-- Thanks Andres _ Get gifts for them and cashback for you. Try Bing now. http://www.bing.com/shopping/search?q=xbox+gamesscope=cashbackform=MSHYCBpubl=WLHMTAGcrea=TEXT_MSHYCB_Shopping_Giftsforthem_cashback_1x1 -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users _ Chat with Messenger straight from your Hotmail inbox. http://www.microsoft.com/windows/windowslive/hotmail_bl1/hotmail_bl1.aspx?ocid=PID23879::T:WLMTAGL:ON:WL:en-ww:WM_IMHM_4:092009 -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] MSI built with WiX inconsistently misreporting file sizes as 0KB
I'm using WiX 3.0 in Visual Studio 2008. I have created an MSI using WiX. I now have an issue with the displayed file size in the Custom Setup screen. I have 9 features to install: the core files, plus 8 optional files. These optional files are quite large, between about 60 and 150 MB each. The issue is that the size of these files is frequently misreported in the installer's Custom Setup screen as 0 KB, and I can't figure out why. The displayed size does not change between builds; however, I cannot figure out a consistent method of building an MSI so that the file sizes are the same. I have tried all 4 combinations of light -sh for the linker and, in my .wxs file, component\fi...@defaultsize=123456 (i.e. using the -sh switch with DefaultSize set, not using the -sh switch with DefaultSize set, etc.) and I can't see a consistent pattern. The documentation (http://wix.sourceforge.net/manual-wix3/light.htm, http://wix.sourceforge.net/manual-wix2/wix_xsd_file.htm) suggests to me that I should leave DefaultSize undefined and NOT use the -sh switch, and that is what I am doing now. At this moment, the file sizes are reported correctly in my build. However, I have built the installer with these same conditions previously, and got only a 0 KB for the file sizes. So my concern is that I will put my .wxs file into version control and someone else will use it for a build, resulting in the 0 KB condition I don't want. Thanks, Jerry -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patching problems with alternate directories
Thanks for the tip Tom, I'm looking into at least one discrepency that I saw come up after the Orca/patch transform. I'm not sure if it's causing this error or not but chances are it would have caused problems down the road. The second issue you mentioned I was curious about as well. Do you know of anything that could cause a property to be set by the UI and not by repair and uninstall? I could see this happening with registry key entries which shouldn't be the case in my installer, but could you help me to understand what to look for with troublesome UI properties as well? Thomas Svare wrote: Hello, You just open the msi with Orca then choose Transform-View Patch and navigate to the msp and select OK and you'll see the changes in Orca. Since repairs and uninstalls are showing the problem it sounds like some property is getting set by the UI that isn't being re-set during patch/repair/uninstall. Thanks, Tom -Original Message- From: XorPtr [mailto:reaper4...@gmail.com] Sent: Thursday, December 10, 2009 12:59 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Patching problems with alternate directories I definitely reviewed the tables for both my installer msi as well as my patch msp while trying to figure out this problem. I've never heard of applying a patch using orca before though, I took at look but didn't see an obvious way of doing this. Could you let me know how to use orca to apply the patch? Also the issue extends beyond patching to include repairs and uninstalls so I think the problem runs deeper than just how the patch is applied. Thomas Svare wrote: Hello, You may have already tried this but sometimes opening the msi and applying the patch with Orca can point out things that are buried in a verbose log like removing a component from a feature during a patch etc. Thanks, Tom -Original Message- From: XorPtr [mailto:reaper4...@gmail.com] Sent: Thursday, December 10, 2009 12:00 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Patching problems with alternate directories All of the components are listed as: Installed: Local; Request: Local; Action: Local. Blair-2 wrote: What does the log say about the component statuses? -Original Message- From: XorPtr [mailto:reaper4...@gmail.com] Sent: Thursday, December 10, 2009 6:27 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Patching problems with alternate directories Hey Blair-2, I'd be happy to share a log of the installation but unfortunately I'm doing this for a company and I'm not allowed to post the information for a log. I've studied the logs myself during patching and it looks like it doesn't recognize that the install path is different from C:\Program Files\Appname\etc. What it ends up outputting is a list of the files being installed by the patch but each one specifies To be installed; Won't patch; No existing file. If you're interested in a particular portion of the log file I might be able to show you by replacing the product and path information with fictional data so you could see what might be the problem without my violating my company's policies. Thank for all your help so far! Blair-2 wrote: The location that the components you are patching are already installed. Could you share a log that shows it not working in that circumstance? -Original Message- From: XorPtr [mailto:reaper4...@gmail.com] Sent: Wednesday, December 09, 2009 1:55 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Patching problems with alternate directories When you refer to the currently installed location, are you referring to the location that my product installs to by default or the location selected by the user. If the latter, then the patch should be installing to that location. Blair-2 wrote: Are your patches MSP files performing either small updates or minor upgrades? If so, the patch application won't let you patch anywhere other than the currently installed location since the keypath of the components can't be changed without a major upgrade. -Original Message- From: XorPtr [mailto:reaper4...@gmail.com] Sent: Wednesday, December 02, 2009 1:12 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Patching problems with alternate directories I've been having an issue with my WiX patch which I haven't been able to find any information for. The company I work for wants to give users the freedom to install our product in a directory of their choice. We've given the installer a default directory which can be changed at install time by the user. This has worked fine up until attempting to patch the package. I successfully made a patch which patches the package without problem if it's installed to the default location, however if users choose to install
Re: [WiX-users] How Do I Verify Group Membership?
You said something I was not aware of. add that local user/group to the appropriate domain group. Can you really add local users and groups to a domain group? Where can I find documentation that explains how to do that? I'm an AD newbie. How would you handle a database deployment that needs to grant permissions to service account a service is going to be running as? 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: Richard [mailto:legal...@xmission.com] Sent: Wednesday, December 09, 2009 7:56 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] How Do I Verify Group Membership? Believe me, I hear you. I went through all this when I was on the install team at Medium Sized Corporation. MSC initially had a philosophy of trying to cram everything into the install. Eventually, they learned that the tools used in post install configuration were useful in maintenance operations that their customers were already doing. Initially the install team argued for making the install as simple as possible, but were forced to implement requirements similar to those you describe (all in the install). This created problems because the added complexity in the install which caused more points of failure in the install, particularly in upgrade, patching and repair scenarios. Eventually, configuration operations were moved to a utility program -- generally this was a matter of database operations, but it could be anything. I would still create a local user/group that your code uses and add that local user/group to the appropriate domain group that they use to grant you domain priveleges. In other words don't run *as* their domain user/group; run as your own user/group and have them add that user/group to the appropriate domain group that has the priveleges you need. This decouples you from their setup and makes your security environment more granular and amenable to control/policy. -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://legalizeadulthood.wordpress.com/the-direct3d-graphics- pipeline/ Legalize Adulthood! http://legalizeadulthood.wordpress.com --- --- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patching problems with alternate directories
Hello, Try looking at the property dump section of a verbose log and compare the directory table entry values between a good default install and a bad patch/repair/uninstall. INSTALLDIR is has been an issue for me in the past. Thanks, Tom -Original Message- From: XorPtr [mailto:reaper4...@gmail.com] Sent: Thursday, December 10, 2009 3:50 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Patching problems with alternate directories Thanks for the tip Tom, I'm looking into at least one discrepency that I saw come up after the Orca/patch transform. I'm not sure if it's causing this error or not but chances are it would have caused problems down the road. The second issue you mentioned I was curious about as well. Do you know of anything that could cause a property to be set by the UI and not by repair and uninstall? I could see this happening with registry key entries which shouldn't be the case in my installer, but could you help me to understand what to look for with troublesome UI properties as well? Thomas Svare wrote: Hello, You just open the msi with Orca then choose Transform-View Patch and navigate to the msp and select OK and you'll see the changes in Orca. Since repairs and uninstalls are showing the problem it sounds like some property is getting set by the UI that isn't being re-set during patch/repair/uninstall. Thanks, Tom -Original Message- From: XorPtr [mailto:reaper4...@gmail.com] Sent: Thursday, December 10, 2009 12:59 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Patching problems with alternate directories I definitely reviewed the tables for both my installer msi as well as my patch msp while trying to figure out this problem. I've never heard of applying a patch using orca before though, I took at look but didn't see an obvious way of doing this. Could you let me know how to use orca to apply the patch? Also the issue extends beyond patching to include repairs and uninstalls so I think the problem runs deeper than just how the patch is applied. Thomas Svare wrote: Hello, You may have already tried this but sometimes opening the msi and applying the patch with Orca can point out things that are buried in a verbose log like removing a component from a feature during a patch etc. Thanks, Tom -Original Message- From: XorPtr [mailto:reaper4...@gmail.com] Sent: Thursday, December 10, 2009 12:00 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Patching problems with alternate directories All of the components are listed as: Installed: Local; Request: Local; Action: Local. Blair-2 wrote: What does the log say about the component statuses? -Original Message- From: XorPtr [mailto:reaper4...@gmail.com] Sent: Thursday, December 10, 2009 6:27 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Patching problems with alternate directories Hey Blair-2, I'd be happy to share a log of the installation but unfortunately I'm doing this for a company and I'm not allowed to post the information for a log. I've studied the logs myself during patching and it looks like it doesn't recognize that the install path is different from C:\Program Files\Appname\etc. What it ends up outputting is a list of the files being installed by the patch but each one specifies To be installed; Won't patch; No existing file. If you're interested in a particular portion of the log file I might be able to show you by replacing the product and path information with fictional data so you could see what might be the problem without my violating my company's policies. Thank for all your help so far! Blair-2 wrote: The location that the components you are patching are already installed. Could you share a log that shows it not working in that circumstance? -Original Message- From: XorPtr [mailto:reaper4...@gmail.com] Sent: Wednesday, December 09, 2009 1:55 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Patching problems with alternate directories When you refer to the currently installed location, are you referring to the location that my product installs to by default or the location selected by the user. If the latter, then the patch should be installing to that location. Blair-2 wrote: Are your patches MSP files performing either small updates or minor upgrades? If so, the patch application won't let you patch anywhere other than the currently installed location since the keypath of the components can't be changed without a major upgrade. -Original Message- From: XorPtr [mailto:reaper4...@gmail.com] Sent: Wednesday, December 02, 2009 1:12 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Patching problems with alternate directories I've been having an issue with my WiX patch which I haven't been able to
Re: [WiX-users] How do you set APRNOMODIFY in WIX - I get a compileerror when I do it.
http://www.tramontana.co.hu/wix/lesson6.php#6.7 Also, verify that it is not defined twice. AFAIR, certain WiX UI mode has it defined... -- Yan From: Robert Hermann [mailto:rob.herm...@nicewareintl.com] Sent: Thu 12/10/2009 20:51 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] How do you set APRNOMODIFY in WIX - I get a compileerror when I do it. In my wix program I have set ARPNOMODIFY to 0 which prevents doing it through ARP. Property Id =ARPNOMODIFY Value =0/Property But when I compile I get this error what am I doing wroing Error 2 The primary key 'ARPNOMODIFY' is duplicated in table 'Property'. Please remove one of the entries or rename a part of the primary key to avoid the collision. Rob Hermann Senior Software Developer Niceware International, LLC 10437 Innovation Drive Suite 147 Milwaukee, WI 53226 Tel: 414-476-6423 x110 Fax: 414-476-7955 Email: rob.herm...@nicewareintl.com http://www.nicewareintl.com http://www.nicewareintl.com/ http://healthcare.nicewareintl.com http://healthcare.nicewareintl.com/ December 4th - 10:30AM CST - 11:30AM CST - Benefits of Upgrading from NiceLabel v3 to NiceLabel v5 - Register Today! December 11th - 10:30AM CST - 11:30AM CST - A Complete Introduction to LabelClinic CT - Register Today! December 18th - 10:30AM CST - 11:30AM CST - A Complete Introduction to NiceLabel SDK and WebSDK - Register Today! The information in this e-mail and any attachments is confidential and may be subject to legal professional privilege. It is intended solely for the attention and use of the named addressee(s). If you are not the intended recipient or person responsible for delivering this information to the intended recipient, please notify the sender immediately. Unless you are the intended recipient or his/her representative you are not authorized to, and must not, read, copy, distribute, use or retain this message or any part of it -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Question on updating GAC assemblies
Something here on that: http://blogs.msdn.com/astebner/archive/2008/08/10/8847259.aspx and you should keep the assembly name values the same (so don't change the strong name). Phil Wilson -Original Message- From: DanR [mailto:daniel.roberts...@repab.se] Sent: Thursday, December 10, 2009 9:36 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Question on updating GAC assemblies We develop multiple applications using the same framwork, hence we put some DLL files in the GAC. Now I’m trying to patch an assembly in the GAC to a new version. I’m giving it a new strong name by increasing the build number and are then updating my application by reinstalling the MSI (minor upgrade) with the new assembly in it. So fooCore.dll is increased from version 1.0.0.0 = 1.0.1.0 After the upgrade both the old and the new version of the fooCore.dll assembly are placed in the GAC. When does the old assembly gets removed from the GAC? Does it ever? Since, on this particular test-computer, I have but one of our products installed, hence no other product is using/referencing version 1.0.0.0 of the fooCore.dll. Shouldn’t that one then be removed automaticly during the upgrade? Of course, if there were other products using fooCore.dll I understand why the first version would still be there, but now the 1.0.1.0 version is the only one in use. regards Daniel -- View this message in context: http://n2.nabble.com/Question-on-updating-GAC-assemblies-tp4146652p4146652.html Sent from the wix-users mailing list archive at Nabble.com. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users *** Confidentiality Notice: This e-mail, including any associated or attached files, is intended solely for the individual or entity to which it is addressed. This e-mail is confidential and may well also be legally privileged. If you have received it in error, you are on notice of its status. Please notify the sender immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person. This email comes from a division of the Invensys Group, owned by Invensys plc, which is a company registered in England and Wales with its registered office at Portland House, Bressenden Place, London, SW1E 5BF (Registered number 166023). For a list of European legal entities within the Invensys Group, please go to http://www.invensys.com/legal/default.asp?top_nav_id=77nav_id=80prev_id=77. You may contact Invensys plc on +44 (0)20 7821 3848 or e-mail inet.hqhelpd...@invensys.com. This e-mail and any attachments thereto may be subject to the terms of any agreements between Invensys (and/or its subsidiaries and affiliates) and the recipient (and/or its subsidiaries and affiliates). -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Instance transforms with the msi
Thanks for all the pointers! I grouped the non file data in this recommended method and it is working beautifully. Thanks! Uma- -Original Message- From: John Nannenga [mailto:john.nanne...@microsoft.com] Sent: Wednesday, December 09, 2009 7:50 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Instance transforms with the msi Here's the key point from the SDK: * To keep the nonfile data of each instance isolated, the base package should collect nonfile data into sets of components for each instance. The appropriate components should then be installed based on conditional statements that depend on the instance identifier. The emphasis here is on nonfile data; which includes (but not limited to) shortcuts, registry items, ini items, ODBC items [and the list goes on and on]. You do not 'have' to do this for file data. The SDK recommendation here is to (if you're going to support multiple instances) segregate nonfile data into their own components which would then have their own unique component GUIDs and installed conditionally based upon the instance identifier. To answer your question then, Uma: I find that HKLM\Software\ESRI\Instance1 is still left behind on the machine after instance 1 is uninstalled. Is this because the component that includes this registry key is still in the installed state with the base setup? I believe that occurs because the component was ref-counted. What you would see then is that when the last instance is uninstalled, the registry information for only that instance would be removed, but all the other instance registry keys would remain (thus, orphaned). You can also run into this situation when you upgrade a product and are performing 'efficient upgrades' where the registry information location for that instance changes. You'll need to change the component GUID in this situation as well. From: Michael Osmond [mosm...@baytech.com.au] Sent: Monday, December 07, 2009 5:46 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Instance transforms with the msi Hi If you are using MSI Instances and installing to different locations, you don't need different component GUIDs for each component in each installed instance and the reference counting seems to work okay. I will be honest and say I don't know how it works under the hood, but it does work.The installer is able to work out where things are. I do however use a registry key for each instance to keep the path where I installed that instance too, which comes in handy on major upgrades. Also have found it usefull to record the product ID of the instance in the registry as well. Michael From: kelly.le...@milliman.com [kelly.le...@milliman.com] Sent: Tuesday, 8 December 2009 9:32 AM To: General discussion for Windows Installer XML toolset. Cc: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Instance transforms with the msi I wasn't asking about ProductCode. I'm asking about the component GUID for the registry key you're referring to. You need to assign different GUIDs for all components that could be installed in two locations by the two different instances. If you want to install the same files in two places, you're going to have to modify all the component GUIDs for the files, if I understand the process correctly. I'm not an expert on using instance transforms to install multiple instances, but it seems like no matter what you do, you can't break the component rules. Otherwise, it won't install the files to the new locations, since it will think they are already installed (based on the component ID and its installed state). Kelly Uma Harano uhar...@esri.com 12/07/2009 03:24 PM Please respond to General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net To General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net cc Subject Re: [WiX-users] Instance transforms with the msi Each instance has a unique Product Code. Also, I was following the guidelines from the Windows installer SDK (On how to author instance transforms). How do I install the same set of files for multiple instances using transforms? Please advise! Uma- Here is the windows installer sdk topic on this: Authoring Multiple Instances with Instance Transforms To install multiple instances of a product from one Windows(r) Installer package, you need to author a base installation package for the product and an instance transform for each instance to be installed in addition to the base instance. Use the following guidelines when authoring your base package and transforms: *Your setup application can check for the presence of the installer running on a version of the Microsoft(r)Windows Server 2003 family, Windows XP SP1, Windows 2000 SP4 and the Windows Installer
Re: [WiX-users] Reserved directory Id names?
On 10/12/2009 17:10, Rob Mensching wrote: Yes, there definitely is. Feel free to file a bug then use .wixlibs instead of Merge Modules. wink/ On 09/12/2009 17:55, Wilson, Phil wrote: All the CommonFilesFolder values in merge modules are by convention appended with a mangled guid, but as far as I can tell the mechanism that rationalizes all the folder name properties from merge modules (such as CommonFilesFolder.guid) at merge time is indiscriminate. If the folder name from the merge module *starts* with a standard folder property then the merge generates a CA to set it to the actual CommonFilesFolder. So when it gets merged into the MSI file it generates that type 51 custom action to set CommonFilesFolderanything at all to [CommonFilesFolder]. So yes, you're right, it is a really bad thing to use folder names in merge modules that start exactly like an actual folder name. Is there a case, then, for WiX giving a warning (or even an error) message if a Directory/@Id is used which starts with a predefined folder name? Thanks, both, for your help. Bug submitted. I look forward to being able to use wixlibs, but for the moment at least I need retain compatibility with InstallShield :( -- Cheers, John -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How Do I Verify Group Membership?
One thing to consider with this type of requirement, is how to define the scope of installation Many setup developers consider install as a much narrower scope than those who are defining the requirements. Leveraging a configuration utility on MSI setup completion (via a bootstrapper or the finish button) is still part of the install process from a users point of view. For example, our installation comes in two flavours... For retail customers, we provide an interactive installation that doesn't try to gather any config date, they step through the UI, install the software and on pressing the Finish button we launch a separate configuration utility. For corporate customers, we provide a tool to set installation parameters, then using the Windows Installer API we create an MST file. The MSI provided to corporate customers doesn't provide any UI, so the application checks on first run to ensure it's configured properly and only requires post-install steps as a fallback option for when information wasn't provided pre-install. HTH. Sascha On Thu, Dec 10, 2009 at 1:46 PM, Castro, Edwin G. (Hillsboro) edwin.cas...@fiserv.com wrote: Enter Requirement X: There should be no post-install configuration. I tell you, these requirement peoples just love to get in the way! ;-) BTW: I completely agree with you. I'm just pointing out that sometimes we get forced to implement ugly requirements. I have to choose my battles. This one is relatively minor so I don't complain so much. 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: Richard [mailto:legal...@xmission.com] Sent: Wednesday, December 09, 2009 6:19 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] How Do I Verify Group Membership? shrug I don't think I would try to cram this into the installer. If the installer isn't going to change the group membership, then it shouldn't be gathering the information to query the group membeship. Do it after installation time with a standalone configuration utility. That way they can change which domain user/group they use at any time. -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://legalizeadulthood.wordpress.com/the-direct3d-graphics- pipeline/ Legalize Adulthood! http://legalizeadulthood.wordpress.com --- --- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Adding Files Using Patch
If the file didn't exist in the baseline image there really shouldn't be a difference for that file by merely adding the delta switch. Is this something where you can share the wixmst file with me? -Original Message- From: nearnick [mailto:n...@nearglobal.com] Sent: Thursday, December 10, 2009 10:08 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Adding Files Using Patch I cannot for the life of me work out how to add files when using a delta patch. It works easily enough without the delta flag even when not creating a new component for the new files (just adding them to an exisiting one). However with the delta patch i always get Info 1334. The file 'SampleFile' cannot be installed because the file cannot be found in cabinet file 'RTM.cab'. This could indicate a network error, an error reading from the CD-ROM, or a problem with this package. I am adding the files within a new component and updating the major version number of the product. I am building using wixpdbs. I am running msiexec with REINSTALL=ALL REINSTALLMODE=amus REBOOT=Supress /qb /p I tried doing it in two patches, first non-delta just adding the files and then second doing the delta on everything else but still got the same error. What else can I do to make this work? This must be a very common operation isn't it? -- View this message in context: http://n2.nabble.com/Adding-Files-Using-Patch-tp4146882p4146882.html Sent from the wix-users mailing list archive at Nabble.com. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Validation on UI dialogs
In article 4d6ef6e1711cde4e93d1f1e591a614d6345...@nl1mail0302.global.sdl.corp, Igor Paniushkin ipaniush...@sdl.com writes: It is not really related to your question, but I had a question about popup message box from custom action and I got an answer from Bob Arnson: Set a property in the CA and use that property as the condition in a SpawnDialog control event to show a message box. Never show UI from a CA; there's no way to get the same UI level information that MSI uses to determine whether UI should be shown. So probably try to change not to popup message box from CA, but SpawnDialog (new dialog?) from installer UI and maybe after closing it, you will have a correct focus. I agree with Bob, you should not be calling MessageBox directly from a CA. However, there is a way to have Windows Installer display a message box from a CA with ::MsiProcessMessage. I've used this to detect error conditions and conditionally fail a deferred CA based on a yes/no response from the user. If you use MsiProcessMessage, than even a deferred CA can display a message box. For immediate UI related CAs, its better to use the SpawnDialog approach however. -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/ Legalize Adulthood! http://legalizeadulthood.wordpress.com -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
