Re: [WiX-users] Does the msi-filename matter?
Couple things: 1. You can have multiple .wxs files to create a single or set of MSI files. I recommend breaking your product down into useful chunks and putting them in Fragments then grouping the Fragments in logical files. Managing a product in a single .wxs file can be very challenging. smile/ 2. I think Burn would work very well for your scenario below. That doesn't help you since Burn isn't available yet and won't really be stable until early next year. They way things could work in Burn, is you could break 1 - 4 into 4 separate MSI package but make one Bundle. Then you can release ever increasing versions of the Bundle with various major or minor or small updates to the contained packages.Burn is smart enough to update only the MSIs that are newer... Basically, I think your scenario is best served by a multi-MSI design. The problem with multi-MSI design is you need a chainer to manage the install/unistall/update process. On Thu, Jul 22, 2010 at 12:37 PM, Lukas Haase lukasha...@gmx.at wrote: Thank you everybody for the discussion! The result is clear to me: I won't use minor- and small updates. One question concerning Best practice left for the deployment. In fact my application consists of: - Viewer (EXE, DLL, CHM) - Database (dat-file (80MB), bunch of PDFs) - License1.RTF, License2.RTF Now I ship my program in various flavours: 1.) Corporate edition with License1.RTF 2.) Private edition: Everything the same except License2.RTF 3.) (private) Network edition: Same as (2) except the name 4.) Demo version: Modified Database (30MB instead of 80MB) And finally each (1)-(3) get updates every few months. At first I thought with WiX it would be possible to just create one installer for all of those. But according to the discussions so far, am I right to just generate separate projects (wxs files) for each of the cases above? And according to the updates: Each of the (1), (2), (3), (4) shares the same UpgradeCode, doesn't it? Regards, Luke Am 22.07.2010 05:28, schrieb Christopher Painter: I wrote thatI had read several blog posts over the years and cited one of them as Vagmi and couldn't recall who the others were. I didn't say any of them were from you. In fact, I recall you writing a post about why WiX uses Major Upgrades and I referred to that as vindication; evidence that we have shared beliefs. BTW, I could ask you the same question considering your still unapologetic personal attack on me several years ago. I still believe that if we ever met in real life we'd hit it really well. I for one sure wish you could spend some time in Austin seeing the work I've done combining WiX with InstallShield. Christopher Painter, Author of Deployment Engineering Blog Have a hot tip, know a secret or read a really good thread that deserves attention? E-Mail Me - Original Message From: Rob Menschingr...@robmensching.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Wed, July 21, 2010 10:10:42 PM Subject: Re: [WiX-users] Does the msi-filename matter? I think you have me confused with someone else. I've always had the stance: If you can use a Major Upgrade do so. Life is too short to deal with the difficulties otherwise. What else have you told people I believe?smile/ On Wed, Jul 21, 2010 at 7:53 PM, Christopher Painter chr...@deploymentengineering.com wrote: Rob- I seem to recall several blog articles years ago talking about how major upgrades are ugly. One was from an active blogger at the time ( Vagmi ) but I don't remember the others. http://geekswithblogs.net/Vagmi.Mudumbai/archive/2006/06/11/81426.aspx Blair- My MSI mojo is good, but what development throws over the wall to me frequently will not end well with anything other then a major upgrade with respect to msi servicing patterns and rules. I'm sure you've seen that also. Chris - Original Message From: Rob Menschingr...@robmensching.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Wed, July 21, 2010 9:33:40 PM Subject: Re: [WiX-users] Does the msi-filename matter? Uhh, I personally always recommend Major Upgrades over all the other options. IMHO, the other options (minor updates and small updates) add pain that is rarely worth it (i.e. you have to be really big with lots of customers to bother with .msp's). I'd be curious to see who actually recommends anything but Major Upgrades for the general case. On Wed, Jul 21, 2010 at 4:07 PM, Christopher Painter chr...@deploymentengineering.com wrote: Same here. I've heard people post for years about how Major Upgrades are a pain and you better follow the component rules to a letter if you want minor upgrades, small updates and patching to work. I've choosen to only support Major
[WiX-users] msi patchs not updating the manually edited files
Hi, We give MSI patches using wix. Customers some time manually edit the xml files and some other config files. When the customer apply our msi patch, The patch is not replacing the manually edited files in the customer environment. Is there any way as to replace all the files irrespective of any manual modifications. Thanks Regards, Srivardhan. -- 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] The DirProperty in RemoveFile table must be a property name in Directory table?
Thanks. After adding the version resource, add a EnsureTable Id=RemoveFile / element, the RemoveFoldersEx action executed successfully. Action 14:10:30: RemoveFoldersEx. Action start 14:10:30: RemoveFoldersEx. MSI (s) (A8:24) [14:10:30:747]: Invoking remote custom action. DLL: C:\Windows\Installer\MSI8168.tmp, Entrypoint: RemoveFoldersEx MSI (s) (A8!60) [14:10:30:747]: PROPERTY CHANGE: Adding _dirCB80BB8E7C4DF6458FEC42C79CD3833C_0 property. Its value is 'C:\Program Files\Foo\bar\abc\'. MSI (s) (A8!60) [14:10:30:762]: PROPERTY CHANGE: Adding _dirCB80BB8E7C4DF6458FEC42C79CD3833C_1 property. Its value is 'C:\Program Files\Foo\bar\Logs\'. MSI (s) (A8!60) [14:10:30:762]: PROPERTY CHANGE: Adding _dirCB80BB8E7C4DF6458FEC42C79CD3833C_2 property. Its value is 'C:\Program Files\Foo\bar\'. Action ended 14:10:30: RemoveFoldersEx. Return value 1. Then, the installer hit the same fatal 2727 error, as I have by using my own c# CA: DEBUG: Error 2727: The directory entry '_dirCB80BB8E7C4DF6458FEC42C79CD3833C_0' does not exist in the Directory table The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2727. The arguments are: _dirCB80BB8E7C4DF6458FEC42C79CD3833C_0, , MSI (s) (A8:5C) [14:14:36:492]: Product: System Center Atlanta -- The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2727. The arguments are: _dirCB80BB8E7C4DF6458FEC42C79CD3833C_0, , Does this approach really work? -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/The-DirProperty-in-RemoveFile-table-must-be-a-property-name-in-Directory-table-tp5317922p5328465.html Sent from the wix-users mailing list archive at Nabble.com. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Drivers' installation design
As I understand in this approach there will be one immediate ca (that will marshal the data to the deferred) and only one deferred custom action that will configure all drivers. If there will be a custom actions for each action to driver, I will have to describe them all in my wixlib. The problem is that I can't schedule only a few deferred custom actions (like InstallDrivers, RemoveDevice, ReinstallDevice) for all drivers because the sequence of drivers' installation also is important (so first I have to run for example InstallDriver, ReinstallDevice for one driver and only after that InstallDriver, ReinstallDevice for another). Also for some drivers actions take different parameters on different conditions (for example on upgrade from one of old versions and on clear installations or upgrade from other versions). Maybe I misunderstand something and it could be done with WixExtension... But I don't see how. -Original Message- From: Blair [mailto:os...@live.com] Sent: Thursday, July 22, 2010 9:15 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Drivers' installation design The WixExtension can supply a compiler extension to implement your schema for your pattern (allows you to easily describe what is being installed) and should populate your custom table that your custom actions use to control their work. It should also create a reference to the fragment in your wixlib where each custom action set is declared and scheduled, so you don't have to expose that to your authors. Your table should include a foreign key to the Components table so that you can use the installation request states of those components to facilitate your install/remove/upgrade/repair determinations. Each custom action should then read the table(s) and marshal the data to the deferred, rollback, and commit (if needed) actions. Organized that way, it should be easy to use, easy to test, and easy to maintain. -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Thursday, July 22, 2010 7:18 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Drivers' installation design I would use a WixExtension. Why didn't that seem to work? On Thu, Jul 22, 2010 at 1:43 AM, vazhenin_mak...@emc.com wrote: I work on WiX-based installer for large product, we need to install 16 drivers (of 3 different types, so there is 3 installation patterns). Difx library is not flexible enough, so we have our own tool to install drivers. For each driver necessary to run this tool about 3 times (for example: remove phantom devices, install disk driver, remove root device), and some of these actions required rollback. So there are about 5 types of custom actions (install, uninstall, remove, reinstall, repair) with different parameters. Write ~50 custom actions for all drivers isn't a good decision, because it's very hard to support this code. What is the best solution to describe a complicated installation process? I already tried the following decisions: - preprocessor cycles. Code becomes compact but very hard to understand. - compiler extension (to describe each type of custom actions). This is useful but still I can't write an installation pattern with it. - preprocessor extension. This seems to be the best solution (also using compiler extension). I wrote preprocessor functions like InstallDriver(Inf=[#mpio.inf], RootDevice=MPIO, Execute=onInstall, Condition=$(var.InstallCondition)) and define the installation sequence in a variable: ?define Actions=InstallDriver(...);RemoveDevice(...);ReinstallDevice(...)? then include a .wxi file with default parameters and required custom actions' definitions. But in these approach there is a problem with custom actions' names (where to define them? in function parameters isn't very clear, randomly like CA_InstallDriver.mpio.9fdcd3f3e45e45e8944194884abf2708 also isn't good, because in every build custom actions will have different names...). - custom table and immediate custom action to add deferred custom actions for all drivers. It also seems good but it's hard to debug. Will be grateful for any suggestions. Thanks, Maks. -- 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
Re: [WiX-users] The DirProperty in RemoveFile table must be a property name in Directory table?
I shipped a couple CTPs of Live Mesh using that code. It worked for me then. On Thu, Jul 22, 2010 at 11:16 PM, Elfe Xu elf...@microsoft.com wrote: Thanks. After adding the version resource, add a EnsureTable Id=RemoveFile / element, the RemoveFoldersEx action executed successfully. Action 14:10:30: RemoveFoldersEx. Action start 14:10:30: RemoveFoldersEx. MSI (s) (A8:24) [14:10:30:747]: Invoking remote custom action. DLL: C:\Windows\Installer\MSI8168.tmp, Entrypoint: RemoveFoldersEx MSI (s) (A8!60) [14:10:30:747]: PROPERTY CHANGE: Adding _dirCB80BB8E7C4DF6458FEC42C79CD3833C_0 property. Its value is 'C:\Program Files\Foo\bar\abc\'. MSI (s) (A8!60) [14:10:30:762]: PROPERTY CHANGE: Adding _dirCB80BB8E7C4DF6458FEC42C79CD3833C_1 property. Its value is 'C:\Program Files\Foo\bar\Logs\'. MSI (s) (A8!60) [14:10:30:762]: PROPERTY CHANGE: Adding _dirCB80BB8E7C4DF6458FEC42C79CD3833C_2 property. Its value is 'C:\Program Files\Foo\bar\'. Action ended 14:10:30: RemoveFoldersEx. Return value 1. Then, the installer hit the same fatal 2727 error, as I have by using my own c# CA: DEBUG: Error 2727: The directory entry '_dirCB80BB8E7C4DF6458FEC42C79CD3833C_0' does not exist in the Directory table The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2727. The arguments are: _dirCB80BB8E7C4DF6458FEC42C79CD3833C_0, , MSI (s) (A8:5C) [14:14:36:492]: Product: System Center Atlanta -- The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2727. The arguments are: _dirCB80BB8E7C4DF6458FEC42C79CD3833C_0, , Does this approach really work? -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/The-DirProperty-in-RemoveFile-table-must-be-a-property-name-in-Directory-table-tp5317922p5328465.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] Automatically include arbitrary files
Yes, exactly. On Thu, Jul 22, 2010 at 12:26 PM, Lukas Haase lukasha...@gmx.at wrote: Dear Blair, Thank you very much for your comprehensive explanation. Together with the comments from Does the MSI-filename matter I think I won't care about minor and small updates and just ship always a major upgrade. Morever if this is best practice. The saving isn't it worth! Just one last comment on this: I will always ship anything and just always change version and product GUID. But I will always keep the same UpgradeCode, won't I? This means that as long as I keep the UpgradeCode the same the MSI will detect a previous version and may upgrade it? Regards, Luke Am 22.07.2010 19:05, schrieb Blair: One strategy would be to split your package into two (one with the frequently changing stuff and another with the rarely changing stuff) and use a bootstrapper to tie them together, but given the relative size differences between your frequently changing (database and pdf files) and your rarely changing (viewer misc files) that doesn't buy you much (I'm calculating a greater than 80:1 ratio of frequent to rare, which gives me 2% static content). If you are vigilant at maintaining the component rules you can use late scheduling of the RemoveExistingProducts and avoid reinstalling the files that rarely change (except, of course, when they are changed) [which saves the time that would have been spent erasing and rewriting them] but you would still be shipping them with each build. If you are only adding/changing files (and you don't otherwise move any component out of any feature) you do have the possibility of using patching to supply your updates, but mixing MSP releases with MSI releases quickly explodes your testing and support matrix and you often no longer realize any size savings in your MSP files (unless you follow the for any given build, release either MSI or superseding MSP, never both rule, which requires new customers to apply the MSI and latest MSP. There can also be issues with MSP removal when adding files, so my recommendation in that case is to make your MSPs superseding and non-uninstallable (they will be uninstalled when the MSI is removed) to reduce your complexity and keep your servicing story more manageable. If all that added complexity is worth saving less than 2% of the size of your updating customers downloads (assuming that the database and PDF files all change every release) then go for it (just test every conceivable scenario before letting anything out the door). Of course, the savings using patching goes up the more you don't change, so my back-of-the-envelope analysis may not be correct. Blair -Original Message- From: Lukas Haase [mailto:lukasha...@gmx.at] Sent: Thursday, July 22, 2010 4:49 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Automatically include arbitrary files ... Since you are adding and removing PDF files, you should be planning on only using Major Upgrades, and so your Product/@Id value should also be * (in that case, the algorithm simply generates a new guid each time, which is the primary requirement for generating major upgrades). Really? :-( I have questions regarding upgrades/packaging left anyway, but for now: My application consists of a viewer (1MB exe + 1kb DLL + helpfile, README, ...) which will be more or less static. The data itself is contained in an 80MB database file and a directory of PDFs (mentioned above). Usually the viewer won't really change in future but every few months there will be an update where the database file as well as the PDFs will be upgraded. I was really happy when I read the WiX Howto because I thought I really can do real upgrades now, i.e. make packages without the viewer component but only update the PDFs and the database file. Is this really not possible in this case? Is it at least possible if only PDFs are added and not removed? Because the PDFs are small and they could reside on the client PC until the next major upgrade... ... -- 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 -- 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
Re: [WiX-users] Drivers' installation design
You are in control of that. If there are sequencing requirements between different drivers, etc. you can represent that in your schema and in your table(s), and make your immediate action (or several immediate actions, if that helps with setting sequencing, each can act on only the part of the data they are interested in) process all that data such that the deferred actions are performed in the correct order. You, as the writer of the actions, are in complete control. All Windows Installer and WiX offer is a framework within which to build correct, effective, and scalable deployment solutions. If you wish, there are several of us on this list that could help you plan or even implement this. Just ask for those interested to respond privately with their requirements for quotes. -Original Message- From: vazhenin_mak...@emc.com [mailto:vazhenin_mak...@emc.com] Sent: Thursday, July 22, 2010 11:21 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Drivers' installation design As I understand in this approach there will be one immediate ca (that will marshal the data to the deferred) and only one deferred custom action that will configure all drivers. If there will be a custom actions for each action to driver, I will have to describe them all in my wixlib. The problem is that I can't schedule only a few deferred custom actions (like InstallDrivers, RemoveDevice, ReinstallDevice) for all drivers because the sequence of drivers' installation also is important (so first I have to run for example InstallDriver, ReinstallDevice for one driver and only after that InstallDriver, ReinstallDevice for another). Also for some drivers actions take different parameters on different conditions (for example on upgrade from one of old versions and on clear installations or upgrade from other versions). Maybe I misunderstand something and it could be done with WixExtension... But I don't see how. -Original Message- From: Blair [mailto:os...@live.com] Sent: Thursday, July 22, 2010 9:15 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Drivers' installation design The WixExtension can supply a compiler extension to implement your schema for your pattern (allows you to easily describe what is being installed) and should populate your custom table that your custom actions use to control their work. It should also create a reference to the fragment in your wixlib where each custom action set is declared and scheduled, so you don't have to expose that to your authors. Your table should include a foreign key to the Components table so that you can use the installation request states of those components to facilitate your install/remove/upgrade/repair determinations. Each custom action should then read the table(s) and marshal the data to the deferred, rollback, and commit (if needed) actions. Organized that way, it should be easy to use, easy to test, and easy to maintain. -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Thursday, July 22, 2010 7:18 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Drivers' installation design I would use a WixExtension. Why didn't that seem to work? On Thu, Jul 22, 2010 at 1:43 AM, vazhenin_mak...@emc.com wrote: I work on WiX-based installer for large product, we need to install 16 drivers (of 3 different types, so there is 3 installation patterns). Difx library is not flexible enough, so we have our own tool to install drivers. For each driver necessary to run this tool about 3 times (for example: remove phantom devices, install disk driver, remove root device), and some of these actions required rollback. So there are about 5 types of custom actions (install, uninstall, remove, reinstall, repair) with different parameters. Write ~50 custom actions for all drivers isn't a good decision, because it's very hard to support this code. What is the best solution to describe a complicated installation process? I already tried the following decisions: - preprocessor cycles. Code becomes compact but very hard to understand. - compiler extension (to describe each type of custom actions). This is useful but still I can't write an installation pattern with it. - preprocessor extension. This seems to be the best solution (also using compiler extension). I wrote preprocessor functions like InstallDriver(Inf=[#mpio.inf], RootDevice=MPIO, Execute=onInstall, Condition=$(var.InstallCondition)) and define the installation sequence in a variable: ?define Actions=InstallDriver(...);RemoveDevice(...);ReinstallDevice(...)? then include a .wxi file with default parameters and required custom actions' definitions. But in these approach there is a problem with custom actions' names (where to define them? in function parameters isn't very clear, randomly like CA_InstallDriver.mpio.9fdcd3f3e45e45e8944194884abf2708 also isn't good,
Re: [WiX-users] InstallExecuteSequence completely ignored
Is your added authoring in a fragment that has other things that ARE in the MSI (use ORCA to see what got into the MSI)? -Original Message- From: Lukas Haase [mailto:lukasha...@gmx.at] Sent: Thursday, July 22, 2010 12:12 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] InstallExecuteSequence completely ignored Hi, As proposed in one mail I wrote a DLL for detecting old installations. But WiX seems to completely ignore InstallExecuteSequence! I played around, tried different things but it is just ignored! For testing I just added this to my file: Property Id='NOTEPAD'Notepad.exe/Property CustomAction Id='FooBar' Property='NOTEPAD' ExeCommand='' Return='asyncNoWait' / InstallExecuteSequence Custom Action='FooBar' After='LaunchConditions' / /InstallExecuteSequence Even if I install with msiexec /i test.msi /l*vx logfile.log there is not even the word FooBar included! After LaunchConditions there is ValidateProductID executed: [...] Aktion gestartet um 21:07:26: LaunchConditions. Aktion beendet um 21:07:26: LaunchConditions. Rückgabewert 1. MSI (c) (74:80) [21:07:26:477]: Doing action: ValidateProductID Aktion 21:07:26: ValidateProductID. [...] Is there anything I should additionally do? Regards, Luke -- 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] Drivers' installation design
IIRC, the immediate custom action can schedule the same deferred custom action multiple times. We've slowly moved away from that patter to calling the deferred custom action once passing it a list of data because that runs much, much faster. On Thu, Jul 22, 2010 at 11:20 PM, vazhenin_mak...@emc.com wrote: As I understand in this approach there will be one immediate ca (that will marshal the data to the deferred) and only one deferred custom action that will configure all drivers. If there will be a custom actions for each action to driver, I will have to describe them all in my wixlib. The problem is that I can't schedule only a few deferred custom actions (like InstallDrivers, RemoveDevice, ReinstallDevice) for all drivers because the sequence of drivers' installation also is important (so first I have to run for example InstallDriver, ReinstallDevice for one driver and only after that InstallDriver, ReinstallDevice for another). Also for some drivers actions take different parameters on different conditions (for example on upgrade from one of old versions and on clear installations or upgrade from other versions). Maybe I misunderstand something and it could be done with WixExtension... But I don't see how. -Original Message- From: Blair [mailto:os...@live.com] Sent: Thursday, July 22, 2010 9:15 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Drivers' installation design The WixExtension can supply a compiler extension to implement your schema for your pattern (allows you to easily describe what is being installed) and should populate your custom table that your custom actions use to control their work. It should also create a reference to the fragment in your wixlib where each custom action set is declared and scheduled, so you don't have to expose that to your authors. Your table should include a foreign key to the Components table so that you can use the installation request states of those components to facilitate your install/remove/upgrade/repair determinations. Each custom action should then read the table(s) and marshal the data to the deferred, rollback, and commit (if needed) actions. Organized that way, it should be easy to use, easy to test, and easy to maintain. -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Thursday, July 22, 2010 7:18 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Drivers' installation design I would use a WixExtension. Why didn't that seem to work? On Thu, Jul 22, 2010 at 1:43 AM, vazhenin_mak...@emc.com wrote: I work on WiX-based installer for large product, we need to install 16 drivers (of 3 different types, so there is 3 installation patterns). Difx library is not flexible enough, so we have our own tool to install drivers. For each driver necessary to run this tool about 3 times (for example: remove phantom devices, install disk driver, remove root device), and some of these actions required rollback. So there are about 5 types of custom actions (install, uninstall, remove, reinstall, repair) with different parameters. Write ~50 custom actions for all drivers isn't a good decision, because it's very hard to support this code. What is the best solution to describe a complicated installation process? I already tried the following decisions: - preprocessor cycles. Code becomes compact but very hard to understand. - compiler extension (to describe each type of custom actions). This is useful but still I can't write an installation pattern with it. - preprocessor extension. This seems to be the best solution (also using compiler extension). I wrote preprocessor functions like InstallDriver(Inf=[#mpio.inf], RootDevice=MPIO, Execute=onInstall, Condition=$(var.InstallCondition)) and define the installation sequence in a variable: ?define Actions=InstallDriver(...);RemoveDevice(...);ReinstallDevice(...)? then include a .wxi file with default parameters and required custom actions' definitions. But in these approach there is a problem with custom actions' names (where to define them? in function parameters isn't very clear, randomly like CA_InstallDriver.mpio.9fdcd3f3e45e45e8944194884abf2708 also isn't good, because in every build custom actions will have different names...). - custom table and immediate custom action to add deferred custom actions for all drivers. It also seems good but it's hard to debug. Will be grateful for any suggestions. Thanks, Maks. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list
Re: [WiX-users] Automatically include arbitrary files
Correct. -Original Message- From: Lukas Haase [mailto:lukasha...@gmx.at] Sent: Thursday, July 22, 2010 12:27 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Automatically include arbitrary files Dear Blair, Thank you very much for your comprehensive explanation. Together with the comments from Does the MSI-filename matter I think I won't care about minor and small updates and just ship always a major upgrade. Morever if this is best practice. The saving isn't it worth! Just one last comment on this: I will always ship anything and just always change version and product GUID. But I will always keep the same UpgradeCode, won't I? This means that as long as I keep the UpgradeCode the same the MSI will detect a previous version and may upgrade it? Regards, Luke Am 22.07.2010 19:05, schrieb Blair: One strategy would be to split your package into two (one with the frequently changing stuff and another with the rarely changing stuff) and use a bootstrapper to tie them together, but given the relative size differences between your frequently changing (database and pdf files) and your rarely changing (viewer misc files) that doesn't buy you much (I'm calculating a greater than 80:1 ratio of frequent to rare, which gives me 2% static content). If you are vigilant at maintaining the component rules you can use late scheduling of the RemoveExistingProducts and avoid reinstalling the files that rarely change (except, of course, when they are changed) [which saves the time that would have been spent erasing and rewriting them] but you would still be shipping them with each build. If you are only adding/changing files (and you don't otherwise move any component out of any feature) you do have the possibility of using patching to supply your updates, but mixing MSP releases with MSI releases quickly explodes your testing and support matrix and you often no longer realize any size savings in your MSP files (unless you follow the for any given build, release either MSI or superseding MSP, never both rule, which requires new customers to apply the MSI and latest MSP. There can also be issues with MSP removal when adding files, so my recommendation in that case is to make your MSPs superseding and non-uninstallable (they will be uninstalled when the MSI is removed) to reduce your complexity and keep your servicing story more manageable. If all that added complexity is worth saving less than 2% of the size of your updating customers downloads (assuming that the database and PDF files all change every release) then go for it (just test every conceivable scenario before letting anything out the door). Of course, the savings using patching goes up the more you don't change, so my back-of-the-envelope analysis may not be correct. Blair -Original Message- From: Lukas Haase [mailto:lukasha...@gmx.at] Sent: Thursday, July 22, 2010 4:49 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Automatically include arbitrary files ... Since you are adding and removing PDF files, you should be planning on only using Major Upgrades, and so your Product/@Id value should also be * (in that case, the algorithm simply generates a new guid each time, which is the primary requirement for generating major upgrades). Really? :-( I have questions regarding upgrades/packaging left anyway, but for now: My application consists of a viewer (1MB exe + 1kb DLL + helpfile, README, ...) which will be more or less static. The data itself is contained in an 80MB database file and a directory of PDFs (mentioned above). Usually the viewer won't really change in future but every few months there will be an update where the database file as well as the PDFs will be upgraded. I was really happy when I read the WiX Howto because I thought I really can do real upgrades now, i.e. make packages without the viewer component but only update the PDFs and the database file. Is this really not possible in this case? Is it at least possible if only PDFs are added and not removed? Because the PDFs are small and they could reside on the client PC until the next major upgrade... ... -- 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 -- 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
Re: [WiX-users] The DirProperty in RemoveFile table must be a property name in Directory table?
Interesting. What is the Windoes Installer version it required? I'm using Win7, the installer version of the product is 4.0 (Package InstallerVersion=400 Compressed=yes /), the Windows Installer version on my machine is 5.0.7600.16385. I've no idea why my code failed :( -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/The-DirProperty-in-RemoveFile-table-must-be-a-property-name-in-Directory-table-tp5317922p5328531.html Sent from the wix-users mailing list archive at Nabble.com. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrading from other setup program to WiX/MSI
You shouldn't prompt from the execute sequence. There are ways of running MSI files where there is no user session to respond to the prompt and you would hang your install. The best way to show a message box from a custom action (and the only supported way if you must do so from the execute sequence) is using the MsiProcessMessage API (or something that wraps it, like WcaProcessMessage or Microsoft.Deployment.WindowsInstaller.Session.Message). -Original Message- From: Lukas Haase [mailto:lukasha...@gmx.at] Sent: Thursday, July 22, 2010 12:47 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Upgrading from other setup program to WiX/MSI Dear Blair, Am 22.07.2010 01:04, schrieb Blair: 1. You can build MSIs with WiX that don't require running the setup as administrator. Nothing that can be done outside of Windows Installer without elevation requires elevation in Windows Installer to also do. In fact this is exactly what I do NOT want: I need to register a COM component which requires admin privileges. So I have Property Id=ALLUSERS1/Property and Condition Message=... Privileged /Condition and I am lucky. In fact this is exactly what messed up my previous installations with SetupSpecialist: The old viewer did not need registering a COM, so some users installed as admins and systemwide, others not. Finally, SetupSpecialist lets you run the setup as normal user and when registering the COM the there is an error. The setup terminates and the a half installed system is left. In my opinion it is the best and consistent way to install the software just into the system (incl. Shortcuts for all users) 2. Windows Installer has no built-in support for detecting/removing non-MSI packages. However, if you know how to find/remove your SetupSpecialist package (the Uninstall key, perhaps?) then you can detect presence and automate removal as part of your upgrade (does the old installer allow silent removal?) You may have trouble detecting/removing things installed by other than the current user, however, but that is due to the nature of how Windows treats user accounts/profiles, not do to any inherent limitation in Windows Installer itself. Thank you for the hint. This is what I have done now. As written in a new post (InstallExecuteSequence completely ignored) I face heavy problems concerning this right now. However, my approach is: CustomAction Id='CheckingSpecialist' BinaryKey='CheckingSpecialist' DllEntry='CheckSpecialist' / CustomAction Id='RefuseInstall' Error='You must uninstall the old one first' / InstallExecuteSequence Custom Action='CheckingSpecialist' After='LaunchConditions' / Custom Action='RefuseInstall' After='CheckingSpecialist'ABORT = 1/Custom /InstallExecuteSequence Binary Id='CheckingSpecialist' SourceFile='CheckSpecialist/Release/CheckSpecialist.dll' / The DLL just opens the registry key in Uninstall and reads out the path to the uninstall program. Then it asks: You must remove the old first, do you want to?. If the users answers with no, then ABORT = 1 is set. Otherwise, the process uninstall is started with ShellExecuteEx and waited for termination with WaitForSingleObject. Afterwards ABORT = 0 is set. If it fails to open the key (i.e. no old version found) just ABORT = 0 is set. Is this a good idea or did I break some best practices? Regards, Luke -- 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] Drivers' installation design
Rob, Blair thank you very much for your explanation! I haven't known that the immediate custom action can schedule the same deferred custom action multiple times. I will try it now. If I'll have some problems with it I will ask for help. Regards, Maks -Original Message- From: Blair [mailto:os...@live.com] Sent: Friday, July 23, 2010 10:38 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Drivers' installation design You are in control of that. If there are sequencing requirements between different drivers, etc. you can represent that in your schema and in your table(s), and make your immediate action (or several immediate actions, if that helps with setting sequencing, each can act on only the part of the data they are interested in) process all that data such that the deferred actions are performed in the correct order. You, as the writer of the actions, are in complete control. All Windows Installer and WiX offer is a framework within which to build correct, effective, and scalable deployment solutions. If you wish, there are several of us on this list that could help you plan or even implement this. Just ask for those interested to respond privately with their requirements for quotes. -Original Message- From: vazhenin_mak...@emc.com [mailto:vazhenin_mak...@emc.com] Sent: Thursday, July 22, 2010 11:21 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Drivers' installation design As I understand in this approach there will be one immediate ca (that will marshal the data to the deferred) and only one deferred custom action that will configure all drivers. If there will be a custom actions for each action to driver, I will have to describe them all in my wixlib. The problem is that I can't schedule only a few deferred custom actions (like InstallDrivers, RemoveDevice, ReinstallDevice) for all drivers because the sequence of drivers' installation also is important (so first I have to run for example InstallDriver, ReinstallDevice for one driver and only after that InstallDriver, ReinstallDevice for another). Also for some drivers actions take different parameters on different conditions (for example on upgrade from one of old versions and on clear installations or upgrade from other versions). Maybe I misunderstand something and it could be done with WixExtension... But I don't see how. -Original Message- From: Blair [mailto:os...@live.com] Sent: Thursday, July 22, 2010 9:15 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Drivers' installation design The WixExtension can supply a compiler extension to implement your schema for your pattern (allows you to easily describe what is being installed) and should populate your custom table that your custom actions use to control their work. It should also create a reference to the fragment in your wixlib where each custom action set is declared and scheduled, so you don't have to expose that to your authors. Your table should include a foreign key to the Components table so that you can use the installation request states of those components to facilitate your install/remove/upgrade/repair determinations. Each custom action should then read the table(s) and marshal the data to the deferred, rollback, and commit (if needed) actions. Organized that way, it should be easy to use, easy to test, and easy to maintain. -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Thursday, July 22, 2010 7:18 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Drivers' installation design I would use a WixExtension. Why didn't that seem to work? On Thu, Jul 22, 2010 at 1:43 AM, vazhenin_mak...@emc.com wrote: I work on WiX-based installer for large product, we need to install 16 drivers (of 3 different types, so there is 3 installation patterns). Difx library is not flexible enough, so we have our own tool to install drivers. For each driver necessary to run this tool about 3 times (for example: remove phantom devices, install disk driver, remove root device), and some of these actions required rollback. So there are about 5 types of custom actions (install, uninstall, remove, reinstall, repair) with different parameters. Write ~50 custom actions for all drivers isn't a good decision, because it's very hard to support this code. What is the best solution to describe a complicated installation process? I already tried the following decisions: - preprocessor cycles. Code becomes compact but very hard to understand. - compiler extension (to describe each type of custom actions). This is useful but still I can't write an installation pattern with it. - preprocessor extension. This seems to be the best solution (also using compiler extension). I wrote preprocessor functions like InstallDriver(Inf=[#mpio.inf], RootDevice=MPIO, Execute=onInstall,
Re: [WiX-users] [BUMP] Passing Values from the ProductModule to a MergeModule - Solved (plus a question for clarification)
Check a verbose extra-info log (both the v and the x in your logging parameters) and you will see exactly when those properties are set. You can then find a place to set your property. -Original Message- From: John Bergman [mailto:john.berg...@xpedienttechnologies.com] Sent: Thursday, July 22, 2010 3:59 PM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] [BUMP] Passing Values from the ProductModule to a MergeModule - Solved (plus a question for clarification) -- Copied from below, it would be appreciated if someone could shed some insight into this. What I was unable to get working is the code that combines the Domain\User in a custom action, I suppose this has to do with the ordering if the CA, Property Id=PermissionableUser Value=user/ CustomAction Id='SetPermissionableUser' Property='PermissionableUser' Value='[DOMAIN]\[USER]' / InstallExecuteSequence Custom Action='SetPermissionableUser' After='LaunchConditions'/Custom /InstallExecuteSequence Can someone comment as to when the CA should execute to have access to the imported properties? The location above does not work because the values are still initialized. (Also, Thanks to everyone that provided pointers, this would be a good candidate for the WiX Wiki or tutorial, should someone care to add it). I pruned the rest of the conversation so that this message is uncluttered. -Original Message- From: John Bergman [mailto:john.berg...@xpedienttechnologies.com] Sent: Wednesday, July 21, 2010 12:48 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Passing Values from the ProductModule to a MergeModule - Solved (plus a question for clarification) That is what I thought, but I was still having problems. I have resolve the issue for what I need, (at least for now). In the main product module, you need to declare the properties as follows: Property Id=DOMAIN SuppressModularization=yes Secure=yes / Property Id=USER SuppressModularization=yes Secure=yes / Property Id=PASSWORD SuppressModularization=yes Secure=yes / Then, in the Merge Module you have to set it up to receive the configuration, and map it to the properties, this is what I have in my merge module Configuration Name=DOMAIN Format=Key Type=Identifier DefaultValue=DOMAIN Description=Service Domain DisplayName=Service Domain/ Configuration Name=USER Format=Key Type=Identifier DefaultValue=USER Description=Service User DisplayName=Service User/ Configuration Name=PASSWORD Format=Key Type=Identifier DefaultValue=PASSWORD Description=Service Password DisplayName=Service Password/ I was able to use the values in my service installer as follows: !-- Install the service -- ServiceInstall Id='ServiceInstaller' Type='ownProcess' Vital=yes Name=XPedientServiceHost DisplayName=My Service Description=My Service Start=auto Account=[DOMAIN]\[USER] Password=[PASSWORD] ErrorControl=normal Interactive=no ServiceDependency Id=Eventlog / util:ServiceConfig FirstFailureActionType=restart SecondFailureActionType=restart ThirdFailureActionType=restart/ /ServiceInstall You also have to declare the properties Property Id=DOMAIN SuppressModularization=yes Secure=yes / Property Id=USER SuppressModularization=yes Secure=yes / Property Id=PASSWORD SuppressModularization=yes Secure=yes / What I was unable to get working is the code that combines the Domain\User in a custom action, I suppose this has to do with the ordering if the CA, Property Id=PermissionableUser Value=user/ CustomAction Id='SetPermissionableUser' Property='PermissionableUser' Value='[DOMAIN]\[USER]' / InstallExecuteSequence Custom Action='SetPermissionableUser' After='LaunchConditions'/Custom /InstallExecuteSequence Can someone comment as to when the CA should execute to have access to the imported properties? The location above does not work because the values are still initialized. (Also, Thanks to everyone that provided pointers, this would be a good candidate for the WiX Wiki or tutorial, should someone care to add it). I pruned the rest of the conversation so that this message is uncluttered. -- 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
Re: [WiX-users] The DirProperty in RemoveFile table must be a property name in Directory table?
The custom action DLL that ends up inside of the Binary table contains the custom action's compiled code must have a Win32 VERSION resource. If you look at that file in the Windows Shell, you can right-click the file then select Properties and see a Details tab (in Win7 and I think Vista also, I've already forgotten the name of the tab in XP) and you will see entries like Product version, File version, Copyright, and/or File description (you may not see all of these, and you may see others besides, but at least one of them would appear if the version resource is present). -Original Message- From: Elfe Xu [mailto:elf...@microsoft.com] Sent: Thursday, July 22, 2010 11:43 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] The DirProperty in RemoveFile table must be a property name in Directory table? Interesting. What is the Windoes Installer version it required? I'm using Win7, the installer version of the product is 4.0 (Package InstallerVersion=400 Compressed=yes /), the Windows Installer version on my machine is 5.0.7600.16385. I've no idea why my code failed :( -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/The-DirPropert y-in-RemoveFile-table-must-be-a-property-name-in-Directory-table-tp5317922p5 328531.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 -- 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] The DirProperty in RemoveFile table must be a property name in Directory table?
Thanks Blair. I've already have the version problem resolved by adding the version resource. This time it's the 2727 fatal error again. Because on my machine seems the if I add rows to RemoveFile with normal property, the installer will fail because the DirProperty is not in Directory table. However, Rob says he has use this approach successfully before. So I wander if it's because the platform/WI version that cause the different behavior. Thanks, -Elfe -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/The-DirProperty-in-RemoveFile-table-must-be-a-property-name-in-Directory-table-tp5317922p5328630.html Sent from the wix-users mailing list archive at Nabble.com. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Drivers' installation design
Yeah, it's pretty crazy. The CA DLL is actually inserted into the execution script for each schedule action. On Thu, Jul 22, 2010 at 11:56 PM, vazhenin_mak...@emc.com wrote: Rob, Blair thank you very much for your explanation! I haven't known that the immediate custom action can schedule the same deferred custom action multiple times. I will try it now. If I'll have some problems with it I will ask for help. Regards, Maks -Original Message- From: Blair [mailto:os...@live.com] Sent: Friday, July 23, 2010 10:38 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Drivers' installation design You are in control of that. If there are sequencing requirements between different drivers, etc. you can represent that in your schema and in your table(s), and make your immediate action (or several immediate actions, if that helps with setting sequencing, each can act on only the part of the data they are interested in) process all that data such that the deferred actions are performed in the correct order. You, as the writer of the actions, are in complete control. All Windows Installer and WiX offer is a framework within which to build correct, effective, and scalable deployment solutions. If you wish, there are several of us on this list that could help you plan or even implement this. Just ask for those interested to respond privately with their requirements for quotes. -Original Message- From: vazhenin_mak...@emc.com [mailto:vazhenin_mak...@emc.com] Sent: Thursday, July 22, 2010 11:21 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Drivers' installation design As I understand in this approach there will be one immediate ca (that will marshal the data to the deferred) and only one deferred custom action that will configure all drivers. If there will be a custom actions for each action to driver, I will have to describe them all in my wixlib. The problem is that I can't schedule only a few deferred custom actions (like InstallDrivers, RemoveDevice, ReinstallDevice) for all drivers because the sequence of drivers' installation also is important (so first I have to run for example InstallDriver, ReinstallDevice for one driver and only after that InstallDriver, ReinstallDevice for another). Also for some drivers actions take different parameters on different conditions (for example on upgrade from one of old versions and on clear installations or upgrade from other versions). Maybe I misunderstand something and it could be done with WixExtension... But I don't see how. -Original Message- From: Blair [mailto:os...@live.com] Sent: Thursday, July 22, 2010 9:15 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Drivers' installation design The WixExtension can supply a compiler extension to implement your schema for your pattern (allows you to easily describe what is being installed) and should populate your custom table that your custom actions use to control their work. It should also create a reference to the fragment in your wixlib where each custom action set is declared and scheduled, so you don't have to expose that to your authors. Your table should include a foreign key to the Components table so that you can use the installation request states of those components to facilitate your install/remove/upgrade/repair determinations. Each custom action should then read the table(s) and marshal the data to the deferred, rollback, and commit (if needed) actions. Organized that way, it should be easy to use, easy to test, and easy to maintain. -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Thursday, July 22, 2010 7:18 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Drivers' installation design I would use a WixExtension. Why didn't that seem to work? On Thu, Jul 22, 2010 at 1:43 AM, vazhenin_mak...@emc.com wrote: I work on WiX-based installer for large product, we need to install 16 drivers (of 3 different types, so there is 3 installation patterns). Difx library is not flexible enough, so we have our own tool to install drivers. For each driver necessary to run this tool about 3 times (for example: remove phantom devices, install disk driver, remove root device), and some of these actions required rollback. So there are about 5 types of custom actions (install, uninstall, remove, reinstall, repair) with different parameters. Write ~50 custom actions for all drivers isn't a good decision, because it's very hard to support this code. What is the best solution to describe a complicated installation process? I already tried the following decisions: - preprocessor cycles. Code becomes compact but very hard to understand. - compiler extension (to describe each type of custom actions). This is useful
Re: [WiX-users] Drivers' installation design
The problem with is rollback. If we have one deferred custom action for all drivers, then we need to know what action failed, so we have to write somewhere what actions we have done and what to do to rollback each of them. -Original Message- From: Blair [mailto:os...@live.com] Sent: Friday, July 23, 2010 11:18 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Drivers' installation design Also I see no reason that one deferred action can't be fed data it loops on such that it does InstallDriver for driver A, then ReinstallDriver for driver B, then InstallDriver for driver C then RemoveDriver for driver D followed by ReinstallDriver for driver C or whatever else you need in whatever order it should end up in. Like Rob said, calling a deferred action one time with a bunch of data is faster than calling several actions, each with just parts of that data. -Original Message- From: vazhenin_mak...@emc.com [mailto:vazhenin_mak...@emc.com] Sent: Thursday, July 22, 2010 11:57 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Drivers' installation design Rob, Blair thank you very much for your explanation! I haven't known that the immediate custom action can schedule the same deferred custom action multiple times. I will try it now. If I'll have some problems with it I will ask for help. Regards, Maks -Original Message- From: Blair [mailto:os...@live.com] Sent: Friday, July 23, 2010 10:38 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Drivers' installation design You are in control of that. If there are sequencing requirements between different drivers, etc. you can represent that in your schema and in your table(s), and make your immediate action (or several immediate actions, if that helps with setting sequencing, each can act on only the part of the data they are interested in) process all that data such that the deferred actions are performed in the correct order. You, as the writer of the actions, are in complete control. All Windows Installer and WiX offer is a framework within which to build correct, effective, and scalable deployment solutions. If you wish, there are several of us on this list that could help you plan or even implement this. Just ask for those interested to respond privately with their requirements for quotes. -Original Message- From: vazhenin_mak...@emc.com [mailto:vazhenin_mak...@emc.com] Sent: Thursday, July 22, 2010 11:21 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Drivers' installation design As I understand in this approach there will be one immediate ca (that will marshal the data to the deferred) and only one deferred custom action that will configure all drivers. If there will be a custom actions for each action to driver, I will have to describe them all in my wixlib. The problem is that I can't schedule only a few deferred custom actions (like InstallDrivers, RemoveDevice, ReinstallDevice) for all drivers because the sequence of drivers' installation also is important (so first I have to run for example InstallDriver, ReinstallDevice for one driver and only after that InstallDriver, ReinstallDevice for another). Also for some drivers actions take different parameters on different conditions (for example on upgrade from one of old versions and on clear installations or upgrade from other versions). Maybe I misunderstand something and it could be done with WixExtension... But I don't see how. -Original Message- From: Blair [mailto:os...@live.com] Sent: Thursday, July 22, 2010 9:15 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Drivers' installation design The WixExtension can supply a compiler extension to implement your schema for your pattern (allows you to easily describe what is being installed) and should populate your custom table that your custom actions use to control their work. It should also create a reference to the fragment in your wixlib where each custom action set is declared and scheduled, so you don't have to expose that to your authors. Your table should include a foreign key to the Components table so that you can use the installation request states of those components to facilitate your install/remove/upgrade/repair determinations. Each custom action should then read the table(s) and marshal the data to the deferred, rollback, and commit (if needed) actions. Organized that way, it should be easy to use, easy to test, and easy to maintain. -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Thursday, July 22, 2010 7:18 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Drivers' installation design I would use a WixExtension. Why didn't that seem to work? On Thu, Jul 22, 2010 at 1:43 AM, vazhenin_mak...@emc.com wrote: I work on WiX-based installer for large product, we need to
[WiX-users] Patches are getting installed automatically on Microsoft Vista OS
Hi We have a technical isuue on Fix Pack 2.x installation. Scenario: 1. RTM + SP2 patch + FP 2.x patch Installed on windows vista using admin user 2. Create another user and add him to admin group. 3. Login with newly created user, SP2 installation runs automatically When we enable UAC on windows Vista, this doesn’t happen. But my Manager doesn’t want to enable UAC because of security issues on windows vista. Can you please help me to resolve this issue? i want to know, why patch installation is getting installed automatically? Thanks, Phani -- 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] Questions about showing warning/error message dialog
Hi, Hope you are not get tired with my name, as I've posted sooo many questions. 1. When write registry value fails, an error message dialog will pop up, and show Retry/Cancel/Ignore. However, in our product, some registry keys are critical, and we don't want allow user to choose Ignore, and rollback if fail. How could I change it to show Retry/Cancel only? 2. For CustomActions that call some executables (type2, type34 etc), we can have the \...@return set to check/ignore etc. If choose check, the failure will cause abort; if choose ignore, the failure will only be logged, but user will not be aware of the failure. How could I make it to show a warning dialog? Surely I can write some wrapper to run the executable, and then use session.Message to show the error. But I wonder if there is an easier way, to assign the CustomAction return value to some property, and then show the warning/error? 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
[WiX-users] Visual Studio Bootstrapper- define order of prerequisites to be installed
Hi Our wix installer makes use of the visual studio 2008 bootstrapper functionality to install Windows Installer 3.1, .NET 3.5 SP1 and Crystal reports. This used to work but suddenly there is an error when i start the setup on a clean machine. After aggreeing to the licence files of crystel reports and of the .NET framework (windows installer is already on the machine) it starts installing crystal reports but it fails. In my opinion, the reason for this is the fact that crystal reports gets installed bevore the .NET framework, which is not the case. How can i ensure the order in which the prerequisites are installed? I tried to change the crystal reports package so it depends on the .NET framework but with no success. Parts of prerequisite package.file (product.xml) from crystal reports: DependsOnProduct Code=Microsoft.Net.Framework.3.5.SP1 / !-- it actually depends on .Net 2.0 but this way we ensure .net framework is installed first DependsOnProduct Code=Microsoft.Net.Framework.2.0 / -- /RelatedProducts Here is our visual studio project file: ItemGroup BootstrapperFile Include=Microsoft.Windows.Installer.3.1 ProductNameWindows Installer 3.1/ProductName /BootstrapperFile BootstrapperFile Include=Microsoft.Net.Framework.3.5.SP1 ProductName.NET Framework 3.5 SP1/ProductName /BootstrapperFile BootstrapperFile Include=BusinessObjects.CrystalReports.10.5 ProductNameCrystal Reports/ProductName /BootstrapperFile /ItemGroup Target Name=AfterBuild GenerateBootstrapper ApplicationFile=Msi\InstallerCaller.msi ApplicationName=Calibrate BootstrapperItems=@(BootstrapperFile) ComponentsLocation=Relative CopyComponents=True OutputPath=bin\$(Configuration)\ Path=$(ProjectDir)\Prerequisites Culture=de-de FallbackCulture=en-us /GenerateBootstrapper !-- -- 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] InstallExecuteSequence completely ignored
MSI (c) (74:80) [21:07:26:477]: Doing action: ValidateProductID Aktion 21:07:26: ValidateProductID. That's the InstallUISequence not the InstallExecuteSequence. WiX doesn't ignore InstallExecuteSequence as the InstallExecuteSequence is just another database table to WiX. WiX is a way for you to make packages for Windows Installer. If your custom action isn't running, it's highly unlikely the blame can be placed on WiX. 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: Blair [mailto:os...@live.com] Sent: 23 July 2010 07:40 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] InstallExecuteSequence completely ignored Is your added authoring in a fragment that has other things that ARE in the MSI (use ORCA to see what got into the MSI)? -Original Message- From: Lukas Haase [mailto:lukasha...@gmx.at] Sent: Thursday, July 22, 2010 12:12 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] InstallExecuteSequence completely ignored Hi, As proposed in one mail I wrote a DLL for detecting old installations. But WiX seems to completely ignore InstallExecuteSequence! I played around, tried different things but it is just ignored! For testing I just added this to my file: Property Id='NOTEPAD'Notepad.exe/Property CustomAction Id='FooBar' Property='NOTEPAD' ExeCommand='' Return='asyncNoWait' / InstallExecuteSequence Custom Action='FooBar' After='LaunchConditions' / /InstallExecuteSequence Even if I install with msiexec /i test.msi /l*vx logfile.log there is not even the word FooBar included! After LaunchConditions there is ValidateProductID executed: [...] Aktion gestartet um 21:07:26: LaunchConditions. Aktion beendet um 21:07:26: LaunchConditions. Rückgabewert 1. MSI (c) (74:80) [21:07:26:477]: Doing action: ValidateProductID Aktion 21:07:26: ValidateProductID. [...] Is there anything I should additionally do? Regards, Luke -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] The DirProperty in RemoveFile table must be a property name in Directory table?
If you read my reply you'll see I never mentioned user accounts
anywhere. My questions was Why are you storing user specific data under
the installation directory instead of somewhere like My Documents or
CommonAppData as per Microsoft's platform guidelines?.
Palbinder Sandher
Software Deployment IT Administrator
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501
http://www.iesve.com
**Design, Simulate + Innovate with the Virtual Environment**
Integrated Environmental Solutions Limited. Registered in Scotland No.
SC151456
Registered Office - Helix Building, West Of Scotland Science Park,
Glasgow G20 0SP
Email Disclaimer
-Original Message-
From: Elfe Xu [mailto:elf...@microsoft.com]
Sent: 23 July 2010 04:34
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] The DirProperty in RemoveFile table must be a
property name in Directory table?
The folder hierarchy is just a example. My application has nothing to do
with user accounts.
Thanks for the suggestion of using wix-contrib. At first I read the code
and thought it was easy for me to translate it to a C# version CA.
Anyway, I add version.lib to the projects, and get wix-contrib build
successfuly. However, when I use it in my project, it seems does not
work (still due to the version issue).
In my code, I have
xmlns:contri=http://wixtoolset.org/wixcontrib/2008;
And for the folders I want to delete completely,
Directory Id=dirA51B01A2E638149A2E0381A7B1B1FA0A Name=Foo
Component Id=cmpC736EC12CD6A4FF8C43A5AB7005B0C22
Guid={B6E6C8AF-EC5D-4A0C-B718-0B6823632C92} KeyPath=yes
CreateFolder /
contri:RemoveFolderEx On=uninstall /
/Component
The log is:
Action 11:29:04: RemoveFoldersEx.
Action start 11:29:04: RemoveFoldersEx.
RemoveFoldersEx: Error 0x80070715: Failed to get file version of custom
action dll CustomAction RemoveFoldersEx returned actual error code 1603
but will be translated to success due to continue marking Action ended
11:29:04: RemoveFoldersEx. Return value 1.
Any idea about the failure?
Thanks,
-Elfe
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/The-DirPro
perty-in-RemoveFile-table-must-be-a-property-name-in-Directory-table-tp5
317922p5328217.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
--
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] SETUPBLD and BURN, multiple uninstalls
Hi Team, It's been a while. I've recently given up on trying to find ways to trick the installer into working where a service needs to be started that relies on a copy of the CRT or .NET that the installer has to put on..An age old tale of mystery. I've finally produced a bootstrapped installer, I've always suspected that it will cause me a headache, but the generation of it was pretty simple.. I have my main installer, then a second installer that just has an exe and the service control stuff in it. Sadly the user now has to uninstall 2 programs, and I just know users will forget to do this. It seems that the bootstrapper (I used setupbld) doesn't notice that one of the packages it is about to install is already on the system, so carries on anyway. I guess this will be more of a request for burn... will(does) it: - have only one item in the uninstall list that represents many msi's chained. - allow a post install script to be run so I wouldn't need this second lightweight installer at all - check for the presence of any of the chained msis before attempting to install, and react according to some command line option? one day we'll get this right I'm sure .whatever happened to that portable executable idea, I liked that. Simon Disclaimer: This electronic communication and its attachments may contain confidential, proprietary and/or legally privileged information which are for the sole use of the intended recipient. If you are not the intended recipient, any use, distribution, or reproduction of this communication is strictly prohibited and may be unlawful; please contact the sender and delete this communication. MWH Soft does not warrant or make any representation regarding this transmission whatsoever nor does it warrant that it is free from viruses or defects, correct or reliable. MWH Soft is not liable for any loss or damage that occurs as a result of this communication entering your computer network. The views expressed in this message are not necessarily those of MWH Soft. This communication cannot form a binding agreement unless that is the express intent of the parties and they are authorized to make such an agreement. MWH Soft reserves all intellectual property rights contained in this transmission. MWH Soft reserves the right to monitor any electronic communication sent or received by its employees. MWH Soft Limited is registered in England with number 6975921. Its registered office is Terriers House, 201 Amersham Rd, High Wycombe, HP13 5AJ. -- 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] Unable to uninstall
Hey everyone, I made an installer with 2 custom actions, taking care of rollback as well. The problem is i messed up with one of them during uninstallation, and every time i try to unistall, it fails and the rollback takes place. So i am unable to uninstall (neither from the msi nor the control panel) Any ideas what i can do now? Regards, Stelios -- Stelios Kyprou Systems Engineer Formicary - delivering quality financial technology solutions(TM) www.formicary.net This message is confidential and may be privileged. It is intended solely for the named addressee. If you are not the intended recipient, please inform us. Any unauthorised dissemination, distribution or copying hereof is prohibited. Formicary Limited registered office in England and Wales, address 1 Taillar Road, Hedon, East Yorkshire HU12 8GU, registration number 3894343, VAT number 747644304, does not guarantee that the integrity of this communication has been maintained nor that this communication is free of viruses, interceptions or interference. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Problem with updating 1.0.1.1 to 1.0.2.1
hi, I have made a product and two patches, msi 1.0.0.1 msp(A) 1.0.1.1 (between 1.0.0.1 and 1.0.1.1) msp(B) 1.0.2.1 (between 1.0.0.1 and 1.0.2.1) I can update to 1.0.2.1 with (B) from 1.0.0.1, but can't update with (A) from 1.0.1.1. What I take attention for wxs? ?define PatchVersion = 1.2 ? 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 Product Id=184848AE-687E-4E63-9FBB-E41616F8608E Name=$(var.AppFullName) Language=1041 Codepage=932 Version=$(var.ProductVersion) Manufacturer=MyCompany UpgradeCode=E66227D3-C778-4817-9AB7-E949A7518674 ... !-- Upgrade Information -- Upgrade Id=$(var.UpgradeCode) UpgradeVersion Minimum=0.0.0 Maximum=$(var.ProductVersion) IncludeMinimum=yes Language=1033 Property=OLDUPGRADE / UpgradeVersion Minimum=$(var.ProductVersion) OnlyDetect=yes Language=1033 Property=DETECTNEW / /Upgrade /Product -- 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] Retry at RMFilesInUse an invalid return value ?
I want to use ExeCommand to start window service. But it shows the command prompt. Is there any way to hide the command prompt ??? Thanks and regards, Swapnil DISCLAIMER == This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. -- 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 32 bit and 64 bit merge modules
Hi Our setup includes various merge modules. Initially, they were all these merge modules were fore 32-bit systems. Testing the installed application on 64-bit windows 7 i found out that we would need the 64-bit merge modules. So I added them to the wxs file: !-- 32 bit -- Merge Id=VSWINFORMS SourceFile=ThirdParty\MergeModules\MStudioUIWinforms.2008.msm Language=1033 DiskId=1 / Merge Id=NIANLYS SourceFile=ThirdParty\MergeModules\nianlys.msm Language=1033 DiskId=1 / Merge Id=NIMESADLL SourceFile=ThirdParty\MergeModules\NIMesaDLL.msm Language=1033 DiskId=1 / Merge Id=NIMETAUTILS SourceFile=ThirdParty\MergeModules\niMetaUtils.msm Language=1033 DiskId=1 / !-- 64 bit -- Merge Id=VSWINFORMS64 SourceFile=ThirdParty\MergeModules\MStudioUIWinforms.2008_x64.msm Language=1033 DiskId=1 / Merge Id=NIANLYS64 SourceFile=ThirdParty\MergeModules\nianlys_x64.msm Language=1033 DiskId=1 / Merge Id=NIMESADLL64 SourceFile=ThirdParty\MergeModules\NIMesa_x64.msm Language=1033 DiskId=1 / Merge Id=NIMETAUTILS64 SourceFile=ThirdParty\MergeModules\niMetaUtils_x64.msm Language=1033 DiskId=1 / Unfortunately, upon compile I get the following error message: Encountered an unexpected merge error of type 'msmErrorPlatformMismatch' for which there is currently no error message to display. More information about the merge and the failure can be found in the merge log: 'C:\Dokumente und Einstellungen\Extnoser1\Lokale Einstellungen\Temp\5-i_y-vo\merge.log' light.exe 0 1 Installer How can i make this work? What is the right approach to ensure the application gets correctly installed on 32 and 64 bit machines. 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
[WiX-users] Property in localized string?
Hi. We are in the process of updating our previous installation framework to Wix and have encountered a minor problem. As a part of our deployment process we use a custom MsBuild script and a string to identify the program being installed (something like 1.2 Build.3 Rev 4) and I want to use it in the localized strings in UI. I already have a Property defined with that string in the .wixproj file but I don't know how to use in the localization file (I think I've tried with every combination of square brackets, exclamation mark, var. env. and wix. prefixes ;-) Where I can find more information? Thanks in advance. -- 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] Unable to uninstall
Had the same problem recently; http://majorgeeks.com/download.php?det=4459 helped. You will need to manually cleanup program files etc., but this should let you run your (fixed :~) ) installer. Ryszard Ryszard Boryna, Solutions Architect Tel: 0141 280 0050 NVable is a limited company registered in Scotland. Registered number: SC287922. Suite 6/5, Skypark SP1, 8 Elliot Pl, Glasgow, G3 8EP -Original Message- From: Stelios Kyprou [mailto:stelios.kyp...@formicary.net] Sent: 23 July 2010 11:43 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Unable to uninstall Hey everyone, I made an installer with 2 custom actions, taking care of rollback as well. The problem is i messed up with one of them during uninstallation, and every time i try to unistall, it fails and the rollback takes place. So i am unable to uninstall (neither from the msi nor the control panel) Any ideas what i can do now? Regards, Stelios -- Stelios Kyprou Systems Engineer Formicary - delivering quality financial technology solutions(TM) www.formicary.net This message is confidential and may be privileged. It is intended solely for the named addressee. If you are not the intended recipient, please inform us. Any unauthorised dissemination, distribution or copying hereof is prohibited. Formicary Limited registered office in England and Wales, address 1 Taillar Road, Hedon, East Yorkshire HU12 8GU, registration number 3894343, VAT number 747644304, does not guarantee that the integrity of this communication has been maintained nor that this communication is free of viruses, interceptions or interference. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Bootstrapper for .Net 2.0
Hi, Our application needs to have .NET 2.0 installed on the user's machine. It is used on both 32 bit and 64 bit operating systems. I looked at the example on Sourceforge and modified the project to create the bootstrapper with 32 bit dotnetfx 2.0, and it works fine. How do I add x64 and IA64 redistributables to the project so it can conditionally install these on different operating systems? Or do I need to write an unmanaged Windows bootstrap application to query the OS and decide which one to launch? Also it is not clear to me how I can query the registry. If my Win32 application queries the registry to check to see if the prerequisite is installed on x64 OS would it be seeing the WoW part of the registry? As I understand it, Win32 applications registry calls would be mapped to a different part of the registry. Can someone clarify how these work and how they affect the deployment scenarios? Thanks. Umesh _ The New Busy think 9 to 5 is a cute idea. Combine multiple calendars with Hotmail. http://www.windowslive.com/campaign/thenewbusy?tile=multicalendarocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_5 -- 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] Unable to uninstall
Cleanup utilities are a last resort because they can leave the machine in a corrupted state. You have a better option: Rebuild your msi *exactly* as before but with the custom action corrected or removed, (or it might be easier to edit it with orca to achieve the same result). Reinstall and recache the new MSI with msiexec /fv and then uninstall the now corrected version. Rob discussed the issue in a blog post http://robmensching.com/blog/posts/2009/3/6/More-on-Haacks-Troubleshooti ng-Windows-MSI-Installers -Original Message- From: Ryszard Boryna [mailto:ryszard.bor...@nvable.com] Sent: 23 July 2010 12:36 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Unable to uninstall Had the same problem recently; http://majorgeeks.com/download.php?det=4459 helped. You will need to manually cleanup program files etc., but this should let you run your (fixed :~) ) installer. Ryszard Ryszard Boryna, Solutions Architect Tel: 0141 280 0050 NVable is a limited company registered in Scotland. Registered number: SC287922. Suite 6/5, Skypark SP1, 8 Elliot Pl, Glasgow, G3 8EP -Original Message- From: Stelios Kyprou [mailto:stelios.kyp...@formicary.net] Sent: 23 July 2010 11:43 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Unable to uninstall Hey everyone, I made an installer with 2 custom actions, taking care of rollback as well. The problem is i messed up with one of them during uninstallation, and every time i try to unistall, it fails and the rollback takes place. So i am unable to uninstall (neither from the msi nor the control panel) Any ideas what i can do now? Regards, Stelios -- Stelios Kyprou Systems Engineer Formicary - delivering quality financial technology solutions(TM) www.formicary.net This message is confidential and may be privileged. It is intended solely for the named addressee. If you are not the intended recipient, please inform us. Any unauthorised dissemination, distribution or copying hereof is prohibited. Formicary Limited registered office in England and Wales, address 1 Taillar Road, Hedon, East Yorkshire HU12 8GU, registration number 3894343, VAT number 747644304, does not guarantee that the integrity of this communication has been maintained nor that this communication is free of viruses, interceptions or interference. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users /pre BR style=font-size:4px; a href = http://www.sdl.com;img src=http://www.sdl.com/images/email logo_150dpi-01.png alt=www.sdl.com border=0//a BR font face=arial size=2 a href = http://www.sdl.com; style=color:005740; font-weight: boldwww.sdl.com/a BR BR font face=arial size=1 color=#736F6E bSDL PLC confidential, all rights reserved./b If you are not the intended recipient of this mail SDL requests and requires that you delete it without acting upon or copying any of its contents, and we further request that you advise us.BR SDL PLC is a public limited company registered in England and Wales. Registered number: 02675207.BR Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK. /font -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Problem with updating 1.0.1.1 to 1.0.2.1
You need to add a TargetImage Element for the 1.0.1.1 package to your UpgradeImage Element as you have done for the 1.0.0.1 package Without that the 1.0.2.1 patch knows nothing of the existence of the 1.0.1.1 package. 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: KATO Kanryu [mailto:k.kan...@gmail.com] Sent: 23 July 2010 12:01 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Problem with updating 1.0.1.1 to 1.0.2.1 hi, I have made a product and two patches, msi 1.0.0.1 msp(A) 1.0.1.1 (between 1.0.0.1 and 1.0.1.1) msp(B) 1.0.2.1 (between 1.0.0.1 and 1.0.2.1) I can update to 1.0.2.1 with (B) from 1.0.0.1, but can't update with (A) from 1.0.1.1. What I take attention for wxs? ?define PatchVersion = 1.2 ? 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 Product Id=184848AE-687E-4E63-9FBB-E41616F8608E Name=$(var.AppFullName) Language=1041 Codepage=932 Version=$(var.ProductVersion) Manufacturer=MyCompany UpgradeCode=E66227D3-C778-4817-9AB7-E949A7518674 ... !-- Upgrade Information -- Upgrade Id=$(var.UpgradeCode) UpgradeVersion Minimum=0.0.0 Maximum=$(var.ProductVersion) IncludeMinimum=yes Language=1033 Property=OLDUPGRADE / UpgradeVersion Minimum=$(var.ProductVersion) OnlyDetect=yes Language=1033 Property=DETECTNEW / /Upgrade /Product -- 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] Bootstrapper for .Net 2.0
http://dotnetinstaller.codeplex.com/ 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: Umesh Joglekar [mailto:umesh_jogle...@hotmail.com] Sent: 23 July 2010 12:40 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Bootstrapper for .Net 2.0 Hi, Our application needs to have .NET 2.0 installed on the user's machine. It is used on both 32 bit and 64 bit operating systems. I looked at the example on Sourceforge and modified the project to create the bootstrapper with 32 bit dotnetfx 2.0, and it works fine. How do I add x64 and IA64 redistributables to the project so it can conditionally install these on different operating systems? Or do I need to write an unmanaged Windows bootstrap application to query the OS and decide which one to launch? Also it is not clear to me how I can query the registry. If my Win32 application queries the registry to check to see if the prerequisite is installed on x64 OS would it be seeing the WoW part of the registry? As I understand it, Win32 applications registry calls would be mapped to a different part of the registry. Can someone clarify how these work and how they affect the deployment scenarios? Thanks. Umesh _ The New Busy think 9 to 5 is a cute idea. Combine multiple calendars with Hotmail. http://www.windowslive.com/campaign/thenewbusy?tile=multicalendarocid=P ID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_5 -- 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] InstallExecuteSequence completely ignored
Dear Rob, This was also my first guess. But I deleted and recompiled a few times. I even renamed the file. I do not know which entry in the logfile you mean but the one line containing cache on the top is: MSI (c) (04:E8) [13:50:57:178]: Resetting cached policy values Another two lines attracted my attention: MSI (c) (04:E8) [13:51:04:439]: Original package == D:\devel\Test.msi MSI (c) (04:E8) [13:51:04:439]: Package we're running from == C:\DOKUME~1\root\LOKALE~1\Temp\acccbfa.msi But in fact the acccbfa.msi is created *after* I start the installation and it is identical to the original msi... Regards, Luke Am 23.07.2010 08:37, schrieb Rob Mensching: Hmm, my first guess is that the new MSI isn't actually being used for the install. Is it possible the MSI is already cached and you're re-running using the cached MSI? The verbose log file will show you at the top. On Thu, Jul 22, 2010 at 12:12 PM, Lukas Haaselukasha...@gmx.at wrote: Hi, As proposed in one mail I wrote a DLL for detecting old installations. But WiX seems to completely ignore InstallExecuteSequence! I played around, tried different things but it is just ignored! For testing I just added this to my file: Property Id='NOTEPAD'Notepad.exe/Property CustomAction Id='FooBar' Property='NOTEPAD' ExeCommand='' Return='asyncNoWait' / InstallExecuteSequence Custom Action='FooBar' After='LaunchConditions' / /InstallExecuteSequence Even if I install with msiexec /i test.msi /l*vx logfile.log there is not even the word FooBar included! After LaunchConditions there is ValidateProductID executed: [...] Aktion gestartet um 21:07:26: LaunchConditions. Aktion beendet um 21:07:26: LaunchConditions. Rückgabewert 1. MSI (c) (74:80) [21:07:26:477]: Doing action: ValidateProductID Aktion 21:07:26: ValidateProductID. [...] Is there anything I should additionally do? Regards, Luke -- 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] Unable to uninstall
I would like to also strongly recommend Peter's advice on only using Windows Installer clean up utilities as the very last resort when everything else fails. We've had to rebuild a users Vista SP2 machine recently because he took IT matters into his own inexperienced hands, googled MSICUU.exe broke his installation of our own software so it no longer uninstalls properly (component reference counts are permanently set to 1, re-installing the app sets them to 2, uninstalling won't remove files registry entries as the component reference counts are only decremented to 1 with no way of decrementing them to 0). Also test your packages using Virtualization as Bob A. recommends on his blog you should catch these issues before you ship your package - http://www.joyofsetup.com/2007/09/24/test-your-setups-virtually/ On a VM you don't even need to fix the below issue for that installation, just revert the VM back to before you installed, fix your code, build it try again. 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: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Sent: 23 July 2010 12:47 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Unable to uninstall Cleanup utilities are a last resort because they can leave the machine in a corrupted state. You have a better option: Rebuild your msi *exactly* as before but with the custom action corrected or removed, (or it might be easier to edit it with orca to achieve the same result). Reinstall and recache the new MSI with msiexec /fv and then uninstall the now corrected version. Rob discussed the issue in a blog post http://robmensching.com/blog/posts/2009/3/6/More-on-Haacks-Troubleshooti ng-Windows-MSI-Installers -Original Message- From: Ryszard Boryna [mailto:ryszard.bor...@nvable.com] Sent: 23 July 2010 12:36 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Unable to uninstall Had the same problem recently; http://majorgeeks.com/download.php?det=4459 helped. You will need to manually cleanup program files etc., but this should let you run your (fixed :~) ) installer. Ryszard Ryszard Boryna, Solutions Architect Tel: 0141 280 0050 NVable is a limited company registered in Scotland. Registered number: SC287922. Suite 6/5, Skypark SP1, 8 Elliot Pl, Glasgow, G3 8EP -Original Message- From: Stelios Kyprou [mailto:stelios.kyp...@formicary.net] Sent: 23 July 2010 11:43 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Unable to uninstall Hey everyone, I made an installer with 2 custom actions, taking care of rollback as well. The problem is i messed up with one of them during uninstallation, and every time i try to unistall, it fails and the rollback takes place. So i am unable to uninstall (neither from the msi nor the control panel) Any ideas what i can do now? Regards, Stelios -- Stelios Kyprou Systems Engineer Formicary - delivering quality financial technology solutions(TM) www.formicary.net This message is confidential and may be privileged. It is intended solely for the named addressee. If you are not the intended recipient, please inform us. Any unauthorised dissemination, distribution or copying hereof is prohibited. Formicary Limited registered office in England and Wales, address 1 Taillar Road, Hedon, East Yorkshire HU12 8GU, registration number 3894343, VAT number 747644304, does not guarantee that the integrity of this communication has been maintained nor that this communication is free of viruses, interceptions or interference. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users /pre BR style=font-size:4px; a href = http://www.sdl.com;img src=http://www.sdl.com/images/email
Re: [WiX-users] include 32 bit and 64 bit merge modules
Hi Thanks for the information. I already feared this could be the reason. So what I am trying to do is the following: ?if $(var.Platform)=x64 ? !-- 64 bit -- MergeRef Id=CRT64 / MergeRef Id=ATL64 / ?else ? !-- 32 bit -- MergeRef Id=CRT / MergeRef Id=ATL / ?endif ? This way, i can hopefully reuse the same wix project. Having the wix project included in the visual studio solution, I can strangely not set the plattform (click on WixProject-Settings-Build- dropdown Plattform) to x64. There is only the option x86 in the dropdown. How can I trigger a 64 bit build and would it be possible to change the name of the msi file when building on a 64 bit platform? (Example: Installer.msi for 32 bit, Installer_x64.msi for 64 bit. All this in the same visual studio wix project. I know a may be asking some funny or simple quistions, but i am more or less a wix newbe and am running out of time. Thanks for any help in advance. Dan Von: Pally Sandher [pally.sand...@iesve.com] Gesendet: Freitag, 23. Juli 2010 13:58 An: General discussion for Windows Installer XML toolset. Betreff: Re: [WiX-users] include 32 bit and 64 bit merge modules You need an x86 package and an x64 package which consume the correct merge modules. You can't use x64 merge modules in an x86 package, that's what the error is trying to tell you. 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: daniel.knoep...@noser.com [mailto:daniel.knoep...@noser.com] Sent: 23 July 2010 12:22 To: wix-users@lists.sourceforge.net Subject: [WiX-users] include 32 bit and 64 bit merge modules Hi Our setup includes various merge modules. Initially, they were all these merge modules were fore 32-bit systems. Testing the installed application on 64-bit windows 7 i found out that we would need the 64-bit merge modules. So I added them to the wxs file: !-- 32 bit -- Merge Id=VSWINFORMS SourceFile=ThirdParty\MergeModules\MStudioUIWinforms.2008.msm Language=1033 DiskId=1 / Merge Id=NIANLYS SourceFile=ThirdParty\MergeModules\nianlys.msm Language=1033 DiskId=1 / Merge Id=NIMESADLL SourceFile=ThirdParty\MergeModules\NIMesaDLL.msm Language=1033 DiskId=1 / Merge Id=NIMETAUTILS SourceFile=ThirdParty\MergeModules\niMetaUtils.msm Language=1033 DiskId=1 / !-- 64 bit -- Merge Id=VSWINFORMS64 SourceFile=ThirdParty\MergeModules\MStudioUIWinforms.2008_x64.msm Language=1033 DiskId=1 / Merge Id=NIANLYS64 SourceFile=ThirdParty\MergeModules\nianlys_x64.msm Language=1033 DiskId=1 / Merge Id=NIMESADLL64 SourceFile=ThirdParty\MergeModules\NIMesa_x64.msm Language=1033 DiskId=1 / Merge Id=NIMETAUTILS64 SourceFile=ThirdParty\MergeModules\niMetaUtils_x64.msm Language=1033 DiskId=1 / Unfortunately, upon compile I get the following error message: Encountered an unexpected merge error of type 'msmErrorPlatformMismatch' for which there is currently no error message to display. More information about the merge and the failure can be found in the merge log: 'C:\Dokumente und Einstellungen\Extnoser1\Lokale Einstellungen\Temp\5-i_y-vo\merge.log' light.exe 0 1 Installer How can i make this work? What is the right approach to ensure the application gets correctly installed on 32 and 64 bit machines. 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 -- 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] InstallExecuteSequence completely ignored
Dear Pally, Am 23.07.2010 11:04, schrieb Pally Sandher: MSI (c) (74:80) [21:07:26:477]: Doing action: ValidateProductID Aktion 21:07:26: ValidateProductID. That's the InstallUISequence not the InstallExecuteSequence. Indeed! I changed now to InstallUISequence and now it works! But why? The tutorial clearly states that InstallExecuteSequence is *always* called: InstallExecuteSequence is always consulted by the installer to determine the actions, InstallUISequence is only considered when the installer runs in full or reduced UI mode (yet another functionality to experiment with, try msiexec /qn, /qb and /qr) And second, this is the sample from the tutorial: CustomAction Id=CheckingPID BinaryKey=CheckPID DllEntry=CheckPID / CustomAction Id=RefusePID Error=Invalid key. Installation aborted. / InstallExecuteSequence Custom Action=CheckingPID After=CostFinalize / Custom Action=RefusePID After=CheckingPIDPIDACCEPTED = 0 AND NOT Installed/Custom /InstallExecuteSequence Binary Id=CheckPID SourceFile=CheckPID.dll / It uses InstallExecuteSequence as well! WiX doesn't ignore InstallExecuteSequence as the InstallExecuteSequence is just another database table to WiX. WiX is a way for you to make packages for Windows Installer. If your custom action isn't running, it's highly unlikely the blame can be placed on WiX. Sorry if you got me wrong. Of course, I do NOT want to blame WiX :-) I just did not understand the action is not called (it seemed to me that my sequence was ignored)... Regards, Luke -- 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] RegistryKey doesn't get removed, WiX/MSI bug?
Hi! When I installed the following test MSI, and uninstall it afterwards, the registry key gets removed. HOWEVER, if I install a version 1.0 and a version 1.1 of the MSI (with different Versions and product codes, of course), and I uninstall own of them, the Registry key is still there. Please note that the Key has a $(var.ProductCode) inside, so its different from version to version. I introduced the Property DISABLEMSIUPGRADE to disable the RemoveExistingProducts Action. I need to do this, because I have some custom upgrade logic in my external UI handler. If I don't set DISABLEMSIUPGRADE, the problem doesn't occour. Is there another way to disable the Upgrade using a property? How can I fix this probem? Thanks a lot. WiX file: ?xml version=1.0 encoding=UTF-8? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; ?define ProductVersion=$(var.Version)? ?define ProductCode=$(var.PCode)? Product Id=$(var.ProductCode) Name=UpgradeTest Language=1033 Version=$(var.ProductVersion) Manufacturer=Test UpgradeCode=5cb959d6-9ea9-4581-aa9f-76d44ec9dab7 Package InstallerVersion=301 Compressed=yes / Property Id=DISABLEMSIUPGRADE Secure=yes / Media Id=1 Cabinet=media1.cab EmbedCab=yes / Upgrade Id=5cb959d6-9ea9-4581-aa9f-76d44ec9dab7 UpgradeVersion Minimum=1.0.0 IncludeMaximum=yes Maximum=1.2.1 Property=OLDERVERSIONBEINGUPGRADED / /Upgrade UIRef Id=WixUI_Minimal/ Directory Id=TARGETDIR Name=SourceDir Directory Id=ProgramFilesFolder Directory Id=APPLICATIONFOLDER Name=UpgradeTest $(var.ProductVersion) Component Id=ProductComponent Guid=b136fee3-3bc6-47d4-967a-d0a807eb6735 File Id=TestFile Source=TestFiles\$(var.ProductVersion)\TestFile.txt Shortcut Advertise=yes Id=shortMain Name=TestFile $(var.ProductVersion) Directory=MainAppProgramMenu WorkingDirectory=INSTALLLOCATION / /File RegistryKey Root=HKLM Key=SOFTWARE\Test\UpgradeTest\$(var.ProductCode) Action=createAndRemoveOnUninstall RegistryValue Name=Test Type=string Value=UpgradeTest $(var.ProductVersion) / /RegistryKey RemoveFolder Id=RemoveShortcut Directory=MainAppProgramMenu On=uninstall/ /Component /Directory /Directory Directory Id=ProgramMenuFolder Directory Id=MainAppProgramMenu Name=UpgradeTest /Directory /Directory /Directory Feature Id=ProductFeature Title=UpgradeTest Level=1 ComponentRef Id=ProductComponent / /Feature InstallExecuteSequence !-- RemoveExistingProducts nur ausführen, wenn es nicht von der Kommandozeile (Setup.exe) deaktiviert wurde -- RemoveExistingProducts After=InstallInitializeNOT DISABLEMSIUPGRADE/RemoveExistingProducts /InstallExecuteSequence /Product /Wix -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/RegistryKey-doesn-t-get-removed-WiX-MSI-bug-tp5329658p5329658.html Sent from the wix-users mailing list archive at Nabble.com. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrading from other setup program to WiX/MSI
Having dealt with a similar scenario with InstallShield, the best I can suggest is to bootstrap uninstall. You can use dotNetInstaller (http://dotnetinstaller.codeplex.com) and write a command line that will uninstall the previous application. Write an MSI to uninstall the legacy thing or write a tool to do it. I'd do everything to avoid bloating the new installer with any kind of logic that deals with a legacy installer. For your user/administrator problem - when you run as administrator, you can do everything any user can do. So embed a manifest in the bootstrapper that will make it always run as administrator. If you must have just 1 MSI, you will try to do what we did. In the MSI we would detect that a previous installshield application is installed (registry) and ran uninstall, dropping an .rsp file that drives the installshield uninstall. We made the MSI believe it's doing a major upgrade (some convenience properties here: http://code.dblock.org/ShowPost.aspx?id=42). It was pretty hard overall and took more effort to clean-up once the customers were off those very old versions. dB. @ dblock.org Moscow|Geneva|Seattle|New York -Original Message- From: Lukas Haase [mailto:lukasha...@gmx.at] Sent: Wednesday, July 21, 2010 4:20 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Upgrading from other setup program to WiX/MSI Hi, Today I began creating my first WiX project. Until now I used SetupSpecialist but as I am facing serious problems with it I want to use WiX in future. This is my first big question: On clients' computers there will be an old instance of my program (with SetupSpecialist) installed. Even worse: My new version requires the setup to be run as administrator. However, the old versions might be installed as normal users. What is the best way to handle this situation? Thank you. Regards, Luke -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] [Wix-users] Installing a windows service based on user give account
Use stock UI and samples from http://msiext.codeplex.com. You have a ready-to-go screen that will set all the properties correctly, check that the user has logon as a service privilege, etc. Check some screenshots here: http://msiext.codeplex.com/wikipage?title=Common%20UI%20Wix%20ExtensionreferringTitle=Home. dB. @ dblock.org Moscow|Geneva|Seattle|New York -Original Message- From: Stelios Kyprou [mailto:stelios.kyp...@formicary.net] Sent: Monday, July 19, 2010 12:04 PM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] [Wix-users] Installing a windows service based on user give account Hello! I am currently trying to install a windows service using ServiceInstall. The requirement i have, is that the account the service will run as, is defined by the user, in a dialog. If: 1) the user chooses Local System, the service should run as Local System 2) the user gives an account, the service should run as that account. When defining the service install, i do the following: Component Id='ServiceExeComponent' Guid='06C01846-FA5B-40E7-875E-E8A3A13262DE' SharedDllRefCount='no' KeyPath='no' NeverOverwrite='no' Permanent='no' Transitive='no' Win64='yes' Location='either' Directory=INSTALLLOCATION File Id=Alm_Executable KeyPath=yes Checksum=yes Source=$(var.ALM_GC_FilesDir)\ALM_GC.exe / util:User Id=UpdateUserLogonAsService UpdateIfExists=yes CreateUser=no Name=[WINDOWSDOMAIN]\[WINDOWSUSERNAME] LogonAsService=yes/ ServiceInstall Id='ALM_ServiceInstall' DisplayName='Asset Bot' Description='Asset Bot for GC' Name='ALM' ErrorControl='ignore' Type='ownProcess' Start='auto' Vital='yes' Interactive='no'/ ServiceControl Id='ALM_ServiceControl' Name='ALM' Start='install' Stop='both' Remove='uninstall' Wait='yes'/ /Component In the case where the user chooses LocalSystem, the service that get's installed has This account: set in the Log on tab (as NT AUTHORITY/SYSTEM) instead of the Local System account radio box. I know that i can make that happen if i don't provide Account and Password in the ServiceInstall tag, but then again it depends on what the user chooses to run the service as in a dialog. What are my options here? Regards, Stelios -- Stelios Kyprou Systems Engineer Formicary - delivering quality financial technology solutions(TM) www.formicary.net This message is confidential and may be privileged. It is intended solely for the named addressee. If you are not the intended recipient, please inform us. Any unauthorised dissemination, distribution or copying hereof is prohibited. Formicary Limited registered office in England and Wales, address 1 Taillar Road, Hedon, East Yorkshire HU12 8GU, registration number 3894343, VAT number 747644304, does not guarantee that the integrity of this communication has been maintained nor that this communication is free of viruses, interceptions or interference. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] include 32 bit and 64 bit merge modules
Hi I tried to build wix project for 32 and 64 bit resulting in two separate msi. I tried to use the var.Platform variable but I have not yet managed to set it. How can I do that so depending on the variable different merge modules are included. (The dropdown in the visual studio project only shows x86) Thanks in advance The crucial parts of my wix project look as follows Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; ?if $(var.Platform)=x64 ? ?define msiProductId = F4805BED-69FA-4D6A-9243-C39AEE207764 ? ?define win64Flag = yes ? ?else ? ?define msiProductId = 2500b11a-2907-4721-97d2-1ad7a639a3c3 ? ?define win64Flag = no ? ?endif ? Product Id=$(var.msiProductId) .. Package Keywords=!(loc.PackageKeywords) . Platform=$(var.Platform) / ?if $(var.Platform)=x64 ? !-- 64 bit -- MergeRef Id=CRT64 / MergeRef Id=ATL64 / ?else ? !-- 32 bit -- MergeRef Id=CRT / MergeRef Id=ATL / ?endif ? Von: daniel.knoep...@noser.com [daniel.knoep...@noser.com] Gesendet: Freitag, 23. Juli 2010 14:14 An: wix-users@lists.sourceforge.net Betreff: Re: [WiX-users] include 32 bit and 64 bit merge modules Hi Thanks for the information. I already feared this could be the reason. So what I am trying to do is the following: ?if $(var.Platform)=x64 ? !-- 64 bit -- MergeRef Id=CRT64 / MergeRef Id=ATL64 / ?else ? !-- 32 bit -- MergeRef Id=CRT / MergeRef Id=ATL / ?endif ? This way, i can hopefully reuse the same wix project. Having the wix project included in the visual studio solution, I can strangely not set the plattform (click on WixProject-Settings-Build- dropdown Plattform) to x64. There is only the option x86 in the dropdown. How can I trigger a 64 bit build and would it be possible to change the name of the msi file when building on a 64 bit platform? (Example: Installer.msi for 32 bit, Installer_x64.msi for 64 bit. All this in the same visual studio wix project. I know a may be asking some funny or simple quistions, but i am more or less a wix newbe and am running out of time. Thanks for any help in advance. Dan Von: Pally Sandher [pally.sand...@iesve.com] Gesendet: Freitag, 23. Juli 2010 13:58 An: General discussion for Windows Installer XML toolset. Betreff: Re: [WiX-users] include 32 bit and 64 bit merge modules You need an x86 package and an x64 package which consume the correct merge modules. You can't use x64 merge modules in an x86 package, that's what the error is trying to tell you. 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: daniel.knoep...@noser.com [mailto:daniel.knoep...@noser.com] Sent: 23 July 2010 12:22 To: wix-users@lists.sourceforge.net Subject: [WiX-users] include 32 bit and 64 bit merge modules Hi Our setup includes various merge modules. Initially, they were all these merge modules were fore 32-bit systems. Testing the installed application on 64-bit windows 7 i found out that we would need the 64-bit merge modules. So I added them to the wxs file: !-- 32 bit -- Merge Id=VSWINFORMS SourceFile=ThirdParty\MergeModules\MStudioUIWinforms.2008.msm Language=1033 DiskId=1 / Merge Id=NIANLYS SourceFile=ThirdParty\MergeModules\nianlys.msm Language=1033 DiskId=1 / Merge Id=NIMESADLL SourceFile=ThirdParty\MergeModules\NIMesaDLL.msm Language=1033 DiskId=1 / Merge Id=NIMETAUTILS SourceFile=ThirdParty\MergeModules\niMetaUtils.msm Language=1033 DiskId=1 / !-- 64 bit -- Merge Id=VSWINFORMS64 SourceFile=ThirdParty\MergeModules\MStudioUIWinforms.2008_x64.msm Language=1033 DiskId=1 / Merge Id=NIANLYS64 SourceFile=ThirdParty\MergeModules\nianlys_x64.msm Language=1033 DiskId=1 / Merge Id=NIMESADLL64 SourceFile=ThirdParty\MergeModules\NIMesa_x64.msm Language=1033 DiskId=1 / Merge Id=NIMETAUTILS64 SourceFile=ThirdParty\MergeModules\niMetaUtils_x64.msm Language=1033 DiskId=1 / Unfortunately, upon compile I get the following error message: Encountered an unexpected merge error of type 'msmErrorPlatformMismatch' for which there is currently no error message to display. More information about the merge and the failure can be found in the merge log: 'C:\Dokumente und Einstellungen\Extnoser1\Lokale Einstellungen\Temp\5-i_y-vo\merge.log' light.exe 0 1 Installer How can i make this work? What is the right approach to ensure the application gets correctly installed on 32 and 64 bit machines. Thanks in advance.. Dan
Re: [WiX-users] Patches are getting installed automatically on Microsoft Vista OS
I suspect you may have some advertised entry point firing a repair due to some per-profile keypath not existing in the new user's profile. What does the application event log say (event Ids are 1001 and 1004)? http://msdn.microsoft.com/library/aa371546.aspx -Original Message- From: BSR PHANI [mailto:bsrphani...@gmail.com] Sent: Friday, July 23, 2010 1:04 AM To: General discussion for Windows Installer XML toolset.; wix-users-requ...@lists.sourceforge.net Subject: [WiX-users] Patches are getting installed automatically on Microsoft Vista OS Hi We have a technical isuue on Fix Pack 2.x installation. Scenario: 1. RTM + SP2 patch + FP 2.x patch Installed on windows vista using admin user 2. Create another user and add him to admin group. 3. Login with newly created user, SP2 installation runs automatically When we enable UAC on windows Vista, this doesn't happen. But my Manager doesn't want to enable UAC because of security issues on windows vista. Can you please help me to resolve this issue? i want to know, why patch installation is getting installed automatically? Thanks, Phani -- 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] MsiGetProductInfoFromScript returns 1603
Thanks Rob I tested this quickly with the code snippet below and it works great: Type t = Type.GetTypeFromProgID(WindowsInstaller.Installer); Installer i = (Installer)Activator.CreateInstance(t); Database d = i.OpenDatabase(@C:\Test\Test.msi, MsiOpenDatabaseMode.msiOpenDatabaseModeReadOnly); View v = d.OpenView(SELECT * FROM Property WHERE Property = 'ProductCode'); v.Execute(null); Record r = v.Fetch(); string version = r.get_StringData(2); On Thu, Jul 22, 2010 at 10:40 PM, Rob Mensching r...@robmensching.comwrote: How about: SELECT `Value` FROM `Property` WHERE Property=ProductCode I don't think you want ::MsiGetProductInfoFromScript(). On Thu, Jul 22, 2010 at 4:42 PM, Jacques Eloff repst...@gmail.com wrote: Hi I'm trying to extract the Product code from an MSI using C# (this is for a custom msbuild task I'm writing). I'm using the following definition for P/Invoke [DllImport(msi.dll, CharSet = CharSet.Unicode)] static extern Int32 MsiGetProductInfoFromScript(string scriptFile, StringBuilder product, ref ushort langId, ref uint version, StringBuildername, ref uint nameSize, StringBuilder package, ref uint packageSize); I keep getting a return code of 1603. Everything looks OK, but I'm starting to suspect that the script file I'm passing is causing a problem, ushort langId = 0; uint version = 0; uint packageSize = 10; uint nameSize = 40; StringBuilder product = new StringBuilder(40); StringBuilder package = new StringBuilder(40); StringBuilder name = new StringBuilder(100); int e = MsiGetProductInfoFromScript(@C:\Test\Test.msi, product, reflangId, ref version, name, ref nameSize, package, ref packageSize); Am I even calling the correct method? The only other option I can think of is to open the DB and go through the whole SELECT * FROM Property and then extract the product code from the returned view. Thanks, Jacques -- 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.comhttp://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 -- 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] Questions about showing warning/error message dialog
1. Not really. The only option that comes to mind is to use EmbeddedUI and to refuse to show the Ignore button when asked, but even that can be bypassed. 2. Only by wrapping the executable in your own custom action (usually DLL). -Original Message- From: Elfe Xu [mailto:elf...@microsoft.com] Sent: Friday, July 23, 2010 1:09 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Questions about showing warning/error message dialog Hi, Hope you are not get tired with my name, as I've posted sooo many questions. 1. When write registry value fails, an error message dialog will pop up, and show Retry/Cancel/Ignore. However, in our product, some registry keys are critical, and we don't want allow user to choose Ignore, and rollback if fail. How could I change it to show Retry/Cancel only? 2. For CustomActions that call some executables (type2, type34 etc), we can have the \...@return set to check/ignore etc. If choose check, the failure will cause abort; if choose ignore, the failure will only be logged, but user will not be aware of the failure. How could I make it to show a warning dialog? Surely I can write some wrapper to run the executable, and then use session.Message to show the error. But I wonder if there is an easier way, to assign the CustomAction return value to some property, and then show the warning/error? 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] Unable to uninstall
I think i can use orca to fix my problem...i actually have a custom action that tries to get a file from the installlocation, and get some data from there(while uninstalling) but i accidentally added that action after the deletefiles action. So i can change that with orca. The problem now is: I don't have the msi anymore. I have the GUID. How can i get the msi? as in where does control panel grab it from when uninstalling a program? I am using windows vista Pally Sandher wrote: I would like to also strongly recommend Peter's advice on only using Windows Installer clean up utilities as the very last resort when everything else fails. We've had to rebuild a users Vista SP2 machine recently because he took IT matters into his own inexperienced hands, googled MSICUU.exe broke his installation of our own software so it no longer uninstalls properly (component reference counts are permanently set to 1, re-installing the app sets them to 2, uninstalling won't remove files registry entries as the component reference counts are only decremented to 1 with no way of decrementing them to 0). Also test your packages using Virtualization as Bob A. recommends on his blog you should catch these issues before you ship your package - http://www.joyofsetup.com/2007/09/24/test-your-setups-virtually/ On a VM you don't even need to fix the below issue for that installation, just revert the VM back to before you installed, fix your code, build it try again. 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: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Sent: 23 July 2010 12:47 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Unable to uninstall Cleanup utilities are a last resort because they can leave the machine in a corrupted state. You have a better option: Rebuild your msi *exactly* as before but with the custom action corrected or removed, (or it might be easier to edit it with orca to achieve the same result). Reinstall and recache the new MSI with msiexec /fv and then uninstall the now corrected version. Rob discussed the issue in a blog post http://robmensching.com/blog/posts/2009/3/6/More-on-Haacks-Troubleshooti ng-Windows-MSI-Installers -Original Message- From: Ryszard Boryna [mailto:ryszard.bor...@nvable.com] Sent: 23 July 2010 12:36 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Unable to uninstall Had the same problem recently; http://majorgeeks.com/download.php?det=4459 helped. You will need to manually cleanup program files etc., but this should let you run your (fixed :~) ) installer. Ryszard Ryszard Boryna, Solutions Architect Tel: 0141 280 0050 NVable is a limited company registered in Scotland. Registered number: SC287922. Suite 6/5, Skypark SP1, 8 Elliot Pl, Glasgow, G3 8EP -Original Message- From: Stelios Kyprou [mailto:stelios.kyp...@formicary.net] Sent: 23 July 2010 11:43 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Unable to uninstall Hey everyone, I made an installer with 2 custom actions, taking care of rollback as well. The problem is i messed up with one of them during uninstallation, and every time i try to unistall, it fails and the rollback takes place. So i am unable to uninstall (neither from the msi nor the control panel) Any ideas what i can do now? Regards, 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
Re: [WiX-users] SETUPBLD and BURN, multiple uninstalls
- Burn supports that. - Not that I know of. - Chained MSI detection is built into Burn. Your UI code you add to Burn allows you to react to command-line options and package detection performed by burn and allows you to order (if you wish) or decide to include/exclude/even remove packages as part of your installation. -Original Message- From: Simon Topley [mailto:simon.top...@mwhsoft.com] Sent: Friday, July 23, 2010 3:21 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] SETUPBLD and BURN, multiple uninstalls ... I guess this will be more of a request for burn... will(does) it: - have only one item in the uninstall list that represents many msi's chained. - allow a post install script to be run so I wouldn't need this second lightweight installer at all - check for the presence of any of the chained msis before attempting to install, and react according to some command line option? ... -- 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] Unable to uninstall
If you know what the error is and how to correct it, you can perform a small update to replace your package and then uninstall. -Original Message- From: Stelios Kyprou [mailto:stelios.kyp...@formicary.net] Sent: Friday, July 23, 2010 3:43 AM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Unable to uninstall Hey everyone, I made an installer with 2 custom actions, taking care of rollback as well. The problem is i messed up with one of them during uninstallation, and every time i try to unistall, it fails and the rollback takes place. So i am unable to uninstall (neither from the msi nor the control panel) Any ideas what i can do now? Regards, Stelios -- Stelios Kyprou Systems Engineer Formicary - delivering quality financial technology solutions(TM) www.formicary.net This message is confidential and may be privileged. It is intended solely for the named addressee. If you are not the intended recipient, please inform us. Any unauthorised dissemination, distribution or copying hereof is prohibited. Formicary Limited registered office in England and Wales, address 1 Taillar Road, Hedon, East Yorkshire HU12 8GU, registration number 3894343, VAT number 747644304, does not guarantee that the integrity of this communication has been maintained nor that this communication is free of viruses, interceptions or interference. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Retry at RMFilesInUse an invalid return value ?
Look up Quiet Execution Custom Action (qtexec) in the wix help. -Original Message- From: Swapnil Sankla [mailto:swapnil_san...@persistent.co.in] Sent: Friday, July 23, 2010 4:04 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Retry at RMFilesInUse an invalid return value ? I want to use ExeCommand to start window service. But it shows the command prompt. Is there any way to hide the command prompt ??? Thanks and regards, Swapnil DISCLAIMER == This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. -- 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] Property in localized string?
If your string is named MyLocString in your WXL file, use !(loc.MyLocString) in your authoring. -Original Message- From: A.Rios [mailto:cosasvar...@gmail.com] Sent: Friday, July 23, 2010 4:29 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Property in localized string? Hi. We are in the process of updating our previous installation framework to Wix and have encountered a minor problem. As a part of our deployment process we use a custom MsBuild script and a string to identify the program being installed (something like 1.2 Build.3 Rev 4) and I want to use it in the localized strings in UI. I already have a Property defined with that string in the .wixproj file but I don't know how to use in the localization file (I think I've tried with every combination of square brackets, exclamation mark, var. env. and wix. prefixes ;-) Where I can find more information? Thanks in advance. -- 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] RegistryKey doesn't get removed, WiX/MSI bug?
That RegistryKey must be the KeyPath of the component that contains it. Your component morphs between different products and thus violates component rules. I recommend moving that registry key into its own component and setting the registry key's guid to *. -Original Message- From: SimonKnight6600 [mailto:simonschwei...@gmail.com] Sent: Friday, July 23, 2010 6:59 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] RegistryKey doesn't get removed, WiX/MSI bug? Hi! When I installed the following test MSI, and uninstall it afterwards, the registry key gets removed. HOWEVER, if I install a version 1.0 and a version 1.1 of the MSI (with different Versions and product codes, of course), and I uninstall own of them, the Registry key is still there. Please note that the Key has a $(var.ProductCode) inside, so its different from version to version. I introduced the Property DISABLEMSIUPGRADE to disable the RemoveExistingProducts Action. I need to do this, because I have some custom upgrade logic in my external UI handler. If I don't set DISABLEMSIUPGRADE, the problem doesn't occour. Is there another way to disable the Upgrade using a property? How can I fix this probem? Thanks a lot. WiX file: ?xml version=1.0 encoding=UTF-8? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; ?define ProductVersion=$(var.Version)? ?define ProductCode=$(var.PCode)? Product Id=$(var.ProductCode) Name=UpgradeTest Language=1033 Version=$(var.ProductVersion) Manufacturer=Test UpgradeCode=5cb959d6-9ea9-4581-aa9f-76d44ec9dab7 Package InstallerVersion=301 Compressed=yes / Property Id=DISABLEMSIUPGRADE Secure=yes / Media Id=1 Cabinet=media1.cab EmbedCab=yes / Upgrade Id=5cb959d6-9ea9-4581-aa9f-76d44ec9dab7 UpgradeVersion Minimum=1.0.0 IncludeMaximum=yes Maximum=1.2.1 Property=OLDERVERSIONBEINGUPGRADED / /Upgrade UIRef Id=WixUI_Minimal/ Directory Id=TARGETDIR Name=SourceDir Directory Id=ProgramFilesFolder Directory Id=APPLICATIONFOLDER Name=UpgradeTest $(var.ProductVersion) Component Id=ProductComponent Guid=b136fee3-3bc6-47d4-967a-d0a807eb6735 File Id=TestFile Source=TestFiles\$(var.ProductVersion)\TestFile.txt Shortcut Advertise=yes Id=shortMain Name=TestFile $(var.ProductVersion) Directory=MainAppProgramMenu WorkingDirectory=INSTALLLOCATION / /File RegistryKey Root=HKLM Key=SOFTWARE\Test\UpgradeTest\$(var.ProductCode) Action=createAndRemoveOnUninstall RegistryValue Name=Test Type=string Value=UpgradeTest $(var.ProductVersion) / /RegistryKey RemoveFolder Id=RemoveShortcut Directory=MainAppProgramMenu On=uninstall/ /Component /Directory /Directory Directory Id=ProgramMenuFolder Directory Id=MainAppProgramMenu Name=UpgradeTest /Directory /Directory /Directory Feature Id=ProductFeature Title=UpgradeTest Level=1 ComponentRef Id=ProductComponent / /Feature InstallExecuteSequence !-- RemoveExistingProducts nur ausführen, wenn es nicht von der Kommandozeile (Setup.exe) deaktiviert wurde -- RemoveExistingProducts After=InstallInitializeNOT DISABLEMSIUPGRADE/RemoveExistingProducts /InstallExecuteSequence /Product /Wix -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/RegistryKey-doesn-t-get-removed-WiX-MSI-bug-tp5329658p5329658.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 -- 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] Unable to uninstall
In your verbose unisntall log (you are generating an uninstall log when you run) you can gather the name/path of the cached/stripped MSI that Installer is using, along with the original name you will need your MSI to be named in order to use your updated one to recache the package. Be sure to change the package code in orca when you change your sequence (if you don't change the package code, Windows Installer may think there are no changes and ignore the request to recache). -Original Message- From: Stelios Kyprou [mailto:stelios.kyp...@formicary.net] Sent: Friday, July 23, 2010 8:40 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Unable to uninstall I think i can use orca to fix my problem...i actually have a custom action that tries to get a file from the installlocation, and get some data from there(while uninstalling) but i accidentally added that action after the deletefiles action. So i can change that with orca. The problem now is: I don't have the msi anymore. I have the GUID. How can i get the msi? as in where does control panel grab it from when uninstalling a program? I am using windows vista Pally Sandher wrote: I would like to also strongly recommend Peter's advice on only using Windows Installer clean up utilities as the very last resort when everything else fails. We've had to rebuild a users Vista SP2 machine recently because he took IT matters into his own inexperienced hands, googled MSICUU.exe broke his installation of our own software so it no longer uninstalls properly (component reference counts are permanently set to 1, re-installing the app sets them to 2, uninstalling won't remove files registry entries as the component reference counts are only decremented to 1 with no way of decrementing them to 0). Also test your packages using Virtualization as Bob A. recommends on his blog you should catch these issues before you ship your package - http://www.joyofsetup.com/2007/09/24/test-your-setups-virtually/ On a VM you don't even need to fix the below issue for that installation, just revert the VM back to before you installed, fix your code, build it try again. 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: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Sent: 23 July 2010 12:47 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Unable to uninstall Cleanup utilities are a last resort because they can leave the machine in a corrupted state. You have a better option: Rebuild your msi *exactly* as before but with the custom action corrected or removed, (or it might be easier to edit it with orca to achieve the same result). Reinstall and recache the new MSI with msiexec /fv and then uninstall the now corrected version. Rob discussed the issue in a blog post http://robmensching.com/blog/posts/2009/3/6/More-on-Haacks-Troubleshooti ng-Windows-MSI-Installers -Original Message- From: Ryszard Boryna [mailto:ryszard.bor...@nvable.com] Sent: 23 July 2010 12:36 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Unable to uninstall Had the same problem recently; http://majorgeeks.com/download.php?det=4459 helped. You will need to manually cleanup program files etc., but this should let you run your (fixed :~) ) installer. Ryszard Ryszard Boryna, Solutions Architect Tel: 0141 280 0050 NVable is a limited company registered in Scotland. Registered number: SC287922. Suite 6/5, Skypark SP1, 8 Elliot Pl, Glasgow, G3 8EP -Original Message- From: Stelios Kyprou [mailto:stelios.kyp...@formicary.net] Sent: 23 July 2010 11:43 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Unable to uninstall Hey everyone, I made an installer with 2 custom actions, taking care of rollback as well. The problem is i messed up with one of them during uninstallation, and every time i try to unistall, it fails and the rollback takes place. So i am unable to uninstall (neither from the msi nor the control panel) Any ideas what i can do now? Regards, 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
Re: [WiX-users] Property in localized string?
I want to do exactly the opposite (assuming it can be done, of course): I have a property defined MyPropertyApplication version 2/MyProperty and I want to use it in the WXL,something like String Id=blablaWelcome to [MyProperty] installation wizard/string like you use [ProductName] or [ProductVersion], but I cannot figure the correct syntax. Am I missing something obvious? El 23/07/10 17:49, Blair escribió: If your string is named MyLocString in your WXL file, use !(loc.MyLocString) in your authoring. -Original Message- From: A.Rios [mailto:cosasvar...@gmail.com] Sent: Friday, July 23, 2010 4:29 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Property in localized string? Hi. We are in the process of updating our previous installation framework to Wix and have encountered a minor problem. As a part of our deployment process we use a custom MsBuild script and a string to identify the program being installed (something like 1.2 Build.3 Rev 4) and I want to use it in the localized strings in UI. I already have a Property defined with that string in the .wixproj file but I don't know how to use in the localization file (I think I've tried with every combination of square brackets, exclamation mark, var. env. and wix. prefixes ;-) Where I can find more information? Thanks in advance. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Drivers' installation design
wcautil.lib has a solution for that, see the externed functions from wcascript.cpp. We use it for Users, I think. On Fri, Jul 23, 2010 at 1:00 AM, vazhenin_mak...@emc.com wrote: The problem with is rollback. If we have one deferred custom action for all drivers, then we need to know what action failed, so we have to write somewhere what actions we have done and what to do to rollback each of them. -Original Message- From: Blair [mailto:os...@live.com] Sent: Friday, July 23, 2010 11:18 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Drivers' installation design Also I see no reason that one deferred action can't be fed data it loops on such that it does InstallDriver for driver A, then ReinstallDriver for driver B, then InstallDriver for driver C then RemoveDriver for driver D followed by ReinstallDriver for driver C or whatever else you need in whatever order it should end up in. Like Rob said, calling a deferred action one time with a bunch of data is faster than calling several actions, each with just parts of that data. -Original Message- From: vazhenin_mak...@emc.com [mailto:vazhenin_mak...@emc.com] Sent: Thursday, July 22, 2010 11:57 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Drivers' installation design Rob, Blair thank you very much for your explanation! I haven't known that the immediate custom action can schedule the same deferred custom action multiple times. I will try it now. If I'll have some problems with it I will ask for help. Regards, Maks -Original Message- From: Blair [mailto:os...@live.com] Sent: Friday, July 23, 2010 10:38 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Drivers' installation design You are in control of that. If there are sequencing requirements between different drivers, etc. you can represent that in your schema and in your table(s), and make your immediate action (or several immediate actions, if that helps with setting sequencing, each can act on only the part of the data they are interested in) process all that data such that the deferred actions are performed in the correct order. You, as the writer of the actions, are in complete control. All Windows Installer and WiX offer is a framework within which to build correct, effective, and scalable deployment solutions. If you wish, there are several of us on this list that could help you plan or even implement this. Just ask for those interested to respond privately with their requirements for quotes. -Original Message- From: vazhenin_mak...@emc.com [mailto:vazhenin_mak...@emc.com] Sent: Thursday, July 22, 2010 11:21 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Drivers' installation design As I understand in this approach there will be one immediate ca (that will marshal the data to the deferred) and only one deferred custom action that will configure all drivers. If there will be a custom actions for each action to driver, I will have to describe them all in my wixlib. The problem is that I can't schedule only a few deferred custom actions (like InstallDrivers, RemoveDevice, ReinstallDevice) for all drivers because the sequence of drivers' installation also is important (so first I have to run for example InstallDriver, ReinstallDevice for one driver and only after that InstallDriver, ReinstallDevice for another). Also for some drivers actions take different parameters on different conditions (for example on upgrade from one of old versions and on clear installations or upgrade from other versions). Maybe I misunderstand something and it could be done with WixExtension... But I don't see how. -Original Message- From: Blair [mailto:os...@live.com] Sent: Thursday, July 22, 2010 9:15 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Drivers' installation design The WixExtension can supply a compiler extension to implement your schema for your pattern (allows you to easily describe what is being installed) and should populate your custom table that your custom actions use to control their work. It should also create a reference to the fragment in your wixlib where each custom action set is declared and scheduled, so you don't have to expose that to your authors. Your table should include a foreign key to the Components table so that you can use the installation request states of those components to facilitate your install/remove/upgrade/repair determinations. Each custom action should then read the table(s) and marshal the data to the deferred, rollback, and commit (if needed) actions. Organized that way, it should be easy to use, easy to test, and easy to maintain. -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Thursday, July 22, 2010 7:18 AM To: General discussion for
Re: [WiX-users] Unable to uninstall
Hmm, I would never recommend using that tool: http://robmensching.com/blog/posts/2009/3/6/More-on-Haacks-Troubleshooting-Windows-MSI-Installers http://robmensching.com/blog/posts/2009/3/6/More-on-Haacks-Troubleshooting-Windows-MSI-InstallersUse recache/reinstall (msiexec /fv) with a fixed MSI instead. On Fri, Jul 23, 2010 at 4:35 AM, Ryszard Boryna ryszard.bor...@nvable.comwrote: Had the same problem recently; http://majorgeeks.com/download.php?det=4459helped. You will need to manually cleanup program files etc., but this should let you run your (fixed :~) ) installer. Ryszard Ryszard Boryna, Solutions Architect Tel: 0141 280 0050 NVable is a limited company registered in Scotland. Registered number: SC287922. Suite 6/5, Skypark SP1, 8 Elliot Pl, Glasgow, G3 8EP -Original Message- From: Stelios Kyprou [mailto:stelios.kyp...@formicary.net] Sent: 23 July 2010 11:43 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Unable to uninstall Hey everyone, I made an installer with 2 custom actions, taking care of rollback as well. The problem is i messed up with one of them during uninstallation, and every time i try to unistall, it fails and the rollback takes place. So i am unable to uninstall (neither from the msi nor the control panel) Any ideas what i can do now? Regards, Stelios -- Stelios Kyprou Systems Engineer Formicary - delivering quality financial technology solutions(TM) www.formicary.net This message is confidential and may be privileged. It is intended solely for the named addressee. If you are not the intended recipient, please inform us. Any unauthorised dissemination, distribution or copying hereof is prohibited. Formicary Limited registered office in England and Wales, address 1 Taillar Road, Hedon, East Yorkshire HU12 8GU, registration number 3894343, VAT number 747644304, does not guarantee that the integrity of this communication has been maintained nor that this communication is free of viruses, interceptions or interference. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- 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] Unable to uninstall
I ended up fixing the msi... up to now i never got to use orca, but now i see the full potential of it and i understand why everyone suggests using this tool when writing installers... Good stuff! Rob Mensching wrote: Hmm, I would never recommend using that tool: http://robmensching.com/blog/posts/2009/3/6/More-on-Haacks-Troubleshooting-Windows-MSI-Installers http://robmensching.com/blog/posts/2009/3/6/More-on-Haacks-Troubleshooting-Windows-MSI-InstallersUse recache/reinstall (msiexec /fv) with a fixed MSI instead. On Fri, Jul 23, 2010 at 4:35 AM, Ryszard Boryna ryszard.bor...@nvable.comwrote: Had the same problem recently; http://majorgeeks.com/download.php?det=4459helped. You will need to manually cleanup program files etc., but this should let you run your (fixed :~) ) installer. Ryszard Ryszard Boryna, Solutions Architect Tel: 0141 280 0050 NVable is a limited company registered in Scotland. Registered number: SC287922. Suite 6/5, Skypark SP1, 8 Elliot Pl, Glasgow, G3 8EP -Original Message- From: Stelios Kyprou [mailto:stelios.kyp...@formicary.net] Sent: 23 July 2010 11:43 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Unable to uninstall Hey everyone, I made an installer with 2 custom actions, taking care of rollback as well. The problem is i messed up with one of them during uninstallation, and every time i try to unistall, it fails and the rollback takes place. So i am unable to uninstall (neither from the msi nor the control panel) Any ideas what i can do now? Regards, Stelios -- Stelios Kyprou Systems Engineer Formicary - delivering quality financial technology solutions(TM) www.formicary.net This message is confidential and may be privileged. It is intended solely for the named addressee. If you are not the intended recipient, please inform us. Any unauthorised dissemination, distribution or copying hereof is prohibited. Formicary Limited registered office in England and Wales, address 1 Taillar Road, Hedon, East Yorkshire HU12 8GU, registration number 3894343, VAT number 747644304, does not guarantee that the integrity of this communication has been maintained nor that this communication is free of viruses, interceptions or interference. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- 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
Re: [WiX-users] Visual Studio Bootstrapper- define order of prerequisites to be installed
Have you installed the windows sdk? One thing we did was take all of the files for the prereq's and check them into source control... it made it a lot more reliable to reference that,rather than the SDK (which, gets installed inconsistently in my opinion because I had to install 6.0a, 7.0 and 7.1 to get all the prereqs we needed until I moved them into version control. -Original Message- From: daniel.knoep...@noser.com [mailto:daniel.knoep...@noser.com] Sent: Friday, July 23, 2010 3:34 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Visual Studio Bootstrapper- define order of prerequisites to be installed Hi Our wix installer makes use of the visual studio 2008 bootstrapper functionality to install Windows Installer 3.1, .NET 3.5 SP1 and Crystal reports. This used to work but suddenly there is an error when i start the setup on a clean machine. After aggreeing to the licence files of crystel reports and of the .NET framework (windows installer is already on the machine) it starts installing crystal reports but it fails. In my opinion, the reason for this is the fact that crystal reports gets installed bevore the .NET framework, which is not the case. How can i ensure the order in which the prerequisites are installed? I tried to change the crystal reports package so it depends on the .NET framework but with no success. Parts of prerequisite package.file (product.xml) from crystal reports: DependsOnProduct Code=Microsoft.Net.Framework.3.5.SP1 / !-- it actually depends on .Net 2.0 but this way we ensure .net framework is installed first DependsOnProduct Code=Microsoft.Net.Framework.2.0 / -- /RelatedProducts Here is our visual studio project file: ItemGroup BootstrapperFile Include=Microsoft.Windows.Installer.3.1 ProductNameWindows Installer 3.1/ProductName /BootstrapperFile BootstrapperFile Include=Microsoft.Net.Framework.3.5.SP1 ProductName.NET Framework 3.5 SP1/ProductName /BootstrapperFile BootstrapperFile Include=BusinessObjects.CrystalReports.10.5 ProductNameCrystal Reports/ProductName /BootstrapperFile /ItemGroup Target Name=AfterBuild GenerateBootstrapper ApplicationFile=Msi\InstallerCaller.msi ApplicationName=Calibrate BootstrapperItems=@(BootstrapperFile) ComponentsLocation=Relative CopyComponents=True OutputPath=bin\$(Configuration)\ Path=$(ProjectDir)\Prerequisites Culture=de-de FallbackCulture=en-us /GenerateBootstrapper !-- -- 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] Property in localized string?
If you don't mind polluting your Property table, you could create MSI properties importing your relevant MSBuild properties: In your WIXPROJ file (under an appropriate element): DefineConstantsMyProperty=$(MyProperty);$(DefineConstants)/DefineConstant s In your WXS (in an appropriate location): Property Id=MyProperty Value=$(var.MyProperty)/ Your !(loc.blabla) needs to be in a Formatted field, of course, since the [MyProperty] substitution will then occur during runtime, but most fields that are shown to the user are (like dialog titles, dialog static text, etc.). -Original Message- From: A.Rios [mailto:cosasvar...@gmail.com] Sent: Friday, July 23, 2010 9:34 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Property in localized string? I want to do exactly the opposite (assuming it can be done, of course): I have a property defined MyPropertyApplication version 2/MyProperty and I want to use it in the WXL,something like String Id=blablaWelcome to [MyProperty] installation wizard/string like you use [ProductName] or [ProductVersion], but I cannot figure the correct syntax. Am I missing something obvious? El 23/07/10 17:49, Blair escribió: If your string is named MyLocString in your WXL file, use !(loc.MyLocString) in your authoring. -Original Message- From: A.Rios [mailto:cosasvar...@gmail.com] Sent: Friday, July 23, 2010 4:29 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Property in localized string? Hi. We are in the process of updating our previous installation framework to Wix and have encountered a minor problem. As a part of our deployment process we use a custom MsBuild script and a string to identify the program being installed (something like 1.2 Build.3 Rev 4) and I want to use it in the localized strings in UI. I already have a Property defined with that string in the .wixproj file but I don't know how to use in the localization file (I think I've tried with every combination of square brackets, exclamation mark, var. env. and wix. prefixes ;-) Where I can find more information? Thanks in advance. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] After upgrading to latest build of Wix3.5/VS2010, web site install now fails on IIS7
Hi All, We have an installer that was working fine under VS2008 - we just recently upgraded the installer solution to VS2010 and updated to the latest weekly build of Wix v3.5 (3.5.1923.0), and it no longer works when installing to IIS7 - does anyone have any pointers. Here's the log from the installer, where I believe the issue is occurring: MSI (s) (8C:94) [11:09:02:788]: Invoking remote custom action. DLL: C:\Windows\Installer\MSIBA76.tmp, Entrypoint: ExecSecureObjects MSI (s) (8C:2C) [11:09:02:876]: Executing op: ActionStart(Name=StartIIS7ConfigTransaction,Description=Starting IIS Config Transaction,) Action 11:09:02: StartIIS7ConfigTransaction. Starting IIS Config Transaction MSI (s) (8C:2C) [11:09:02:877]: Executing op: CustomActionSchedule(Action=StartIIS7ConfigTransaction,ActionType=11265,Source=BinaryData,Target=**,CustomActionData=**) MSI (s) (8C:70) [11:09:02:884]: Invoking remote custom action. DLL: C:\Windows\Installer\MSIBAC5.tmp, Entrypoint: StartIIS7ConfigTransaction MSI (s) (8C:2C) [11:09:02:917]: Executing op: ActionStart(Name=RollbackIIS7ConfigTransaction,Description=Rolling back IIS Config Transaction,) Action 11:09:02: RollbackIIS7ConfigTransaction. Rolling back IIS Config Transaction MSI (s) (8C:2C) [11:09:02:918]: Executing op: CustomActionSchedule(Action=RollbackIIS7ConfigTransaction,ActionType=11521,Source=BinaryData,Target=**,CustomActionData=**) MSI (s) (8C:2C) [11:09:02:919]: Executing op: ActionStart(Name=CommitIIS7ConfigTransaction,Description=Committing IIS Config Transaction,) Action 11:09:02: CommitIIS7ConfigTransaction. Committing IIS Config Transaction MSI (s) (8C:2C) [11:09:02:920]: Executing op: CustomActionSchedule(Action=CommitIIS7ConfigTransaction,ActionType=11777,Source=BinaryData,Target=**,CustomActionData=**) MSI (s) (8C:2C) [11:09:02:921]: Executing op: ActionStart(Name=WriteIIS7ConfigChanges,Description=Installing Config Keys and Values,) Action 11:09:02: WriteIIS7ConfigChanges. Installing Config Keys and Values MSI (s) (8C:2C) [11:09:02:923]: Executing op: CustomActionSchedule(Action=WriteIIS7ConfigChanges,ActionType=11265,Source=BinaryData,Target=**,CustomActionData=**) MSI (s) (8C:04) [11:09:02:924]: Invoking remote custom action. DLL: C:\Windows\Installer\MSIBAF4.tmp, Entrypoint: WriteIIS7ConfigChanges *WriteIIS7ConfigChanges: Error 0x80070002: Site not found for create application* WriteIIS7ConfigChanges: Error 0x80070002: Failed to configure IIS application. WriteIIS7ConfigChanges: Error 0x80070002: WriteIIS7ConfigChanges Failed. Here is the relevant config for the website itself: ?xml version=1.0 encoding=UTF-8? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; xmlns:util= http://schemas.microsoft.com/wix/UtilExtension; Fragment ComponentGroup Id=WebSiteComponents Component Id=WebSiteComponent Guid=F2F93934-ECA0-45f0-A540-433510E56270 Directory=WebSiteFolder RemoveFolder Id=WebSiteDir Directory=WebSiteFolder On=uninstall / /Component Component Id=WebVirtualDirComponent Guid=1033A594-153E-4bfd-8E85-4169D9487B59 Directory=ApplicationFolder ConditionNOT VersionNT64/Condition CreateFolder/ WebVirtualDir Id=MyAppVirtualDirectory Alias=MyApp Directory=WebSiteFolder WebSite=DefaultWebSite xmlns= http://schemas.microsoft.com/wix/IIsExtension; DirProperties=WebSiteProperties WebApplication Id=MyAppWebApplication Name=MyApp WebApplicationExtension CheckPath=no Script=yes Extension=rails Executable=[NETFRAMEWORKROOT]v2.0.50727\aspnet_isapi.dll Verbs=GET,HEAD,POST,DEBUG,PUT,DELETE / WebApplicationExtension CheckPath=yes Script=yes Extension=aspx Executable=[NETFRAMEWORKROOT]v2.0.50727\aspnet_isapi.dll Verbs=GET,HEAD,POST,DEBUG / WebApplicationExtension CheckPath=no Script=yes Executable=[NETFRAMEWORKROOT]v2.0.50727\aspnet_isapi.dll Verbs=GET,HEAD,POST,DEBUG,PUT,DELETE / /WebApplication /WebVirtualDir /Component Component Id=WebVirtualDirComponent64 Guid=1033A594-153E-4bfd-8E85-4169D9487B64 Directory=ApplicationFolder ConditionVersionNT64/Condition CreateFolder/ WebVirtualDir Id=MyAppVirtualDirectory64 Alias=MyApp Directory=WebSiteFolder WebSite=DefaultWebSite xmlns= http://schemas.microsoft.com/wix/IIsExtension; DirProperties=WebSiteProperties WebApplication Id=MyAppWebApplication64 Name=MyApp WebApplicationExtension CheckPath=no Script=yes Extension=rails Executable=[NETFRAMEWORKROOT64]v2.0.50727\aspnet_isapi.dll Verbs=GET,HEAD,POST,DEBUG,PUT,DELETE / WebApplicationExtension CheckPath=yes Script=yes Extension=aspx Executable=[NETFRAMEWORKROOT64]v2.0.50727\aspnet_isapi.dll Verbs=GET,HEAD,POST,DEBUG / WebApplicationExtension CheckPath=no Script=yes Executable=[NETFRAMEWORKROOT64]v2.0.50727\aspnet_isapi.dll Verbs=GET,HEAD,POST,DEBUG,PUT,DELETE /
