[WiX-users] How to detect which older version is already present on target machine ?
how to detect which older version of product is already present on target machine ? Regards, Sanjay -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] How to add UI for Minor Patches(msp)?
hi, I made a minor patch with PatchCreation, .pcp and MsiMsp.exe But the msp doesn't have any Wizard UIs. How to add UI for that? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; PatchCreation Id=224C316D-5894-4771-BABF-21A3AC1F75FF CleanWorkingFolder=yes OutputPath=patch.pcp WholeFilesOnly=yes Codepage=932 PatchInformation Description=$(var.AppFullName) Updater $(var.PatchVersion) Comments=$(var.AppFullName) Updater $(var.PatchVersion) ShortNames=no Languages=1041 Compressed=yes Manufacturer=Our Company/ PatchMetadata AllowRemoval=yes Description=$(var.AppFullName) Updater $(var.PatchVersion) ManufacturerName=Our Company TargetProductName=$(var.AppFullName) MoreInfoURL=http://www.ours.co.jp; Classification=Update DisplayName=$(var.AppFullName) Updater $(var.PatchVersion)/ Family DiskId=5000 MediaSrcProp=Sample Name=Sample SequenceStart=5000 UpgradeImage SourceFile=Maou11.msi Id=SampleUpgrade TargetImage SourceFile=Maou.msi Order=2 Id=SampleTarget IgnoreMissingFiles=no / /UpgradeImage /Family PatchSequence PatchFamily=SamplePatchFamily Sequence=1.0.0.0 Supersede=yes / /PatchCreation /Wix -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Conditionally Show Dialog Button based onInstalleraction (installed vs. removed vs. repaired, etc)
So you're telling us you have trouble knowing the contents of a file you're installing on the target machine until after it's been installed? Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Jeremy Rimer [mailto:jeremyri...@gmail.com] Sent: 14 July 2010 17:40 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Conditionally Show Dialog Button based onInstalleraction (installed vs. removed vs. repaired, etc) funny you mention that... The original requirements of this installer were to prompt the user the defaults provided in the App.Config file of the deployed program, which meant that we COULDNT prompt the user for settings before the files were copied. It turned out that particular action was impossible ANYWAY, because you can't modify the session for use in dialogs AFTER the files are copied, only prior in the UI sequence... So perhaps if I re-engineered this whole thing to prompt FIRST, I can avoid these problems? The way it is currently written, you can either overwrite, or set the settings OPTIONALLY before exiting the installer. (i.e. leave the app.config unmolested from the installation, or prior installation, OR, branch off and edit the entries, and submit to update the deployed app.config file... On Wed, Jul 14, 2010 at 11:29 AM, Pally Sandher pally.sand...@iesve.comwrote: Wouldn't it be better to ask the user the configuration questions during the UI Sequence make the modifications to the app.config using XMLConfig as part of the install process? That way you could condition when your dialog is shown more appropriately instead of needing multiple ExitDialogs and you'd be following standard expected installer conventions. Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Jeremy Rimer [mailto:jeremyri...@gmail.com] Sent: 14 July 2010 17:09 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Conditionally Show Dialog Button based on Installeraction (installed vs. removed vs. repaired, etc) I put ![CDATA[NOT INSTALLED=1]] in those Show elements, but it still showed the MyExitDialog in both the Remove and Install paths... ? On Wed, Jul 14, 2010 at 10:55 AM, Dan Hoeger dan.hoe...@microsoft.comwrote: INSTALLED is still undefined at the end of the initial install. So you would want the condition below to be NOT INSTALLED to be true for the initial install. -Original Message- From: Jeremy Rimer [mailto:jeremyri...@gmail.com] Sent: Wednesday, July 14, 2010 10:25 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Conditionally Show Dialog Button based on Installer action (installed vs. removed vs. repaired, etc) I must also add that under my custom exit dialog, I have this: == InstallUISequence Show Dialog=MyExitDialog OnExit=success![CDATA[INSTALLED]]/Show /InstallUISequence AdminUISequence Show Dialog=MyExitDialog OnExit=success ![CDATA[INSTALLED]]/Show /AdminUISequence == ... but this just causes NO exit dialog to show in both Install and Remove paths of the installer :( -Jeremy On Wed, Jul 14, 2010 at 10:17 AM, Jeremy Rimer jeremyri...@gmail.com wrote: I have one last problem before my installer is completely working: I have a custom EXIT dialog that I created called MyExitDialog that contains an extra button that spawns a custom dialog to gather application settings from the user to write into the App.Config file that was deployed and/or existed during installation or repair. The dialog does its job, but unfortunately it also displays (and does its job) after an application has been removed with the installer, which is useless, of course since there's no more app.config file to care about on a removal of the application. I see in the Publish elements how to conditionally control what a button * does*, but how do you conditionally control when a button *shows itself*in its dialog? If this is impossible, how can I force the installer to display the standard WIX ExitDialog instead of MyExitDialog in the case of a
Re: [WiX-users] Virtual directories not deleted when uninstalling
Thanks for your suggestion, I got the solution for my problem also. :) srinivas -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Virtual-directories-not-deleted-when-uninstalling-tp688905p5296608.html Sent from the wix-users mailing list archive at Nabble.com. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] About running Any CPU custom EXE from 32bit MSI on 64bit machine
Hi everyone, We are running custom EXEs ( .NET 2.0 console application ) built with Any CPU platform from a 32bit MSI on 64bit machine. In the custom EXE, we use * Environment.GetFolderPath(Environment.SpecialFolder.ProgramFiles)* to execute some custom logic on our files installed in the ProgramFiles folder path. The issue is on 64bit machine: 32bit MSI installs files to C:\Program Files (x86)\ custom EXE runs logic in C:\Program Files\ ... we think this is because it was built for Any CPU platform In the CustomAction node, we tried to set Win64=no so that it runs the custom EXE as if it were on 32bit machine. However, still the custom EXE runs logic in C:\Program Files\ instead of C:\Program Files (x86)\ Do you have any suggestions ? Thanks Chirag -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to detect which older version is already present on target machine ?
http://www.tramontana.co.hu/wix/lesson4.php#4.1 Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Sanjay Rao [mailto:s...@noida.interrasystems.com] Sent: 15 July 2010 07:19 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] How to detect which older version is already present on target machine ? how to detect which older version of product is already present on target machine ? Regards, Sanjay -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] FileSharePermission - Change?
Probably the correct combination of flags. On Wed, Jul 14, 2010 at 12:13 AM, Elfe Xu elf...@microsoft.com wrote: WOW! GenericRead + Traverse really works for Read! Why it has such an interesting behavior? Is it a bug or by design? The GenericRead='yes' Traverse='yes' seems to give Read. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/FileSharePermission-Change-tp711870p5291311.html Sent from the wix-users mailing list archive at Nabble.com. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Restart Manager (reboot after uninstall)
Maybe: the CloseApps WiX extension could detect that your shell extension is loaded and then you could use that to condition a ScheduleReboot action. On Wed, Jul 14, 2010 at 1:36 PM, i...@roadrunner.com wrote: Right. So basically the Windows Installer/Restart Manager combo don't work very well for shell extensions that can be loaded in various processes. Probably the best thing I can do is try to detect the user's response to the Restart Manager prompt run a ScheduleReboot action if the user has selected to not close the offending processes. Also if running in basic UI mode and the shell feature is installed. Looking at the sources, I think I can do something like: InstallExecuteSequence ScheduleReboot After='InstallFinalize'WixUIRMOption=DontUseRM OR (UILevel=2 AND !MyFeature=3)/ScheduleReboot /InstallExecuteSequence Blair os...@live.com wrote: Believe it or not, there is a saying oft repeated in the hallways at Microsoft: Reboots are evil. The current design in Windows Installer is to request a reboot only when under no reasonable scenario can the reboot be avoided (such as an upgrade of a running program when the program won't die during the upgrade). If a running program is holding a file in use, Windows Installer will move/rename that file and mark it for removal upon the next reboot (the move is into a hidden directory). If the move happens as a result of a removal attempt, the file is considered to be safe for the program to continue to use until it is shutdown by the user at their convenience (it is up to each program to fail gracefully if some other file they didn't hold open is suddenly missing or who's version/content suddenly changes). If, on the other hand, the developer of the program knows that the program can't safely continue to use the file(s), it is up to the developer to stop the running instances of the program(s) or force a reboot, since Windows Installer cannot possibly know who is good at defensive programming and who is not (even when the program comes from the Windows team). -Original Message- From: i...@roadrunner.com [mailto:i...@roadrunner.com] Sent: Wednesday, July 14, 2010 12:16 PM To: General discussion for Windows Installer XML toolset. Cc: Blair Subject: Re: [WiX-users] Restart Manager (reboot after uninstall) OK, so basically you are saying that the restart prompt is only supposed to appear during an upgrade when a file is being replaced. In my case I'm always using a major upgrade, so the old version is uninstalled first, then the new one is installed. No file is directly overwritten. It is a bit weird that the system doesn't handle uninstalls or major upgrades, but I can live with that. I don't have a problem if I'm getting the intended behavior. My only concern is that I'm somehow breaking a feature I'm supposed to get out of the box. Blair os...@live.com wrote: In scenario #1, Windows Installer will not by default [prompt for] reboot. In scenario #2, there are two possibilities: 2.1 - RemoveExistingProducts is scheduled early and this is a major upgrade: Removal of the old file occurs before writing of the new file: no [prompt for] reboot (same as scenario #1). 2.2 - all other cases (RemoveExistingProducts scheduled late or non-major upgrade): File is overwritten (assuming that the component rules were followed) and a prompt for reboot occurs. For any other possibility you have to detect the situation yourself and ask for the reboot prompt. The simplest way is to always ask for reboot except for clean initial installation, or ask for reboot always (I assume that the shell has to be restarted no matter what to start using a new shell extension). The next simplest is to change your MsiRMFilesInUse dialog such that the ignore button is either disabled, hidden or removed (thus the user has no choice but to use the restart manager), although that won't help with basic or silent installations. The third option is to add an embedded UI (assuming your minimum MSI version is 4.5) or ensure that your transactions are always under the control of a bootstrapper (hard to do, under the best circumstances) and capture the MsiRMFilesInUse call to always return a code for using the restart manager without ever showing the option to the user. Next harder is to duplicate the files-in-use logic yourself and set a property. There may be some property that gets set when a file-in-use is detected, but I have never seen it. -Original Message- From: Ivo Beltchev [mailto:i...@roadrunner.com] Sent: Wednesday, July 14, 2010 9:27 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Restart Manager (reboot after uninstall) This is a shell extension and the DLL is used by the Explorer process. There are two scenarios: 1) Uninstall - no file
Re: [WiX-users] Using Integrated security for connectionstring in CustomAction
Forget installation for a moment. How would you do this in any program? On Wed, Jul 14, 2010 at 2:24 PM, Stelios Kyprou stelios.kyp...@formicary.net wrote: That would not help in my case though, since i am aiming to validate any user defined values entered in the UI sequence. So in the case where the user chooses to run the service to be installed as LocalSystem, and the connectionstring uses integrated security, i want to make sure that the connectionstring is correct, by connecting and disconnecting to the database. If the action does not succeed, i would like to prevent the user from going to the next dialog, until i'm sure that all values are correct. Now in the case where integrated security is true but the service account is a user account, i could go around it by impersonating that user and the doing the DB connect attempt. Not sure if it would be good practice to try and impersonate the local system account though. So there is no way around this? That would mean that i would provide an incomplete Installer since i can validate ALL user defined values except the case where: connectionstring uses Instegrated Security and the account that will be used based on that configuration is LocalSystem. So that is one senario where the installation completes, i run the installed service, but it doesn't work as excpected because the service can't access the DB(either because LocalSystem has no access to it, or the connectionstring is wrong, and i couldn't detect that error during installation, which i want to)... Any opinions? Blair wrote: The custom actions used in the WixSQLExtension do not have the no-impersonate bit set, so they never run as LocalSystem (except in the rare instance that the installation were being performed by a service running as LocalSystem). Thus, if you are using the WiX-supplied SQL support you must launch the installation itself from an account with the desired access. The only ways to run a custom action as LocalSystem are to run it deferred with the Impersonate attribute set to no in the CustomAction element in your authoring where the Execute attribute is set to some in-script type (deferred, rollback, or commit), which cannot be run from the UI since they must be between InstallInitialize and InstallFinalize in the InstallExecuteSequence table. -Original Message- From: Stelios Kyprou [mailto:stelios.kyp...@formicary.net] Sent: Wednesday, July 14, 2010 12:57 PM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Using Integrated security for connectionstring in CustomAction Hello all! Let's say that i am using a C# custom action, to validate the database connectionstring that a user has entered in a dialog. If the user has selected to use Integrated Security, and the account of the Windows Service that will be running the application is Local System, that would mean that when the service is running, when connecting to the database it would use the Local System to try and access it(which is what i want). In my c# custom action, when i try and connect to the db using Integrated Security, would it use the local system account to connect(which i think is the account the installer is running as)? or will it use the account of the user that is logged in the machine(which will fail to connect)? In the latter case, any ideas on how to make it run as local system? Thanks in advance, Stelios -- Stelios Kyprou Systems Engineer Formicary - delivering quality financial technology solutions(TM) www.formicary.net This message is confidential and may be privileged. It is intended solely for the named addressee. If you are not the intended recipient, please inform us. Any unauthorised dissemination, distribution or copying hereof is prohibited. Formicary Limited registered office in England and Wales, address 1 Taillar Road, Hedon, East Yorkshire HU12 8GU, registration number 3894343, VAT number 747644304, does not guarantee that the integrity of this communication has been maintained nor that this communication is free of viruses, interceptions or interference. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- This SF.net email is sponsored by Sprint What will you do first
Re: [WiX-users] About running Any CPU custom EXE from 32bit MSI on 64bit machine
The issue is a combination of these things: * Win64=yes|no does not apply across executable launch; it's only relevant for in-process actions (dll, script) * Your executable tries to guess where things are instead of being passed a value on the command-line * Your executable takes on the bit-ness of the platform on which it is installed So I'd actually recommend fixing both of the second points. If you're trying to distribute it as if it's 32-bit, make it 32-bit by changing the project options. Then also, instead of guessing the installation path, make it a command-line argument that is passed in by the custom action. Fixing either will likely resolve your behavior, but fixing both feels cleaner to me. -- Michael Urman On Thu, Jul 15, 2010 at 04:45, Chirag Goradia chiraggora...@gmail.com wrote: Hi everyone, We are running custom EXEs ( .NET 2.0 console application ) built with Any CPU platform from a 32bit MSI on 64bit machine. In the custom EXE, we use * Environment.GetFolderPath(Environment.SpecialFolder.ProgramFiles)* to execute some custom logic on our files installed in the ProgramFiles folder path. The issue is on 64bit machine: 32bit MSI installs files to C:\Program Files (x86)\ custom EXE runs logic in C:\Program Files\ ... we think this is because it was built for Any CPU platform In the CustomAction node, we tried to set Win64=no so that it runs the custom EXE as if it were on 32bit machine. However, still the custom EXE runs logic in C:\Program Files\ instead of C:\Program Files (x86)\ Do you have any suggestions ? Thanks Chirag -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Various WiX questions
I think you want a .bat file not a .msi file. The things you are trying to do go against the general purpose of the Windows Installer: to provide a robust mechanism to install, uninstall, upgrade and patch software on the machine. It sounds like you want: something that elevates my executable that modifies machine state. smile/ On Tue, Jul 13, 2010 at 9:02 AM, wirtzenator wirtzena...@gmail.com wrote: Hi, I have just started using WiX and I have a couple questions concerning some of the things I want to do. If you can help on any of them, that would be greatly appreciated. 1. Is it possible to have the program run through the installer, then have it not be an installed program, so it doesn't show up in add/remove programs, and that I can just run the msi again and again? 2. Can I automatically run the uninstall after the install have finished? Similar to get the effect of #1. 3. I include EXE(s) in my msi file, can I run them from the msi and not actually copy them to the local computer? 4. I run these EXEs quietly, but everytime another one runs, whatever program the user is on will lose focus, can I change that? I don't ask for someone to answer all these questions, if you can that's great, but I need some direction on them. Also, my company has requested that I use .msi for this, and I have to run these exes through the msi, even though I'm not really installing anything, and don't really want to. I know it's weird, but it's what I have to do, and don't really have a choice. Code so far for reference: File 1: ?xml version='1.0'? Wix xmlns='http://schemas.microsoft.com/wix/2006/wi' Product Id='GUID' Name='Updates' Language='1033' Version='1.0.0.0' Manufacturer='MYCOMPANY' UpgradeCode='GUID' Package Description='Windows Installer package' Comments='Windows Installer to apply patches.' Manufacturer='MYCOMPANY' InstallerVersion='200' Compressed='yes' / Media Id='1' Cabinet='product.cab' EmbedCab='yes' / Directory Id='TARGETDIR' Name='SourceDir' Directory Id='ProgramFilesFolder' Name='PFiles' Directory Id='MyDir' Name='Updates' Component Id='MyComponent' Guid='GUID' File Id='patch0' Name = '67C5CEF0522B242E7FE17BE9734860117FAB1F5D.exe' DiskId='1' Source = 'C:\Save Directory\patches\67C5CEF0522B242E7FE17BE9734860117FAB1F5D.exe' / File Id='patch1' Name = '9D1F72ABA7BFD6670433E4B997A88860F217E520.exe' DiskId='1' Source = 'C:\Save Directory\patches\9D1F72ABA7BFD6670433E4B997A88860F217E520.exe' / File Id='patch2' Name = '49AE6AC4F6E0A609124F2CE6F80FCEF249273C02.exe' DiskId='1' Source = 'C:\Save Directory\patches\49AE6AC4F6E0A609124F2CE6F80FCEF249273C02.exe' / File Id='patch3' Name = 'B6A3D8953714847D02D614E8FCB5B4171D1029FB.exe' DiskId='1' Source = 'C:\Save Directory\patches\B6A3D8953714847D02D614E8FCB5B4171D1029FB.exe' / File Id='patch4' Name = '8F9E90BF9B6AD58FD264CC1CF0F187F9A83223A5.exe' DiskId='1' Source = 'C:\Save Directory\patches\8F9E90BF9B6AD58FD264CC1CF0F187F9A83223A5.exe' / File Id='patch5' Name = 'D137985D21958A9F3F277189287B9A71EEE02421.exe' DiskId='1' Source = 'C:\Save Directory\patches\D137985D21958A9F3F277189287B9A71EEE02421.exe' / File Id='patch6' Name = 'D1BA1076CB5D94B06333011C6EB29DEDB5C2C48D.exe' DiskId='1' Source = 'C:\Save Directory\patches\D1BA1076CB5D94B06333011C6EB29DEDB5C2C48D.exe' / File Id='patch7' Name = 'E5FEC41B4A9647BC5050DBBD1A08B469D72C69F4.exe' DiskId='1' Source = 'C:\Save Directory\patches\E5FEC41B4A9647BC5050DBBD1A08B469D72C69F4.exe' / File Id='patch8' Name = '9FC0909C468C17870AB868D0D7F4EB815B309045.exe' DiskId='1' Source = 'C:\Save Directory\patches\9FC0909C468C17870AB868D0D7F4EB815B309045.exe' / /Component /Directory /Directory /Directory Feature Id='MyFeature' Title='Features' Level='1' ComponentRef Id='MyComponent' / /Feature InstallExecuteSequence Custom Action='LaunchExe0' After='InstallFiles'NOT Installed/Custom Custom Action='LaunchExe1' After='InstallFiles'NOT Installed/Custom Custom Action='LaunchExe2' After='InstallFiles'NOT Installed/Custom Custom Action='LaunchExe3' After='InstallFiles'NOT Installed/Custom Custom Action='LaunchExe4' After='InstallFiles'NOT Installed/Custom Custom Action='LaunchExe5' After='InstallFiles'NOT Installed/Custom Custom Action='LaunchExe6' After='InstallFiles'NOT Installed/Custom Custom Action='LaunchExe7' After='InstallFiles'NOT Installed/Custom Custom Action='LaunchExe8' After='InstallFiles'NOT Installed/Custom /InstallExecuteSequence /Product /Wix File 2: ?xml
Re: [WiX-users] Is it possible to modify an XML file element with Wix 2.0?
1. I don't think that is supported by the WiX custom actions today. 2. Avoid that installation pattern. It is very difficult to upgrade/patch/uninstall well. On Wed, Jul 14, 2010 at 12:57 PM, d8x...@hotmail.com wrote: I have used the XMLConfig and XMLFile in Wix 2.0 and they work fine for adding new items. However, I am unable to use these to append to existing values. Is there a way to append an XML file using Wix 2.0? I am attempting to take the following XML: ?xml version=1.0 encoding=utf-8? XmlFile One TWO my IDs=One,TWO,/ /TWO /One /XmlFile And modify the IDs value to include a new items: ?xml version=1.0 encoding=utf-8? XmlFile One TWO my IDs=One,TWO,THREE,FOUR/ /TWO /One /XmlFile I can write my own custom action to perform this, but thought I would first check to see if Wix v2.0 handles this for me. Thank you. _ The New Busy is not the too busy. Combine all your e-mail accounts with Hotmail. http://www.windowslive.com/campaign/thenewbusy?tile=multiaccountocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_4 -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Using Integrated security for connectionstring in CustomAction
Yes i eventually realised that in order to do this kind of action, you must impersonate LocalSystem in you c# custom action. But in order to do that, you must have a priviledge called: Act as part of the operating system OR SE_TCB_NAME. LocalSystem has this priviledge, but no users, and it's a security risk to give it to a user account, since with this priviledge you can do almost everything on the local machine. Plus barely anyone that will be using the installers will have this priviledge, thus again not being able to impersonate LocalSystem. So it's better to not breach any security walls, and insdead notify the user that in the senario i described in the previous post of this thread, the installer will not be able to verify the connectionstring. Rob Mensching wrote: Forget installation for a moment. How would you do this in any program? On Wed, Jul 14, 2010 at 2:24 PM, Stelios Kyprou stelios.kyp...@formicary.net wrote: That would not help in my case though, since i am aiming to validate any user defined values entered in the UI sequence. So in the case where the user chooses to run the service to be installed as LocalSystem, and the connectionstring uses integrated security, i want to make sure that the connectionstring is correct, by connecting and disconnecting to the database. If the action does not succeed, i would like to prevent the user from going to the next dialog, until i'm sure that all values are correct. Now in the case where integrated security is true but the service account is a user account, i could go around it by impersonating that user and the doing the DB connect attempt. Not sure if it would be good practice to try and impersonate the local system account though. So there is no way around this? That would mean that i would provide an incomplete Installer since i can validate ALL user defined values except the case where: connectionstring uses Instegrated Security and the account that will be used based on that configuration is LocalSystem. So that is one senario where the installation completes, i run the installed service, but it doesn't work as excpected because the service can't access the DB(either because LocalSystem has no access to it, or the connectionstring is wrong, and i couldn't detect that error during installation, which i want to)... Any opinions? Blair wrote: The custom actions used in the WixSQLExtension do not have the no-impersonate bit set, so they never run as LocalSystem (except in the rare instance that the installation were being performed by a service running as LocalSystem). Thus, if you are using the WiX-supplied SQL support you must launch the installation itself from an account with the desired access. The only ways to run a custom action as LocalSystem are to run it deferred with the Impersonate attribute set to no in the CustomAction element in your authoring where the Execute attribute is set to some in-script type (deferred, rollback, or commit), which cannot be run from the UI since they must be between InstallInitialize and InstallFinalize in the InstallExecuteSequence table. -Original Message- From: Stelios Kyprou [mailto:stelios.kyp...@formicary.net] Sent: Wednesday, July 14, 2010 12:57 PM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Using Integrated security for connectionstring in CustomAction Hello all! Let's say that i am using a C# custom action, to validate the database connectionstring that a user has entered in a dialog. If the user has selected to use Integrated Security, and the account of the Windows Service that will be running the application is Local System, that would mean that when the service is running, when connecting to the database it would use the Local System to try and access it(which is what i want). In my c# custom action, when i try and connect to the db using Integrated Security, would it use the local system account to connect(which i think is the account the installer is running as)? or will it use the account of the user that is logged in the machine(which will fail to connect)? In the latter case, any ideas on how to make it run as local system? Thanks in advance, Stelios -- Stelios Kyprou Systems Engineer Formicary - delivering quality financial technology solutions(TM) www.formicary.net This message is confidential and may be privileged. It is intended solely for the named addressee. If you are not the intended recipient, please inform us. Any unauthorised dissemination, distribution or copying hereof is prohibited. Formicary Limited registered office in England and Wales, address 1 Taillar Road, Hedon, East Yorkshire HU12 8GU, registration number 3894343, VAT number 747644304, does not guarantee
[WiX-users] Best practice to include customer/user specific files (also when using a bootstrapper)
Hi Some parts of our application are very customer/user specific. For example, there will be a varying number of files in the appData-folder depending on the installation. The approach i have used so far is having a custom action copying these files. . An example installation package could look like this. It is important the the msi and the other files reside in the same folder! Application.msi FOLDER_WITH_USER_SPECIFIC_FILES (These files change per customer, impossible to compile them into the msi) Via the SourceDir Property I then manage to copy the files into the desired folder. This works well so far, although I am not entirely happy about it as the declarative approach of windows installer is undermined. However, with my limited wix knowledge, this is the only solution a can see. Unfortunately, our application has some prerequisites (.NET framework, crystal reports...) and therefore needs to have a bootstraper containing all prerequisites and the msi file, that takes care of installing them. The bootstrapper i have tried (dotNetInstaller), copies the msi to a temp folder and as a consequence, the msi and the installation-specific files no longer reside in the same folder. The SourceDir points then to the wrong directory and the the user specific files cannot be copied. My questions are now: - Are there any better, well-proven approaches, that stick to the msi declarative approach - Is there a solution to the bootstrapper problem? Are there (free) bootstrappers, that embedd all files and trigger the msi installation with the SourceDir property pointing to the directory of the bootstrapper? It would then look like this: Bootstrapper.exe FOLDER_WITH_USER_SPECIFIC_FILES (These files change per customer, impossible to compile them into the msi, or Bootstrapper) Any help is appreciated. Thanks in advance. Dan -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Conditionally Show Dialog Button based onInstalleraction (installed vs. removed vs. repaired, etc)
Sorry if I wasn't clear... There are database connection strings stored in the app.config file of the deployed application... The WIX installer's purpose is to provide a sysops team the ability to easily deploy our application across multiple system installations, all needing different connectivity strings for the DB... So far, the installer I wrote does the following: Fresh Install: - Deploys the software to the InstallDir - MyExitDialog at the Finish screen has these buttons showing MODIFY CONFIG FINISH CANCEL(disabled at this point). Clicking Finish exits the program leaving the deployed App.Config alone. - clicking MODIFY CONFIG Prompts the user for connectivity settings with empty input fields (no defaultsI originally wanted the defaults that came in the App.Config that was deployed, but later we decided it was unnecessary to prompt ANY default on fresh install.). - Saving and Exiting will run one more CA to overwrite the App.Config file with the provided DB strings. (or you can cancel and exit leaving the program installed with defaults.) Repair - Deploys the software to the InstallDir, loading the existing DB strings from the deployed App.Config file for later prompting - MyExitDialog at the Finish screen has these buttons showing MODIFY CONFIG FINISH CANCEL(disabled at this point). Clicking Finish exits the program leaving the deployed App.Config alone. - clicking MODIFY CONFIG Prompts the user for connectivity settings with the default values from the existing configuration - Saving and Exiting will run one more CA to overwrite the App.Config file with the provided DB strings. (or you can cancel and exit leaving the program installed with defaults.) Upgrade - Detects existing version, and silently removes it. - loads the existing DB strings from the deployed App.Config file for later prompting - Deploys the software to the InstallDir - MyExitDialog at the Finish screen has these buttons showing MODIFY CONFIG FINISH CANCEL(disabled at this point). Clicking Finish exits the program leaving the deployed App.Config alone. - clicking MODIFY CONFIG Prompts the user for connectivity settings with the default values from the existing configuration - Saving and Exiting will run one more CA to overwrite the App.Config file with the provided DB strings. (or you can cancel and exit leaving the program installed with defaults.) REMOVE - UNINSTALLS and removes the deployed software - MyExitDialog at the Finish screen has these buttons showing MODIFY CONFIG FINISH CANCEL(disabled at this point). Clicking Finish exits the program leaving the deployed App.Config alone. - clicking MODIFY CONFIG Prompts the user for connectivity settings (I'm trying to quash this part)... ...I need to figure out how to suppress the MODIFY CONFIG button from the MyExitDialog given a REMOVE path... I think the point in the installation at which this button is shown that REMOVE=ALL and things aruond installation are no longer checkable... I think I may need to save another Session Property to set at a certain time in the installation to 1 or 0 depending on REMOVE=ALL then or something... Sound right? On Thu, Jul 15, 2010 at 4:25 AM, Pally Sandher pally.sand...@iesve.comwrote: So you're telling us you have trouble knowing the contents of a file you're installing on the target machine until after it's been installed? Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Jeremy Rimer [mailto:jeremyri...@gmail.com] Sent: 14 July 2010 17:40 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Conditionally Show Dialog Button based onInstalleraction (installed vs. removed vs. repaired, etc) funny you mention that... The original requirements of this installer were to prompt the user the defaults provided in the App.Config file of the deployed program, which meant that we COULDNT prompt the user for settings before the files were copied. It turned out that particular action was impossible ANYWAY, because you can't modify the session for use in dialogs AFTER the files are copied, only prior in the UI sequence... So perhaps if I re-engineered this whole thing to prompt FIRST, I can avoid these problems? The way it is currently written, you can either overwrite, or set the settings OPTIONALLY before exiting the installer. (i.e. leave the app.config unmolested from the installation, or prior installation, OR, branch off and edit the entries, and submit to update the deployed app.config file... On Wed,
Re: [WiX-users] Conditionally Show Dialog Button based on Installer action (installed vs. removed vs. repaired, etc)
I'm still struggling to hide a dialog button in an uninstallation case :\. Since REMOVE=ALL didn't seem to ever be true despite the path through the installer (fresh install/repair/remove), I tried to base the Action=hide Condition off a Secure Property that can be modified earlier in the code... The result seems to be the same, REMOVE~=ALL never is true, despite a REMOVE path through the installer... Given my setup below, how can I get the secure property SHOWMODIFYCONFIGBUTTON to = 0 in the case of REMOVE paths through my installer? Here's my Property: === Property Id=SHOWMODIFYCONFIGBUTTON Secure=yes 1/Property === Here's the CustomAction that will modify the value of that property: === CustomAction Id=SetShowModifyConfigButton Property=SHOWMODIFYCONFIGBUTTON Value=0 Execute=immediate Return=check / === Here's the InstallUI and InstallExecute Sequences: === InstallUISequence !-- This runs the App.Config Reader to load the session vars for settings in the prompts -- Custom Action=LoadDefaultOptions After=CostFinalize / !-- This *should* set SHOWMODIFYCONFIGBUTTON to 0 during UNINSTALLATION paths through the installer, but doesn't -- Custom Action=SetShowModifyConfigButton After=MaintenanceWelcomeDlgREMOVE~=ALL/Custom /InstallUISequence InstallExecuteSequence RemoveExistingProducts After=InstallFinalize/ !-- This will fail the installer if a newer installed version is detected -- Custom Action=NewerVersionDetected After=FindRelatedProductsNEWERFOUND/Custom ScheduleReboot Suppress=yes/ScheduleReboot /InstallExecuteSequence === Here's the dialog button I wish to hide during uninstalls: === Control Id=ApplicationSettings Type=PushButton X=94 Y=243 Width=130 Height=17 Default=no Cancel=no Text=Modify Application Settings Condition Action=hideSHOWMODIFYCONFIGBUTTON=0/Condition !-- Only show this button when !Uninstalling -- /Control === On Wed, Jul 14, 2010 at 10:17 AM, Jeremy Rimer jeremyri...@gmail.comwrote: I have one last problem before my installer is completely working: I have a custom EXIT dialog that I created called MyExitDialog that contains an extra button that spawns a custom dialog to gather application settings from the user to write into the App.Config file that was deployed and/or existed during installation or repair. The dialog does its job, but unfortunately it also displays (and does its job) after an application has been removed with the installer, which is useless, of course since there's no more app.config file to care about on a removal of the application. I see in the Publish elements how to conditionally control what a button * does*, but how do you conditionally control when a button *shows itself*in its dialog? If this is impossible, how can I force the installer to display the standard WIX ExitDialog instead of MyExitDialog in the case of a REMOVE operation (vs. repair or new installation?). my MyExitDialog definition is as follows, and the Control with Id=ApplicationSettings is my button I'd like to hide on product removals: Dialog Id=MyExitDialog Width=370 Height=270 Title=!(loc.ExitDialog_Title) Control Id=Finish Type=PushButton X=224 Y=243 Width=56 Height=17 Default=yes Cancel=yes Text=!(loc.WixUIFinish) / !-- The following Control allows us to go beyond finish to do some settings modifications -- Control Id=ApplicationSettings Type=PushButton X=94 Y=243 Width=130 Height=17 Default=no Cancel=no Text=Modify Application Settings /Control Control Id=Cancel Type=PushButton X=304 Y=243 Width=56 Height=17 Disabled=yes Text=!(loc.WixUICancel) / Control Id=Bitmap Type=Bitmap X=0 Y=0 Width=370 Height=234 TabSkip=no Text=!(loc.ExitDialogBitmap) / !-- Control Id=Back Type=PushButton X=224 Y=243 Width=56 Height=17 Disabled=yes Text=!(loc.WixUIBack) / -- Control Id=BottomLine Type=Line X=0 Y=234 Width=370 Height=0 / Control Id=Description Type=Text X=135 Y=70 Width=220 Height=40 Transparent=yes NoPrefix=yes Text= Click the Finish button to exit the Setup Wizard. Alternatively, Click the Modify Application Settings button to alter the behavior of the application. / Control Id=Title Type=Text X=135 Y=20 Width=220 Height=60 Transparent=yes NoPrefix=yes Text=!(loc.ExitDialogTitle) / Control Id=OptionalText Type=Text X=135 Y=110 Width=220 Height=80 Transparent=yes NoPrefix=yes Hidden=yes Text=[WIXUI_EXITDIALOGOPTIONALTEXT] Condition Action=showWIXUI_EXITDIALOGOPTIONALTEXT AND NOT Installed/Condition /Control Control Id=OptionalCheckBox Type=CheckBox X=135 Y=190 Width=220 Height=40 Hidden=yes Property=WIXUI_EXITDIALOGOPTIONALCHECKBOX CheckBoxValue=1 Text=[WIXUI_EXITDIALOGOPTIONALCHECKBOXTEXT] Condition
[WiX-users] Difficulties registering a Preview Pane handler
Hello, I'm trying to register a Preview Pane handler for our product's files using Wix. Unfortunately, Heat is unable to harvest anything from the preview handler .dll file. Iit gives a HEAT5151 error and reports Exception has been thrown by the target of an invocation. I've tried using the before-and-after registry snapshot approach, which has given me a large number of registry keys and values, which oddly work fine on most computers but not at all on a few. My installer is GACing the .dll just fine, and if I run regasm from a command line after my installer is finished, everything works as expected. As I've just had the installer project transferred to me recently, I often reference our old InstallShield installer to see what my predecessor did, but in this case he used a binary custom action to manually run regasm, something that I intend to avoid at all costs. Thanks, Daniel Moody | QA Engineer | Gibbs and Associates -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Conditionally Show Dialog Button basedonInstalleraction (installed vs. removed vs. repaired, etc)
Given all that I still don't see why you're trying to do user config on the ExitDialog instead of during the InstallUISequence. The only thing you'd need to implement in anything resembling custom code to accomplish those 4 scenarios would be reading the entries from the app.config to populate the fields in the repair upgrade scenarios as reading XML doesn't have a Standard Custom Action AFAIK in WiX (yet). You seem pretty set on doing it your way however so good luck. Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Jeremy Rimer [mailto:jeremyri...@gmail.com] Sent: 15 July 2010 15:17 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Conditionally Show Dialog Button basedonInstalleraction (installed vs. removed vs. repaired, etc) Sorry if I wasn't clear... There are database connection strings stored in the app.config file of the deployed application... The WIX installer's purpose is to provide a sysops team the ability to easily deploy our application across multiple system installations, all needing different connectivity strings for the DB... So far, the installer I wrote does the following: Fresh Install: - Deploys the software to the InstallDir - MyExitDialog at the Finish screen has these buttons showing MODIFY CONFIG FINISH CANCEL(disabled at this point). Clicking Finish exits the program leaving the deployed App.Config alone. - clicking MODIFY CONFIG Prompts the user for connectivity settings with empty input fields (no defaultsI originally wanted the defaults that came in the App.Config that was deployed, but later we decided it was unnecessary to prompt ANY default on fresh install.). - Saving and Exiting will run one more CA to overwrite the App.Config file with the provided DB strings. (or you can cancel and exit leaving the program installed with defaults.) Repair - Deploys the software to the InstallDir, loading the existing DB strings from the deployed App.Config file for later prompting - MyExitDialog at the Finish screen has these buttons showing MODIFY CONFIG FINISH CANCEL(disabled at this point). Clicking Finish exits the program leaving the deployed App.Config alone. - clicking MODIFY CONFIG Prompts the user for connectivity settings with the default values from the existing configuration - Saving and Exiting will run one more CA to overwrite the App.Config file with the provided DB strings. (or you can cancel and exit leaving the program installed with defaults.) Upgrade - Detects existing version, and silently removes it. - loads the existing DB strings from the deployed App.Config file for later prompting - Deploys the software to the InstallDir - MyExitDialog at the Finish screen has these buttons showing MODIFY CONFIG FINISH CANCEL(disabled at this point). Clicking Finish exits the program leaving the deployed App.Config alone. - clicking MODIFY CONFIG Prompts the user for connectivity settings with the default values from the existing configuration - Saving and Exiting will run one more CA to overwrite the App.Config file with the provided DB strings. (or you can cancel and exit leaving the program installed with defaults.) REMOVE - UNINSTALLS and removes the deployed software - MyExitDialog at the Finish screen has these buttons showing MODIFY CONFIG FINISH CANCEL(disabled at this point). Clicking Finish exits the program leaving the deployed App.Config alone. - clicking MODIFY CONFIG Prompts the user for connectivity settings (I'm trying to quash this part)... ...I need to figure out how to suppress the MODIFY CONFIG button from the MyExitDialog given a REMOVE path... I think the point in the installation at which this button is shown that REMOVE=ALL and things aruond installation are no longer checkable... I think I may need to save another Session Property to set at a certain time in the installation to 1 or 0 depending on REMOVE=ALL then or something... Sound right? On Thu, Jul 15, 2010 at 4:25 AM, Pally Sandher pally.sand...@iesve.comwrote: So you're telling us you have trouble knowing the contents of a file you're installing on the target machine until after it's been installed? Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email
Re: [WiX-users] Calling an exe file upon installation (works but either cmd remains open, or installation does not finish)
If you don't know how to write a Launcher .exe, I can make one for you Just ask On Wed, Jul 14, 2010 at 4:49 PM, daniel.knoep...@noser.com wrote: Hi Thanks for your answer. Having a launcher exe seems to be the save way to go. In the meantime, i noticed that on some machine it works as supposed, using the following custom action definiton: CustomAction Id=LaunchPrintProcessAction Directory=PrintProcessDir Return=asyncNoWait ExeCommand=[PrintProcessDir]PrintProcess.exe -autostart / However, i think we still have to use the launcher as we have to ensure it has to work on all machines. Regards Von: Dan Vasilov [...@rms.ro] Gesendet: Mittwoch, 14. Juli 2010 07:51 An: wix-users@lists.sourceforge.net Betreff: Re: [WiX-users] Calling an exe file upon installation (works but either cmd remains open, or installation does not finish) I would use a launcher .exe that can properly be launched from the setup. Then this launcher would start your application. Probably your executable has some particularity, the setups we've developed with Wix properly launch the main executable. Dan -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Porting installer to WiX
I am working on porting an InstallShield installer over to wix. I don't have the source code for the installer and the installer itself is an executable file. Is there a way to get the GUIDs for the product Id and upgrade code from the executable file? Thanks, Katelyn Note: The information contained in this message may be privileged and confidential and thus protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Porting installer to WiX
Yes, a million info programs around Try SuperORCA On Fri, Jul 16, 2010 at 2:39 AM, Thode, Katelyn katelyn.th...@guidancesoftware.com wrote: I am working on porting an InstallShield installer over to wix. I don't have the source code for the installer and the installer itself is an executable file. Is there a way to get the GUIDs for the product Id and upgrade code from the executable file? Thanks, Katelyn Note: The information contained in this message may be privileged and confidential and thus protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Conditionally Show Dialog Button basedonInstalleraction (installed vs. removed vs. repaired, etc)
I only did it in this manner because original requirements dictated the application be copied to the installdir before reading back defaults for entry... turns out the defaults are actually blank strings in the application, so nothing ever really needed to be read on fresh install... they do on upgrades/repairs though. I got everything working this way, so figured why change it... On Thu, Jul 15, 2010 at 11:28 AM, Pally Sandher pally.sand...@iesve.comwrote: Given all that I still don't see why you're trying to do user config on the ExitDialog instead of during the InstallUISequence. The only thing you'd need to implement in anything resembling custom code to accomplish those 4 scenarios would be reading the entries from the app.config to populate the fields in the repair upgrade scenarios as reading XML doesn't have a Standard Custom Action AFAIK in WiX (yet). You seem pretty set on doing it your way however so good luck. Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Jeremy Rimer [mailto:jeremyri...@gmail.com] Sent: 15 July 2010 15:17 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Conditionally Show Dialog Button basedonInstalleraction (installed vs. removed vs. repaired, etc) Sorry if I wasn't clear... There are database connection strings stored in the app.config file of the deployed application... The WIX installer's purpose is to provide a sysops team the ability to easily deploy our application across multiple system installations, all needing different connectivity strings for the DB... So far, the installer I wrote does the following: Fresh Install: - Deploys the software to the InstallDir - MyExitDialog at the Finish screen has these buttons showing MODIFY CONFIG FINISH CANCEL(disabled at this point). Clicking Finish exits the program leaving the deployed App.Config alone. - clicking MODIFY CONFIG Prompts the user for connectivity settings with empty input fields (no defaultsI originally wanted the defaults that came in the App.Config that was deployed, but later we decided it was unnecessary to prompt ANY default on fresh install.). - Saving and Exiting will run one more CA to overwrite the App.Config file with the provided DB strings. (or you can cancel and exit leaving the program installed with defaults.) Repair - Deploys the software to the InstallDir, loading the existing DB strings from the deployed App.Config file for later prompting - MyExitDialog at the Finish screen has these buttons showing MODIFY CONFIG FINISH CANCEL(disabled at this point). Clicking Finish exits the program leaving the deployed App.Config alone. - clicking MODIFY CONFIG Prompts the user for connectivity settings with the default values from the existing configuration - Saving and Exiting will run one more CA to overwrite the App.Config file with the provided DB strings. (or you can cancel and exit leaving the program installed with defaults.) Upgrade - Detects existing version, and silently removes it. - loads the existing DB strings from the deployed App.Config file for later prompting - Deploys the software to the InstallDir - MyExitDialog at the Finish screen has these buttons showing MODIFY CONFIG FINISH CANCEL(disabled at this point). Clicking Finish exits the program leaving the deployed App.Config alone. - clicking MODIFY CONFIG Prompts the user for connectivity settings with the default values from the existing configuration - Saving and Exiting will run one more CA to overwrite the App.Config file with the provided DB strings. (or you can cancel and exit leaving the program installed with defaults.) REMOVE - UNINSTALLS and removes the deployed software - MyExitDialog at the Finish screen has these buttons showing MODIFY CONFIG FINISH CANCEL(disabled at this point). Clicking Finish exits the program leaving the deployed App.Config alone. - clicking MODIFY CONFIG Prompts the user for connectivity settings (I'm trying to quash this part)... ...I need to figure out how to suppress the MODIFY CONFIG button from the MyExitDialog given a REMOVE path... I think the point in the installation at which this button is shown that REMOVE=ALL and things aruond installation are no longer checkable... I think I may need to save another Session Property to set at a certain time in the installation to 1 or 0 depending on REMOVE=ALL then or something... Sound right? On Thu, Jul 15, 2010 at 4:25 AM, Pally Sandher pally.sand...@iesve.comwrote: So
Re: [WiX-users] Porting installer to WiX
It can't be MSI-based with guids everywhere *and* be simply an executable, so I'd verify that it's not an older non-MSI setup of the type that InstallShield used to do. If it is MSI-based and an exe, then maybe the MSI file is embedded in the resources of the exe (something like Winzip might show you that), or if you run it then there'll be an MSI file pop out somewhere to be installed, then you can use Orca to look at it, and Dark to decompile it to WiX source. Phil Wilson -Original Message- From: Thode, Katelyn [mailto:katelyn.th...@guidancesoftware.com] Sent: Thursday, July 15, 2010 9:40 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Porting installer to WiX I am working on porting an InstallShield installer over to wix. I don't have the source code for the installer and the installer itself is an executable file. Is there a way to get the GUIDs for the product Id and upgrade code from the executable file? Thanks, Katelyn Note: The information contained in this message may be privileged and confidential and thus protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users *** 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). -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Porting installer to WiX
Thanks for the quick response. It seems like SuperOrca is an MSI editor. I have a .exe file that I need to get the upgrade GUID from. -Original Message- From: Alec Taylor [mailto:alec.tayl...@gmail.com] Sent: Thursday, July 15, 2010 11:51 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Porting installer to WiX Yes, a million info programs around Try SuperORCA On Fri, Jul 16, 2010 at 2:39 AM, Thode, Katelyn katelyn.th...@guidancesoftware.com wrote: I am working on porting an InstallShield installer over to wix. I don't have the source code for the installer and the installer itself is an executable file. Is there a way to get the GUIDs for the product Id and upgrade code from the executable file? Thanks, Katelyn Note: The information contained in this message may be privileged and confidential and thus protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users Note: The information contained in this message may be privileged and confidential and thus protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] C# Custom Action DLL fails
Hi, I'm having a problem with WiX 3.5 launching a separate executable from a custom action during the InstallFinalize action. This seems to only occur on systems where I don't have Visual Studio 2005 installed. On my development system, the installer runs just fine. The Custom Action is a C# WiX Custom Action DLL. The code pulls in the System.Diagnostics.Process class, and uses it to launch a couple of processes. If I comment out the Process class portion of the code, everything runs just fine. If I try to launch a Process instance, I get this error: SFXCA: Extracting custom action to temporary directory: C:\WINDOWS\Installer\MSI86.tmp-\ SFXCA: Binding to CLR version v2.0.50727 Calling custom action WiXCustomActions!WiXCustomActions.CustomActions.ConfigureTerminals This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem at System.Diagnostics.Process.StartWithShellExecuteEx(ProcessStartInfo startInfo) at System.Diagnostics.Process.Start() at WiXCustomActions.CustomActions.ConfigureTerminals(Session session) My first thought was that the CRT (C lang runtime) wasn't installed. I tried installing the Windows 2008 SP1 Redistributable, but that had no impact. I then decided to generate a simple test executable just to see if there was something inherently problematic about the System.Diagnostics namespace/classes. But my test executable ran just fine (and the test executable contains nearly identical Process class code as the custom action DLL). Anyway, I noticed that the SFXCA is loading CLR version 2.0.50727. So I modified CustomActions.config to use version 4.0 of the .NET framework, and that also made no difference: SFXCA: Extracting custom action to temporary directory: C:\WINDOWS\Installer\MSI12.tmp-\ SFXCA: Binding to CLR version v4.0.30319 Calling custom action WiXCustomActions!WiXCustomActions.CustomActions.ConfigureTerminals This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem Finally, I also tried installing the .NET 4.0 Framework, but that didn't make a difference either. I think this must be an issue of a missing library, but I can't seem to figure out which it is. I'm tempted to run a trace to see what it's looking for, but that might take me hours/days. Any ideas? Keith -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Porting installer to WiX
The executable wraps an msi that was created with InstallShield 12. Is there a way for me to extract the msi? -Original Message- From: Wilson, Phil [mailto:phil.wil...@invensys.com] Sent: Thursday, July 15, 2010 12:40 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Porting installer to WiX It can't be MSI-based with guids everywhere *and* be simply an executable, so I'd verify that it's not an older non-MSI setup of the type that InstallShield used to do. If it is MSI-based and an exe, then maybe the MSI file is embedded in the resources of the exe (something like Winzip might show you that), or if you run it then there'll be an MSI file pop out somewhere to be installed, then you can use Orca to look at it, and Dark to decompile it to WiX source. Phil Wilson -Original Message- From: Thode, Katelyn [mailto:katelyn.th...@guidancesoftware.com] Sent: Thursday, July 15, 2010 9:40 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Porting installer to WiX I am working on porting an InstallShield installer over to wix. I don't have the source code for the installer and the installer itself is an executable file. Is there a way to get the GUIDs for the product Id and upgrade code from the executable file? Thanks, Katelyn Note: The information contained in this message may be privileged and confidential and thus protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users *** 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). -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users Note: The information contained in this message may be privileged and confidential and thus protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Include an optional file in installer during compile/link
I'm trying to optionally include a file in my installer at compile/link time. If the file is included, then the installer will copy it to the appropriate location (thus it is not optional for the user to install it). If the file is NOT included in the installer, then it the installer skips it, and it is not an error. Is there a way to conditionally include a file in the installer? My automated build system will takes care of the logic of determining whether or not the file should be included. As an example, I have a single feature called Configuration: Feature Id=Complete Title=Install Level=1 ComponentRef Id=Configuration / /Feature In the component description, I have a config file that is required. I've tried to add a second file (weather.lnk) that is optional: Directory Id=TARGETDIR Name=SourceDir Directory Id=ProgramFilesFolder Directory Id=CompanyFolderName Name=MyCompany Directory Id=INSTALLLOCATION Name=MyApp Component Id=Configuration Guid=175F0351-F122-4c64-92B6-BED06F22E195 File Id=MyApp.exe.config Source=$(var.SourceRoot)\MyApp.exe.config /File File Id=Weather.lnk Source=$(var.SourceRoot)\Weather.lnk /File /Component /Directory /Directory /Directory /Directory If the Weather.lnk file does not exist in the given location, the linker gives a LGHT0083 error (file not found). I'd like to annotate this file (if possible) as optional, or somehow put a conditional around it so if it is not found in the given location, it is not an error and is just skipped when the installer is compiled and linked. And then assuming the successful build of the installer, when the installer is run, it will just skip this file. Do I need to make a separate component or feature for this particular file? I've looked around at the descriptions of the File, Component, Feature items and didn't see anything that was obvious to me to make it optional. I did find the Vital attribute for the File - I tried setting this to no, but still got the link error. Is this possible? I'm using Wix 3.0 Thanks, Beth --- This email and any files transmitted with it are confidential proprietary to Systems and Software Enterprises, Inc. (dba IMS). This information is intended solely for the use of the individual or entity to which it is addressed. Access or transmittal of the information contained in this e-mail, in full or in part, to any other organization or persons is not authorized. --- -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Include an optional file in installer during compile/link
How about using the preprocessor for it? Something like: ?if condition ? File ... /File ?endif ? You can control the condition through command line parameters to candle. Ivo Beth Hechanova bhechan...@imsco-us.com wrote: I'm trying to optionally include a file in my installer at compile/link time. If the file is included, then the installer will copy it to the appropriate location (thus it is not optional for the user to install it). If the file is NOT included in the installer, then it the installer skips it, and it is not an error. Is there a way to conditionally include a file in the installer? My automated build system will takes care of the logic of determining whether or not the file should be included. As an example, I have a single feature called Configuration: Feature Id=Complete Title=Install Level=1 ComponentRef Id=Configuration / /Feature In the component description, I have a config file that is required. I've tried to add a second file (weather.lnk) that is optional: Directory Id=TARGETDIR Name=SourceDir Directory Id=ProgramFilesFolder Directory Id=CompanyFolderName Name=MyCompany Directory Id=INSTALLLOCATION Name=MyApp Component Id=Configuration Guid=175F0351-F122-4c64-92B6-BED06F22E195 File Id=MyApp.exe.config Source=$(var.SourceRoot)\MyApp.exe.config /File File Id=Weather.lnk Source=$(var.SourceRoot)\Weather.lnk /File /Component /Directory /Directory /Directory /Directory If the Weather.lnk file does not exist in the given location, the linker gives a LGHT0083 error (file not found). I'd like to annotate this file (if possible) as optional, or somehow put a conditional around it so if it is not found in the given location, it is not an error and is just skipped when the installer is compiled and linked. And then assuming the successful build of the installer, when the installer is run, it will just skip this file. Do I need to make a separate component or feature for this particular file? I've looked around at the descriptions of the File, Component, Feature items and didn't see anything that was obvious to me to make it optional. I did find the Vital attribute for the File - I tried setting this to no, but still got the link error. Is this possible? I'm using Wix 3.0 Thanks, Beth --- This email and any files transmitted with it are confidential proprietary to Systems and Software Enterprises, Inc. (dba IMS). This information is intended solely for the use of the individual or entity to which it is addressed. Access or transmittal of the information contained in this e-mail, in full or in part, to any other organization or persons is not authorized. --- -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Porting installer to WiX
If you have WinZip and you open that exe with it, you may see the embedded files. Or the internals might be proprietary. Otherwise as I said. If you run the exe the MSI file will be extracted somewhere, just hunt for it and copy/save it. Phil Wilson -Original Message- From: Thode, Katelyn [mailto:katelyn.th...@guidancesoftware.com] Sent: Thursday, July 15, 2010 4:06 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Porting installer to WiX The executable wraps an msi that was created with InstallShield 12. Is there a way for me to extract the msi? -Original Message- From: Wilson, Phil [mailto:phil.wil...@invensys.com] Sent: Thursday, July 15, 2010 12:40 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Porting installer to WiX It can't be MSI-based with guids everywhere *and* be simply an executable, so I'd verify that it's not an older non-MSI setup of the type that InstallShield used to do. If it is MSI-based and an exe, then maybe the MSI file is embedded in the resources of the exe (something like Winzip might show you that), or if you run it then there'll be an MSI file pop out somewhere to be installed, then you can use Orca to look at it, and Dark to decompile it to WiX source. Phil Wilson -Original Message- From: Thode, Katelyn [mailto:katelyn.th...@guidancesoftware.com] Sent: Thursday, July 15, 2010 9:40 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Porting installer to WiX I am working on porting an InstallShield installer over to wix. I don't have the source code for the installer and the installer itself is an executable file. Is there a way to get the GUIDs for the product Id and upgrade code from the executable file? Thanks, Katelyn Note: The information contained in this message may be privileged and confidential and thus protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users *** 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). -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users Note: The information contained in this message may be privileged and confidential and thus protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. -- This SF.net email
Re: [WiX-users] How to add UI for Minor Patches(msp)?
MSP application uses the UI from the MSI it upgrades to. -Original Message- From: KATO Kanryu [mailto:k.kan...@gmail.com] Sent: Wednesday, July 14, 2010 11:20 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] How to add UI for Minor Patches(msp)? hi, I made a minor patch with PatchCreation, .pcp and MsiMsp.exe But the msp doesn't have any Wizard UIs. How to add UI for that? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; PatchCreation Id=224C316D-5894-4771-BABF-21A3AC1F75FF CleanWorkingFolder=yes OutputPath=patch.pcp WholeFilesOnly=yes Codepage=932 PatchInformation Description=$(var.AppFullName) Updater $(var.PatchVersion) Comments=$(var.AppFullName) Updater $(var.PatchVersion) ShortNames=no Languages=1041 Compressed=yes Manufacturer=Our Company/ PatchMetadata AllowRemoval=yes Description=$(var.AppFullName) Updater $(var.PatchVersion) ManufacturerName=Our Company TargetProductName=$(var.AppFullName) MoreInfoURL=http://www.ours.co.jp; Classification=Update DisplayName=$(var.AppFullName) Updater $(var.PatchVersion)/ Family DiskId=5000 MediaSrcProp=Sample Name=Sample SequenceStart=5000 UpgradeImage SourceFile=Maou11.msi Id=SampleUpgrade TargetImage SourceFile=Maou.msi Order=2 Id=SampleTarget IgnoreMissingFiles=no / /UpgradeImage /Family PatchSequence PatchFamily=SamplePatchFamily Sequence=1.0.0.0 Supersede=yes / /PatchCreation /Wix -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] How to make Edit control readonly?
Could we have a read-only edit control, so user can select the text, but cannot modify it? Thanks, -Elfe -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] About running Any CPU custom EXE from 32bit MSI on 64bit machine
Use Environment.SpecialFolder.ProgramFilesX86 instead of Environment.SpecialFolder.ProgramFiles. Both values should be defined on a 32-bit machine. -Original Message- From: Chirag Goradia [mailto:chiraggora...@gmail.com] Sent: Thursday, July 15, 2010 2:46 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] About running Any CPU custom EXE from 32bit MSI on 64bit machine Hi everyone, We are running custom EXEs ( .NET 2.0 console application ) built with Any CPU platform from a 32bit MSI on 64bit machine. In the custom EXE, we use * Environment.GetFolderPath(Environment.SpecialFolder.ProgramFiles)* to execute some custom logic on our files installed in the ProgramFiles folder path. The issue is on 64bit machine: 32bit MSI installs files to C:\Program Files (x86)\ custom EXE runs logic in C:\Program Files\ ... we think this is because it was built for Any CPU platform In the CustomAction node, we tried to set Win64=no so that it runs the custom EXE as if it were on 32bit machine. However, still the custom EXE runs logic in C:\Program Files\ instead of C:\Program Files (x86)\ Do you have any suggestions ? Thanks Chirag -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Best practice to include customer/user specific files (also when using a bootstrapper)
SourceDir is set by Windows Installer and is a private session property, so no bootstrapper can easily change it to something different than the folder the MSI is run from. You could try using a bootstrapper that passes a property with a value corresponding to its current directory (or adding similar code to a bootstrapper to which you have source code). Alternately, use a release mechanism such that you embed the FOLDER_WITH_USER_SPECIFIC_FILES into your bootstrapper along with the MSI. -Original Message- From: daniel.knoep...@noser.com [mailto:daniel.knoep...@noser.com] Sent: Thursday, July 15, 2010 7:09 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Best practice to include customer/user specific files (also when using a bootstrapper) Hi Some parts of our application are very customer/user specific. For example, there will be a varying number of files in the appData-folder depending on the installation. The approach i have used so far is having a custom action copying these files. . An example installation package could look like this. It is important the the msi and the other files reside in the same folder! Application.msi FOLDER_WITH_USER_SPECIFIC_FILES (These files change per customer, impossible to compile them into the msi) Via the SourceDir Property I then manage to copy the files into the desired folder. This works well so far, although I am not entirely happy about it as the declarative approach of windows installer is undermined. However, with my limited wix knowledge, this is the only solution a can see. Unfortunately, our application has some prerequisites (.NET framework, crystal reports...) and therefore needs to have a bootstraper containing all prerequisites and the msi file, that takes care of installing them. The bootstrapper i have tried (dotNetInstaller), copies the msi to a temp folder and as a consequence, the msi and the installation-specific files no longer reside in the same folder. The SourceDir points then to the wrong directory and the the user specific files cannot be copied. My questions are now: - Are there any better, well-proven approaches, that stick to the msi declarative approach - Is there a solution to the bootstrapper problem? Are there (free) bootstrappers, that embedd all files and trigger the msi installation with the SourceDir property pointing to the directory of the bootstrapper? It would then look like this: Bootstrapper.exe FOLDER_WITH_USER_SPECIFIC_FILES (These files change per customer, impossible to compile them into the msi, or Bootstrapper) Any help is appreciated. Thanks in advance. Dan -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Difficulties registering a Preview Pane handler
It would appear that the preview handler you are using does some calculations to determine what changes to make to the box (a part of the evil of self-registration is when there is no way to know beforehand what some component will try to do to your box). You will need to get a hold of the source code to your preview handler and see what it is doing, and try to distill out of that what really needs to be done in a declarative way. -Original Message- From: Daniel Moody [mailto:dani...@gibbscam.com] Sent: Thursday, July 15, 2010 9:23 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Difficulties registering a Preview Pane handler Hello, I'm trying to register a Preview Pane handler for our product's files using Wix. Unfortunately, Heat is unable to harvest anything from the preview handler .dll file. Iit gives a HEAT5151 error and reports Exception has been thrown by the target of an invocation. I've tried using the before-and-after registry snapshot approach, which has given me a large number of registry keys and values, which oddly work fine on most computers but not at all on a few. My installer is GACing the .dll just fine, and if I run regasm from a command line after my installer is finished, everything works as expected. As I've just had the installer project transferred to me recently, I often reference our old InstallShield installer to see what my predecessor did, but in this case he used a binary custom action to manually run regasm, something that I intend to avoid at all costs. Thanks, Daniel Moody | QA Engineer | Gibbs and Associates -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to make Edit control readonly?
Here is the list of attributes that Windows Installer allows edit controls to have: http://msdn.microsoft.com/library/aa368342.aspx Readonly isn't one of them. I haven't tried: can you select and copy text from a static text control? -Original Message- From: Elfe Xu [mailto:elf...@microsoft.com] Sent: Thursday, July 15, 2010 6:36 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] How to make Edit control readonly? Could we have a read-only edit control, so user can select the text, but cannot modify it? Thanks, -Elfe -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Difficulties registering a Preview Pane handler
Have you taken a look at the documentation on registering preview
handlers? http://msdn.microsoft.com/en-us/library/cc144144(VS.85).aspx
explains pretty much everything in detail.
Here's some sample code for installing a 32-bit native code handler on
both 32 and 64-bit systems, hope this helps.
Fragment
Component Id=MyPreviewHandler.dll
Directory=APPLICATIONFOLDER Guid=*
File Id=MyPreviewHandler.dll KeyPath=yes
Source=SourceDir\MyPreviewHandler.dll /
RegistryValue Root=HKLM
Key=SOFTWARE\Classes\AcmeXYZ.Document\shellex\{8895b1c6-b41f-4c1c-a562-0d564250836f}
Value={XXX-XXX-XXX-XXX} Type=string /
RegistryValue Root=HKLM
Key=SOFTWARE\Microsoft\Windows\CurrentVersion\PreviewHandlers
Name={XXX-XXX-XXX-XXX} Value=XYZ Preview Handler Type=string /
RegistryValue Root=HKLM
Key=SOFTWARE\Classes\CLSID\{XXX-XXX-XXX-XXX} Value=XYZ Preview
Handler Type=string /
RegistryValue Root=HKLM
Key=SOFTWARE\Classes\CLSID\{XXX-XXX-XXX-XXX} Name=DisplayName
Value=XYZ Preview Handler Type=string /
RegistryValue Root=HKLM
Key=SOFTWARE\Classes\CLSID\{XXX-XXX-XXX-XXX}
Name=DisableLowILProcessIsolation Value=1 Type=integer /
!-- 32-bit handler needs to use different AppID on
x64, refer
http://msdn.microsoft.com/en-us/library/cc144144(VS.85).aspx --
?if $(var.ProcessorArchitecture)=x64 ?
RegistryValue Root=HKLM
Key=SOFTWARE\Classes\CLSID\{XXX-XXX-XXX-XXX} Name=AppID
Value={534A1E02-D58F-44f0-B58B-36CBED287C7C} Type=string /
?else?
RegistryValue Root=HKLM
Key=SOFTWARE\Classes\CLSID\{XXX-XXX-XXX-XXX} Name=AppID
Value={6d2b5079-2f0b-48dd-ab7f-97cec514d30b} Type=string /
?endif?
RegistryValue Root=HKLM
Key=SOFTWARE\Classes\CLSID\{XXX-XXX-XXX-XXX}\InprocServer32
Value=[!MyPreviewHandler.dll] Type=string /
RegistryValue Root=HKLM
Key=SOFTWARE\Classes\CLSID\{XXX-XXX-XXX-XXX}\InprocServer32
Name=ThreadingModel Value=Apartment Type=string /
RegistryValue Root=HKLM
Key=SOFTWARE\Classes\CLSID\{XXX-XXX-XXX-XXX}\InprocServer32
Name=ProgID Value=AcmeXYZ.Document Type=string /
!-- Only install for Vista+ --
Condition![CDATA[VersionNT = 600]]/Condition
/Component
/Fragment
Fragment
!-- 64-bit preview handler voodoo *waves hands magically* --
Component Id=MyPreviewHandler_x64 Directory=XYZCommonFiles
Guid=* Win64=yes
RegistryValue Root=HKLM
Key=SOFTWARE\Classes\CLSID\{XXX-XXX-XXX-XXX} Value=XYZ Preview
Handler Type=string /
RegistryValue Root=HKLM
Key=SOFTWARE\Classes\CLSID\{XXX-XXX-XXX-XXX} Name=DisplayName
Value=!(loc.ApplicationName) Type=string /
RegistryValue Root=HKLM
Key=SOFTWARE\Classes\CLSID\{XXX-XXX-XXX-XXX}
Name=DisableLowILProcessIsolation Value=1 Type=integer /
RegistryValue Root=HKLM
Key=SOFTWARE\Classes\CLSID\{XXX-XXX-XXX-XXX}\InprocServer32
Value=[!MyPreviewHandler.dll] Type=string /
RegistryValue Root=HKLM
Key=SOFTWARE\Classes\CLSID\{XXX-XXX-XXX-XXX}\InprocServer32
Name=ThreadingModel Value=Apartment Type=string /
RegistryValue Root=HKLM
Key=SOFTWARE\Classes\CLSID\{XXX-XXX-XXX-XXX}\InprocServer32
Name=ProgID Value=AcmeXYZ.Document Type=string /
!-- Only install for Vista+ --
Condition![CDATA[VersionNT = 600]]/Condition
/Component
/Fragment
On Fri, Jul 16, 2010 at 2:23 AM, Daniel Moody dani...@gibbscam.com wrote:
Hello,
I'm trying to register a Preview Pane handler for our product's files using
Wix. Unfortunately, Heat is unable to harvest anything from the preview
handler .dll file. Iit gives a HEAT5151 error and reports Exception has
been thrown by the target of an invocation. I've tried using the
before-and-after registry snapshot approach, which has given me a large
number of registry keys and values, which oddly work fine on most computers
but not at all on a few.
My installer is GACing the .dll just fine, and if I run regasm from a
command line after my installer is finished, everything works as expected.
As I've just had the installer project transferred to me recently, I often
reference our old InstallShield installer to see what my predecessor did,
but in this case he used a binary custom action to manually run regasm,
something that I intend to avoid at all costs.
Thanks,
Daniel Moody | QA Engineer | Gibbs and Associates
--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G
Re: [WiX-users] C# Custom Action DLL fails
Could it be something related to the executable being launched instead of an issue with the custom action itself? What is the impersonate setting of the custom action doing the launching? What is the executionLevel value for the executable being launched? -Original Message- From: Keith Hassen [mailto:keith.has...@gmail.com] Sent: Thursday, July 15, 2010 11:41 AM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] C# Custom Action DLL fails Hi, I'm having a problem with WiX 3.5 launching a separate executable from a custom action during the InstallFinalize action. This seems to only occur on systems where I don't have Visual Studio 2005 installed. On my development system, the installer runs just fine. The Custom Action is a C# WiX Custom Action DLL. The code pulls in the System.Diagnostics.Process class, and uses it to launch a couple of processes. If I comment out the Process class portion of the code, everything runs just fine. If I try to launch a Process instance, I get this error: SFXCA: Extracting custom action to temporary directory: C:\WINDOWS\Installer\MSI86.tmp-\ SFXCA: Binding to CLR version v2.0.50727 Calling custom action WiXCustomActions!WiXCustomActions.CustomActions.ConfigureTerminals This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem at System.Diagnostics.Process.StartWithShellExecuteEx(ProcessStartInfo startInfo) at System.Diagnostics.Process.Start() at WiXCustomActions.CustomActions.ConfigureTerminals(Session session) My first thought was that the CRT (C lang runtime) wasn't installed. I tried installing the Windows 2008 SP1 Redistributable, but that had no impact. I then decided to generate a simple test executable just to see if there was something inherently problematic about the System.Diagnostics namespace/classes. But my test executable ran just fine (and the test executable contains nearly identical Process class code as the custom action DLL). Anyway, I noticed that the SFXCA is loading CLR version 2.0.50727. So I modified CustomActions.config to use version 4.0 of the .NET framework, and that also made no difference: SFXCA: Extracting custom action to temporary directory: C:\WINDOWS\Installer\MSI12.tmp-\ SFXCA: Binding to CLR version v4.0.30319 Calling custom action WiXCustomActions!WiXCustomActions.CustomActions.ConfigureTerminals This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem Finally, I also tried installing the .NET 4.0 Framework, but that didn't make a difference either. I think this must be an issue of a missing library, but I can't seem to figure out which it is. I'm tempted to run a trace to see what it's looking for, but that might take me hours/days. Any ideas? Keith -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
