Re: [WiX-users] unable to start a service through MSI
On 02/02/2012 01:15, Rajesh Khetan wrote: Thanks Phil. Is there a way to ensure in WXS file, such that the service gets started after all the dependent dlls are installed? You could add a commit custom action to start the service. This will run once the install has been finalised, so the everything should be good to go at this point. Rob -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Visual C++ 2010 Merge Module
Hi Blair, Thank you very much for this new insight. The use of WixLib sounds good; the actual wxs files of product A are already in a WixLib, so that they can be shared between the installer and MSM. The only thing is that the repository of product B then has to have access to the repository of product A, which we don't want. I really like the idea of using the Common Files directory though. We will give this a try in our next sprint. So again, thanks for your time! Regards, Jari -Original Message- From: Blair [mailto:os...@live.com] Sent: Wednesday, February 01, 2012 6:11 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Visual C++ 2010 Merge Module That is what the Common Program Files directory was created for smile/. You use it similarly to the non-Common directory, except that components shared between simultaneously installed products live there. Then there is never any need to keep track of or even care about a COM object's installation directory. Do you build both Product A and Product B with the same (or at least similar) builds of WiX? If so, your problem as you have designed it would probably be easier to solve using WIXLIBs instead of MSMs. Create a WixLib project (instead of a module) of Product A. Even better than the registry search would be a component search to get the component's installation directory, but a registry search can be used as well (as long as you write the registry key). Place that search in the WixLib. Create two WiX-MSI projects, one for A and the other for B. Both consume (and depend on) the WixLib for A. The linker (which is not heavily involved in the the incorporation of MSM content) will be able to arbitrate the various actions needed between the different parts the installation much more easily than the binder can, and you will also avoid the issues you are seeing with trying to force the AppSearch from an MSM. Blair This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How does Torch decide which files changed?!
Hi, Good to know about Dark.exe, didn't notice it till now :) I'm having problems after converting my Original MSI to WXS file, I try to Candle it so I can then light it to get the wixpdb, but I get this error: \\sqlsrv\tsinstallers\TestShell Suite\4.6.255 SP1\Data\Driver Builder\TestShell DriverBuilder Setup.wxs(2939) : error CNDL0072 : A InstallExecute element must have a Before attribute, After attribute, or a Sequence attribute. If I look at my original setup.wxs file the InstallExecute tag looks like this: InstallExecuteSequence InstallExecute After=RemoveExistingProducts/ /InstallExecuteSequence It does have an After attribute... what am I doing wrong... maybe it's the UNC path? Naa. -Original Message- From: Blair [mailto:os...@live.com] Sent: Wednesday, February 01, 2012 6:55 PM To: 'General discussion for Windows Installer XML toolset.' Cc: Alex Abugov; Ronen Akri Subject: Re: [WiX-users] How does Torch decide which files changed?! If the only changes in your bug fix are files in the file table, that should work. To rebuild your code you may consider using dark on your released MSI to get your base WIXPDB and to get your starting point for your bug fix. The REINSTALL property will be autoselected to be the smallest section of already installed features that cover all of the database changes contained in the patch if you don't override it (as you are proposing). Normally the default value should suffice, unless you have a complex feature/component tree or if you have files that don't lend themselves well to the file versioning rules. Your overridden value for REINSTALLMODE property will prevent application of registry and shortcuts from the patched view. If you don't have a requirement for the a flag, the default should suffice. Blair -Original Message- From: tome...@qualisystems.com [mailto:tome...@qualisystems.com] Sent: Wednesday, February 01, 2012 12:26 AM To: wix-users@lists.sourceforge.net Cc: alex...@qualisystems.com; rone...@qualisystems.com Subject: Re: [WiX-users] How does Torch decide which files changed?! Hi, After all your help :) I think I have a solution to my problem, please let me know what you think: My product is already installed on customers machines, I didn't save the wixpdb nor the files.wxs (the Heat harvest file) of those releases, since I didn't know I'll need them to issue a patch, I also don't have the product Id since it's * (auto generated). So, I need to rebuild my code and create the MSIs again with the same code as the released product making sure I hard code the Original Product Id I take from the released MSI. Then I make my changes (fix the bug or whatever) and rebuild my code and create the MSIs again MAKING SURE to use the same files.wxs created by the previous HEAT harvest (so the GUIDS will be the same). Now I have both wixpdb files without the change and with the change. I torch them to get the diff.wixmst. (using the -xi and -p flags) And then I pyro. (pyro.exe patch\patch.wixmsp -out patch.msp -t RTM patch\diff.wixmst -v) The customer needs to install the msp with this command: MSIEXEC /update \\tomer-c-d3\Share\patch.msp REINSTALL=ALL REINSTALLMODE=a It seems a bit cumbersome, will it work? :) Thanks again. -Original Message- From: Blair [mailto:os...@live.com] Sent: Monday, January 30, 2012 9:51 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] How does Torch decide which files changed?! One way to see what the transforms in a patch actually contain WRT any particular MSI, open the MSI in Orca, then open the MSP file using the Transform menu item View a patch. It will highlight the database changes, and in the case of files, you can look at the two file-related tables to see which files it thinks have been changed. -Original Message- From: tome...@qualisystems.com [mailto:tome...@qualisystems.com] Sent: Saturday, January 28, 2012 10:59 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] How does Torch decide which files changed?! One more thing, I opened the msp file with z7, there are only: exe dll (.net assemblies) and one txt file!? there. -Original Message- From: Blair [mailto:os...@live.com] Sent: Friday, January 27, 2012 10:24 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] How does Torch decide which files changed?! Torch marks up the database changes. Including -p causes it to leave the unchanged portions of the database intact so they will be present for Pyro to use in its processing. It is Pyro that looks at the two files and determines if they are the same or not, and it promotes files that compare as different to be considered as changed and thus be included with the other marked database changes. If you use WIXOUT or WIXPDB files then fragment boundaries are considered in the comparisons, so if you specify references to things to include in your patch family/families, things
Re: [WiX-users] How does Torch decide which files changed?!
One more thing I found out: (concerning the msi to wixpdb using dark, candle, light) I have another tag in my setup.wxs: ?if $(var.HasQsConfig) = true ? CustomAction Id=RunConfigInstall FileKey=QsConfig.exe ExeCommand= Execute=immediate Return=ignore / CustomAction Id=RunConfigUninstall FileKey=QsConfig.exe ExeCommand=RunMode=Uninstall Execute=immediate Return=ignore / InstallExecuteSequence Custom Action='RunConfigInstall' After='InstallFinalize' (NOT Installed AND RUN_QSCONFIG = true) OR (REINSTALL) /Custom Custom Action='RunConfigUninstall' After='CostFinalize' (Installed) /Custom /InstallExecuteSequence ?endif? Maybe it has something to do with the error since the generated wxs file (from the dark command) has this: InstallExecuteSequence Custom Action=RunConfigUninstall After=CostFinalize(Installed)/Custom Custom Action=RunConfigInstall After=InstallFinalize(NOT Installed AND RUN_QSCONFIG = true) OR (REINSTALL)/Custom InstallExecute / /InstallExecuteSequence Somehoe it generates an InstallExecute tag without the attribute... Thanks -Original Message- From: Blair [mailto:os...@live.com] Sent: Wednesday, February 01, 2012 6:55 PM To: 'General discussion for Windows Installer XML toolset.' Cc: Alex Abugov; Ronen Akri Subject: Re: [WiX-users] How does Torch decide which files changed?! If the only changes in your bug fix are files in the file table, that should work. To rebuild your code you may consider using dark on your released MSI to get your base WIXPDB and to get your starting point for your bug fix. The REINSTALL property will be autoselected to be the smallest section of already installed features that cover all of the database changes contained in the patch if you don't override it (as you are proposing). Normally the default value should suffice, unless you have a complex feature/component tree or if you have files that don't lend themselves well to the file versioning rules. Your overridden value for REINSTALLMODE property will prevent application of registry and shortcuts from the patched view. If you don't have a requirement for the a flag, the default should suffice. Blair -Original Message- From: tome...@qualisystems.com mailto:tome...@qualisystems.com [mailto:tome...@qualisystems.com mailto:tome...@qualisystems.com ] Sent: Wednesday, February 01, 2012 12:26 AM To: wix-users@lists.sourceforge.net mailto:wix-users@lists.sourceforge.net Cc: alex...@qualisystems.com mailto:alex...@qualisystems.com ; rone...@qualisystems.com mailto:rone...@qualisystems.com Subject: Re: [WiX-users] How does Torch decide which files changed?! Hi, After all your help :) I think I have a solution to my problem, please let me know what you think: My product is already installed on customers machines, I didn't save the wixpdb nor the files.wxs (the Heat harvest file) of those releases, since I didn't know I'll need them to issue a patch, I also don't have the product Id since it's * (auto generated). So, I need to rebuild my code and create the MSIs again with the same code as the released product making sure I hard code the Original Product Id I take from the released MSI. Then I make my changes (fix the bug or whatever) and rebuild my code and create the MSIs again MAKING SURE to use the same files.wxs created by the previous HEAT harvest (so the GUIDS will be the same). Now I have both wixpdb files without the change and with the change. I torch them to get the diff.wixmst. (using the -xi and -p flags) And then I pyro. (pyro.exe patch\patch.wixmsp -out patch.msp -t RTM patch\diff.wixmst -v) The customer needs to install the msp with this command: MSIEXEC /update \\tomer-c-d3\Share\patch.msp file:///\\tomer-c-d3\Share\patch.msp REINSTALL=ALL REINSTALLMODE=a It seems a bit cumbersome, will it work? :) Thanks again. -Original Message- From: Blair [mailto:os...@live.com mailto:os...@live.com ] Sent: Monday, January 30, 2012 9:51 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] How does Torch decide which files changed?! One way to see what the transforms in a patch actually contain WRT any particular MSI, open the MSI in Orca, then open the MSP file using the Transform menu item View a patch. It will highlight the database changes, and in the case of files, you can look at the two file-related tables to see which files it thinks have been changed. -Original Message- From: tome...@qualisystems.com mailto:tome...@qualisystems.com [mailto:tome...@qualisystems.com mailto:tome...@qualisystems.com ] Sent: Saturday, January 28, 2012 10:59 PM To: wix-users@lists.sourceforge.net mailto:wix-users@lists.sourceforge.net Subject: Re: [WiX-users] How does Torch decide which files changed?! One more thing, I opened the msp file with z7,
[WiX-users] remote installer + bootstrapper
Hi, We are having a installer having 2 features(each feature is install a windows service which do some jobs). Both services/features can be installed on multiple computers and then using application's user interface user can interconnect all the application components. Thereafter all application components residing on multiple computers work together. Right now we have an msi installer having both components as two features. User has to visit all the machines one by one if he wants to install on say 10 computers. We want to create a bootstrapper application which also has capability to launch installer on multiple machines in one go. Can anybody give some pointers that how to start on this ? Many-many thanks in advance. Regards, Sanjay Rao -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Install issue - wix2010.target line 761
The location of the exes is taken from the registry and put in $(WixToolPath). Can you check the InstallRoot value under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Installer XML\3.5 or HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows Installer XML\3.5 and see if it is correct? Otherwise, are you overriding $(WixToolPath) somewhere else in the project? Pete Date: Wed, 1 Feb 2012 22:56:52 + From: mark.sug...@gmail.com To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Install issue - wix2010.target line 761 Thanks for the reply. How do I set %WIX%? And what should I set it to? Previously, I just installed WiX and compile worked fine. What might have changed? On Wed, Feb 1, 2012 at 18:05, Blair os...@live.com wrote: I don't know. Is the %WIX% environment variable set? I use the HarvestDirectory items instead of the PreBuildEvent property to use the harvester in 3.5 myself. -Original Message- From: Mark Sugrue [mailto:mark.sug...@gmail.com] Sent: Wednesday, February 01, 2012 8:57 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Install issue - wix2010.target line 761 I'm setting up a new build machine. VS2010, Wix3.5, etc. Everything the same as the old machine. (both are x64 Win7 Pro) When I try to build the installer on the new machine, I get an odd error which I don't understand. Nothing on the web seems to match it. The error isn't in my code, its on line 761 of wix2010.targets The line is Exec WorkingDirectory=$(OutDir) Command=$(ExpandedPreBuildEvent) / I haven't edited this file at all. The error I get is this: Error 3 The command %WIX%\bin\heat dir D:\Code\products\LE\bin\Debug\Help -dr HelpFolder -cg HelpComponentGroup -var var.HelpDir -srd -gg -sfrag -suid -template:fragment -out D:\Code\products\LE\Setup\help.wxs.sample exited with code 3. C:\Program Files (x86)\MSBuild\Microsoft\WiX\v3.x\wix2010.targets761 6 Setup But the exact same code compiles fine on the old machine. Is there some setting I need to change maybe? -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Struggling to get bal:Condition to work (wix burn)
Is there some way to log the value of the Burn Built-in Variables. At the moment the log just tells me that my test resolved to False and I can't tell if the value of Privileged is set to False or is undefined. I've tried testing against some of the other built-in variables and had unexpected results. With out being able to examine those variables he is hard to say if they are not being set how I expect or if I am forming my logic test incorrectly. On Mon, Jan 30, 2012 at 4:38 PM, Rob Mensching r...@robmensching.com wrote: Maybe I should be more clear. When I say something is a bug, I mean The behavior you described is not expected. That does not mean there is a bug on SourceForge tracking it. Privileged in Burn means the process was launched elevated. If you are launching Burn elevated (aka: you see the consent prompt or the process launching Burn was already elevated) and Privileged is not true, then that would be a bug. smile/ On Mon, Jan 30, 2012 at 2:49 AM, Boyd Ludlow boyd.lud...@gmail.com wrote: Rob, I just assumed that it was a bug because your response to that Stack Overflow question stated that the behaviour being seen was a bug. I didn't know enough about working with Burn to know if I was doing something wrong or if it was a problem with Burn but I accepted that you would know what you were talking about. However this is a side track. My original question still stands. Why is it that when I test against Privileged it always returns false regardless of whether I an running as an administrator or not. On Sun, Jan 29, 2012 at 4:46 AM, Rob Mensching r...@robmensching.com wrote: That's not a bug. That's a Stack Overflow question. If you really are hitting a bug, please open it so we can get details and track progress on the issue. On Fri, Jan 27, 2012 at 12:04 AM, Boyd Ludlow boyd.lud...@gmail.com wrote: As per this post http://stackoverflow.com/questions/8691061/wix-3-6-burn-bootstrapper-fails-to-elevate On Fri, Jan 27, 2012 at 4:40 AM, Bob Arnson b...@joyofsetup.com wrote: On 26-Jan-12 11:18, Boyd Ludlow wrote: I know that a bug currently exists when using burn that it errors rather than asking for elevated rights. What bug is that? -- sig://boB http://joyofsetup.com/ -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- Try before you buy = See our experts in action! The most
[WiX-users] Custom Action Condition Table
Can somebody provide with the table that can show which conditions to use for Custom Actions to run only on Install only, Install and Modify, Modify only and Uninstall only? Thanks in advance. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Custom-Action-Condition-Table-tp7246590p7246590.html Sent from the wix-users mailing list archive at Nabble.com. -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WriteIIS7ConfigChanges: Error 0x80070057: Failed get handlers section for DirProp
Certainly. I'll get right on it. -- John M. Cooper -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Wednesday, February 01, 2012 6:16 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] WriteIIS7ConfigChanges: Error 0x80070057: Failed get handlers section for DirProp That's what I was going to suggest first. Can you open a bug to track the issue? On Wed, Feb 1, 2012 at 1:12 PM, John Cooper jocoo...@jackhenry.com wrote: Hmm. Rebuilt with the latest Wix 3.6, and I still get: Action 15:10:21: WriteIIS7ConfigChanges. Installing Config Keys and Values MSI (s) (44:24) [15:10:21:915]: Executing op: CustomActionSchedule(Action=WriteIIS7ConfigChanges,ActionType=11265,So urce=BinaryData,Target=**,CustomActionData=**) MSI (s) (44:20) [15:10:21:945]: Invoking remote custom action. DLL: C:\Windows\Installer\MSIA97A.tmp, Entrypoint: WriteIIS7ConfigChanges WriteIIS7ConfigChanges: Error 0x80070057: Failed get handlers section for DirProp WriteIIS7ConfigChanges: Error 0x80070057: Failed to configure IIS DirProperties. WriteIIS7ConfigChanges: Error 0x80070057: WriteIIS7ConfigChanges Failed. CustomAction WriteIIS7ConfigChanges returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox) Action ended 15:10:22: InstallFinalize. Return value 3. -- John M. Cooper -Original Message- From: John Cooper Sent: Wednesday, February 01, 2012 2:36 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] WriteIIS7ConfigChanges: Error 0x80070057: Failed get handlers section for DirProp Wonderful. Is there an assembly I can take from the Wix 3.6 build and replace in the 3.5? I've got to stay with 3.5 until 3.6 goes RTM. -- John M. Cooper -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Wednesday, February 01, 2012 2:25 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] WriteIIS7ConfigChanges: Error 0x80070057: Failed get handlers section for DirProp This sounds very much like a bug that was fixed in WiX v3.6... On Wed, Feb 1, 2012 at 11:17 AM, John Cooper jocoo...@jackhenry.com wrote: Replying to myself: Commenting out the iis:WebDirProperties element results in a different error: Action 13:13:03: WriteIIS7ConfigChanges. Installing Config Keys and Values MSI (s) (60:E0) [13:13:03:168]: Executing op: CustomActionSchedule(Action=WriteIIS7ConfigChanges,ActionType=11265, So urce=BinaryData,Target=**,CustomActionData=**) MSI (s) (60:B4) [13:13:03:170]: Invoking remote custom action. DLL: C:\Windows\Installer\MSI4097.tmp, Entrypoint: WriteIIS7ConfigChanges WriteIIS7ConfigChanges: Error 0x80070057: Failed get httpErrors section WriteIIS7ConfigChanges: Error 0x80070057: Failed to configure IIS web svc ext. WriteIIS7ConfigChanges: Error 0x80070057: WriteIIS7ConfigChanges Failed. CustomAction WriteIIS7ConfigChanges returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox) Action ended 13:13:06: InstallFinalize. Return value 3. -- John M. Cooper -Original Message- From: John Cooper Sent: Wednesday, February 01, 2012 12:45 PM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] WriteIIS7ConfigChanges: Error 0x80070057: Failed get handlers section for DirProp I'm getting an install time error during IIS7 Configuration: WriteIIS7ConfigChanges: Error 0x80070057: Failed get handlers for DirProp. This is with Wix 3.5 RTM. An extract of the verbose log looks like: Action 12:37:38: WriteIIS7ConfigChanges. Installing Config Keys and Values MSI (s) (F4:74) [12:37:38:134]: Executing op: CustomActionSchedule(Action=WriteIIS7ConfigChanges,ActionType=11265, So urce=BinaryData,Target=**,CustomActionData=**) MSI (s) (F4:CC) [12:37:38:137]: Invoking remote custom action. DLL: C:\Windows\Installer\MSID717.tmp, Entrypoint: WriteIIS7ConfigChanges WriteIIS7ConfigChanges: Error 0x80070057: Failed get handlers section for DirProp WriteIIS7ConfigChanges: Error 0x80070057: Failed to configure IIS DirProperties. WriteIIS7ConfigChanges: Error 0x80070057: WriteIIS7ConfigChanges Failed. CustomAction WriteIIS7ConfigChanges returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox) Action ended 12:37:41: InstallFinalize. Return value 3. The relevant source looks like: Fragment PropertyRef Id=WEBSITE_NAME / iis:WebSite Id=TargetWebSite Description=[WEBSITE_NAME] Directory=WebsiteFolder iis:WebAddress Id=AllUnassigned Port=80 IP=* / iis:WebAddress Id=AllUnassignedSsl Port=443 IP=* Secure=yes / /iis:WebSite /Fragment Fragment Property
Re: [WiX-users] WriteIIS7ConfigChanges: Error 0x80070057: Failed get handlers section for DirProp
Bug is 3483215. -- John M. Cooper -Original Message- From: John Cooper Sent: Thursday, February 02, 2012 8:02 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] WriteIIS7ConfigChanges: Error 0x80070057: Failed get handlers section for DirProp Certainly. I'll get right on it. -- John M. Cooper -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Wednesday, February 01, 2012 6:16 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] WriteIIS7ConfigChanges: Error 0x80070057: Failed get handlers section for DirProp That's what I was going to suggest first. Can you open a bug to track the issue? On Wed, Feb 1, 2012 at 1:12 PM, John Cooper jocoo...@jackhenry.com wrote: Hmm. Rebuilt with the latest Wix 3.6, and I still get: Action 15:10:21: WriteIIS7ConfigChanges. Installing Config Keys and Values MSI (s) (44:24) [15:10:21:915]: Executing op: CustomActionSchedule(Action=WriteIIS7ConfigChanges,ActionType=11265,So urce=BinaryData,Target=**,CustomActionData=**) MSI (s) (44:20) [15:10:21:945]: Invoking remote custom action. DLL: C:\Windows\Installer\MSIA97A.tmp, Entrypoint: WriteIIS7ConfigChanges WriteIIS7ConfigChanges: Error 0x80070057: Failed get handlers section for DirProp WriteIIS7ConfigChanges: Error 0x80070057: Failed to configure IIS DirProperties. WriteIIS7ConfigChanges: Error 0x80070057: WriteIIS7ConfigChanges Failed. CustomAction WriteIIS7ConfigChanges returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox) Action ended 15:10:22: InstallFinalize. Return value 3. -- John M. Cooper -Original Message- From: John Cooper Sent: Wednesday, February 01, 2012 2:36 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] WriteIIS7ConfigChanges: Error 0x80070057: Failed get handlers section for DirProp Wonderful. Is there an assembly I can take from the Wix 3.6 build and replace in the 3.5? I've got to stay with 3.5 until 3.6 goes RTM. -- John M. Cooper -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Wednesday, February 01, 2012 2:25 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] WriteIIS7ConfigChanges: Error 0x80070057: Failed get handlers section for DirProp This sounds very much like a bug that was fixed in WiX v3.6... On Wed, Feb 1, 2012 at 11:17 AM, John Cooper jocoo...@jackhenry.com wrote: Replying to myself: Commenting out the iis:WebDirProperties element results in a different error: Action 13:13:03: WriteIIS7ConfigChanges. Installing Config Keys and Values MSI (s) (60:E0) [13:13:03:168]: Executing op: CustomActionSchedule(Action=WriteIIS7ConfigChanges,ActionType=11265, So urce=BinaryData,Target=**,CustomActionData=**) MSI (s) (60:B4) [13:13:03:170]: Invoking remote custom action. DLL: C:\Windows\Installer\MSI4097.tmp, Entrypoint: WriteIIS7ConfigChanges WriteIIS7ConfigChanges: Error 0x80070057: Failed get httpErrors section WriteIIS7ConfigChanges: Error 0x80070057: Failed to configure IIS web svc ext. WriteIIS7ConfigChanges: Error 0x80070057: WriteIIS7ConfigChanges Failed. CustomAction WriteIIS7ConfigChanges returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox) Action ended 13:13:06: InstallFinalize. Return value 3. -- John M. Cooper -Original Message- From: John Cooper Sent: Wednesday, February 01, 2012 12:45 PM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] WriteIIS7ConfigChanges: Error 0x80070057: Failed get handlers section for DirProp I'm getting an install time error during IIS7 Configuration: WriteIIS7ConfigChanges: Error 0x80070057: Failed get handlers for DirProp. This is with Wix 3.5 RTM. An extract of the verbose log looks like: Action 12:37:38: WriteIIS7ConfigChanges. Installing Config Keys and Values MSI (s) (F4:74) [12:37:38:134]: Executing op: CustomActionSchedule(Action=WriteIIS7ConfigChanges,ActionType=11265, So urce=BinaryData,Target=**,CustomActionData=**) MSI (s) (F4:CC) [12:37:38:137]: Invoking remote custom action. DLL: C:\Windows\Installer\MSID717.tmp, Entrypoint: WriteIIS7ConfigChanges WriteIIS7ConfigChanges: Error 0x80070057: Failed get handlers section for DirProp WriteIIS7ConfigChanges: Error 0x80070057: Failed to configure IIS DirProperties. WriteIIS7ConfigChanges: Error 0x80070057: WriteIIS7ConfigChanges Failed. CustomAction WriteIIS7ConfigChanges returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox) Action ended 12:37:41: InstallFinalize. Return value 3. The relevant source looks like: Fragment PropertyRef
[WiX-users] Problem with EventSource on XP
I'm having a problem with getting an EventSource to work correctly on XP, the same install works fine on Win7. Component Id=ApplicationExe Guid=* File Id=mergefarms.exe Source=$(var.MergeFarms.TargetDir)$(var.MergeFarms.TargetFileName) / util:EventSource Log=SnapPlus Name=SnapPlus EventMessageFile=[NETFRAMEWORK40CLIENTINSTALLROOTDIR]EventLogMessages.dll/ /Component Is how I have it setup. The problem on XP is that the registry entry for the eventmessagefile comes out as plain old EventLogMessages.dll. It's supposed to tack on the .NET 4 path and be C:\Windows\Microsoft.NET\Framework\v4.0.30319\EventLogMessages.dll. On Win7 it does come out with the full path. This is causing the annoying message about a missing event messages. The rest of the WiX install looks to be working. I do have the WixNetFxExtension and WixUtilExtension on my setup project and the xmlns: set at the top. I did go back to my clean XP build and installed .NET 4. Is this a problem on XP or am I missing something? Thanks --Dirk -- Dirk Herr-Hoyman -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Harvesting dll's referenced in a c# project in VS
Hi! I'm pretty new to the toolset so bear with me :) I'm using 3.5, and am trying to harvest the dll's from the c# project, using the property Harvest set to true in Visual Studio. I do get a ComponentGroup named x.Binaries, but it don't contain any of the dll's that my project is referencing, something I did expect. It does harvest a lot of other stuff, so I would guess it would do these dll's too, which are kind of the more important ones. Is there something special one need to turn on for these to be harvested too ? best regards Terje Sandstrøm Chief Software Architect Inmetahttp://www.inmeta.com/ Visual Studio ALM MVPhttps://mvp.support.microsoft.com/profile=805E36BF-F29F-4FF6-8908-223F3666EE9C geekswithblogs.net/terjehttp://geekswithblogs.net/terje Twitter: @OsirisTerje Skype: osiris_terje (+47) 95750354 -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Visual C++ 2010 Merge Module
If you were using the MSM simply because it is a container of files themselves, you can get the same effect by binding the files to the WixLib by supplying the -bf flag to lit.exe. In MSBuild/VisualStudio, you can do this by setting either of the following properties to true in the WixProj file: LibBindFiles or BindFiles. Blair -Original Message- From: Joost van Zoest [mailto:jzo...@siqura.com] Sent: Thursday, February 02, 2012 12:53 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Visual C++ 2010 Merge Module Hi Blair, Thank you very much for this new insight. The use of WixLib sounds good; the actual wxs files of product A are already in a WixLib, so that they can be shared between the installer and MSM. The only thing is that the repository of product B then has to have access to the repository of product A, which we don't want. I really like the idea of using the Common Files directory though. We will give this a try in our next sprint. So again, thanks for your time! Regards, Jari -Original Message- From: Blair [mailto:os...@live.com] Sent: Wednesday, February 01, 2012 6:11 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Visual C++ 2010 Merge Module That is what the Common Program Files directory was created for smile/. You use it similarly to the non-Common directory, except that components shared between simultaneously installed products live there. Then there is never any need to keep track of or even care about a COM object's installation directory. Do you build both Product A and Product B with the same (or at least similar) builds of WiX? If so, your problem as you have designed it would probably be easier to solve using WIXLIBs instead of MSMs. Create a WixLib project (instead of a module) of Product A. Even better than the registry search would be a component search to get the component's installation directory, but a registry search can be used as well (as long as you write the registry key). Place that search in the WixLib. Create two WiX-MSI projects, one for A and the other for B. Both consume (and depend on) the WixLib for A. The linker (which is not heavily involved in the the incorporation of MSM content) will be able to arbitrate the various actions needed between the different parts the installation much more easily than the binder can, and you will also avoid the issues you are seeing with trying to force the AppSearch from an MSM. Blair This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Harvesting dll's referenced in a c# project in VS
Unfortunately heat doesn't harvest referenced assemblies in a project. Neil -Original Message- From: Terje Sandstrom [mailto:te...@hermit.onmicrosoft.com] Sent: 02 February 2012 19:02 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Harvesting dll's referenced in a c# project in VS Hi! I'm pretty new to the toolset so bear with me :) I'm using 3.5, and am trying to harvest the dll's from the c# project, using the property Harvest set to true in Visual Studio. I do get a ComponentGroup named x.Binaries, but it don't contain any of the dll's that my project is referencing, something I did expect. It does harvest a lot of other stuff, so I would guess it would do these dll's too, which are kind of the more important ones. Is there something special one need to turn on for these to be harvested too ? best regards Terje Sandstrøm Chief Software Architect Inmetahttp://www.inmeta.com/ Visual Studio ALM MVPhttps://mvp.support.microsoft.com/profile=805E36BF-F29F-4FF6-8908-223F3666EE9C geekswithblogs.net/terjehttp://geekswithblogs.net/terje Twitter: @OsirisTerje Skype: osiris_terje (+47) 95750354 -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Creating msi installer with merge modules.
I suspect that the MSM would also fail validation. If it fails, can you get
your third party to fix their MSM until it passes validation?
Blair
-Original Message-
From: Sireesha Jakku [mailto:sireesha_ja...@persistent.co.in]
Sent: Thursday, February 02, 2012 3:14 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Creating msi installer with merge modules.
Hi,
We are trying to create a msi installer which includes third party merge
module using WiX 3.5.
I just need to create installer with just merge modules and I don't have any
files to be shipped in the installer.
When I try to compile the project, I am getting below errors:
--
light.exe(0,0): error LGHT0204: ICE18: KeyPath for Component:
'For32bit.{guid}' is Directory: 'INSTALLDIR.{guid}'. The Directory/Component
pair must be listed in the CreateFolders table.
light.exe(0,0): error LGHT0204: ICE18: KeyPath for Component:
'For64bit.{guid}' is Directory: 'INSTALLDIR.{guid}'. The Directory/Component
pair must be listed in the CreateFolders table.
light.exe(0,0): error LGHT0204: ICE18: KeyPath for Component:
'RestoreOldInstallEXEName.{guid}' is Directory: 'INSTALLDIR.{guid}'. The
Directory/Component pair must be listed in the CreateFolders table.
light.exe(0,0): error LGHT0204: ICE18: KeyPath for Component:
'WriteInstallEXEName.{guid}' is Directory: 'INSTALLDIR.{guid}'. The
Directory/Component pair must be listed in the CreateFolders table.
-
Can anyone suggest how to solve this issue?
Thankyou in advance.
Regards,
Sireesha
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.
--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers is
just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro
Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Problem with EventSource on XP
This is the registry key used to populate the NETFRAMEWORK40CLIENTINSTALLROOTDIR property. Can you verify that the registry key is set propertly on the XP box? HKLM\Software\Microsoft\NET Framework Setup\NDP\v4\Client InstallPath Also in your verbose installation log you should see the property being set during the AppSearch action. Can you confirm? Also, you should have a PropertyRef for that property in your authoring (i.e. adjacent to your Component include this element: PropertyRef Id=NETFRAMEWORK40CLIENTINSTALLROOTDIR /) to ensure that the property will be setup in your MSI. Blair -Original Message- From: Dirk Herr-Hoyman [mailto:hoym...@gmail.com] Sent: Thursday, February 02, 2012 10:53 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Problem with EventSource on XP I'm having a problem with getting an EventSource to work correctly on XP, the same install works fine on Win7. Component Id=ApplicationExe Guid=* File Id=mergefarms.exe Source=$(var.MergeFarms.TargetDir)$(var.MergeFarms.TargetFileName) / util:EventSource Log=SnapPlus Name=SnapPlus EventMessageFile=[NETFRAMEWORK40CLIENTINSTALLROOTDIR]EventLogMessages.dll/ /Component Is how I have it setup. The problem on XP is that the registry entry for the eventmessagefile comes out as plain old EventLogMessages.dll. It's supposed to tack on the .NET 4 path and be C:\Windows\Microsoft.NET\Framework\v4.0.30319\EventLogMessages.dll. On Win7 it does come out with the full path. This is causing the annoying message about a missing event messages. The rest of the WiX install looks to be working. I do have the WixNetFxExtension and WixUtilExtension on my setup project and the xmlns: set at the top. I did go back to my clean XP build and installed .NET 4. Is this a problem on XP or am I missing something? Thanks --Dirk -- Dirk Herr-Hoyman -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How does Torch decide which files changed?!
What did dark write in line 2939 of TestShell DriverBuilder Setup.wxs? -Original Message- From: tome...@qualisystems.com [mailto:tome...@qualisystems.com] Sent: Thursday, February 02, 2012 1:19 AM To: wix-users@lists.sourceforge.net Cc: alex...@qualisystems.com; rone...@qualisystems.com Subject: Re: [WiX-users] How does Torch decide which files changed?! Hi, Good to know about Dark.exe, didn't notice it till now :) I'm having problems after converting my Original MSI to WXS file, I try to Candle it so I can then light it to get the wixpdb, but I get this error: \\sqlsrv\tsinstallers\TestShell Suite\4.6.255 SP1\Data\Driver Builder\TestShell DriverBuilder Setup.wxs(2939) : error CNDL0072 : A InstallExecute element must have a Before attribute, After attribute, or a Sequence attribute. If I look at my original setup.wxs file the InstallExecute tag looks like this: InstallExecuteSequence InstallExecute After=RemoveExistingProducts/ /InstallExecuteSequence It does have an After attribute... what am I doing wrong... maybe it's the UNC path? Naa. -Original Message- From: Blair [mailto:os...@live.com] Sent: Wednesday, February 01, 2012 6:55 PM To: 'General discussion for Windows Installer XML toolset.' Cc: Alex Abugov; Ronen Akri Subject: Re: [WiX-users] How does Torch decide which files changed?! If the only changes in your bug fix are files in the file table, that should work. To rebuild your code you may consider using dark on your released MSI to get your base WIXPDB and to get your starting point for your bug fix. The REINSTALL property will be autoselected to be the smallest section of already installed features that cover all of the database changes contained in the patch if you don't override it (as you are proposing). Normally the default value should suffice, unless you have a complex feature/component tree or if you have files that don't lend themselves well to the file versioning rules. Your overridden value for REINSTALLMODE property will prevent application of registry and shortcuts from the patched view. If you don't have a requirement for the a flag, the default should suffice. Blair -Original Message- From: tome...@qualisystems.com [mailto:tome...@qualisystems.com] Sent: Wednesday, February 01, 2012 12:26 AM To: wix-users@lists.sourceforge.net Cc: alex...@qualisystems.com; rone...@qualisystems.com Subject: Re: [WiX-users] How does Torch decide which files changed?! Hi, After all your help :) I think I have a solution to my problem, please let me know what you think: My product is already installed on customers machines, I didn't save the wixpdb nor the files.wxs (the Heat harvest file) of those releases, since I didn't know I'll need them to issue a patch, I also don't have the product Id since it's * (auto generated). So, I need to rebuild my code and create the MSIs again with the same code as the released product making sure I hard code the Original Product Id I take from the released MSI. Then I make my changes (fix the bug or whatever) and rebuild my code and create the MSIs again MAKING SURE to use the same files.wxs created by the previous HEAT harvest (so the GUIDS will be the same). Now I have both wixpdb files without the change and with the change. I torch them to get the diff.wixmst. (using the -xi and -p flags) And then I pyro. (pyro.exe patch\patch.wixmsp -out patch.msp -t RTM patch\diff.wixmst -v) The customer needs to install the msp with this command: MSIEXEC /update \\tomer-c-d3\Share\patch.msp REINSTALL=ALL REINSTALLMODE=a It seems a bit cumbersome, will it work? :) Thanks again. -Original Message- From: Blair [mailto:os...@live.com] Sent: Monday, January 30, 2012 9:51 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] How does Torch decide which files changed?! One way to see what the transforms in a patch actually contain WRT any particular MSI, open the MSI in Orca, then open the MSP file using the Transform menu item View a patch. It will highlight the database changes, and in the case of files, you can look at the two file-related tables to see which files it thinks have been changed. -Original Message- From: tome...@qualisystems.com [mailto:tome...@qualisystems.com] Sent: Saturday, January 28, 2012 10:59 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] How does Torch decide which files changed?! One more thing, I opened the msp file with z7, there are only: exe dll (.net assemblies) and one txt file!? there. -Original Message- From: Blair [mailto:os...@live.com] Sent: Friday, January 27, 2012 10:24 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] How does Torch decide which files changed?! Torch marks up the database changes. Including -p causes it to leave the unchanged portions of the database intact so they will be present for Pyro to use in its processing. It is Pyro that looks at the two
Re: [WiX-users] How does Torch decide which files changed?!
I'm assuming that the attribute-less InstallExecute in this email is the line in the error message, correct? If so, then this really looks like a bug in dark.exe. The ?if? from the original source shouldn't have anything to do with the this bug in dark.exe. Go ahead and fix that line in the generated file after you file a bug against dark.exe. Blair -Original Message- From: tome...@qualisystems.com [mailto:tome...@qualisystems.com] Sent: Thursday, February 02, 2012 1:29 AM To: wix-users@lists.sourceforge.net Cc: alex...@qualisystems.com; rone...@qualisystems.com Subject: Re: [WiX-users] How does Torch decide which files changed?! One more thing I found out: (concerning the msi to wixpdb using dark, candle, light) I have another tag in my setup.wxs: ?if $(var.HasQsConfig) = true ? CustomAction Id=RunConfigInstall FileKey=QsConfig.exe ExeCommand= Execute=immediate Return=ignore / CustomAction Id=RunConfigUninstall FileKey=QsConfig.exe ExeCommand=RunMode=Uninstall Execute=immediate Return=ignore / InstallExecuteSequence Custom Action='RunConfigInstall' After='InstallFinalize' (NOT Installed AND RUN_QSCONFIG = true) OR (REINSTALL) /Custom Custom Action='RunConfigUninstall' After='CostFinalize' (Installed) /Custom /InstallExecuteSequence ?endif? Maybe it has something to do with the error since the generated wxs file (from the dark command) has this: InstallExecuteSequence Custom Action=RunConfigUninstall After=CostFinalize(Installed)/Custom Custom Action=RunConfigInstall After=InstallFinalize(NOT Installed AND RUN_QSCONFIG = true) OR (REINSTALL)/Custom InstallExecute / /InstallExecuteSequence Somehoe it generates an InstallExecute tag without the attribute... Thanks -Original Message- From: Blair [mailto:os...@live.com] Sent: Wednesday, February 01, 2012 6:55 PM To: 'General discussion for Windows Installer XML toolset.' Cc: Alex Abugov; Ronen Akri Subject: Re: [WiX-users] How does Torch decide which files changed?! If the only changes in your bug fix are files in the file table, that should work. To rebuild your code you may consider using dark on your released MSI to get your base WIXPDB and to get your starting point for your bug fix. The REINSTALL property will be autoselected to be the smallest section of already installed features that cover all of the database changes contained in the patch if you don't override it (as you are proposing). Normally the default value should suffice, unless you have a complex feature/component tree or if you have files that don't lend themselves well to the file versioning rules. Your overridden value for REINSTALLMODE property will prevent application of registry and shortcuts from the patched view. If you don't have a requirement for the a flag, the default should suffice. Blair -Original Message- From: tome...@qualisystems.com mailto:tome...@qualisystems.com [mailto:tome...@qualisystems.com mailto:tome...@qualisystems.com ] Sent: Wednesday, February 01, 2012 12:26 AM To: wix-users@lists.sourceforge.net mailto:wix-users@lists.sourceforge.net Cc: alex...@qualisystems.com mailto:alex...@qualisystems.com ; rone...@qualisystems.com mailto:rone...@qualisystems.com Subject: Re: [WiX-users] How does Torch decide which files changed?! Hi, After all your help :) I think I have a solution to my problem, please let me know what you think: My product is already installed on customers machines, I didn't save the wixpdb nor the files.wxs (the Heat harvest file) of those releases, since I didn't know I'll need them to issue a patch, I also don't have the product Id since it's * (auto generated). So, I need to rebuild my code and create the MSIs again with the same code as the released product making sure I hard code the Original Product Id I take from the released MSI. Then I make my changes (fix the bug or whatever) and rebuild my code and create the MSIs again MAKING SURE to use the same files.wxs created by the previous HEAT harvest (so the GUIDS will be the same). Now I have both wixpdb files without the change and with the change. I torch them to get the diff.wixmst. (using the -xi and -p flags) And then I pyro. (pyro.exe patch\patch.wixmsp -out patch.msp -t RTM patch\diff.wixmst -v) The customer needs to install the msp with this command: MSIEXEC /update \\tomer-c-d3\Share\patch.msp file:///\\tomer-c-d3\Share\patch.msp REINSTALL=ALL REINSTALLMODE=a It seems a bit cumbersome, will it work? :) Thanks again. -Original Message- From: Blair [mailto:os...@live.com mailto:os...@live.com ] Sent: Monday, January 30, 2012 9:51 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] How does Torch decide which files changed?! One way to see what the transforms in a patch actually contain WRT any particular MSI,
Re: [WiX-users] Harvesting dll's referenced in a c# project in VS
Thanks ! Surprising, but. What is the workaround ?There is a workaround, right ? Best regards Terje -Original Message- From: Neil Sleightholm [mailto:n...@x2systems.com] Sent: 2. februar 2012 21:24 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Harvesting dll's referenced in a c# project in VS Unfortunately heat doesn't harvest referenced assemblies in a project. Neil -Original Message- From: Terje Sandstrom [mailto:te...@hermit.onmicrosoft.com] Sent: 02 February 2012 19:02 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Harvesting dll's referenced in a c# project in VS Hi! I'm pretty new to the toolset so bear with me :) I'm using 3.5, and am trying to harvest the dll's from the c# project, using the property Harvest set to true in Visual Studio. I do get a ComponentGroup named x.Binaries, but it don't contain any of the dll's that my project is referencing, something I did expect. It does harvest a lot of other stuff, so I would guess it would do these dll's too, which are kind of the more important ones. Is there something special one need to turn on for these to be harvested too ? best regards Terje Sandstrøm Chief Software Architect Inmetahttp://www.inmeta.com/ Visual Studio ALM MVPhttps://mvp.support.microsoft.com/profile=805E36BF-F29F-4FF6-8908-223F3666EE9C geekswithblogs.net/terjehttp://geekswithblogs.net/terje Twitter: @OsirisTerje Skype: osiris_terje (+47) 95750354 -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Creating msi installer with merge modules.
FWIW, I'm a strong advocate of the use of internally generated merge
modules to support decentralized setup development, but I am very, very
wary of using merge modules from third parties. It usually doesn't end
well.
From: Blair os...@live.com
Sent: Thursday, February 02, 2012 2:41 PM
To: General discussion for Windows Installer XML toolset.
wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Creating msi installer with merge modules.
I suspect that the MSM would also fail validation. If it fails, can you
get
your third party to fix their MSM until it passes validation?
Blair
-Original Message-
From: Sireesha Jakku [mailto:sireesha_ja...@persistent.co.in]
Sent: Thursday, February 02, 2012 3:14 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Creating msi installer with merge modules.
Hi,
We are trying to create a msi installer which includes third party merge
module using WiX 3.5.
I just need to create installer with just merge modules and I don't have
any
files to be shipped in the installer.
When I try to compile the project, I am getting below errors:
--
light.exe(0,0): error LGHT0204: ICE18: KeyPath for Component:
'For32bit.{guid}' is Directory: 'INSTALLDIR.{guid}'. The
Directory/Component
pair must be listed in the CreateFolders table.
light.exe(0,0): error LGHT0204: ICE18: KeyPath for Component:
'For64bit.{guid}' is Directory: 'INSTALLDIR.{guid}'. The
Directory/Component
pair must be listed in the CreateFolders table.
light.exe(0,0): error LGHT0204: ICE18: KeyPath for Component:
'RestoreOldInstallEXEName.{guid}' is Directory: 'INSTALLDIR.{guid}'. The
Directory/Component pair must be listed in the CreateFolders table.
light.exe(0,0): error LGHT0204: ICE18: KeyPath for Component:
'WriteInstallEXEName.{guid}' is Directory: 'INSTALLDIR.{guid}'. The
Directory/Component pair must be listed in the CreateFolders table.
-
Can anyone suggest how to solve this issue?
Thankyou in advance.
Regards,
Sireesha
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.
--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers is
just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro
Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Problem with EventSource on XP
On Thu, Feb 2, 2012 at 2:54 PM, Blair os...@live.com wrote: This is the registry key used to populate the NETFRAMEWORK40CLIENTINSTALLROOTDIR property. Can you verify that the registry key is set propertly on the XP box? HKLM\Software\Microsoft\NET Framework Setup\NDP\v4\Client InstallPath Yep, that's set correctly Also in your verbose installation log you should see the property being set during the AppSearch action. Can you confirm? I see NETFRAMEWORK40, but not NETFRAMEWORK40CLIENTINSTALLROOTDIR Also, you should have a PropertyRef for that property in your authoring (i.e. adjacent to your Component include this element: PropertyRef Id=NETFRAMEWORK40CLIENTINSTALLROOTDIR /) to ensure that the property will be setup in your MSI. I had NETFRAMEWORK40 set, but not NETFRAMEWORK40CLIENTINSTALLROOTDIR Doh! Had this right in another project, but neglected to bring forward both PropertyRef. I am now seeing the right setting in the Registry. Thanks for your help! --Dirk Blair -Original Message- From: Dirk Herr-Hoyman [mailto:hoym...@gmail.com] Sent: Thursday, February 02, 2012 10:53 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Problem with EventSource on XP I'm having a problem with getting an EventSource to work correctly on XP, the same install works fine on Win7. Component Id=ApplicationExe Guid=* File Id=mergefarms.exe Source=$(var.MergeFarms.TargetDir)$(var.MergeFarms.TargetFileName) / util:EventSource Log=SnapPlus Name=SnapPlus EventMessageFile=[NETFRAMEWORK40CLIENTINSTALLROOTDIR]EventLogMessages.dll/ /Component Is how I have it setup. The problem on XP is that the registry entry for the eventmessagefile comes out as plain old EventLogMessages.dll. It's supposed to tack on the .NET 4 path and be C:\Windows\Microsoft.NET\Framework\v4.0.30319\EventLogMessages.dll. On Win7 it does come out with the full path. This is causing the annoying message about a missing event messages. The rest of the WiX install looks to be working. I do have the WixNetFxExtension and WixUtilExtension on my setup project and the xmlns: set at the top. I did go back to my clean XP build and installed .NET 4. Is this a problem on XP or am I missing something? Thanks --Dirk -- Dirk Herr-Hoyman -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Dirk Herr-Hoyman -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Question from a WiX Votive newbie
I am new to WiX Votive but not new to installers or setups by any means. Briefly, I am getting spun up on WiX as a plausible upgrade from the basic Setup (VDPROJ) project that Visual Studio 2010 offices out of the box. Can someone tell me briefly, how does it compare? Besides doing what the Setup project does by automatically detecting dependencies, generating an MSI output, folder organization, registry actions, and other custom actions... I am interested that WiX Votive supports custom dialogs? Also that it can be incorporated into a solution seamlessly during a Continuous Integration build using MSBuild is a huge plus (you don't even know...). Thank you... Best regards, Michael Powell -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Custom Action Condition Table
Yes. But I don't want to include these files. I would like to see simple chart which use these properties e.g. REMOVE=ALL, Installed, NOT Upgrading, NOT Uninstalling AND NOT UPGRADINGPRODUCTCODE and tell me where they are applicable. But I think I'll try to get that information from this link that you provided. Thanks very much for the link. Amit -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Custom-Action-Condition-Table-tp7246590p7249613.html Sent from the wix-users mailing list archive at Nabble.com. -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Struggling to get bal:Condition to work (wix burn)
Not today but it's been asked before. On Thu, Feb 2, 2012 at 3:15 AM, Boyd Ludlow boyd.lud...@gmail.com wrote: Is there some way to log the value of the Burn Built-in Variables. At the moment the log just tells me that my test resolved to False and I can't tell if the value of Privileged is set to False or is undefined. I've tried testing against some of the other built-in variables and had unexpected results. With out being able to examine those variables he is hard to say if they are not being set how I expect or if I am forming my logic test incorrectly. On Mon, Jan 30, 2012 at 4:38 PM, Rob Mensching r...@robmensching.com wrote: Maybe I should be more clear. When I say something is a bug, I mean The behavior you described is not expected. That does not mean there is a bug on SourceForge tracking it. Privileged in Burn means the process was launched elevated. If you are launching Burn elevated (aka: you see the consent prompt or the process launching Burn was already elevated) and Privileged is not true, then that would be a bug. smile/ On Mon, Jan 30, 2012 at 2:49 AM, Boyd Ludlow boyd.lud...@gmail.com wrote: Rob, I just assumed that it was a bug because your response to that Stack Overflow question stated that the behaviour being seen was a bug. I didn't know enough about working with Burn to know if I was doing something wrong or if it was a problem with Burn but I accepted that you would know what you were talking about. However this is a side track. My original question still stands. Why is it that when I test against Privileged it always returns false regardless of whether I an running as an administrator or not. On Sun, Jan 29, 2012 at 4:46 AM, Rob Mensching r...@robmensching.com wrote: That's not a bug. That's a Stack Overflow question. If you really are hitting a bug, please open it so we can get details and track progress on the issue. On Fri, Jan 27, 2012 at 12:04 AM, Boyd Ludlow boyd.lud...@gmail.com wrote: As per this post http://stackoverflow.com/questions/8691061/wix-3-6-burn-bootstrapper-fails-to-elevate On Fri, Jan 27, 2012 at 4:40 AM, Bob Arnson b...@joyofsetup.com wrote: On 26-Jan-12 11:18, Boyd Ludlow wrote: I know that a bug currently exists when using burn that it errors rather than asking for elevated rights. What bug is that? -- sig://boB http://joyofsetup.com/ -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ WiX-users mailing list
Re: [WiX-users] Question from a WiX Votive newbie
Doesn't compare really at all. VDPROJ is all Designer based. pointy-clicky type stuff. :) WiX toolset is source code based, typey-typey type stuff. You can create custom dialogs (by typing in source code) but there isn't a drag and drop editor in Votive today. Some people said WixEdit did dialog designer pretty well. shrug/ Continuous integration, WiX does great. Check-in source code (.wxs files) to source control, have build machine sync and build and everything flies. smile/ But if you're looking for a designer environment, WiX doesn't provide that. Think Visual C++ not VB WinForm Designer. smile/ On Thu, Feb 2, 2012 at 6:24 PM, Michael Powell mwpowel...@gmail.com wrote: I am new to WiX Votive but not new to installers or setups by any means. Briefly, I am getting spun up on WiX as a plausible upgrade from the basic Setup (VDPROJ) project that Visual Studio 2010 offices out of the box. Can someone tell me briefly, how does it compare? Besides doing what the Setup project does by automatically detecting dependencies, generating an MSI output, folder organization, registry actions, and other custom actions... I am interested that WiX Votive supports custom dialogs? Also that it can be incorporated into a solution seamlessly during a Continuous Integration build using MSBuild is a huge plus (you don't even know...). Thank you... Best regards, Michael Powell -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn OS condition
Can you provide more context. Are you sure the condition is getting included in the Bundle? On Thu, Feb 2, 2012 at 3:08 PM, David L. Beckwith beckw...@interaccess.comwrote: I'm trying to prevent a burn application from installing on Windows 8 but without success. I've tried to set the condition in the bundle which doesn't seem to allow me to set the message. I then try setting a condition in a fragment that includes a packagedef which lets me include a message. However, either case is ignored. Here is my condition: Installed OR (Version9X or (Not VersionNT601)) -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-OS-condition-tp7248923p7248923.html Sent from the wix-users mailing list archive at Nabble.com. -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Custom Action Condition Table
Better to write your CustomActions to be data driven and use Component states to control when things get installed. That's what the WiX custom actions do so there is plenty of example code. On Thu, Feb 2, 2012 at 8:05 PM, Amit Khurana amit.khur...@gmail.com wrote: Yes. But I don't want to include these files. I would like to see simple chart which use these properties e.g. REMOVE=ALL, Installed, NOT Upgrading, NOT Uninstalling AND NOT UPGRADINGPRODUCTCODE and tell me where they are applicable. But I think I'll try to get that information from this link that you provided. Thanks very much for the link. Amit -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Custom-Action-Condition-Table-tp7246590p7249613.html Sent from the wix-users mailing list archive at Nabble.com. -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
