[WiX-users] How to detect if prevous version uninstall is triggered by RemoveExistingProducts
I would like to know if there is a way to detect what triggered a product uninstall. Issue: We have some custom actions that should NOT be triggered if the install is running in Upgrade mode. This is true for the upgrade install, but the custom actions in the previous version, that is being uninstalled by RemoveExistingProducts, do get triggered and therefore removes content that we do not removed on an upgrade install. We have the custom actions conditioned on the property WIX_UPGRADE_DETECTED, the this property only gets set in the upgrade install, not the previous version that is being uninstalled. So we need to know how the previous version is being triggered to uninstall, that it can detect, so that we can turn off the custom actions. We know if we get something that will work it would mean that it will not take affect until the current install project becomes the previous version, but at least if we get something built in now to detect this then it would work for future releases... So if there is anything that we can detect to know that the previous version is being uninstalled by an upgrade install then this would greatly help us out... Thanks, -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-to-detect-if-prevous-version-uninstall-is-triggered-by-RemoveExistingProducts-tp7600881.html Sent from the wix-users mailing list archive at Nabble.com. -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to detect if prevous version uninstall is triggered by RemoveExistingProducts
Okay I have been searching around and found the following property: UPGRADINGPRODUCTCODE I totally forgot about this property and therefore this is the one that I should be setting my custom action conditions on. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-to-detect-if-prevous-version-uninstall-is-triggered-by-RemoveExistingProducts-tp7600881p7600882.html Sent from the wix-users mailing list archive at Nabble.com. -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Uninstall running very Slow....
Nope the VM's are strictly captured snapshots and therefore no accumulative changes are applied to the images. Another thing to note is that we have our own uninstaller application that simply launch the uninstalls of our products that are selected by the user and the tester noticed that the slow down more often when doing an administration push of the uninstall in silent mode. If he pushes the uninstall in UI mode, or runs the same cmds on the local machines then the uninstalls do seem to go faster, at least that is how he sees it. I do not know how running the uninstaller in silent mode and being pushed by the admin would make much difference, that that is what he is seeing. I'll see about posting logs of the same uninstall were one is fast and the other slow to see if someone can see anything unusual. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Uninstall-running-very-Slow-tp7600812p7600826.html Sent from the wix-users mailing list archive at Nabble.com. -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Uninstall running very Slow....
Here is the download link to the uninstall logs: https://www.dropbox.com/s/5qivuotwbornc8t/UninstallLogs.zip?dl=0 -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Uninstall-running-very-Slow-tp7600812p7600828.html Sent from the wix-users mailing list archive at Nabble.com. -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Uninstall running very Slow....
Our testing department has been doing some install/uninstall testing with our products and have reported that sometimes the uninstall can be very slow at times and therefore wanted to know if we can fix these.I reviewed the logs and there were no indication of any tasks taking an overall long time to do, just consistently slow over all.I mentioned that there was not much that I could do as it was probably that their machines were busy during uninstall and therefore simply slowed down the uninstall. And I also mentioned that if the slow down was in any of our custom actions that we could at least look into them, but if any of the build in tasks were the cause of the slow down then there was not much we could do about these. They basically stated if there was any thing that we could do to detect this slow down and why as they did not accept my response that it could have just been a busy machine.So is there anything that I can do, or see in the log that would explain the slow down so that I could report back as to why the slow downs are taking place?I was given two logs of the same product being uninstalled on 2 different VM machines and one completed within 1 min where as the other completed after 45 mins.Again looking at the logs simply shows that each step of the uninstall was just taking longer to perform, ie for the FileRemove actions it took 22 seconds on the fast uninstall, where as on the slow uninstall it took 24 mins.So if someone could better explain why the uninstalls may be taking longer in some cases that I could then explain to the testing department then maybe they will know that it is not something that I can fix in the install project and therefore not report as a bug. Sure having installs/uninstalls taking way longer than expected is not a good user experience, but if there is nothing that I can actually do to fix it then what else am I suppose to do???Thanks for any input. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Uninstall-running-very-Slow-tp7600812.html Sent from the wix-users mailing list archive at Nabble.com. -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Windows Updates - either pending or running causes our installs to fail
Does anyone know of a way we can detect if there are pending Windows Updates or currently running Windows Updates?We have seen this issue quite a lot where we have 32 bit assemblies within our installs that get installed and then published near the end of the install. But if there are pending Windows updates or running Windows Updates they seem to conflict with our Assembly publish stage and therefore our installs will fail with assembly 1935 errors or simple assembly sxs errors.When these occur we get customers to run our clean up tool, verify that all Windows updates have been applied and then to re-run our installs. Once this is done the install is successful.We want to try to prevent these errors and therefore if we can detect if there are Windows Updates or updates that are running then we can have the install inform the user to finish the Windows updates before launching the install.We have seen these issues too many times and would like to find a way to prevent these install errors.So if anyone has seen these types of issues, knows how to fix them, and/or knows how to detect pending Windows updates then please let me know.Thanks. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Windows-Updates-either-pending-or-running-causes-our-installs-to-fail-tp7598536.html Sent from the wix-users mailing list archive at Nabble.com. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Shortcut creation seems to cause sxs assembly error in Event Viewer
We have some advertises and some that are not. I'll have to check if the apps to the shortcuts that are advertised are the only ones that produce sxs in the event viewer during installs. If so then I'll check to see what happens if I turn advertisement off. Thanks. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Shortcut-creation-seems-to-cause-sxs-assembly-error-in-Event-Viewer-tp7589133p7597352.html Sent from the wix-users mailing list archive at Nabble.com. -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Shortcut creation seems to cause sxs assembly error in Event Viewer
Coming back to this one just to see if there may be another reason for this issue. Again it does not prevent out apps from running at the end of the install, it is just an issue of seeing sxs errors in the Event Viewer. I checked the app .exe manifest files and yes all the assemblies that are declared as dependencies are shown and yes they are all installed and required. So I do not think this is the issue, but maybe it is causes by the MsiPublishAssemblies and when this is triggered. Now this may be the main issue, our installs that show these sxs errors are mainly our Chained .msi installs. The parent .msi install actually does not trigger the MsiPublishAssemblies until all installs are complete, so all installer that contain assemblies do not actually get published until all the children installers are complete and the parent is finishing off. So in this case can anything be done to prevent these sxs errors? As is if any of our children .msi projects launch any apps we condition them NOT to be triggered if being ran in silent mode or from the Chain as again if the assemblies are not published then the apps will fail to run because the assemblies are not published yet and therefore we get sxs errors until the full install is complete. Then apps will then work. So just verifying that there is not much that we can do here with respect to shortcut creation from .exe files that have assembly dependencies? It would be nice if the shortcut creation did not actually have to touch the .exe file, just simply create the shortcut from a .ico file and path/file name. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Shortcut-creation-seems-to-cause-sxs-assembly-error-in-Event-Viewer-tp7589133p7597219.html Sent from the wix-users mailing list archive at Nabble.com. -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://p.sf.net/sfu/Zoho ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Shortcut creation seems to cause sxs assembly error in Event Viewer
No we are not doing nested installs. Since Wix does not support an admin chain install that creates a output .msi we are using InstallShield to create our chain installs to chain all out wix install projects. We have quite a few wixlib 32 bit assemblies that we create to that gets installed and are required for a lot of out main products that we install, either standalone or chained into a suite admin installer .msi. The wixlib's use the File Id - Assembly=win32 and AssemblyManifest elements so that they are correctly registered as assemblies on the machines in the GAC. As for the shortcuts we have them defined as following: Shortcut Id=StartMenu_NB_Shortcut Directory=SMARTIconFolder Target=[INSTALLDIR]Notebook.exe Name=SMART Notebook 14 Icon=NB_ARP_Icon Show=normal WorkingDirectory=INSTALLDIR / Where Icon=NB_ARP_Icon is the Icon Id to the source .ico file. So when you say you use resource only native DLL are you referring to a dll that contains all your icon resources and you just point to the correct IconIndex? We used sort of do that, but we just pointed to the main .exe file and the correct IconIndex, but we found out that this duplicates the .exe in the installer for resources and therefore increased the sizes of our installers quite a bit, especially if the .exe files were large -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Shortcut-creation-seems-to-cause-sxs-assembly-error-in-Event-Viewer-tp7589133p7597226.html Sent from the wix-users mailing list archive at Nabble.com. -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://p.sf.net/sfu/Zoho ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Shortcut creation seems to cause sxs assembly error in Event Viewer
Yes that is basically what InstallShield is doing and again the only reason that we are still supporting this is that we still have administrators that push out our software by .msi only and therefore we had to support a multi .msi package so that they only had to push out a single .msi file instead of multiple packages. Some of our packages contain up to 30 .msi projects and therefore pushing one .msi is preferable. Now we are starting to get our admin customers to switch over to our Wrapper .exe packages that have full support for admin silent pushes and supports our full range of properties, but we have not fully got that transition in place and therefore have to continue to support the chain .msi projects. So yes it could be that the assembly registration transaction could be causing the issue if CreateShortcuts happens way before this, but then just a single .msi has the same issue where CreateShortcuts occurs before MsiPublishAssemblies and therefore it is not only the Chain that we have seen this issue. So I know that CreateShortcuts is msi Microsoft action, but what does it do that makes sxs get triggered. Does the creation of the shortcut access the .exe in someway that is triggering a sxs error because the assemblies have not been registered yet? Again it is not a big issue as after install all apps work as expected, it is only when there are issues and when we ask the customers for logs and what not we see these sxs errors and it just does not look good and the install gets blamed for a lot of issues, some of which like these ones we can not do anything about. At least not that we have found... -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Shortcut-creation-seems-to-cause-sxs-assembly-error-in-Event-Viewer-tp7589133p7597237.html Sent from the wix-users mailing list archive at Nabble.com. -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://p.sf.net/sfu/Zoho ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Help using PIDKEY + MaskedEdit + PIDTemplate
Joe, did you ever get the MaskedEdit control to only accept Upper/Lower case letters and numbers? I am trying the same thing and I just want the MaskedEdit to only access the same thing, but at the moment it will accept all characters and then I have to create conditions/CA to validate to make sure the format is correct. But if there is a simple MaskedEdit element that only lets the user enter Upper/Lower case letters and numbers that would be great. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Help-using-PIDKEY-MaskedEdit-PIDTemplate-tp697581p7596782.html Sent from the wix-users mailing list archive at Nabble.com. -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] PIDTemplate w/ MaskedEdit
No the Visual Basic MaskedEdit may support uppercase 'A', but the WiX MaskedEdit does not. I tried it anyways I set the MaskedEdit Text control to: A-A-A-A and when I ran the install the entry field was set to A-A-A-A. So definitely did not work... Since we would like to support Upper case and numbers I tried: ^-^-^-^ And it again allowed for any characters to be entered and when finished it did not convert any letters to upper case. So MaskedEdit does not look good for mixed PID entries... without having to go outside of the box and creating custom action that will convert lower case to upper case and validate that only letters and numbers are entered... From: Phil Wilson [via Windows Installer XML (WiX) toolset] [mailto:ml-node+s687559n7596768...@n2.nabble.com] Sent: Thursday, September 11, 2014 11:55 AM To: Tim Mayert Subject: Re: PIDTemplate w/ MaskedEdit According to this: http://msdn.microsoft.com/en-us/library/aa733654(v=vs.60).aspx all uppercase A might be what you need. --- Phil Wilson On Tue, Sep 9, 2014 at 2:30 PM, TimM [hidden email]/user/SendEmail.jtp?type=nodenode=7596768i=0 wrote: Okay I have another question about the masked edit field. If we have a PID that contains only letters and numbers then is there a maskededit setting that will ONLY allow this mix of characters or is this something that it can not handle and therefore other actions would have to be used to validate the entries? -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/PIDTemplate-w-MaskedEdit-tp4815087p7596737.html Sent from the wix-users mailing list archive at Nabble.com. -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce. Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ WiX-users mailing list [hidden email]/user/SendEmail.jtp?type=nodenode=7596768i=1 https://lists.sourceforge.net/lists/listinfo/wix-users -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ WiX-users mailing list [hidden email]/user/SendEmail.jtp?type=nodenode=7596768i=2 https://lists.sourceforge.net/lists/listinfo/wix-users If you reply to this email, your message will be added to the discussion below: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/PIDTemplate-w-MaskedEdit-tp4815087p7596768.html To unsubscribe from PIDTemplate w/ MaskedEdit, click herehttp://windows-installer-xml-wix-toolset.687559.n2.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=4815087code=VGltTWF5ZXJ0QHNtYXJ0dGVjaC5jb218NDgxNTA4N3wtMTcxMzc3MTUwNA==. NAMLhttp://windows-installer-xml-wix-toolset.687559.n2.nabble.com/template/NamlServlet.jtp?macro=macro_viewerid=instant_html%21nabble%3Aemail.namlbase=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespacebreadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/PIDTemplate-w-MaskedEdit-tp4815087p7596785.html Sent from the wix-users mailing list archive at Nabble.com. -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Getting the lenght of string in Edit/MaskedEdit field
I have a MaskedEdit control that can either be blank or filled in. If blank then next button will continue, but if any characters are entered then I only want it to continue if all the required characters are filled in. So is there some built in method to validate that all characters have been filled in or do I actually have to create a custom action that will validate that all the characters have been filled in? -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Getting-the-lenght-of-string-in-Edit-MaskedEdit-field-tp7596787.html Sent from the wix-users mailing list archive at Nabble.com. -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] PIDTemplate w/ MaskedEdit
Okay I have another question about the masked edit field. If we have a PID that contains only letters and numbers then is there a maskededit setting that will ONLY allow this mix of characters or is this something that it can not handle and therefore other actions would have to be used to validate the entries? -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/PIDTemplate-w-MaskedEdit-tp4815087p7596737.html Sent from the wix-users mailing list archive at Nabble.com. -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce. Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Where to get the ClassicTheme.xml/wxl Bootstrapper files?
I am updating the WiX 3.8 to see the differences in the updated Bootstrapper and therefore I am looking at the following page: https://classicwixburntheme.codeplex.com/wikipage?title=Guide%201referringTitle=Documentation Just to follow the example it states to download 1033.zip and extract the ClassicTheme files. It just does not state where to get this 1033.zip file from. So where can I get this 1033.zip file, as well as any of the other language files that contain these ClassicTheme files? -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Where-to-get-the-ClassicTheme-xml-wxl-Bootstrapper-files-tp7596697.html Sent from the wix-users mailing list archive at Nabble.com. -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn built-in variables question
Sorry, Rob but I am still at a loss here as how what I would need to update to be able to get the values of these environment variables into the WiX burn bootstrapper that then get passed to my .msi installer. Again I am not up to date with programming skills and therefore having to update code is not as easy a task for me then it is for others to do.. So again any help that would make it easier for me to accomplish this would be great. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-built-in-variables-question-tp7596676p7596699.html Sent from the wix-users mailing list archive at Nabble.com. -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn Bootstrapper run executable on exit
Okay so it is not as easy as adding a new control to the Success Page in the theme because as stated I did that and it shows no problem, but have basically no control over this and it's execution. So the actions that were on the Launch button has to be switched actions that get triggered only if this checkbox is checked as well as the Finish button would have to be enabled to call this custom action and then exit the install. So does this mean that if I want this checkbox and Finish button to actually do anything then I have to create a custom BootstrapperApplication so that I can interact with this checkbox and button? I was hoping that it was simply adding a check box and then updating the custom action trigger to only be triggered if the checkbox was checked... So if I am missing some steps to where I do NOT need to create a special custom made BootstrapperApplication then I would really like to know what I have to do. If I have to create a custom BootstrapperApplication then where is the code that I can would have to try and understand and figure out what would have to change so that if the checkbox is checked that it would launch the app and exist the install at the end? -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-Bootstrapper-run-executable-on-exit-tp7580830p7596700.html Sent from the wix-users mailing list archive at Nabble.com. -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Where to get the ClassicTheme.xml/wxl Bootstrapper files?
Thanks Rob, I'll do that. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Where-to-get-the-ClassicTheme-xml-wxl-Bootstrapper-files-tp7596697p7596704.html Sent from the wix-users mailing list archive at Nabble.com. -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn built-in variables question
Yes I already do this, but I was trying to get the value so that it could be appended to a property that gets passed to the main installer. Since what gets passed to the install will override what defaults gets set in main install those and therefore you lose the entries. I'll figure something out that involves the least amount of extra work on my side.. Thanks. From: Rob Mensching-7 [via Windows Installer XML (WiX) toolset] [mailto:ml-node+s687559n7596702...@n2.nabble.com] Sent: Monday, September 08, 2014 10:24 AM To: Tim Mayert Subject: Re: Burn built-in variables question Neither Burn nor wixstdba read environment variables so you'd need to write code to do that. In WiX v3.8 you could maybe write a BA function (though I've never tried that myself). Although if you're just going to pass it to the MSI, why not have the MSI get the variable. Windows Installer reads environment variables. _ Short replies here. Complete answers over there: http://www.firegiant.com/ -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ WiX-users mailing list [hidden email]/user/SendEmail.jtp?type=nodenode=7596702i=0 https://lists.sourceforge.net/lists/listinfo/wix-users If you reply to this email, your message will be added to the discussion below: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-built-in-variables-question-tp7596676p7596702.html To unsubscribe from Burn built-in variables question, click herehttp://windows-installer-xml-wix-toolset.687559.n2.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=7596676code=VGltTWF5ZXJ0QHNtYXJ0dGVjaC5jb218NzU5NjY3NnwtMTcxMzc3MTUwNA==. NAMLhttp://windows-installer-xml-wix-toolset.687559.n2.nabble.com/template/NamlServlet.jtp?macro=macro_viewerid=instant_html%21nabble%3Aemail.namlbase=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespacebreadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-built-in-variables-question-tp7596676p7596705.html Sent from the wix-users mailing list archive at Nabble.com. -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn Bootstrapper run executable on exit
Oh and one more thing about customizing the burn bootstrapper theme files. I figured that if it was too much work to simply add a checkbox on the success screen and have it set to launch the app on finish, I figured that maybe just add a text control at the bottom that then informs the user what the Launch button will do and therefore they can choose to click on Launch to launch our tool or Close to finish the install. Again this works, but then during uninstall this text also shows up and therefore it would be great if we have a bit more control over added controls in the theme file so that we could easily condition controls so that they show on Not Installed only. So again if I am missing something that actually does this then let me know where I am going wrong. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-Bootstrapper-run-executable-on-exit-tp7580830p7596718.html Sent from the wix-users mailing list archive at Nabble.com. -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn Bootstrapper run executable on exit
Yes this all works and all, but is there no way that we can have say some text with a description of what will be launched? I have a WiX .msi installer that contains all the standard and custom UI that we need and it contains the check box at the end of the install for the user to launch our admin tool. This all works great but since it is only a .msi we decided that it would be better to have a setup .exe output. Do do this we are trying out Burn to call this one .msi and therefore we are trying to disable all UI from Burn so that it all comes from the .msi. But now it is this check box on the finish dialog of the msi that did not see correct. So we turned that one off and placed the launch code to launch at end of the Burn .exe. This works but it just has a basic finish dialog box with an extra button called Launch. There is not indication what this is launching and therefore is there anyway to display the checkbox text that we used for the end of the .msi or do we have to live with what is currently supplied? -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-Bootstrapper-run-executable-on-exit-tp7580830p7596673.html Sent from the wix-users mailing list archive at Nabble.com. -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Burn built-in variables question
There are a bunch of Burn built-in variables that we can use, but if what I want is not included in that list then how can I go about declaring a new variable that gets a standard environment variable? Basically what I need is to get the %USERDNSDOMAIN and %USERDOMAIN environment variables and append those values on to some Variable Names that I have declared. I have just tried: Variable Name=DNS Type=string Value=[%USERDNSDOMAIN] / Variable Name=UserDomain Type=string Value=[%USERDOMAIN] / But this will simply set those variables to [%USERDNSDOMAIN] and [%USERDOMAIN]. So is there a way to get the value of these environment variables and place them into variable names that I can then use to append to other variables that get pushed to the chained msi? -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-built-in-variables-question-tp7596676.html Sent from the wix-users mailing list archive at Nabble.com. -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn built-in variables question
Thanks Rob... Since I have not yet had to do any Burn customization is there any samples that would help me get started on how to customizing the BootstrapperApplication? Thanks. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-built-in-variables-question-tp7596676p7596685.html Sent from the wix-users mailing list archive at Nabble.com. -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn Bootstrapper run executable on exit
Okay I was able to generate a check box field at the end of the bootstrapper, but now I need to know how it actually gets triggered to launch the app? Here is what I have in the theme file: Page Name=Success Text X=11 Y=80 Width=-11 Height=30 FontId=2 DisablePrefix=yes#(loc.SuccessHeader)/Text Checkbox Name=LaunchCheckbox X=11 Y=121 Width=260 Height=17 TabStop=yes FontId=3 HideWhenDisabled=yes#(loc.LaunchAppCheckbox)/Checkbox Button Name=OptionsOkButton X=-91 Y=-11 Width=75 Height=23 TabStop=yes FontId=0#(loc.OptionsOkButton)/Button Text Name=SuccessRestartText X=-11 Y=-51 Width=400 Height=34 FontId=3 HideWhenDisabled=yes DisablePrefix=yes#(loc.SuccessRestartText)/Text Button Name=SuccessRestartButton X=-91 Y=-11 Width=75 Height=23 TabStop=yes FontId=0 HideWhenDisabled=yes#(loc.SuccessRestartButton)/Button Button Name=SuccessCancelButton X=-11 Y=-11 Width=75 Height=23 TabStop=yes FontId=0#(loc.SuccessCloseButton)/Button /Page Now the way have this it will create a un-checked check box and I also commented out the LaunchButton code and placed a OptionsOkButton control there. So it looks okay, but checking the check box does nothing at the moment and the OK button also does nothing. The finish dialog goes blank after hitting the OK button and then I have to close it by clicking on the 'X'. So how do I enable the buttons/checkbox to do what I need. Oh and on uninstall the checkbox also shows up so how to prevent that as well? Thanks again for any and all help. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-Bootstrapper-run-executable-on-exit-tp7580830p7596688.html Sent from the wix-users mailing list archive at Nabble.com. -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] [Light] light.exe error LGHT0001: Cannot create a file when that file already exists.
We are randomly get having out WiX builds fail with the following: [Light] light.exe error LGHT0001: Cannot create a file when that file already exists. The log does not indicate what file it is complaining about and I have not seen any other reports of this error in the groups. Has anyone seen this error and/or how to prevent this error from occurring? We are still working with WiX 3.7 Thanks. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Light-light-exe-error-LGHT0001-Cannot-create-a-file-when-that-file-already-exists-tp7596363.html Sent from the wix-users mailing list archive at Nabble.com. -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] [Light] light.exe error LGHT0001: Cannot create a file when that file already exists.
Thanks Phill, I do not think someone would have been on the TeamCity build machine opening up files at the times of the failures, so that should rule out that case. We have a build step that will generate a new Product Code for the product and replace the one in the WiX projects, but that again should not have caused this and that step occurs first out of 7 steps and the build failure occurs on the 6th step during the building of the main solution file that builds all the products and the install build is the last step of that solution. So I do not think that it could be that. Now maybe it has to do with this being a CI build. Our full nightly builds do not seem to have this issue. It is only the incremental builds that occur every time someone checks in new/updated code, but again randomly. So, just guessing here, maybe a build was already at the install step and then another CI build was triggered off and therefore some files in use at that time??? Anyways is there anything else that we could be looking for to determine out the main cause of this failure? I could possibly take the build of the WiX project out of the main solution and simply create a new build step that starts after the main solution file is built and that way it will eliminate the main solution and what is being built in it from being the or part of the issue. Thanks, Tim. From: Phill Hogland [via Windows Installer XML (WiX) toolset] [mailto:ml-node+s687559n7596365...@n2.nabble.com] Sent: Thursday, August 14, 2014 11:17 AM To: Tim Mayert Subject: Re: [Light] light.exe error LGHT0001: Cannot create a file when that file already exists. I get this error when the output file (bundle.exe, msipackage.msi, or library.wixlib, depending on the type of project) is open in another process, like Orca. So for me it is not random. Is your build process trying to do something with the prior version of the output file, as the project is being built? If you reply to this email, your message will be added to the discussion below: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Light-light-exe-error-LGHT0001-Cannot-create-a-file-when-that-file-already-exists-tp7596363p7596365.html To unsubscribe from [Light] light.exe error LGHT0001: Cannot create a file when that file already exists., click herehttp://windows-installer-xml-wix-toolset.687559.n2.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=7596363code=VGltTWF5ZXJ0QHNtYXJ0dGVjaC5jb218NzU5NjM2M3wtMTcxMzc3MTUwNA==. NAMLhttp://windows-installer-xml-wix-toolset.687559.n2.nabble.com/template/NamlServlet.jtp?macro=macro_viewerid=instant_html%21nabble%3Aemail.namlbase=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespacebreadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Light-light-exe-error-LGHT0001-Cannot-create-a-file-when-that-file-already-exists-tp7596363p7596366.html Sent from the wix-users mailing list archive at Nabble.com. -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Custom Dialog box edit controls and setting Alt hotkeys
This could be a simple question, but at the moment I just can not see it... For push buttons and check boxes we just add the amp; in front of the character that we want set for controls Alt hotkey, but if you have Edit and MaskedEdit controls how do you set it's controls Alt hotkey? Thanks. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Custom-Dialog-box-edit-controls-and-setting-Alt-hotkeys-tp7595958.html Sent from the wix-users mailing list archive at Nabble.com. -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Custom Dialog box edit controls and setting Alt hotkeys
It was a request from one of our managers as they noticed that they can use Alt-Hotkey on the Change Directory dialog box, even though this is a built-in MS dialog box. But that dialog box can do it so they wanted in in the main installer as I have a Custom Dialog box that has 5 edit controls and they would like to Alt-hotkey to set focus to each one. If there is nothing built into WiX that can support this then I can convince them to just use the Tab instead of the Alt-hotkey method. Thanks. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Custom-Dialog-box-edit-controls-and-setting-Alt-hotkeys-tp7595958p7595960.html Sent from the wix-users mailing list archive at Nabble.com. -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Custom Dialog box edit controls and setting Alt hotkeys
No I have not tried that so I'll give it a try. Thanks. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Custom-Dialog-box-edit-controls-and-setting-Alt-hotkeys-tp7595958p7595962.html Sent from the wix-users mailing list archive at Nabble.com. -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Custom Dialog box edit controls and setting Alt hotkeys
Okay thanks Rob that did the trick. I had to make sure the static text controls had Tabskip set to 'no' though to get it working. But all good now -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Custom-Dialog-box-edit-controls-and-setting-Alt-hotkeys-tp7595958p7595969.html Sent from the wix-users mailing list archive at Nabble.com. -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Install fails to detect .NET 4.5 or greater on system
My condition is: Again we are still at WiX 3.7 so will not be able to look at the 3.8 functionality until we move to that version in our build environment. I have not yet looks into the registry keys, but I guess that I should if we support 4.5, but most of the machines that we will be installing on will have 4.5.1 and therefore if the 3.7 NETFRAMEWORK45 check only detect 4.5 and therefore will not validate 4.5.1 then I'll need manually verify that one. Thanks, Tim. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Install-fails-to-detect-NET-4-5-or-greater-on-system-tp7595756p7595770.html Sent from the wix-users mailing list archive at Nabble.com. -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] PIDTemplate w/ MaskedEdit
Okay now I am experiencing another issue with this. Since I have set my Text to # so that I can accept values from 1 to 9 it is actually back filling my property with spaces if I enter less than 5 numbers. So if I enter '34' the property would end up being '34 ', meaning the string now has 3 spaces behind the 34. So is there any way to prevent this or will I have to then create a custom action dll just to strip off the extra spaces that it is placing on the end of my entry? -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/PIDTemplate-w-MaskedEdit-tp4815087p7595777.html Sent from the wix-users mailing list archive at Nabble.com. -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Install fails to detect .NET 4.5 or greater on system
That's the think though, I checked the install log after it failed to find .NET 4.5 and the NETFRAMEWORK45 property was not generated at all. So if in WiX 3.7 it will detect 4.5 and greater then it should have at least created that property with the version that it found. So why did it not do that for my install? -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Install-fails-to-detect-NET-4-5-or-greater-on-system-tp7595756p7595780.html Sent from the wix-users mailing list archive at Nabble.com. -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Install fails to detect .NET 4.5 or greater on system
Yes, I should have netfx linked in. It shows in my project References and it is listed at the top of my wix project: ?xml version=1.0 encoding=UTF-8? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; xmlns:netfx=http://schemas.microsoft.com/wix/NetFxExtension; Now we build through msbuild - building the main solution file so would this be an issue as it has never caused any issues with any of the other Wix extensions that have been added to our projects and built through msbuild? Here is the install log to indicate that the NETFRAMEWORK45 property does not get created: MSIc7937.LOG http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/file/n7595786/MSIc7937.LOG -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Install-fails-to-detect-NET-4-5-or-greater-on-system-tp7595756p7595786.html Sent from the wix-users mailing list archive at Nabble.com. -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Install fails to detect .NET 4.5 or greater on system
Well I feel like an Idiot I was declaring Property Id=NETFRAMEWORK45 / and missed the Ref part of it and did not even noticed after all the examples that I looked at Sorry for all the hassles that I put you through. I'll give it another shot and more than likely it will work now.. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Install-fails-to-detect-NET-4-5-or-greater-on-system-tp7595756p7595789.html Sent from the wix-users mailing list archive at Nabble.com. -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Install fails to detect .NET 4.5 or greater on system
Okay changing the property to PropertyRef fixed the issue. The MsiNetAsseblySupport = 4.0.30319.33440 The NETFRAMEWORK45 = #378675 Which means that what is installed is: 4.5.51641 So I am good to go. Thanks for all the help. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Install-fails-to-detect-NET-4-5-or-greater-on-system-tp7595756p7595797.html Sent from the wix-users mailing list archive at Nabble.com. -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] PIDTemplate w/ MaskedEdit
Thanks John. After a bit of frustration I finally figured out my issue, it was one of my conditions on the publish events that was screwing me up. Now that I fixed that I can correctly enter 1 to 5 numbers and have it do what I expected it to do -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/PIDTemplate-w-MaskedEdit-tp4815087p7595752.html Sent from the wix-users mailing list archive at Nabble.com. -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] PIDTemplate w/ MaskedEdit
I was actually using a PORT_NUMBER 0 conditions before I switched to MaskedEdit and therefore once I switched I did not remove that condition as the mask # does not accept negative numbers and therefore I did not need that condition. Once I removed it then it began to work as expected. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/PIDTemplate-w-MaskedEdit-tp4815087p7595755.html Sent from the wix-users mailing list archive at Nabble.com. -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Install fails to detect .NET 4.5 or greater on system
I have seen many WiX articles on detecting .NET 4.5 or greater and I have implemented the recommended entires, but my install will FAIL to detect .NET 4.5 on machines that have .NET 4.5 and 4.5.1. Now we are still using WiX 3.7, and therefore if the machine has .NET 4.5.1 does the NETFRAMEWORK45 not get set properly in that version of Wix? So here are the relevant entries: ?xml version=1.0 encoding=UTF-8? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; xmlns:netfx=http://schemas.microsoft.com/wix/NetFxExtension; Product Id=* Name=$(var.ProductName) Language=1033 Version=$(var.ProductVersion) Manufacturer=$(var.Manufacturer) UpgradeCode=F4472484-91DD-43E3-B998-FA5BD4099B72 Package InstallerVersion=400 Compressed=yes InstallScope=perMachine InstallPrivileges=elevated Description=$(var.ProductName) / Property Id=NETFRAMEWORK45 Secure=yes / Condition Message=This setup requires Microsoft .NET Framework 4.5 or greater needs to be installed for this installation to continue. /Condition So am I missing something or since we are still on Win 3.7 we will have to add some manual searches for machines running .NET 4.5.1? Thanks for any help on this issue. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Install-fails-to-detect-NET-4-5-or-greater-on-system-tp7595756.html Sent from the wix-users mailing list archive at Nabble.com. -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] PIDTemplate w/ MaskedEdit
Thanks John, but yes I have seen that article and it still does not explain how you can enter 1 to 5 numbers in the field. If I change enter 1, 11, 111, the next but will fail to do anything, but if I enter 1 then the install will proceed as expected. So it seems that if the text field has 5 - # then you have to enter 5 numbers. So is there a way to format it so that you can enter any amount of numbers only and that it would only fail if it is empty? -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/PIDTemplate-w-MaskedEdit-tp4815087p7595733.html Sent from the wix-users mailing list archive at Nabble.com. -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] PIDTemplate w/ MaskedEdit
I am trying to do a MaskedEdit control that can contain 0-9, so I set the text to # and I have a default of 2279. When test the dialog box the Next button will do nothing until I enter 5 numbers in the MaskedEdit control. So what am I supposed to set the text field to so that I can enter only numbers and can have from 1 to 5 numbers entered into that field? -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/PIDTemplate-w-MaskedEdit-tp4815087p7595725.html Sent from the wix-users mailing list archive at Nabble.com. -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Is using Powershell script as a Wix Custom Action a good idea?
Piping in a little later here, as had no requirements for PowerShell custom actions but now do. Our product team is developing a Server app and require a bunch of PowerShell actions to be ran, some only require triggering commands that are used to log server info, but others are more detailed/complicated. So what I need to know, currently using WiX 3.7, is if it is best for the developers to simply create the PowerShell *.ps1 file or files and therefore I just have to have a custom action that calls them with parameters, or can the PS script be embedded in to the WiX fragments. Again I have no experience with PS and therefore would like to keep it simple or at least have the least amount of failure points in the install? Is there any good examples that show PS custom actions and/or embedding actions within the WiX installer? Thanks. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Is-using-Powershell-script-as-a-Wix-Custom-Action-a-good-idea-tp7584243p7595699.html Sent from the wix-users mailing list archive at Nabble.com. -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Is using Powershell script as a Wix Custom Action a good idea?
Thanks for the information John. I'll prompt the developers on if they know what modes the servers will be ran under, but I would figure that it would be Restricted. I do not have much/any experience in creating C#, so are you suggesting a wrapper .exe or custom action dll, which would therefore have to be a .msi based custom action dll as we need to pass in/get access to some properties that are entered by the admin during install to be pass into some of these PowerShell commands. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Is-using-Powershell-script-as-a-Wix-Custom-Action-a-good-idea-tp7584243p7595705.html Sent from the wix-users mailing list archive at Nabble.com. -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] building wixlib project with included wixlib references fail
Is it possible to reference a wixlib within a wixlib project? I am re-asking this as I had no responses to the inquiry I posted back in January: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Problems-with-referencing-wixlibs-within-a-wixlib-project-td7591687.html It has been a while since that post and I had actually forgotten about it as I must have simply removed the wixlib reference in the wixlib and just added it to the parent install project. But now another developer in our installer group has ran into the same thing with the same error and therefore the question comes back as to why when building a wixlib project that contains a wixlib reference that it fails to find files within the referenced wixlib, even though the files are correctly binded in the wixlib? So if any one knows how to get this to work that would be great as if not then we'll have to use work arounds, like referencing the wixlibs within the parent projects. And remember to do that for every project that requires the main wixlib. Thanks for any help. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/building-wixlib-project-with-included-wixlib-references-fail-tp7595435.html Sent from the wix-users mailing list archive at Nabble.com. -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Multi-language WiX installer to display different EULA's
I have looks at the WiX 3 Tutorial: Custom EULA License and MSI localization: http://weblogs.sqlteam.com/mladenp/archive/2010/04/15/WiX-3-Tutorial-Custom-EULA-License-and-MSI-localization.aspx And see how they had to actually modify the LicenseAgreementDialog.wxs file to accomplish this, but as stated it is a bit more work for armature WiX developers that would then have to start modify built in UI dialog boxes and sequencing. Would it not been a lot better to simply have the original built in LicenseAgreementDialog code updated to simply accept what ever value was set to the WiXUILicenseRtf variable? That way WiX developers, that support multiple languages could simply add the localization string variable, that points to their translated EUAL, and simply place that variable for the WiXUILicenseRtf variable. ie it should have been able to accept any of the following for the variable: WixVariable Id=WixUILicenseRtf Value=$(var.EULAfile) / WixVariable Id=WixUILicenseRtf Value=!(loc.EULAfile) / WixVariable Id=WixUILicenseRtf Value=..\..\Licenses\license.rtf / I do not know how hard it would be to update the original to support this so that WiX developers have a bit more flexibility without having to modify, maintain, and work with customized UI that should be standard in WiX. We tend to create a lot of our installs without UI as we wrapper our .msi files within wrappers .exe files that contain all the UI we need, but in the small occasion that we do have to use UI in the .msi we prefer to simply use the standard build in UI and therefore having to add/modify standard UI just for something as simply as supporting different languages EULA files that should have been supported is more work for a simple installer. Anyways enough of my ranting and thoughts on the multi-language subject If there are any updates to the standard UI that better supports multiple languages that would be great -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Multi-language-WiX-installer-to-display-different-EULA-s-tp7595052.html Sent from the wix-users mailing list archive at Nabble.com. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Multi-language WiX installer to display different EULA's
Thanks Rob. No I have not seen this. I am definitely not a high end developer as I do mostly install related development, but with that said I could always have a sand boxed look at the code and see if I can figure out how to implement and test. What would I need to be able to look at/modify/build and test with respect to License box changes? Thanks, Tim. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Multi-language-WiX-installer-to-display-different-EULA-s-tp7595052p7595056.html Sent from the wix-users mailing list archive at Nabble.com. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Multi-language WiX installer to display different EULA's
Okay, since for now I have to use the modify method for the License dialog found another issue that would be nice if it could be supported as well. In the tutorial the set the following in the language string files: String Id=LicenseRtf Overridable=yes\Lang\en-us\EULA_en-us.rtf/String But my path to the EULA's was declared in a variable property that I wanted to use and therefore I tried the following: String Id=LicenseRtf Overridable=yes$(var.EULA_Pah)\lang\en-us\EULA_en-us.rtf/String When building I get an error stating that it could not find the file in the following location: $(var.EULA_Pah)\lang\en-us\EULA_en-us.rtf So during the build it did not substitute the actually path for $(var.EULA_Path), it used it literally. So this would be another nice to have if we use variable names in the language string file that they get correctly substituted... -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Multi-language-WiX-installer-to-display-different-EULA-s-tp7595052p7595077.html Sent from the wix-users mailing list archive at Nabble.com. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Which is best to use in my case: XmlFile or XmlConfig?
Okay I do have this working now, but have one more question on this... If the element keys exists and you only have to change the values then we can simply use the XmlFile action=setvalue method. If the element keys do not exist then I had to use the XmlFile action=createElement and a few setValue entries to get it to work. So my question is if there is a way to determine if the element key exists or not so that if it needs creating then the correct method is used? Or is there a method that can be used in both cases where if it does exist then it will simply modify the value, but if it does not exist it will create it and set the correct value? Thanks. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Which-is-best-to-use-in-my-case-XmlFile-or-XmlConfig-tp7594691p7594922.html Sent from the wix-users mailing list archive at Nabble.com. -- The best possible search technologies are now affordable for all companies. Download your FREE open source Enterprise Search Engine today! Our experts will assist you in its installation for $59/mo, no commitment. Test it for FREE on our Cloud platform anytime! http://pubads.g.doubleclick.net/gampad/clk?id=145328191iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Passing command line arguments to an app launched after setup
Bob, what was the 'normal' custom action that you used at the end of the install to launch your app with arguments? I was also using LaunchApplication to trigger the launch of my application at the end of the UI by check box selection, but I also needed to supply arguments and therefore it did not work. I was just searching for 'launch app at end of install' and that was the main one I found and therefore did not see any entries for this 'normal' custom action. So if you can give me a little example of this 'normal' CA that would be great.. Thanks. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Passing-command-line-arguments-to-an-app-launched-after-setup-tp1366362p7594862.html Sent from the wix-users mailing list archive at Nabble.com. -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Launch exe after install WITH Command line
This does not work if the file you want launched is installed through a merge module or wixlib as you can not specify the FileKey to an Id that does not exist in your main wxs project. So what other methods are there to launch an installed app at the end of the install that requires arguments that are needed? -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Launch-exe-after-install-WITH-Command-line-tp6088067p7594866.html Sent from the wix-users mailing list archive at Nabble.com. -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Which is best to use in my case: XmlFile or XmlConfig?
Okay still having an issue with util:XmlConfig. If I use the following:
Component Id=ProgramComponent
Guid={68FCE723-347D-4FD9-A3DF-3BB5A961F0E0}
File Id=sample.config Source=sample.config Vital=yes DiskId=1/
util:XmlFile Id=ModifyServiceLocation Action=setValue
ElementPath=/configuration/appSettings/add[\[]@key='ServiceLocation'[\]]/@value
File=[#sample.config]
Value=[LYNC_SERVER_ADDRESS]/
util:XmlConfig Id=SetClientMode Action=create
ElementPath=//configuration/appSettings
File=[#sample.config] Name=ClientMode
Node=value On=install
PreserveModifiedDate=yes Sequence=100
Value=[CLIENT_MODE] /
/Component
Then the install will work and no errors, the .config file will look like
the following:
configuration
appSettings ClientMode=Personal
add key=ServiceLocation
value=net.tcp://example.com:54321/RemoteInk/
/appSettings
/configuration
As you can see the ClientMode is in the wrong location, it should look like
this:
configuration
appSettings
add key=ServiceLocation
value=net.tcp://example.com:54321/RemoteInk/
add key=ClientMode value=Personal/
/appSettings
/configuration
So if I change the util:XmlConfig line to the following then I get the
'Failed to find node:' error:
util:XmlConfig Id=SetClientMode Action=create
ElementPath=//configuration/appSettings/add[\[]@key='ClientMode'[\]]/@value
File=[#sample.config] Name=ClientMode Node=value On=install
PreserveModifiedDate=yes Sequence=100 Value=[CLIENT_MODE] /
Now the util:XmlFile element does work, but only for element keys that
already exist and you only need to change the value on, but if the element
key does not exist then XmlFile does not work. So we have to use the
XmlConfig element and therefore I need to get this working...
So if anyone can tell me what is wrong with my XmlConfig element line I
would appreciate it.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Which-is-best-to-use-in-my-case-XmlFile-or-XmlConfig-tp7594691p7594754.html
Sent from the wix-users mailing list archive at Nabble.com.
--
Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free.
http://p.sf.net/sfu/SauceLabs
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Which is best to use in my case: XmlFile or XmlConfig?
Okay do you have a small example of using XmlConfig to create and set the value of a key, as I was also trying XmlConfig and I did not get any errors, but it did not do anything to the .config file? Thanks. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Which-is-best-to-use-in-my-case-XmlFile-or-XmlConfig-tp7594691p7594730.html Sent from the wix-users mailing list archive at Nabble.com. -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Which is best to use in my case: XmlFile or XmlConfig?
Okay newbie question here concerning the updating of a .config file during install, using WiX 3.7. I was given the task to update a new .config file during our install and I found the documentation for XmlConfig Element (Util Extension): http://wixtoolset.org/documentation/manual/v3/xsd/util/xmlconfig.html And XmlFile Element (Util Extension): http://wixtoolset.org/documentation/manual/v3/xsd/util/xmlfile.html Now I have never used these before and have not updated a .xml file during install so I was trying to find examples for these. There are a few examples out there, but the one problem I am running into is the ElementPath entry. I have not found out how it is set, meaning what values are expected and where do you get or know what the values are suppose to be... So how do I find out what I am supposed to enter in for ElementPath and should I be using Xmlfile or Xmlconfig? The information I was given to update the .config file was only: Add 2 keys to the .config file: 1. ServiceInfo with value of [LYNC_SERVER_ADDRESS] 2. ClientMode with value of [CLIENT_MODE] - can be one of 3 values - Room, Personal, or Thin I was also given an example of the key,value pairs in the application .config file: configuration ... appSettings ... add key=ServiceInfo value=LYNC_SERVER_ADDRESS / add key=ClientMode value=Room / /appSettings /configuration So can anyone help me in how this is configured in my WiX project and how I determine what the ElementPath should be or how I can get the information to know how it should be set? Thanks for any and all help that can be provided. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Which-is-best-to-use-in-my-case-XmlFile-or-XmlConfig-tp7594691.html Sent from the wix-users mailing list archive at Nabble.com. -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Which is best to use in my case: XmlFile or XmlConfig?
Okay I tried the following: util:XmlConfig Id=ServiceInfo Action=create ElementPath=/configuration/appSettings/ Name=ServiceInfo Value=[LYNC_SERVER_ADDRESS] File=[INSTALLDIR]RemoteInk.exe.config On=install Sequence=9 / This one did nothing at all, no errors, but did not update file. So I tried the following: util:XmlFile Id=ServiceInfo Action=setValue ElementPath=/configuration/appSettings Name=ServiceInfo Value=[LYNC_SERVER_ADDRESS] File=[INSTALLDIR]RemoteInk.exe.config / And this one did create the entry, but not how I was expecting it to be created. Above is what I wanted/needed, but what was created with this line is as follows: configuration ... appSettings ServiceInfo=net.tcp://example.com:54321/RemoteInk /configuration So first it placed it on the same line as the start of the appSettings element and 2nd it is not in the format that I wanted, which should have been: add key=ServiceInfo value=net.tcp://example.com:54321/RemoteInk / So again has anyone created new entries in an application .config file and if so then could you let me know what I am doing wrong or missing altogether? -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Which-is-best-to-use-in-my-case-XmlFile-or-XmlConfig-tp7594691p7594699.html Sent from the wix-users mailing list archive at Nabble.com. -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Which is best to use in my case: XmlFile or XmlConfig?
Okay I am re-looking at the XmlConfig method as described in the following link: http://sourceforge.net/p/wix/mailman/message/20326106/ And when I use the example that is in that link I get the following failure in the install: Failed to find node: //configuration/appSettings/add[@key='ServiceInfo'] in XML file: C:\Program Files (x86)\CompanyName\Product\Product.exe.config, system error: -2147020584 So I have some configuration wrong to get this error, but what is it??? Has anyone used the Util:XmlConfig element to update/add data to an app.config file? Again any help would be appreciated... -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Which-is-best-to-use-in-my-case-XmlFile-or-XmlConfig-tp7594691p7594701.html Sent from the wix-users mailing list archive at Nabble.com. -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Updating app.config
I have just been given a task to update one of our apps .config file and so I tried what was listed in this topic but I am getting the following error: Failed to find node: //configuration/appSettings/add[@key='ServiceInfo'] in XML file: C:\Program Files (x86)\CompanyName\Product\Product.exe.config, system error: -2147020584 Here is my code: Component Id=EditConfigFile Guid= KeyPath=yes util:XmlConfig Id=SetServiceInfo Action=create Node=value Name=ServiceInfo ElementPath=//configuration/appSettings/add[\[]@key='ServiceInfo'[\]] VerifyPath=//configuration/appSettings/add[\[]@key='ServiceInfo'[\]] Sequence=10 File=[INSTALLDIR]RemoteInk.exe.config On=install Value=[LYNC_SERVER_ADDRESS] / /Component Here is what the .config file is supposed to look like after being updated: configuration ... appSettings ... add key=ServiceInfo value=LYNC_SERVER_ADDRESS / /configuration So what do I have wrong in the util:XmlConfig element that is causing this error and what changes do I need to make to get this working? Thanks for any help. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Updating-app-config-tp1077780p7594702.html Sent from the wix-users mailing list archive at Nabble.com. -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Which is best to use in my case: XmlFile or XmlConfig?
Thanks eyoung, I made the recommended changes: util:XmlFile Id=SetServiceInfo Action=setValue ElementPath=/configuration/appSettings/add[@key='ServiceInfo']/@value Value=[LYNC_SERVER_ADDRESS] File=[INSTALLDIR]RemoteInk.exe.config Sequence=5 / But when I build the install I get the following error: C:\Work\Projects\Lync2013SP\RemoteInk.Lync2013SP\Src\Client\Installs\Client\Product.wxs(85,0): error LGHT0204: ICE03: Invalid format string; Table: XmlFile, Column: ElementPath, Key(s): SetServiceInfo So where did I go wrong? -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Which-is-best-to-use-in-my-case-XmlFile-or-XmlConfig-tp7594691p7594704.html Sent from the wix-users mailing list archive at Nabble.com. -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Which is best to use in my case: XmlFile or XmlConfig?
Thanks John, I made that change and the build worked but when I ran the install to test it I get the following error: Failed to find node: //configuration/appSettings/add[@key='ServiceInfo']/@value in XML file: C:\Program Files (x86)\CompanyName\Product\Product.exe.config, system error: -2147020584 My updated element looks like this: util:XmlFile Id=SetServiceInfo Action=setValue ElementPath=//configuration/appSettings/add[\[]@key='ServiceInfo'[\]]/@value Value=[LYNC_SERVER_ADDRESS] File=[INSTALLDIR]RemoteInk.exe.config Sequence=5 / So what is this error and what else do I need to do to get this to work? Thanks... -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Which-is-best-to-use-in-my-case-XmlFile-or-XmlConfig-tp7594691p7594707.html Sent from the wix-users mailing list archive at Nabble.com. -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Which is best to use in my case: XmlFile or XmlConfig?
I added the Name=value entry, but I still get the same error??? util:XmlFile Id=SetServiceInfo Action=setValue Name=value ElementPath=//configuration/appSettings/add[\[]@key='ServiceInfo'[\]]/@value File=[#RemoteInk.exe.config] Value=[LYNC_SERVER_ADDRESS] Sequence=5 / So I am still at a loss as to what I am missing or doing wrong to get this to work So in the error message when it states: 'Failed to find node: //configuration/appSettings/add[@key='ServiceInfo'] in XML file What is it stating? configuration and appSetting elements exist. And only need to create the ServiceInfo entry and value -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Which-is-best-to-use-in-my-case-XmlFile-or-XmlConfig-tp7594691p7594710.html Sent from the wix-users mailing list archive at Nabble.com. -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Which is best to use in my case: XmlFile or XmlConfig?
Okay I must be missing something as as I mentioned above this one did write to the file, just did not write it correctly: util:XmlFile Id=ServiceInfo Action=setValue ElementPath=/configuration/appSettings Name=ServiceInfo Value=[LYNC_SERVER_ADDRESS] File=[INSTALLDIR]RemoteInk.exe.config / When I update this to: util:XmlFile Id=ServiceInfo Action=setValue ElementPath=/configuration/appSettings/add[\[]@key='ServiceInfo'[\]] Name=ServiceInfo Value=[LYNC_SERVER_ADDRESS] File=[#RemoteInk.exe.config] / Basically the same thing except for the add[\[]@key='ServiceInfo'[\]] and then run it I get the 'Failed to find Node:' error. So why would adding this give me an error unless I am missing something that can correctly read that line... So I only have the following at the top of my Product.wxs file: Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; xmlns:util=http://schemas.microsoft.com/wix/UtilExtension; Did I have to include anything else to get this to work? Also in your example the add key=ServerLocation value= / entry already existed, so does that make a difference if the entry that I am trying to create exists or not? I'll see if I can get that example to work on my machine to verify if it works or not. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Which-is-best-to-use-in-my-case-XmlFile-or-XmlConfig-tp7594691p7594712.html Sent from the wix-users mailing list archive at Nabble.com. -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Which is best to use in my case: XmlFile or XmlConfig?
Well I created the Sample and it worked correctly, using exactly what was shown. So then I simply substituted my app.config file with the sample.config file and built and ran the test again and it failed? So I figured that it was my .config file that was the issue, but then I simply added the following entry to the .config file: add key=ServiceLocation value=localhost/ Ran the test again and this time it worked... So that implies that if the key that is to be updated does not exist then it will fail??? So if a key entry is not there then it has to be created and a value set to it, but according to that last link it shows that it will create and set the value. So why did it not work for me? I guess more work is required, what a pain as I have been looking at this for most of the day. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Which-is-best-to-use-in-my-case-XmlFile-or-XmlConfig-tp7594691p7594720.html Sent from the wix-users mailing list archive at Nabble.com. -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Testing Wix FirewallException element logging question.
Okay I changed the Name entries and it finally worked So this works, but it would have been nice to be able to use the same Name as we let the app run without the firewall entries and it prompts for firewall exception then it will create the entry using the app name and therefore there is only one. This way we have 2 Name entries, one for Domain and one for Private. And if the app is ran before hand it will create a 3rd entry... It would have been nice if the FirewallException CA could have used the same Name and therefore just created one line in the exception list with Domain and Private checkbox checked... If you use the 'all' flag for Profile then it correctly has one line with all check boxes checked... Maybe someone should look at updating that custom action to either allow same Name or under Profile allow multiple entries so that it all goes under the same Name entry... Anyways thanks Phill as this update will get me going for now. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Testing-Wix-FirewallException-element-logging-question-tp7594455p7594471.html Sent from the wix-users mailing list archive at Nabble.com. -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Testing Wix FirewallException element logging question.
I am just starting to use the Wix FirewallException element to create File exceptions for Domain and Home\Work (Private) entries and it seems to work, but I just have a slight concern when viewing the msi log for these actions. The entry in the log looks corrupt and I am just wanting to know if this is a problem? Here is a few of the lines: MSI (s) (40:58) [06:40:00:253]: Executing op: CustomActionSchedule(Action=WixExecFirewallExceptionsInstall,ActionType=3073,Source=BinaryData,Target=ExecFirewallExceptions,CustomActionData=1€SMART Notebook€2€*€1€2€c:\Program Files (x86)\SMART Technologies\Education Software\Notebook.exe€€-2147483648€€1€SMART Notebook€1€*€1€2€c:\Program Files (x86)\SMART Technologies\Education Software\Notebook.exe€€-2147483648€) Property(S): WixRollbackFirewallExceptionsInstall = 1€SMART Notebook€2€*€1€2€c:\Program Files (x86)\SMART Technologies\Education Software\Notebook.exe€€-2147483648€€1€SMART Notebook€1€*€1€2€c:\Program Files (x86)\SMART Technologies\Education Software\Notebook.exe€€-2147483648€ Property(S): WixExecFirewallExceptionsInstall = 1€SMART Notebook€2€*€1€2€c:\Program Files (x86)\SMART Technologies\Education Software\Notebook.exe€€-2147483648€€1€SMART Notebook€1€*€1€2€c:\Program Files (x86)\SMART Technologies\Education Software\Notebook.exe€€-2147483648€ Notice the €€following in those lines: 1€*€1€2, 2€*€1€2, -2147483648 Is this garbage or does it actually mean anything to the firewall CA as it does not seem like it is getting to correct information. So what is the firewall CA trying to write here and again will it affect install in any way? -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Testing-Wix-FirewallException-element-logging-question-tp7594455.html Sent from the wix-users mailing list archive at Nabble.com. -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Testing Wix FirewallException element logging question.
Actually during my testing it looks like the Domain exception does not seem to be created, only the Private exception is created. So maybe I have something wrong with my configurations. Here is what I have: fire:FirewallException Id=NB_FirewallException_Private Name=[ProductName] File=notebook.exe Scope=any IgnoreFailure=yes Profile=private / fire:FirewallException Id=NB_FirewallException_Domain Name=[ProductName] File=notebook.exe Scope=any IgnoreFailure=yes Profile=domain / So do I have these declared correctly? Any insight would be helpful. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Testing-Wix-FirewallException-element-logging-question-tp7594455p7594457.html Sent from the wix-users mailing list archive at Nabble.com. -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Problem getting FirewallException element to register File for Domain
We have ran into a case where a change in our product has now required one of our files to need access through the firewall. We need Domain and Private rules set. Since I have not used the new FirewallException element before I do not know if I have the configurations set up correctly or not. Here are the entries that I have: fire:FirewallException Id=NB_FirewallException_Private Name=[ProductName] File=notebook.exe Scope=any IgnoreFailure=yes Profile=private / fire:FirewallException Id=NB_FirewallException_Domain Name=[ProductName] File=notebook.exe Scope=any IgnoreFailure=yes Profile=domain / When I run my install then the Private exception rule is correctly created, but the Domain exception rule is NOT created. So do I have these declared correctly? and if not then what changes do I need? Any help would be great as we need to get this done today. Thanks. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Problem-getting-FirewallException-element-to-register-File-for-Domain-tp7594458.html Sent from the wix-users mailing list archive at Nabble.com. -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Testing Wix FirewallException element logging question.
Thanks Phil. We at first did use Profile=all, but it was decided that we did not want our program to have Public firewall access. So we figured that we would simply create the 2 entries, one for Domain and one for Private. But as stated above only Private gets enabled and Domain does not. So is there a way to have both Domain and Private rules set up using this WiX FirewallException element? Thanks. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Testing-Wix-FirewallException-element-logging-question-tp7594455p7594462.html Sent from the wix-users mailing list archive at Nabble.com. -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Testing Wix FirewallException element logging question.
Sorry for taking you away from Torch work Phill. Now with my code my Id's are different, so it is not that that is causing the issue, but I noticed that you are not using the File or Program elements and you also have your Scope set to 'localSubnet' where as mine is set to 'any'. If you do not specify File/Program then what firewall exception gets created? I also have my firewall elements under separate standalone components so that they can be conditioned to be turned off if need be. So one or more of these differences much be causing my issue. could one of these two differences be causing my issue? Thanks for your help Phill. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Testing-Wix-FirewallException-element-logging-question-tp7594455p7594468.html Sent from the wix-users mailing list archive at Nabble.com. -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Localized strings not in Wix Extensions
Hello, We are currently building with WiX 3.7 and our install supports multiple languages and I just added the FirewallExecption to our project. And we are also receiving the localization error LGHT0102 for the firewall strings. So this still has not been fixed/updated as of yet? Or am I also missing something? Having to create all those string id entries in all my string .wxl files will be a pain, but if we have to do it for now then I guess I will. But if there is a solution out there that we can use the more the better -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Localized-strings-not-in-Wix-Extensions-tp3658448p7594413.html Sent from the wix-users mailing list archive at Nabble.com. -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Can a Wixlib contain a merge module?
Thanks Rob... It actually turned out to be the first build I did from TeamCity did not link in the merge module as it did not have access to it at the time. So the wixlib that went into the parent just did not have the merge module to install. So I re-verified with the latest build and it correctly linked in the merge module and installed correctly. So everything is working fine now -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Can-a-Wixlib-contain-a-merge-module-tp7594055p7594071.html Sent from the wix-users mailing list archive at Nabble.com. -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Can a Wixlib contain a merge module?
I have a wixlib project that now needs to install files that are within a merge module. I thought that just adding the Merge Id to the wixlib fragment DirectoryRef and the MergeRef Id to the fragment Feature Id that it would just work, but it did not. The wixlib built without errors and during the install all files/entries in the wixlib were correctly installed, but the merge module within the wixlib did not get installed. So if this is not possible then I'll move the merge module into the main parents project, but I just want to keep things together as this merge module is only related to this fragment wixlib. So if it is possible then I would like to know how otherwise parent it will go. Thanks. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Can-a-Wixlib-contain-a-merge-module-tp7594055.html Sent from the wix-users mailing list archive at Nabble.com. -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] String registry key that contains {} seems to be causing LGHT0311 error
We just added a new registry key to our installer:
RegistryValue Id=ArgumentTemplate_Regkey Name=ArgumentTemplate
Value=BUT_AREA_CAPTURE –x{0} –y{1} –w{2} –h{3} Type=string /
Our install supports 26 languages and during the install we will get the
following error on this registry key entry:
[22:35:13][Light]
D:\BuildAgent73\work\91fb0265b456f38d\SBTools\Source\SBTools\installs\win\SMARTTools.wxs(118,
0): error LGHT0311: A string was provided with characters that are not
available in the specified database code page '932'. Either change these
characters to ones that exist in the database's code page, or update the
database's code page by modifying one of the following attributes:
Product/@Codepage, Module/@Codepage, Patch/@Codepage,
PatchCreation/@Codepage, or WixLocalization/@Codepage.
So does this mean that if we support multiple languages and have registry
keys with {} entries that it they are supported?
Is there any way to get around this issue?
Any help would be appreciated.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/String-registry-key-that-contains-seems-to-be-causing-LGHT0311-error-tp7593049.html
Sent from the wix-users mailing list archive at Nabble.com.
--
Subversion Kills Productivity. Get off Subversion Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster operations. Version large binaries. Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] String registry key that contains {} seems to be causing LGHT0311 error
Thanks Carter.
It actually turned out to be some hidden characters that were on that line
caused by copy/paste from SharePoint... What a pain when these extra hidden
characters are copied and causes issues like this
Tim.
From: eyoung100 [via Windows Installer XML (WiX) toolset]
[mailto:ml-node+s687559n759305...@n2.nabble.com]
Sent: Monday, March 03, 2014 8:28 AM
To: Tim Mayert
Subject: Re: String registry key that contains {} seems to be causing
LGHT0311 error
Looks like those Characters arent available in the Japanese CodePage.
See: http://msdn.microsoft.com/en-US/goglobal/cc305152
Carter
Quoting TimM [hidden email]/user/SendEmail.jtp?type=nodenode=7593051i=0:
We just added a new registry key to our installer:
RegistryValue Id=ArgumentTemplate_Regkey Name=ArgumentTemplate
Value=BUT_AREA_CAPTURE –x{0} –y{1} –w{2} –h{3} Type=string /
Our install supports 26 languages and during the install we will get the
following error on this registry key entry:
[22:35:13][Light]
D:\BuildAgent73\work\91fb0265b456f38d\SBTools\Source\SBTools\installs\win\SMARTTools.wxs(118,
0): error LGHT0311: A string was provided with characters that are not
available in the specified database code page '932'. Either change these
characters to ones that exist in the database's code page, or update the
database's code page by modifying one of the following attributes:
Product/@Codepage, Module/@Codepage, Patch/@Codepage,
PatchCreation/@Codepage, or WixLocalization/@Codepage.
So does this mean that if we support multiple languages and have registry
keys with {} entries that it they are supported?
Is there any way to get around this issue?
Any help would be appreciated.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/String-registry-key-that-contains-seems-to-be-causing-LGHT0311-error-tp7593049.html
Sent from the wix-users mailing list archive at Nabble.com.
--
Subversion Kills Productivity. Get off Subversion Make the Move to
Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster operations. Version large binaries. Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk
___
WiX-users mailing list
[hidden email]/user/SendEmail.jtp?type=nodenode=7593051i=1
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Subversion Kills Productivity. Get off Subversion Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster operations. Version large binaries. Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk
___
WiX-users mailing list
[hidden email]/user/SendEmail.jtp?type=nodenode=7593051i=2
https://lists.sourceforge.net/lists/listinfo/wix-users
The Birth and Growth of Science is the Death and Atrophy of Art. -- Unknown
If you reply to this email, your message will be added to the discussion below:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/String-registry-key-that-contains-seems-to-be-causing-LGHT0311-error-tp7593049p7593051.html
To unsubscribe from String registry key that contains {} seems to be causing
LGHT0311 error, click
herehttp://windows-installer-xml-wix-toolset.687559.n2.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=7593049code=VGltTWF5ZXJ0QHNtYXJ0dGVjaC5jb218NzU5MzA0OXwtMTcxMzc3MTUwNA==.
NAMLhttp://windows-installer-xml-wix-toolset.687559.n2.nabble.com/template/NamlServlet.jtp?macro=macro_viewerid=instant_html%21nabble%3Aemail.namlbase=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespacebreadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/String-registry-key-that-contains-seems-to-be-causing-LGHT0311-error-tp7593049p7593053.html
Sent from the wix-users mailing list archive at Nabble.com.
--
Subversion Kills Productivity. Get off Subversion Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster operations. Version large binaries. Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk
Re: [WiX-users] Creating Wix Pure patch with Melt.exe and Pyro.exe fails
Thanks Blair, I have created bug #4187. I have added, to the bug, the dropbox link to the zipped up product files that can be used to reproduce the issue as well. So hopefully a solution to this issue can be found or at least maybe let me know what I could possibly be doing that may be causing this issue... But as mentioned using Patch Creation Properties does work and therefore we'll at least go with that for now until this can be fixed. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Creating-Wix-Pure-patch-with-Melt-exe-and-Pyro-exe-fails-tp7590635p7590653.html Sent from the wix-users mailing list archive at Nabble.com. -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Creating Wix Pure patch with Melt.exe and Pyro.exe fails
I have been testing the 2 patching methods for WiX: Using Patch Creation Properties Using Purely WiX I have created basic samples for both and got both of them working okay so I am now try a real install upgrade patch. So I get the .msi and .wixpdb files for say version 1.0 and for version 1.1 Since these files are moved from the original source trees I have to use melt.exe to extract and generate new .wixpdb files so I use the following cmds: Melt.exe 1.0\product.msi -out 1.0x\product.wibpdb -pdb 1.0\product.wixpdb -x 1.0x\Productbits Melt.exe 1.1\product.msi -out 1.1x\product.wixpdb -pdb 1.1\product.wixpdb -x 1.1x\Productbits Once this step is done I trigger the torch.exe, candle, and light.exe commands to generate the wixmst and wixmsp files. Finally I run the pyro.exe -delta on these files to generate the patch and it is at this point it fails with a bunch of PYRO0103 errors. These errors are all referring to files that are missing from the original source directories where they were built from or stored on the build machine. Now these missing files are all binary table entries and merge module .msm entries. So I thought that melt was suppose to do a correct extraction of the .msi's so that the original build folder structure was not needed? Are there any melt or pyro cmd options that are suppose to be used to make sure that this does not occur? Again if we have to retail the exact build folder structure for the release builds and the builds that will be used for creating a patch then it will be a pain to maintain Has anyone ran into these kind of Pyro errors and if so what did you do to solve the issue? -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Creating-Wix-Pure-patch-with-Melt-exe-and-Pyro-exe-fails-tp7590635.html Sent from the wix-users mailing list archive at Nabble.com. -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Creating Wix Pure patch with Melt.exe and Pyro.exe fails
Here is part of my build log and all are referring to binary and merge Id's that are listed in fragment files and referencing the path that our build machine created for the build: D:\BuildAgent72\work\9f69624fb270635f\BoardSW\install\win\SMART Product Drivers \Core_x86PNPDrivers.wxs(158) : error PYRO0103 : The system cannot find the file '..\..\..\..\Artifacts\CustomActionDlls\BoardCustomActionMSI.dll'. \CustomActionsTable.wxs(105) : error PYRO0103 : The system cannot find the file '..\..\..\..\Artifacts\CustomActionDlls\CloseAppsTool.dll'. \CustomActionsTable.wxs(106) : error PYRO0103 : The system cannot find the file '..\..\..\../builds/Win32/Static.Release\CloseDriversApps-vc100-mt-s-x86.dll'. \CustomActionsTable.wxs(108) : error PYRO0103 : The system cannot find the file '..\..\..\..\Artifacts\CustomActionDlls\findMSICA.dll'. \CustomActionsTable.wxs(107) : error PYRO0103 : The system cannot find the file '..\..\..\..\Artifacts\ink\InkCustomActionMSI-vc100-mt-s-x86.dll'. \CustomActionsTable.wxs(109) : error PYRO0103 : The system cannot find the file '..\..\..\..\Artifacts\CustomActionDlls\WriteReg64.dll'. \PropertiesTable.wxs(51) : error PYRO0103 : The system cannot find the file '..\..\..\../BoardSW/Source\SBTools\SMARTHelpButtonQt\resources\SMARTBoardToolsWithShading.ico'. \Core_x64PNPDrivers.wxs(36) : error PYRO0103 : The system cannot find the file '..\..\..\../installs/x86/Release/CorePNPx64Drivers.msm'. \Core_Drivers.wxs(207) : error PYRO0103 : The system cannot find the file '..\..\..\../installs/x86/Release/CoreSharedDrivers.msm'. \FilesComponentFragment.wxs(15) : error PYRO0103 : The system cannot find the file '..\..\..\../installs/x86/Release/Diagnostics.msm'. \FilesComponentFragment.wxs(16) : error PYRO0103 : The system cannot find the file '..\..\..\../installs/x86/Release/Diagnostics_TroubleShooting.msm'. \FilesComponentFragment.wxs(17) : error PYRO0103 : The system cannot find the file '..\..\..\../installs/x86/Release/OregonTrainingVideos.msm'. \FilesComponentFragment.wxs(10) : error PYRO0103 : The system cannot find the file '..\..\..\../Artifacts/Merge Modules/sbwdk_merge_module.msm'. \FilesComponentFragment.wxs(6) : error PYRO0103 : The system cannot find the file '..\..\..\../installs/x86/Release/Display Controller.msm'. \Core_Drivers.wxs(213) : error PYRO0103 : The system cannot find the file '..\..\..\../artifacts/Merge Modules/smart_document_camera_vc100_3.0.msm'. Could there actually be something wrong with the generation of these fragment files or the way the merge and binary Id's are declared in them? We have only been doing WiX installs now for a couple years and we are now only looking into patches and therefore if we are actually doing some incorrect formatting of our fragment files that would only affect a Purely WiX patch then this is something that we can look into fixing, but need to know what this issue may be so that we can correct it. Anyways a patch can be made with just the .msi and using Patch Creation, but would like to know what is causing this issue so that we can fix for future versions. Thanks for any help -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Creating-Wix-Pure-patch-with-Melt-exe-and-Pyro-exe-fails-tp7590635p7590638.html Sent from the wix-users mailing list archive at Nabble.com. -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Purely WiX patching and FeatureRef
Well add my name to this request as well to having this work be put to the top of the list Since Purely WiX patching requires generation of the .wixpdb files I would like to know how these work if the install supports multiple languages? We had generation of the .wixpdb files turned off as at the time they were just taking up room and we did not know what the usages of these files were until we were looking into patching. My question is do we have to make use of the other language generated .wixpdb files if the patches we are creating are only application file updates? Just wanted to make sure that we do not have to generate a patch file for every language that our software supports as that would be harder to manage/maintain. Thank. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Purely-WiX-patching-and-FeatureRef-tp7590049p7590594.html Sent from the wix-users mailing list archive at Nabble.com. -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Purely WiX patching and FeatureRef
Okay I have done a bit more testing with Pure Wix and Melt and here is what I have found with my testing. Create Product.wxs with a bunch of components in root and I also create a fragment with is bunch more components. I then built this msi and associated .wixpdb file. I then updated some of the files in the root and some of the file in the fragment and built the msi/wixpdb I then created my patch.wxs file and in the PatchFamily I added one ComponentRef from the components in root. Built then ran my patch batch file that will call Melt, torch, candle, light and pyro to build the patch. Using Orca I applied the patch to the Target .msi and sure enough only the files from root componentref showed as updated. I updated the patch.wxs and added one ComponentRef from the fragment and rebuilt the patch. Orca now shows all updated files from root and fragment. So that worked and therefore tells me that the patch.wxs has to have a ComponentRef of at least one component from every single fragment/wixlib that are associated with the main product.wxs. And it does not matter if the component that is being referenced is changed from the previous version or not. The exception to this would be if there are new components and therefore each of the new componentref's need to be added? Now if I am wrong in anything that I mentioned here then someone please let me know before I get too far. Now how about Merge modules that have been updated??? How does Pure WiX and Melt handle those? Now I had hear or read from somewhere that patch with Pure WiX is less complicated than using the Patch Creation Properties to generate a patch.. Well from the work I have done just to make this sample it seems that Pure WiX is more complicated than Patch Creation as with Patch Creation you only need the Target .msi and all the Update .msi files, have them extracted and simple patch.wxs file that simple has the Upgrade image and all Target Images. So if I am under the wrong opinion here then someone set me straight and show me how Pure WiX patching is better Thanks for reading my rantings It is Friday ;) -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Purely-WiX-patching-and-FeatureRef-tp7590049p7590456.html Sent from the wix-users mailing list archive at Nabble.com. -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Purely WiX patching and FeatureRef
Hey Stephen, Here is the contents for my sample build.bat file: @echo call melt.exe to fix the Version 1.0 wixpdb file so that we do not have to worry about original source files/folders. Melt.exe Ver1.0\product.msi -out Ver1.0Corrected\product.wixpdb -pdb Ver1.0\product.wixpdb -x Ver1.0Corrected\Productbits @echo call melt.exe to fix the Versoin 1.1 wixpdb file so that we do not have to worry about original source files/folders. Melt.exe Ver1.1\product.msi -out Ver1.1Corrected\product.wixpdb -pdb Ver1.1\product.wixpdb -x Ver1.1Corrected\Productbits @echo create the transform between product versions torch.exe -p -xi Ver1.0Corrected\product.wixpdb Ver1.1Corrected\product.wixpdb -out patch\diff.wixmst @echo build the patch .msp from differences. candle.exe patch.wxs light.exe patch.wixobj -out patch\patch.wixmsp pyro.exe patch\patch.wixmsp -out patch\patch.msp -t Patch patch\diff.wixmst Oh and I guess if you know the files that are updated then you can probably use the PatchFamiles to reference the components that are changed and need for updating... But if you have a bunch of components then this could get complicated as I was referring to before Tim. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Purely-WiX-patching-and-FeatureRef-tp7590049p7590468.html Sent from the wix-users mailing list archive at Nabble.com. -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Purely WiX patching and FeatureRef
Okay Rob, taking out the PatchFamily does allow the patch to all updated files to be correctly patched and therefore does reduce the complexity of this method... Now if we look at Stephen's issue I can see this being a major concern as we also do the same thing where files are updated with version and signing each build and therefore when building the new version all files are updated, but we could have simply a couple files that actually have code changes in them that we want patched. If you knew of all files that were to be patched then yes you could simply place these files into a folder that contained the previous version and have the install built from that and therefore the patch creation would then only see the updated files and correctly patch them, but this is not as easy as it sounds as being install developers we may not know of all the files the developers are updating and the build definitely does not let us know and therefore it would be a pain having to figure out what changed and what only had version/signing changes. So it would be great if there was a setting in the patch.wxs that we can set to only get file binary changes instead of whole files. This way even if we got bit differences of files that only had version and signing differences these would not be big differences and therefore the patch .msp would not be that much bigger than if it had to take whole files. So is there a setting that will allow for just bit differences or will we have to do it the hard way and find the files that are updated and to be patched? Thanks, Tim. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Purely-WiX-patching-and-FeatureRef-tp7590049p7590474.html Sent from the wix-users mailing list archive at Nabble.com. -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Purely WiX patching and FeatureRef
Well I just did a test of Patch Creation using two different builds of our next release of our software, which the .msi files are 118 MB in size, and if I set the WholeFilesOnly=yes the patch .msp size is 20MB. Now if I set the WholeFilesOnly=no then the size of the .msp is only 3.8 MB. Way smaller. So for the extra step of extracting the .msi files you get the ability to have a bit difference instead of whole files and you do not have to create a PatchFamily with all the known components that may of changed So just have to see about getting this WholeFilesOnly from PatchCreation into Pure WiX and we would be good to go -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Purely-WiX-patching-and-FeatureRef-tp7590049p7590484.html Sent from the wix-users mailing list archive at Nabble.com. -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Purely WiX patching and FeatureRef
Ah that could be what we are looking for... This is another case of not looking at the documentation or not knowing it there was any I'll get this a try on some of my Pure WiX samples to verify that this works and if it does then we should have everything. Thanks, Tim. From: robmen [via Windows Installer XML (WiX) toolset] [mailto:ml-node+s687559n7590487...@n2.nabble.com] Sent: Friday, November 08, 2013 2:31 PM To: Tim Mayert Subject: Re: Purely WiX patching and FeatureRef Is this: pyro -delta ? -Original Message- From: TimM [mailto:[hidden email]/user/SendEmail.jtp?type=nodenode=7590487i=0] Sent: Friday, November 8, 2013 1:04 PM To: [hidden email]/user/SendEmail.jtp?type=nodenode=7590487i=1 Subject: Re: [WiX-users] Purely WiX patching and FeatureRef Well I just did a test of Patch Creation using two different builds of our next release of our software, which the .msi files are 118 MB in size, and if I set the WholeFilesOnly=yes the patch .msp size is 20MB. Now if I set the WholeFilesOnly=no then the size of the .msp is only 3.8 MB. Way smaller. So for the extra step of extracting the .msi files you get the ability to have a bit difference instead of whole files and you do not have to create a PatchFamily with all the known components that may of changed So just have to see about getting this WholeFilesOnly from PatchCreation into Pure WiX and we would be good to go -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Purely-WiX-patching-and-FeatureRef-tp7590049p7590484.html Sent from the wix-users mailing list archive at Nabble.com. -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ WiX-users mailing list [hidden email]/user/SendEmail.jtp?type=nodenode=7590487i=2 https://lists.sourceforge.net/lists/listinfo/wix-users -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ WiX-users mailing list [hidden email]/user/SendEmail.jtp?type=nodenode=7590487i=3 https://lists.sourceforge.net/lists/listinfo/wix-users If you reply to this email, your message will be added to the discussion below: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Purely-WiX-patching-and-FeatureRef-tp7590049p7590487.html To unsubscribe from Purely WiX patching and FeatureRef, click herehttp://windows-installer-xml-wix-toolset.687559.n2.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=7590049code=VGltTWF5ZXJ0QHNtYXJ0dGVjaC5jb218NzU5MDA0OXwtMTcxMzc3MTUwNA==. NAMLhttp://windows-installer-xml-wix-toolset.687559.n2.nabble.com/template/NamlServlet.jtp?macro=macro_viewerid=instant_html%21nabble%3Aemail.namlbase=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespacebreadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Purely-WiX-patching-and-FeatureRef-tp7590049p7590488.html Sent from the wix-users mailing list archive at Nabble.com. -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Purely WiX patching and FeatureRef
Now most of our builds update the PC so that we can treat every build as a Major Upgrade as sometimes our testers/developers grab the builds and simply install over the previous builds and therefore changing the PC every build will prevent upgrade issues, but when we know that we are going the be doing a patch then we make sure that the PC remains the same as the version(s) that we want to perform the patch on. From: John Cooper-2 [via Windows Installer XML (WiX) toolset] [mailto:ml-node+s687559n7590492...@n2.nabble.com] Sent: Friday, November 08, 2013 3:17 PM To: Tim Mayert Subject: Re: Purely WiX patching and FeatureRef Don't like the experience of -delta and a commented out PatchFamily. It tries to generate a MajorUpgrade patch (changes the ProductVersion property in the Property table and overwrites the Upgrade table). I think this is a side effect of our ProductCodes changing every build, but we're happy with MajorUpgrade in circumstances where we need to touch most of the assemblies. Looking at the patch table, a number of the binary diff's with the -delta switch were less than 512 which I interpret to be assembly header patches. I know the code in those assemblies hadn't actually changed. -- John Merryweather Cooper Build Install Engineer -- ESA Jack Henry Associates, Inc.(r) Shawnee Mission, KS 66227 Office: 913-341-3434 x791011 [hidden email]/user/SendEmail.jtp?type=nodenode=7590492i=0 www.jackhenry.comhttp://www.jackhenry.com -Original Message- From: John Cooper Sent: Friday, November 8, 2013 3:59 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Purely WiX patching and FeatureRef Learn something new every day. Gave -delta a spin and it seems good. I'll have to give it a spin without PatchFamily next and compare results. -- John Merryweather Cooper Build Install Engineer -- ESA Jack Henry Associates, Inc.(r) Shawnee Mission, KS 66227 Office: 913-341-3434 x791011 [hidden email]/user/SendEmail.jtp?type=nodenode=7590492i=1 www.jackhenry.comhttp://www.jackhenry.com -Original Message- From: Rob Mensching [mailto:[hidden email]/user/SendEmail.jtp?type=nodenode=7590492i=2] Sent: Friday, November 8, 2013 3:30 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Purely WiX patching and FeatureRef Is this: pyro -delta ? -Original Message- From: TimM [mailto:[hidden email]/user/SendEmail.jtp?type=nodenode=7590492i=3] Sent: Friday, November 8, 2013 1:04 PM To: [hidden email]/user/SendEmail.jtp?type=nodenode=7590492i=4 Subject: Re: [WiX-users] Purely WiX patching and FeatureRef Well I just did a test of Patch Creation using two different builds of our next release of our software, which the .msi files are 118 MB in size, and if I set the WholeFilesOnly=yes the patch .msp size is 20MB. Now if I set the WholeFilesOnly=no then the size of the .msp is only 3.8 MB. Way smaller. So for the extra step of extracting the .msi files you get the ability to have a bit difference instead of whole files and you do not have to create a PatchFamily with all the known components that may of changed So just have to see about getting this WholeFilesOnly from PatchCreation into Pure WiX and we would be good to go -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Purely-WiX-patching-and-FeatureRef-tp7590049p7590484.html Sent from the wix-users mailing list archive at Nabble.com. -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ WiX-users mailing list [hidden email]/user/SendEmail.jtp?type=nodenode=7590492i=5 https://lists.sourceforge.net/lists/listinfo/wix-users -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ WiX-users mailing list [hidden email]/user/SendEmail.jtp?type=nodenode=7590492i=6 https://lists.sourceforge.net/lists/listinfo/wix-users NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information
Re: [WiX-users] Purely WiX patching and FeatureRef
On 28-Oct-13 22:05, Tunney, Stephen wrote: Ok, good to know. I have thousands of components though spread across a dozen features. Those features are shared amongst 8 products :) Stephen, how did you make out with your patch creation using this Pure-Wix method? We are just looking into the patching methods and I have done examples of both Patch Creation Properties as well as Pure Wix and I have gotten them working, but as I was documenting my findings I found the reference to MELT and therefore that throw a bit of a wench into things as my tests were all based on strict paths. After reading about if the build system moves thing around then I figured that we would then have issues. Anyways slightly off topic I wanted to talk about... We also have thousands of components in multiple fragments and wixlibs and therefore would not want to create a patch .wxs file that has to list every ComponentRef under the PatchFamily element. Now with my tests I created V1.0 with 5 files and then I updated all but 1 file for V1.1. In my patch .wxs file I only added a ComponentRef to one of the components. I then generated the patch and installed V1.0. I then ran the patch .msp and all the files were correctly updated except for the one that did not change. So is this expected behavior or what? I just need to know if I use this method what ComponentRef are needed. Since I only had one file with component does it mean that if I have multiple component fragment files that I have to at least reference one component from each fragment to make this work?? If so then I would think that working with PatchCreation and extracted .msi files would be less complicated... Thanks.. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Purely-WiX-patching-and-FeatureRef-tp7590049p7590407.html Sent from the wix-users mailing list archive at Nabble.com. -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Having issues with permanently installed assemblies and Major Upgrades
Okay thanks for all your help/suggestions, but have found what the actual issue was. The MsiProvideAssembly returning: 1607 on 2 assemblies was actually the hint. After testing a few times I got it to the point where 2 assemblies were gone after the upgrade and they were the ones listed in the MsiProvideAssembly actions. And the 1607 basically means that the components ID could not be found. So I checked the component GUID's of the new updated components and found out that they were the same as the older versions that were installed. So I changed the GUID of one of the assemblies and sure enough that fixed the issue I have mentioned many times, to our install developers, that if we have updated assemblies that we should be changing the GUID's so that there are no conflicts if both assemblies are install, but I guess that when these ones were upgraded the GUID change never happened. Anyways problem now fixed and therefore on to the next... -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Having-issues-with-permanently-installed-assemblies-and-Major-Upgrades-tp7590275p7590297.html Sent from the wix-users mailing list archive at Nabble.com. -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Having issues with permanently installed assemblies and Major Upgrades
We have an install project that installs most of our public assemblies that are used by most of our various apps. The assembly components are all mark as permanent as we do not want them removed during uninstall. The issue that we seem to be are running into with one our assemblies is that when we upgrade to a newer version of one of the assemblies and run one of our older apps, that is still referencing the original assembly, then that app will fail with an assembly sxs error. Now we perform an major upgrade install on the installer that placed the assemblies there and therefore it uninstall that version first before installing the upgrade, but since the assemblies are all marked as permanent the older ones should have been left behind and therefore usable for older versions of the software. We checked the winsxs folder and the files/folders are there for both the new and older assemblies, but again the app does not find the older assemblies. I checked the install log and noticed that the MsiUnpublishAssemblies action was triggered and all the assemblies from the older version were unpublished. Are we suppose to turn off this action so that it can not unpublished any of the assemblies installed with this installer Anyways this seems to only have occurred in this one case and therefore if the assemblies are all unpublished then we should have seen this issue long before now with any other older assemblies, so I looked further in the log and found near the end of the log mention of the assembly in question and it being triggered by the MsiProvideAssembly action. The only thing is that this MsiProvideAssembly is returning: 1607. So is this action trying to re-register the assembly but failing? I do not think many are handling assemblies like we are, but if anyone has any input as to what could be causing our issues I would like to hear from you Thanks. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Having-issues-with-permanently-installed-assemblies-and-Major-Upgrades-tp7590275.html Sent from the wix-users mailing list archive at Nabble.com. -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Having issues with permanently installed assemblies and Major Upgrades
Nope this is not the issue, because as I mentioned, the sxs folder and files for both versions do exists after the install and if it was like this article then the older version would be gone. So the files exist, but the app can not find the assembly, so this implies that the system no longer has that version registered even though the files and folders are intact. So again could the MsiUnpublishAssemblies and MsiProvideAssembly actions be causing the issue, or could there be some kind of conflict before the 2 versions that are causing the register of the new version to somehow override the registration of the older version? Thanks. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Having-issues-with-permanently-installed-assemblies-and-Major-Upgrades-tp7590275p7590278.html Sent from the wix-users mailing list archive at Nabble.com. -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patch Creation Properties example in manual not working
Ok, figured out what was wrong, operator error . I had my Upgrade and Target sourcefiles reversed. After I fixed that it worked as expected -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Patch-Creation-Properties-example-in-manual-not-working-tp7590092p7590109.html Sent from the wix-users mailing list archive at Nabble.com. -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Creating Cumulative patches with Patch Creation Properties
I am currently testing the creation of WiX patches using Patch Creation
Properties. Now I am trying this over Pure WiX patches because the versions
that we will initially be patching have already been released and when they
were built they were NOT built to generate the .wixpdb files. So we have to
go with admin extracted installs.
I create the initial first patch and test out and it works great. Now we are
looking at cumulative patches so I updated my Patch.wxs to have UpgradeImage
and 2 TargetImage entries. When I apply the original version 2 patch to
version 1 it is ok.
I then use the new cumulative patch, that contains version 1 and version 2
changes, and apply that to version 1 release and it correctly upgrades to
version 3.
But if I apply the original version 2 patch to version 1 and then apply new
version 3 patch to that it will not do anything. No files are upgraded and
it remains at version 2. So what am I doing wrong here???
Here is what the patch.wxs file looks like:
?xml version=1.0 encoding=UTF-8?
Wix xmlns=http://schemas.microsoft.com/wix/2006/wi;
PatchCreation
Id={1C7DC01C-72AB-4050-A853-CC53FEE72D5E}
CleanWorkingFolder=yes
OutputPath=patch.pcp
WholeFilesOnly=yes
PatchInformation
Description=Cumulative Update Patch
Comments=Testing Cumulative Update Patch
Manufacturer=SMART Technologies /
PatchMetadata
AllowRemoval=yes
Description=Cumulative Update Patch
ManufacturerName=SMART Technologies
MoreInfoURL=http://www.smarttech.com/;
Classification=Update
DisplayName=Cumulative Patch
MinorUpdateTargetRTM=yes /
Family DiskId=5000
MediaSrcProp=Upgrade
Name=Upgrade
SequenceStart=5000
UpgradeImage SourceFile=C:\Temp\1.0\Sample.msi Id=Upgrade
TargetImage SourceFile=C:\Temp\1.2\Sample.msi Order=1
Id=Target IgnoreMissingFiles=no /
TargetImage SourceFile=C:\Temp\1.3\Sample.msi Order=1
Id=Target2 IgnoreMissingFiles=no /
/UpgradeImage
/Family
PatchSequence
PatchFamily=UpgradePatchFamily
Sequence=1.0.0.0
Supersede=yes /
/PatchCreation
/Wix
Now I did change Order numbers from TargetImage, but that did not help. What
should the Order numbers be?
I did not make any changes to the PatchSequence entries. Should any of these
entries change between patches?
Thanks for any help.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Creating-Cumulative-patches-with-Patch-Creation-Properties-tp7590119.html
Sent from the wix-users mailing list archive at Nabble.com.
--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Patch Creation Properties example in manual not working
I am looking in to creating patches with WiX and therefore I am starting with the basics of both: Using Patch Creation Properties and Using Purely WiX I am currently using the 3.7 released version of WiX and following the exact example for the 'Using Purely WiX' from the following documentation works as described: http://wixtoolset.org/documentation/manual/v3/patching/wix_patching.html Now I am trying the 'Using Patch Creation Properties and following the example as shown in the following documentation does not work. The file does NOT get updated: http://wixtoolset.org/documentation/manual/v3/patching/patch_building.html Now we have been generating and releasing all our current project .msi files without .wixpdb and therefore we would have to initially look at using Patch Creation to generate our patches, so we need to verify that this works correctly and to make sure we can built patches from the .msi files. So what changes have be done for 3.7 that prevents the generated patch from 'Patch Creation' in this example from working as indicated? Thanks. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Patch-Creation-Properties-example-in-manual-not-working-tp7590092.html Sent from the wix-users mailing list archive at Nabble.com. -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Creating multiple Minor Updates
Joe, we are just looking at patches and I have a question about this method if you don't mind? I am just testing out with using the sample 'Using Pure WiX' example and I am looking at the PatchFamily element and noticed that you have to add a reference to a component in your main install project. And then you mentioned that you added a new file so in the 2nd patch added the reference to the new component. So my question is do you have to add a reference to all components that changed or do you simply have to add a reference to any component that resides in your target project and then the patch will pick up all changed/updated components? The reason I ask is because in doing the example the sample.txt file updated fine, so I added some .exe files to the sample target and update projects, some that changed and some that did not and I left the ComponentRef in the patch.wxs to still be the same. Did not add any more references. I then built the patch and when I ran it over the target install it correctly upgraded all files that were updated and left all the ones that were the same as is. So it seems to work that way. So was that just a side effect and it was not suppose to do that or is that how it is supposed to work? I have not tried to create a cumulative patch from this example, but if it does work this way then for a 2nd and 3rd patch would you have to add more component references or simply build the cumulative patch and it would only be new components that you would have to add as references? Oh and that does bring up the question on how you built the cumulative patch? what command line do you use to build with to generate the patch to work over 1 and ver 2, and so on? Thanks for any insight that you can supply. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Creating-multiple-Minor-Updates-tp7586073p7590098.html Sent from the wix-users mailing list archive at Nabble.com. -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Conditional Component getting triggered for uninstall when not installed
We have 2 components that are conditioned to be installed. On simply installs
the file, but the other installs the file and creates some file association
entries that are shared by other apps. By default the component that only
installs the file turned on and therefore the other component is turned off.
None of these components are marked as shared.
During install the correct component is installed and therefore no file
association is created, but we noticed that during uninstall the turned off
component seems to be triggered and therefore removed the file association
registry keys, causing the other apps not to have file associations.
Checking the log we do notice the component entry in the log:
MSI (s) (A0:C4) [09:18:00:096]: Executing op:
ComponentUnregister(ComponentId={51275946-63F1-4A82-BC9B-FA3DA39B73B3},,BinaryType=0,PreviouslyPinned=1)
We noticed the PreviousPinned=1 and know that if this is there that the
component should not be uninstalled. We noticed that all components that are
turned off have this entry in the log.
But then we noticed the following in the log:
MSI (s) (A0:C4) [09:18:00:416]: Executing op:
RegExtensionInfoUnregister(Feature=SMART_Ink,Component={51275946-63F1-4A82-BC9B-FA3DA39B73B3},,Extension=pdf,ProgId=SMARTInkDocumentViewer.pdf)
This is where the file association is being uninstalled.
So why is the uninstall triggering components that were NOT installed to
remove entries that we not even created during install?
Any insight would be helpful.
Thanks.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Conditional-Component-getting-triggered-for-uninstall-when-not-installed-tp7589579.html
Sent from the wix-users mailing list archive at Nabble.com.
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60134071iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Quick question about WiXCA - CAQuietExec
Thanks, at first it did not seem to work as the calling app did have failures and they did not cause the install to fail, but then we had another error that did fail the install. So we figured that some returns were not a complete failure and therefore the return did not cause an install failure and some are. So it seems to work as expected. From: Blair Murri-3 [via Windows Installer XML (WiX) toolset] [mailto:ml-node+s687559n7589379...@n2.nabble.com] Sent: Wednesday, October 02, 2013 10:49 AM To: Tim Mayert Subject: Re: Quick question about WiXCA - CAQuietExec Any text written by the app (both stdout and stderr) is written to the log, and any non-zero exit code is interpreted as a failure causing CAQuietExec to also return a failure. Date: Tue, 24 Sep 2013 10:45:53 -0700 From: [hidden email]/user/SendEmail.jtp?type=nodenode=7589379i=0 To: [hidden email]/user/SendEmail.jtp?type=nodenode=7589379i=1 Subject: [WiX-users] Quick question about WiXCA - CAQuietExec We have an app that when runs produces a quick Dos Window and then goes away. So we are using the WiXCA - CAQuietExec custom action to call the app in quite mode. This work great, but my question is if the App fails and I have the WiXCA custom action set to Return the error code will it return the failure of the app that CAQuietExec triggered or will it only return an error return code if the WiXCA returned a failure and ignore what comes from the triggered app? I just have to confirm that if the app fails that the failure is returned to the CA instead of just returning to no where and as long as the quiet app triggered the app successfully then no failure is returned to the install. Thanks. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Quick-question-about-WiXCA-CAQuietExec-tp7589181.html Sent from the wix-users mailing list archive at Nabble.com. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk ___ WiX-users mailing list [hidden email]/user/SendEmail.jtp?type=nodenode=7589379i=2 https://lists.sourceforge.net/lists/listinfo/wix-users -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ WiX-users mailing list [hidden email]/user/SendEmail.jtp?type=nodenode=7589379i=3 https://lists.sourceforge.net/lists/listinfo/wix-users If you reply to this email, your message will be added to the discussion below: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Quick-question-about-WiXCA-CAQuietExec-tp7589181p7589379.html To unsubscribe from Quick question about WiXCA - CAQuietExec, click herehttp://windows-installer-xml-wix-toolset.687559.n2.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=7589181code=VGltTWF5ZXJ0QHNtYXJ0dGVjaC5jb218NzU4OTE4MXwtMTcxMzc3MTUwNA==. NAMLhttp://windows-installer-xml-wix-toolset.687559.n2.nabble.com/template/NamlServlet.jtp?macro=macro_viewerid=instant_html%21nabble%3Aemail.namlbase=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespacebreadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Quick-question-about-WiXCA-CAQuietExec-tp7589181p7589383.html Sent from the wix-users mailing list archive at Nabble.com. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Quick question about WiXCA - CAQuietExec
We have an app that when runs produces a quick Dos Window and then goes away. So we are using the WiXCA - CAQuietExec custom action to call the app in quite mode. This work great, but my question is if the App fails and I have the WiXCA custom action set to Return the error code will it return the failure of the app that CAQuietExec triggered or will it only return an error return code if the WiXCA returned a failure and ignore what comes from the triggered app? I just have to confirm that if the app fails that the failure is returned to the CA instead of just returning to no where and as long as the quiet app triggered the app successfully then no failure is returned to the install. Thanks. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Quick-question-about-WiXCA-CAQuietExec-tp7589181.html Sent from the wix-users mailing list archive at Nabble.com. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Shortcut creation seems to cause sxs assembly error in Event Viewer
I am working on an issue that we are seeing when our WiX project creates shortcuts to target files that require assemblies to be already installed onto the machine. Okay here is the issue. We run our install, all shortcuts are created and the install completes without issues. The app and all shortcuts work and therefore everything looks okay, but when we open up the Event Viewer it will show side by side assembly errors on these apps. We thought that something was triggering the apps during install, but again we see no errors during the install. But in event viewer there were always 2 sxs errors for each app that had a shortcut created. So we checked the install and under the Shortcut Id entries we were only referencing IconIndex and Target .exe. So we figured that during install it has to extract the shortcut from the .exe and therefore that is what caused the issue. So we switched to use Icon=file.ico, where we just reference a .ico file. We ran the install again and this time instead of 2 sxs errors for each app there is only one. So just to verify we turned off the shortcuts and after running the install there are NO sxs errors. So has anyone ran into this before and if so how do we fix it. It is not a high bug as the app installs and runs and it is only in Event Viewer that you see these, but in the case where our install or app fail we normally ask for Install and Event Viewer logs and having these extra sxs errors just makes it more confusing as to what the actual errors are. So if anyone knows how to fix this or other methods to avoid these issues that would be great. Thanks. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Shortcut-creation-seems-to-cause-sxs-assembly-error-in-Event-Viewer-tp7589133.html Sent from the wix-users mailing list archive at Nabble.com. -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] torch transforms
Hello Enrique DomÃnguez, We are basically in the same boat.. We have quite a few WiX projects that contain between 12 and 18 language cultures and at the moment our project files are set up to build all cultures and then using the Torch commands to generate all the language .mst. This process takes quite a while to complete. So if you discover a faster method, that we can automate through our TeamCity build server, that reduces the time to perform these builds then let me know. If we can simple build the English msi and then have all the language .mst generated from that then that would be great and save quite a lot of times during our builds. Thanks. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/torch-transforms-tp7588172p7588293.html Sent from the wix-users mailing list archive at Nabble.com. -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Adding language transform .mst's to Burn Bundle Chain?
Ok Phill, I was able to download and extract the files from your zip. I tried out both .exe that you created and created a German VM to test on. They did show the German EULA and when I switched to my French image it showed the English EULA. I then updated your German .wxl file with German text strings so that I could see if I could build it and show the UI in German just to verify the UI as well as to add a French file, but when the build completes my Symantec AntiVirus Detection pops up stating there is a Heuristic Virus in the .exe file that is created and therefore it will NOT let me create the .exe file. So there is something in the code that you supplied that it does not like and therefore I can not test the UI correctly. Now if I go back to my project, I'll try it again with copying the WiXBalExtention.dll from the specified link and place into my bin folder to test and see it that makes a difference. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Adding-language-transform-mst-s-to-Burn-Bundle-Chain-tp7586986p7588177.html Sent from the wix-users mailing list archive at Nabble.com. -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Adding language transform .mst's to Burn Bundle Chain?
Placing the WiXBalExtentionExt.dll file into my WiX 3.7 bin folder did not make a difference. So was there anything else you had to do or did to make this work? Can both 3.7 and 3.8 reside on the machine at the same time? If as you said that 3.8 already has the fix in it then I was thinking of installing 3.8 on my main machine to test and verify if it works without changing anything in my Burn wrapper code. If it does then I'll make the suggestion to our group to upgrade to 3.8 when we can, but if it does not simply work out of the box then I'll have to do more research before I can make the suggestion to upgrade to 3.8. Tim. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Adding-language-transform-mst-s-to-Burn-Bundle-Chain-tp7586986p7588181.html Sent from the wix-users mailing list archive at Nabble.com. -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Adding language transform .mst's to Burn Bundle Chain?
Okay after getting your install to build I test and it will still not show German or French licenses on German and French systems. This is still building with WiX 3.7 and having the updated WiXBalExtentionExt.dll file into my WiX 3.7 bin folder. So just having no luck what so ever. I'll look at installing Wix 3.8 and giving that a try. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Adding-language-transform-mst-s-to-Burn-Bundle-Chain-tp7586986p7588193.html Sent from the wix-users mailing list archive at Nabble.com. -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Adding language transform .mst's to Burn Bundle Chain?
Okay, when I installed the latest WiX 3.8 and Updated my project files to use 3.8 the build correctly built in the UI so that on German the UI/EULA is German, on French it is French and on English and unsupported languages it shows English. So yes 3.8 has the fixes in it. So my version of 3.7 has an issue and therefore have to wonder about that. When you update your 3.7 with the WixBalExtensionExt.dll file was this the only file that you copied into your WiX 3.7\bin folder and rename it to WixBalExtension.dll or did you have to update any other files? -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Adding-language-transform-mst-s-to-Burn-Bundle-Chain-tp7586986p7588201.html Sent from the wix-users mailing list archive at Nabble.com. -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Next Published Release (3.8) scheduled?
I would like to know when WiX 3.8 will become a published released build? We normally upgrade when a release is published and therefore was wondering if there is a schedule when 3.8 will be released? We are trying to create a Burn .exe with translated UI and 3.7 currently has a bug in it that prevents the UI to come up in the System/User OS language and will only work if -lang is passed to the .exe. There is suppose to be a fix for this, but have been unable to get that fix to work. So in testing the latest WiX 3.8 the burn .exe correctly shows the UI in the language of the OS as it sits at the moment. So it would seem that upgrading to 3.8 would be the easies solution to fix our issues. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Next-Published-Release-3-8-scheduled-tp7588203.html Sent from the wix-users mailing list archive at Nabble.com. -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
