Re: [WiX-users] Client update from 3.5 MSI to 3.6
So what do I need to make sure in order to achieve this? I noticed that we now have a bundle upgradecode, and the existing msi upgradecode,. I would assume that the msi upgrade code has to be the same as the old msi. The bundle upgrade code will be used when? When upgrading to a newer bundle? -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: 28 November 2012 04:25 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Client update from 3.5 MSI to 3.6 You should be fine as long as you do a major upgrade. On Tue, Nov 27, 2012 at 9:32 AM, Stelios Kyprou wrote: > Hello all, > Quick question: If we have a product installed for a client, using the > pre-burn (WiX 3.5) installer, and we give the client a newer product > version installer, but built with 3.6, using Burn, > a) Will the product upgrade as expected? > b) If (a) is "Yes, it will upgrade", then what if we changed the MSI, i.e. > redesigned it (e.g. removed merge modules, added new features, changed > existing features)? > > Thanks! > > > This message w/attachments (message) is intended solely for the use of > the intended recipient(s) and may contain information that is > privileged, confidential or proprietary. If you are not an intended > recipient, please notify the sender, and then please delete and > destroy all copies and attachments, and be advised that any review or > dissemination of, or the taking of any action in reliance on, the > information contained in or attached to this message is prohibited. > Formicary cannot guarantee that this message is secure or free of errors or > viruses. > > > -- > Monitor your physical, virtual and cloud infrastructure from > a single web console. Get in-depth insight into apps, servers, > databases, vmware, SAP, cloud infrastructure, etc. Download 30-day > Free Trial. > Pricing starts from $795 for 25 servers or applications! > http://p.sf.net/sfu/zoho_dev2dev_nov > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > -- virtually, Rob Mensching http://RobMensching.com LLC -- Keep yourself connected to Go Parallel: INSIGHTS What's next for parallel hardware, programming and related areas? Interviews and blogs by thought leaders keep you ahead of the curve. http://goparallel.sourceforge.net ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. Formicary cannot guarantee that this message is secure or free of errors or viruses. -- Keep yourself connected to Go Parallel: INSIGHTS What's next for parallel hardware, programming and related areas? Interviews and blogs by thought leaders keep you ahead of the curve. http://goparallel.sourceforge.net ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Client update from 3.5 MSI to 3.6
Hello all, Quick question: If we have a product installed for a client, using the pre-burn (WiX 3.5) installer, and we give the client a newer product version installer, but built with 3.6, using Burn, a) Will the product upgrade as expected? b) If (a) is "Yes, it will upgrade", then what if we changed the MSI, i.e. redesigned it (e.g. removed merge modules, added new features, changed existing features)? Thanks! This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. Formicary cannot guarantee that this message is secure or free of errors or viruses. -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Install location of installed package
Is there a way to detect the install location of an already installed package via the bootstrapper application in c#? Maybe during the "Detect..." events? Also, on a more general note, is there a place where I can see what each of the eventArgs enums mean and do? Some have comments, like RelatedOperation, others don't, i.e. RequestState, ActionState... This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. Formicary cannot guarantee that this message is secure or free of errors or viruses. -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Editing files from the Bootstrapper Application
There is no reason to be honest. They can end up being in the same MSI in different features. I have 2 MSI's now, because after migrating from 3.5 to 6, I decided to use Burn. This meant removing my Merge Modules (msm A & B) (since it's not recommended anyway). So I converted them into msi's which was an easy change (MSI A and B). The MSI which was adding the msm's together in 3.5 is now my bootstrapper, chaining the MSI's (A and B) together. I will eventually merge them into 1, in multiple features.. This will not help with the problem I have though I think... It's going to be more elegant for sure;) -Original Message- From: Nick Ramirez [mailto:nickra...@hotmail.com] Sent: 21 November 2012 14:41 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Editing files from the Bootstrapper Application I'm curious about your setup. What is it about it that make having two MSIs worthwhile? Did you not want to have two Features in a single MSI? -----Original Message- From: Stelios Kyprou [mailto:stelios.kyp...@fcg.im] Sent: 21 November 2012 12:34 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Editing files from the Bootstrapper Application Hi there, I'm having a Bootsrtapper application, where I have 2 msi's chained. A and B Msi A represents a codebase, that enables functionality based on a configuration file. Msi B depends on A. In the UI, I am planning to have a screen, where you can select what functionality you want from the product. This will decide: a) What to write to the config file when it is instlled via util:XmlConfig in MSI A b) Whether to install MSI B. What I want is: When I run the BA again, if I change the desired functionality: a)Update the config file based on new functionality b)Install/Delete MSI B if the functionality it provides is wanted/not wanted anymore. What I am not sure about, is how to approach point (a). When I initially install, I can provide the values to insert in the config file to MSI A as a property. But when I update my selection later on, how should I update this file? Are Features a good approach? If yes, does this mean I have to reference the same file in multiple features? Or do I just do it in code in the BA, without invoking any MSI actions? (Do not Plan/Apply anything, just do the config edit action). Thanks in advance This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. Formicary cannot guarantee that this message is secure or free of errors or viruses. -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. Formicary cannot guarantee that this message is secure or free of errors or viruses. -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Editing files from the Bootstrapper Application
Hi there, I'm having a Bootsrtapper application, where I have 2 msi's chained. A and B Msi A represents a codebase, that enables functionality based on a configuration file. Msi B depends on A. In the UI, I am planning to have a screen, where you can select what functionality you want from the product. This will decide: a) What to write to the config file when it is instlled via util:XmlConfig in MSI A b) Whether to install MSI B. What I want is: When I run the BA again, if I change the desired functionality: a)Update the config file based on new functionality b)Install/Delete MSI B if the functionality it provides is wanted/not wanted anymore. What I am not sure about, is how to approach point (a). When I initially install, I can provide the values to insert in the config file to MSI A as a property. But when I update my selection later on, how should I update this file? Are Features a good approach? If yes, does this mean I have to reference the same file in multiple features? Or do I just do it in code in the BA, without invoking any MSI actions? (Do not Plan/Apply anything, just do the config edit action). Thanks in advance This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. Formicary cannot guarantee that this message is secure or free of errors or viruses. -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Adding the Secure attribute in a Property fails to build merge module in 3.6
https://sourceforge.net/p/wix/bugs/3108/ -Original Message- From: Bob Arnson [mailto:b...@joyofsetup.com] Sent: 04 October 2012 03:32 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Adding the Secure attribute in a Property fails to build merge module in 3.6 On 03-Oct-12 06:40, Stelios Kyprou wrote: > Strange right? Indeed. Please file a bug. -- sig://boB http://joyofsetup.com/ -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. Formicary cannot guarantee that this message is secure or free of errors or viruses. -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WixLibs do not seem to work after 3.6 upgrade.
https://sourceforge.net/p/wix/bugs/3105/ -Original Message- From: Bob Arnson [mailto:b...@joyofsetup.com] Sent: 03 October 2012 04:18 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] WixLibs do not seem to work after 3.6 upgrade. On 02-Oct-12 11:51, Hoover, Jacob wrote: > Well, in 3.7 I could see logging it as a bug where the documentation should > state that at a minimum the Fragment is required. One could also ask for a > more descript error message during the compile. And to verify the behavior change. -- sig://boB http://joyofsetup.com/ -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. Formicary cannot guarantee that this message is secure or free of errors or viruses. -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Adding the Secure attribute in a Property fails to build merge module in 3.6
I narrowed it down to one use case, but I don't know why this is happening: It's when I have a custom action project included in the MergeModule, and I define a custom action that calls it (you don't even have to schedule it in the execute sequence). Then if I make an irrelevant property as Secure, it fails. The following example replicates this (in a merge module project): http://schemas.microsoft.com/wix/2006/wi";> Strange right? -Original Message- From: Bob Arnson [mailto:b...@joyofsetup.com] Sent: 03 October 2012 04:18 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Adding the Secure attribute in a Property fails to build merge module in 3.6 On 02-Oct-12 11:23, Stelios Kyprou wrote: > After upgrading from 3.5 to 3.6, when building a merge module I get the > following error: Sounds like a bug. Please file with a small merge module project. -- sig://boB http://joyofsetup.com/ -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. Formicary cannot guarantee that this message is secure or free of errors or viruses. -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WixLibs do not seem to work after 3.6 upgrade.
So there is no point logging it, since it works in 3.6 right? It wasn't working in 3.5 only. -Original Message- From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com] Sent: 02 October 2012 16:24 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] WixLibs do not seem to work after 3.6 upgrade. I'd log it for 3.7. The odds of anything changing in 3.6 are very low, unless it's critical. The odds of a 3.5 fix are near nil. -Original Message- From: Stelios Kyprou [mailto:stelios.kyp...@fcg.im] Sent: Tuesday, October 02, 2012 10:17 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] WixLibs do not seem to work after 3.6 upgrade. I would like to, but when I go on sourceforge to create an issue, I'm only allowed to select versions 3.7 or 4.0. This is a 3.5 bug... -Original Message- From: Bob Arnson [mailto:b...@joyofsetup.com] Sent: 02 October 2012 02:40 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] WixLibs do not seem to work after 3.6 upgrade. On 01-Oct-12 12:12, Stelios Kyprou wrote: > In 3.6 by having this as follows worked: > xmlns="http://schemas.microsoft.com/wix/2006/wi";> > I'm surprised that worked in either version: The schema definitely implies something's required. But please file a bug. -- sig://boB http://joyofsetup.com/ -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. Formicary cannot guarantee that this message is secure or free of errors or viruses. -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. Formicary cannot guarantee that this message is secure or free of errors or viruses. -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Adding the Secure attribute in a Property fails to build merge module in 3.6
After upgrading from 3.5 to 3.6, when building a merge module I get the following error: error LGHT0136: There was an error importing table 'Property' from file 'C:\\Local\Temp\lpikpxrr\Property.idt' The file looks like this: PropertyValue s72 l0 PropertyProperty ALLUSERS1 DELETEORPHANEDFILES 1 CONNECTORWINDOWSSERVICENAME.879D8938_14F7_4C42_910E_C588197F88F1 Formicary Chat Connector Service CONNECTORWINDOWSSERVICEDISPLAYNAME.879D8938_14F7_4C42_910E_C588197F88F1 Formicary Connector Service CONNECTORWINDOWSSERVICEDESCRIPTION.879D8938_14F7_4C42_910E_C588197F88F1 Formicary Connector Service EVENTLOGNAME.879D8938_14F7_4C42_910E_C588197F88F1 Application CONNECTOREVENTLOGSOURCE.879D8938_14F7_4C42_910E_C588197F88F1Connector Server SecureCustomProperties WINDOWSPASSWORD MsiHiddenProperties I also noticed that by removing the Secure attribute from the Properties that had it set, made the merge module build. So instead of this: Having this: Is there a reason why this worked in 3.5 and not in 3.6? Thanks, Stel This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. Formicary cannot guarantee that this message is secure or free of errors or viruses. -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WixLibs do not seem to work after 3.6 upgrade.
I would like to, but when I go on sourceforge to create an issue, I'm only allowed to select versions 3.7 or 4.0. This is a 3.5 bug... -Original Message- From: Bob Arnson [mailto:b...@joyofsetup.com] Sent: 02 October 2012 02:40 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] WixLibs do not seem to work after 3.6 upgrade. On 01-Oct-12 12:12, Stelios Kyprou wrote: > In 3.6 by having this as follows worked: > xmlns="http://schemas.microsoft.com/wix/2006/wi";> > I'm surprised that worked in either version: The schema definitely implies something's required. But please file a bug. -- sig://boB http://joyofsetup.com/ -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. Formicary cannot guarantee that this message is secure or free of errors or viruses. -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WixLibs do not seem to work after 3.6 upgrade.
First paragraph I meant to say 3.5 -Original Message- From: Stelios Kyprou [mailto:stelios.kyp...@fcg.im] Sent: 01 October 2012 17:12 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] WixLibs do not seem to work after 3.6 upgrade. Ok I found the problem! You know how when you create a wixlib project, you have a default Library.wxs file? In 3.6 by having this as follows worked: http://schemas.microsoft.com/wix/2006/wi";> With 3.6, this won't work...you NEED to have the fragment tag as well...the way it is when it is created by deafult: http://schemas.microsoft.com/wix/2006/wi";> I never had a look into the wix codebase, but something must have changed so that this doesn't work? If it helps, this is the error I was getting in the output window in VS: C:\\FCGLocales2.wixlib(0,0): error LGHT0133: The end element matching the 'wixLibrary' start element was not found. Done building project "GcwaMerge.wixproj" -- FAILED. This is when I build the merge module that uses the wixlib project. The wixlib project builds successfully. -Original Message- From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Sent: 01 October 2012 16:54 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] WixLibs do not seem to work after 3.6 upgrade. We have 3.6 wixlibs building with no problems and I can't see any relevant bugs in the bugs database. Wix 3.6 was mostly Burn rather than core toolset changes. I wasn't thinking of the strings being bad, so much as the xml elements themselves. The error message makes it sound like badly formed XML but unless you're transforming the intermediate file for some reason, then I can't see why there would be any. -Original Message- From: Stelios Kyprou [mailto:stelios.kyp...@fcg.im] Sent: 01 October 2012 16:34 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] WixLibs do not seem to work after 3.6 upgrade. I don't think so..but just to be sure, I changed all the values to a single string char. So for example, one string definition would end up being: So there are a bunch of these String definitions between http://schemas.microsoft.com/wix/2006/libraries";>http://schemas.microsoft.com/wix/2006/localization";> So is this not an expected behaviour? -Original Message- From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Sent: 01 October 2012 16:18 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] WixLibs do not seem to work after 3.6 upgrade. Is the wixlib xml valid ? There might be a malformed element somewhere inside. -Original Message- From: Stelios Kyprou [mailto:stelios.kyp...@fcg.im] Sent: 01 October 2012 15:47 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] WixLibs do not seem to work after 3.6 upgrade. Hello, We upgraded from WiX3.5.2519 to 3.6.3303.1, and it seems like wixlibs are not working as expected anymore in our projects. The library project builds, but when a merge module attempts to build(which has the wixlib project as a reference), I get the following error: "The end element matching the 'wixLibrary' start element was not found". It seems to have the closing element though, as it looks like this: http://schemas.microsoft.com/wix/2006/libraries";>http://schemas.microsoft.com/wix/2006/localization";> Any ideas why? I'm using VS2012, on Windows 8! Thanks in advance! This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. Formicary cannot guarantee that this message is secure or free of errors or viruses. - - Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users SDL PLC confidential, all rights reserved. If you are not the intended recipient of this mail SDL requests and requires that you delete it without acting upon or copying any of its contents, and we further request that you advise us. SDL PLC is a public limited company registered in Eng
Re: [WiX-users] WixLibs do not seem to work after 3.6 upgrade.
Ok I found the problem! You know how when you create a wixlib project, you have a default Library.wxs file? In 3.6 by having this as follows worked: http://schemas.microsoft.com/wix/2006/wi";> With 3.6, this won't work...you NEED to have the fragment tag as well...the way it is when it is created by deafult: http://schemas.microsoft.com/wix/2006/wi";> I never had a look into the wix codebase, but something must have changed so that this doesn't work? If it helps, this is the error I was getting in the output window in VS: C:\\FCGLocales2.wixlib(0,0): error LGHT0133: The end element matching the 'wixLibrary' start element was not found. Done building project "GcwaMerge.wixproj" -- FAILED. This is when I build the merge module that uses the wixlib project. The wixlib project builds successfully. -Original Message- From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Sent: 01 October 2012 16:54 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] WixLibs do not seem to work after 3.6 upgrade. We have 3.6 wixlibs building with no problems and I can't see any relevant bugs in the bugs database. Wix 3.6 was mostly Burn rather than core toolset changes. I wasn't thinking of the strings being bad, so much as the xml elements themselves. The error message makes it sound like badly formed XML but unless you're transforming the intermediate file for some reason, then I can't see why there would be any. -Original Message- From: Stelios Kyprou [mailto:stelios.kyp...@fcg.im] Sent: 01 October 2012 16:34 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] WixLibs do not seem to work after 3.6 upgrade. I don't think so..but just to be sure, I changed all the values to a single string char. So for example, one string definition would end up being: So there are a bunch of these String definitions between http://schemas.microsoft.com/wix/2006/libraries";>http://schemas.microsoft.com/wix/2006/localization";> So is this not an expected behaviour? -Original Message- From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Sent: 01 October 2012 16:18 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] WixLibs do not seem to work after 3.6 upgrade. Is the wixlib xml valid ? There might be a malformed element somewhere inside. -Original Message- From: Stelios Kyprou [mailto:stelios.kyp...@fcg.im] Sent: 01 October 2012 15:47 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] WixLibs do not seem to work after 3.6 upgrade. Hello, We upgraded from WiX3.5.2519 to 3.6.3303.1, and it seems like wixlibs are not working as expected anymore in our projects. The library project builds, but when a merge module attempts to build(which has the wixlib project as a reference), I get the following error: "The end element matching the 'wixLibrary' start element was not found". It seems to have the closing element though, as it looks like this: http://schemas.microsoft.com/wix/2006/libraries";>http://schemas.microsoft.com/wix/2006/localization";> Any ideas why? I'm using VS2012, on Windows 8! Thanks in advance! This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. Formicary cannot guarantee that this message is secure or free of errors or viruses. - - Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users SDL PLC confidential, all rights reserved. If you are not the intended recipient of this mail SDL requests and requires that you delete it without acting upon or copying any of its contents, and we further request that you advise us. SDL PLC is a public limited company registered in England and Wales. Registered number: 02675207. Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK. - - Got visibility? Most devs has no idea what their production app looks like. Find
Re: [WiX-users] WixLibs do not seem to work after 3.6 upgrade.
I don't think so..but just to be sure, I changed all the values to a single string char. So for example, one string definition would end up being: So there are a bunch of these String definitions between http://schemas.microsoft.com/wix/2006/libraries";>http://schemas.microsoft.com/wix/2006/localization";> So is this not an expected behaviour? -Original Message- From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Sent: 01 October 2012 16:18 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] WixLibs do not seem to work after 3.6 upgrade. Is the wixlib xml valid ? There might be a malformed element somewhere inside. -Original Message- From: Stelios Kyprou [mailto:stelios.kyp...@fcg.im] Sent: 01 October 2012 15:47 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] WixLibs do not seem to work after 3.6 upgrade. Hello, We upgraded from WiX3.5.2519 to 3.6.3303.1, and it seems like wixlibs are not working as expected anymore in our projects. The library project builds, but when a merge module attempts to build(which has the wixlib project as a reference), I get the following error: "The end element matching the 'wixLibrary' start element was not found". It seems to have the closing element though, as it looks like this: http://schemas.microsoft.com/wix/2006/libraries";>http://schemas.microsoft.com/wix/2006/localization";> Any ideas why? I'm using VS2012, on Windows 8! Thanks in advance! This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. Formicary cannot guarantee that this message is secure or free of errors or viruses. - - Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users SDL PLC confidential, all rights reserved. If you are not the intended recipient of this mail SDL requests and requires that you delete it without acting upon or copying any of its contents, and we further request that you advise us. SDL PLC is a public limited company registered in England and Wales. Registered number: 02675207. Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK. -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. Formicary cannot guarantee that this message is secure or free of errors or viruses. -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] WixLibs do not seem to work after 3.6 upgrade.
Hello, We upgraded from WiX3.5.2519 to 3.6.3303.1, and it seems like wixlibs are not working as expected anymore in our projects. The library project builds, but when a merge module attempts to build(which has the wixlib project as a reference), I get the following error: "The end element matching the 'wixLibrary' start element was not found". It seems to have the closing element though, as it looks like this: http://schemas.microsoft.com/wix/2006/libraries";>http://schemas.microsoft.com/wix/2006/localization";> Any ideas why? I'm using VS2012, on Windows 8! Thanks in advance! This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. Formicary cannot guarantee that this message is secure or free of errors or viruses. -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Removing through the UI mode does not promptfor privileges
That didn't seem to work either ... -Original Message- From: Stelios Kyprou [mailto:stelios.kyp...@fcg.im] Sent: 23 December 2011 11:04 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Removing through the UI mode does not promptfor privileges Yeah could do! I'm not showing the feature selection screen so it shouldn't matter. Will let you know if it works -Original Message- From: David Watson [mailto:dwat...@sdl.com] Sent: 23 December 2011 10:42 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Removing through the UI mode does not promptfor privileges Feature conditions are always a pain to work out. Could you move the condition onto the component(s)? -Original Message- From: Stelios Kyprou [mailto:stelios.kyp...@fcg.im] Sent: 23 December 2011 09:47 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Removing through the UI mode does not promptfor privileges I already have that condition in the code...So that didn't help with elevation. I really think that it's the feature installation condition, because when I made the feature install without a conditional set of it's level, it worked as I want it to... So there must be a reason why this happens... -Original Message- From: Sameer Arora [mailto:arora...@gmail.com] Sent: 22 December 2011 22:41 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Removing through the UI mode does not prompt for privileges If the requirement was to invoke elevation prompt for both install and uninstall (be it in from Program and Features or through the Maintenance mode) will this work?: add this condition somewhere in the scope Privileged I understand "Admin privileges" may mean different from "Elevation" that you were looking for. Sameer On Thu, Dec 22, 2011 at 5:23 AM, Stelios Kyprou wrote: > Ok it seems that Remove=ALL was not set for the following reason: > One of the features had a conditional installation, as following: > > Level="0"> > > > > > > And when uninstalling via the UI REMOVE was not set to ALL. > ALSO, I noticed the components of that Feature were not removed from > the installation directory either... > Is there a scenario where STSADM2010 gets set when installing and NOT > when re-running the installer for removal? > This is how I set the property in product.wxs: > > >Path="[CommonFiles64Folder]Microsoft Shared\web server extensions\14\bin"> > > > > > Thanks, > Stelios > > -Original Message- > From: David Watson [mailto:dwat...@sdl.com] > Sent: 21 December 2011 16:06 > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Removing through the UI mode doesnot prompt > forprivileges > > Sorry I am not a UI expert as we use a chainer for our UI. > > I think your Maintenance UI needs to be setting the REMOVE to all somehow. > Try looking in the wix standard or mondo UI to see how that does it. > > If your CA needs to be dependent on the MSI being uninstalled it needs > to be scheduled appropriately, i.e. after the REMOVE has been set correctly. > > Dave > > -Original Message- > From: Stelios Kyprou [mailto:stelios.kyp...@fcg.im] > Sent: 21 December 2011 15:45 > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Removing through the UI mode doesnot prompt > forprivileges > > By the way my CA is scheduled AFTER InstallInitialize > > -Original Message- > From: Stelios Kyprou [mailto:stelios.kyp...@fcg.im] > Sent: 21 December 2011 15:42 > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Removing through the UI mode does not prompt > forprivileges > > You are right David, REMOVE was set to the features that were installed. > So I changed the condition so that the CA runs. > One problem down. > Now after completion, I can still see the product in "Products and > Features", and the files are not removed from the install location. > What do I need to do so that my Remove action via ui does the same > thing as when running the uninstallation process via "Products and Features"? > > Thanks in advance, > Stelios > > -Original Message- > From: David Watson [mailto:dwat...@sdl.com] > Sent: 21 December 2011 14:52 > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Removing through the UI mode does not prompt > forprivileges > > When is your custom action scheduled? > > When you uninstall through the MSI your MSI is in maintenance mode.
Re: [WiX-users] Removing through the UI mode does not promptfor privileges
Yeah could do! I'm not showing the feature selection screen so it shouldn't matter. Will let you know if it works -Original Message- From: David Watson [mailto:dwat...@sdl.com] Sent: 23 December 2011 10:42 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Removing through the UI mode does not promptfor privileges Feature conditions are always a pain to work out. Could you move the condition onto the component(s)? -Original Message----- From: Stelios Kyprou [mailto:stelios.kyp...@fcg.im] Sent: 23 December 2011 09:47 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Removing through the UI mode does not promptfor privileges I already have that condition in the code...So that didn't help with elevation. I really think that it's the feature installation condition, because when I made the feature install without a conditional set of it's level, it worked as I want it to... So there must be a reason why this happens... -Original Message- From: Sameer Arora [mailto:arora...@gmail.com] Sent: 22 December 2011 22:41 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Removing through the UI mode does not prompt for privileges If the requirement was to invoke elevation prompt for both install and uninstall (be it in from Program and Features or through the Maintenance mode) will this work?: add this condition somewhere in the scope Privileged I understand "Admin privileges" may mean different from "Elevation" that you were looking for. Sameer On Thu, Dec 22, 2011 at 5:23 AM, Stelios Kyprou wrote: > Ok it seems that Remove=ALL was not set for the following reason: > One of the features had a conditional installation, as following: > > Level="0"> > > > > > > And when uninstalling via the UI REMOVE was not set to ALL. > ALSO, I noticed the components of that Feature were not removed from > the installation directory either... > Is there a scenario where STSADM2010 gets set when installing and NOT > when re-running the installer for removal? > This is how I set the property in product.wxs: > > >Path="[CommonFiles64Folder]Microsoft Shared\web server extensions\14\bin"> > > > > > Thanks, > Stelios > > -Original Message- > From: David Watson [mailto:dwat...@sdl.com] > Sent: 21 December 2011 16:06 > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Removing through the UI mode doesnot prompt > forprivileges > > Sorry I am not a UI expert as we use a chainer for our UI. > > I think your Maintenance UI needs to be setting the REMOVE to all somehow. > Try looking in the wix standard or mondo UI to see how that does it. > > If your CA needs to be dependent on the MSI being uninstalled it needs > to be scheduled appropriately, i.e. after the REMOVE has been set correctly. > > Dave > > -Original Message- > From: Stelios Kyprou [mailto:stelios.kyp...@fcg.im] > Sent: 21 December 2011 15:45 > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Removing through the UI mode doesnot prompt > forprivileges > > By the way my CA is scheduled AFTER InstallInitialize > > -Original Message- > From: Stelios Kyprou [mailto:stelios.kyp...@fcg.im] > Sent: 21 December 2011 15:42 > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Removing through the UI mode does not prompt > forprivileges > > You are right David, REMOVE was set to the features that were installed. > So I changed the condition so that the CA runs. > One problem down. > Now after completion, I can still see the product in "Products and > Features", and the files are not removed from the install location. > What do I need to do so that my Remove action via ui does the same > thing as when running the uninstallation process via "Products and Features"? > > Thanks in advance, > Stelios > > -Original Message- > From: David Watson [mailto:dwat...@sdl.com] > Sent: 21 December 2011 14:52 > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Removing through the UI mode does not prompt > forprivileges > > When is your custom action scheduled? > > When you uninstall through the MSI your MSI is in maintenance mode. > This probably means that REMOVE is not set to ALL by default in case > you choose some other behaviour. > Check a log to see when REMOVE is being set and what to. > > > -Original Message- > From: Dan Gough [mailto:goug...@gmail.com] > Sent: 21 December 2011 13:20
Re: [WiX-users] Removing through the UI mode does not prompt for privileges
I already have that condition in the code...So that didn't help with elevation. I really think that it's the feature installation condition, because when I made the feature install without a conditional set of it's level, it worked as I want it to... So there must be a reason why this happens... -Original Message- From: Sameer Arora [mailto:arora...@gmail.com] Sent: 22 December 2011 22:41 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Removing through the UI mode does not prompt for privileges If the requirement was to invoke elevation prompt for both install and uninstall (be it in from Program and Features or through the Maintenance mode) will this work?: add this condition somewhere in the scope Privileged I understand "Admin privileges" may mean different from "Elevation" that you were looking for. Sameer On Thu, Dec 22, 2011 at 5:23 AM, Stelios Kyprou wrote: > Ok it seems that Remove=ALL was not set for the following reason: > One of the features had a conditional installation, as following: > > Level="0"> > > > > > > And when uninstalling via the UI REMOVE was not set to ALL. > ALSO, I noticed the components of that Feature were not removed from > the installation directory either... > Is there a scenario where STSADM2010 gets set when installing and NOT > when re-running the installer for removal? > This is how I set the property in product.wxs: > > >Path="[CommonFiles64Folder]Microsoft Shared\web server extensions\14\bin"> > > > > > Thanks, > Stelios > > -Original Message- > From: David Watson [mailto:dwat...@sdl.com] > Sent: 21 December 2011 16:06 > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Removing through the UI mode doesnot prompt > forprivileges > > Sorry I am not a UI expert as we use a chainer for our UI. > > I think your Maintenance UI needs to be setting the REMOVE to all somehow. > Try looking in the wix standard or mondo UI to see how that does it. > > If your CA needs to be dependent on the MSI being uninstalled it needs > to be scheduled appropriately, i.e. after the REMOVE has been set correctly. > > Dave > > -Original Message- > From: Stelios Kyprou [mailto:stelios.kyp...@fcg.im] > Sent: 21 December 2011 15:45 > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Removing through the UI mode doesnot prompt > forprivileges > > By the way my CA is scheduled AFTER InstallInitialize > > -Original Message- > From: Stelios Kyprou [mailto:stelios.kyp...@fcg.im] > Sent: 21 December 2011 15:42 > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Removing through the UI mode does not prompt > forprivileges > > You are right David, REMOVE was set to the features that were installed. > So I changed the condition so that the CA runs. > One problem down. > Now after completion, I can still see the product in "Products and > Features", and the files are not removed from the install location. > What do I need to do so that my Remove action via ui does the same > thing as when running the uninstallation process via "Products and Features"? > > Thanks in advance, > Stelios > > -Original Message- > From: David Watson [mailto:dwat...@sdl.com] > Sent: 21 December 2011 14:52 > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Removing through the UI mode does not prompt > forprivileges > > When is your custom action scheduled? > > When you uninstall through the MSI your MSI is in maintenance mode. > This probably means that REMOVE is not set to ALL by default in case > you choose some other behaviour. > Check a log to see when REMOVE is being set and what to. > > > -Original Message- > From: Dan Gough [mailto:goug...@gmail.com] > Sent: 21 December 2011 13:20 > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Removing through the UI mode does not prompt > forprivileges > > I'm new to WiX so don't know how to do it, but I think you need the > elevation shield attribute 0x0080 set in the Control table on the > button used to uninstall the application. Try editing the msi package > using InstEd to see if it fixes the problem, then you can figure out > how to achieve it in WiX. > On Dec 21, 2011 11:55 AM, "Stelios Kyprou" wrote: > > > I don't think that is the problem...I need to provide same > > functionality when uninstalling from Programs and Features for whe
Re: [WiX-users] Removing through the UI mode does not prompt for privileges
Ok it seems that Remove=ALL was not set for the following reason: One of the features had a conditional installation, as following: And when uninstalling via the UI REMOVE was not set to ALL. ALSO, I noticed the components of that Feature were not removed from the installation directory either... Is there a scenario where STSADM2010 gets set when installing and NOT when re-running the installer for removal? This is how I set the property in product.wxs: Thanks, Stelios -Original Message- From: David Watson [mailto:dwat...@sdl.com] Sent: 21 December 2011 16:06 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Removing through the UI mode doesnot prompt forprivileges Sorry I am not a UI expert as we use a chainer for our UI. I think your Maintenance UI needs to be setting the REMOVE to all somehow. Try looking in the wix standard or mondo UI to see how that does it. If your CA needs to be dependent on the MSI being uninstalled it needs to be scheduled appropriately, i.e. after the REMOVE has been set correctly. Dave -Original Message- From: Stelios Kyprou [mailto:stelios.kyp...@fcg.im] Sent: 21 December 2011 15:45 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Removing through the UI mode doesnot prompt forprivileges By the way my CA is scheduled AFTER InstallInitialize -Original Message- From: Stelios Kyprou [mailto:stelios.kyp...@fcg.im] Sent: 21 December 2011 15:42 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Removing through the UI mode does not prompt forprivileges You are right David, REMOVE was set to the features that were installed. So I changed the condition so that the CA runs. One problem down. Now after completion, I can still see the product in "Products and Features", and the files are not removed from the install location. What do I need to do so that my Remove action via ui does the same thing as when running the uninstallation process via "Products and Features"? Thanks in advance, Stelios -Original Message- From: David Watson [mailto:dwat...@sdl.com] Sent: 21 December 2011 14:52 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Removing through the UI mode does not prompt forprivileges When is your custom action scheduled? When you uninstall through the MSI your MSI is in maintenance mode. This probably means that REMOVE is not set to ALL by default in case you choose some other behaviour. Check a log to see when REMOVE is being set and what to. -Original Message- From: Dan Gough [mailto:goug...@gmail.com] Sent: 21 December 2011 13:20 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Removing through the UI mode does not prompt forprivileges I'm new to WiX so don't know how to do it, but I think you need the elevation shield attribute 0x0080 set in the Control table on the button used to uninstall the application. Try editing the msi package using InstEd to see if it fixes the problem, then you can figure out how to achieve it in WiX. On Dec 21, 2011 11:55 AM, "Stelios Kyprou" wrote: > I don't think that is the problem...I need to provide same > functionality when uninstalling from Programs and Features for when I > uninstall through the MSI. > I found in the logs the following: > > MSI (s) (C0:08) [11:23:34:638]: Skipping action: > UninstallWsp2010PowerShell (condition is false) The condition is: > which should be true when > uninstalling(Executes from Programs and Features, but not from the "Remove" > action of the msi). > > > -Original Message- > From: Karthick R [mailto:karthi...@syncfusion.com] > Sent: 21 December 2011 10:18 > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Removing through the UI mode does not prompt > for privileges > > Hi Stelios, > > Check the InstallScope attribute for the package inside the product > having the value as "perMachine" or "perUser" > > For a per-machine installation, the default installation location will > be [ProgramFilesFolder][ApplicationFolderName] and the user will be > able to change it in the setup UI. For a per-user installation, the > default installation location will be > [LocalAppDataFolder]Apps\[ApplicationFolderName] and the user will not > be able to change it in the setup UI. > > Warm Regards, > Karthick.R > > -Original Message- > From: Stelios Kyprou [mailto:stelios.kyp...@fcg.im] > Sent: Wednesday, December 21, 2011 5:04 AM > To: General discussion for Windows Installer XML toolset. > Subject: [WiX-users] Removing through the UI mode does not prompt for > privileges &
Re: [WiX-users] Removing through the UI mode does not prompt forprivileges
By the way my CA is scheduled AFTER InstallInitialize -Original Message- From: Stelios Kyprou [mailto:stelios.kyp...@fcg.im] Sent: 21 December 2011 15:42 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Removing through the UI mode does not prompt forprivileges You are right David, REMOVE was set to the features that were installed. So I changed the condition so that the CA runs. One problem down. Now after completion, I can still see the product in "Products and Features", and the files are not removed from the install location. What do I need to do so that my Remove action via ui does the same thing as when running the uninstallation process via "Products and Features"? Thanks in advance, Stelios -Original Message- From: David Watson [mailto:dwat...@sdl.com] Sent: 21 December 2011 14:52 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Removing through the UI mode does not prompt forprivileges When is your custom action scheduled? When you uninstall through the MSI your MSI is in maintenance mode. This probably means that REMOVE is not set to ALL by default in case you choose some other behaviour. Check a log to see when REMOVE is being set and what to. -Original Message- From: Dan Gough [mailto:goug...@gmail.com] Sent: 21 December 2011 13:20 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Removing through the UI mode does not prompt forprivileges I'm new to WiX so don't know how to do it, but I think you need the elevation shield attribute 0x0080 set in the Control table on the button used to uninstall the application. Try editing the msi package using InstEd to see if it fixes the problem, then you can figure out how to achieve it in WiX. On Dec 21, 2011 11:55 AM, "Stelios Kyprou" wrote: > I don't think that is the problem...I need to provide same > functionality when uninstalling from Programs and Features for when I > uninstall through the MSI. > I found in the logs the following: > > MSI (s) (C0:08) [11:23:34:638]: Skipping action: > UninstallWsp2010PowerShell (condition is false) The condition is: > which should be true when > uninstalling(Executes from Programs and Features, but not from the "Remove" > action of the msi). > > > -Original Message- > From: Karthick R [mailto:karthi...@syncfusion.com] > Sent: 21 December 2011 10:18 > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Removing through the UI mode does not prompt > for privileges > > Hi Stelios, > > Check the InstallScope attribute for the package inside the product > having the value as "perMachine" or "perUser" > > For a per-machine installation, the default installation location will > be [ProgramFilesFolder][ApplicationFolderName] and the user will be > able to change it in the setup UI. For a per-user installation, the > default installation location will be > [LocalAppDataFolder]Apps\[ApplicationFolderName] and the user will not > be able to change it in the setup UI. > > Warm Regards, > Karthick.R > > -Original Message- > From: Stelios Kyprou [mailto:stelios.kyp...@fcg.im] > Sent: Wednesday, December 21, 2011 5:04 AM > To: General discussion for Windows Installer XML toolset. > Subject: [WiX-users] Removing through the UI mode does not prompt for > privileges > > Any ideas anyone? > > -Original Message- > From: Stelios Kyprou [mailto:stelios.kyp...@fcg.im] > Sent: 15 December 2011 10:55 > To: General discussion for Windows Installer XML toolset. > Subject: [WiX-users] Removing through the UI mode does not prompt for > privileges > > Hello all, > I have an installer built on wix 3.5.2519. It installs per machine and > using WixUI_InstallDir ui. > -When installing the product, it prompts the user for elevated > privileges before installing. > -When uninstalling via "Programs and Features", it prompts the same > user for elevated privileges. > -When uninstalling through the UI mode, no elevation is requested, and > the uninstallation process does not complete successfully because of that. > > Is there something I have to set so that it prompts for elevation > through the UI? > > I do not set anywhere the ALLUSERS anywhere. The only thing I do is > set the installscope to permachine. > > Regards, > Stelios SDL PLC confidential, all rights reserved. If you are not the intended recipient of this mail SDL requests and requires that you delete it without acting upon or copying any of its contents, and we further request that you advise us. SDL PLC is a public limited company registered in England and Wales. Registered number: 02675207. Re
Re: [WiX-users] Removing through the UI mode does not prompt forprivileges
You are right David, REMOVE was set to the features that were installed. So I changed the condition so that the CA runs. One problem down. Now after completion, I can still see the product in "Products and Features", and the files are not removed from the install location. What do I need to do so that my Remove action via ui does the same thing as when running the uninstallation process via "Products and Features"? Thanks in advance, Stelios -Original Message- From: David Watson [mailto:dwat...@sdl.com] Sent: 21 December 2011 14:52 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Removing through the UI mode does not prompt forprivileges When is your custom action scheduled? When you uninstall through the MSI your MSI is in maintenance mode. This probably means that REMOVE is not set to ALL by default in case you choose some other behaviour. Check a log to see when REMOVE is being set and what to. -Original Message- From: Dan Gough [mailto:goug...@gmail.com] Sent: 21 December 2011 13:20 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Removing through the UI mode does not prompt forprivileges I'm new to WiX so don't know how to do it, but I think you need the elevation shield attribute 0x0080 set in the Control table on the button used to uninstall the application. Try editing the msi package using InstEd to see if it fixes the problem, then you can figure out how to achieve it in WiX. On Dec 21, 2011 11:55 AM, "Stelios Kyprou" wrote: > I don't think that is the problem...I need to provide same > functionality when uninstalling from Programs and Features for when I > uninstall through the MSI. > I found in the logs the following: > > MSI (s) (C0:08) [11:23:34:638]: Skipping action: > UninstallWsp2010PowerShell (condition is false) The condition is: > which should be true when > uninstalling(Executes from Programs and Features, but not from the "Remove" > action of the msi). > > > -Original Message- > From: Karthick R [mailto:karthi...@syncfusion.com] > Sent: 21 December 2011 10:18 > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Removing through the UI mode does not prompt > for privileges > > Hi Stelios, > > Check the InstallScope attribute for the package inside the product > having the value as "perMachine" or "perUser" > > For a per-machine installation, the default installation location will > be [ProgramFilesFolder][ApplicationFolderName] and the user will be > able to change it in the setup UI. For a per-user installation, the > default installation location will be > [LocalAppDataFolder]Apps\[ApplicationFolderName] and the user will not > be able to change it in the setup UI. > > Warm Regards, > Karthick.R > > -Original Message- > From: Stelios Kyprou [mailto:stelios.kyp...@fcg.im] > Sent: Wednesday, December 21, 2011 5:04 AM > To: General discussion for Windows Installer XML toolset. > Subject: [WiX-users] Removing through the UI mode does not prompt for > privileges > > Any ideas anyone? > > -Original Message- > From: Stelios Kyprou [mailto:stelios.kyp...@fcg.im] > Sent: 15 December 2011 10:55 > To: General discussion for Windows Installer XML toolset. > Subject: [WiX-users] Removing through the UI mode does not prompt for > privileges > > Hello all, > I have an installer built on wix 3.5.2519. It installs per machine and > using WixUI_InstallDir ui. > -When installing the product, it prompts the user for elevated > privileges before installing. > -When uninstalling via "Programs and Features", it prompts the same > user for elevated privileges. > -When uninstalling through the UI mode, no elevation is requested, and > the uninstallation process does not complete successfully because of that. > > Is there something I have to set so that it prompts for elevation > through the UI? > > I do not set anywhere the ALLUSERS anywhere. The only thing I do is > set the installscope to permachine. > > Regards, > Stelios SDL PLC confidential, all rights reserved. If you are not the intended recipient of this mail SDL requests and requires that you delete it without acting upon or copying any of its contents, and we further request that you advise us. SDL PLC is a public limited company registered in England and Wales. Registered number: 02675207. Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK. -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to con
Re: [WiX-users] Removing through the UI mode does not prompt for privileges
I don't think that is the problem...I need to provide same functionality when uninstalling from Programs and Features for when I uninstall through the MSI. I found in the logs the following: MSI (s) (C0:08) [11:23:34:638]: Skipping action: UninstallWsp2010PowerShell (condition is false) The condition is: which should be true when uninstalling(Executes from Programs and Features, but not from the "Remove" action of the msi). -Original Message- From: Karthick R [mailto:karthi...@syncfusion.com] Sent: 21 December 2011 10:18 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Removing through the UI mode does not prompt for privileges Hi Stelios, Check the InstallScope attribute for the package inside the product having the value as "perMachine" or "perUser" For a per-machine installation, the default installation location will be [ProgramFilesFolder][ApplicationFolderName] and the user will be able to change it in the setup UI. For a per-user installation, the default installation location will be [LocalAppDataFolder]Apps\[ApplicationFolderName] and the user will not be able to change it in the setup UI. Warm Regards, Karthick.R -Original Message- From: Stelios Kyprou [mailto:stelios.kyp...@fcg.im] Sent: Wednesday, December 21, 2011 5:04 AM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Removing through the UI mode does not prompt for privileges Any ideas anyone? -Original Message- From: Stelios Kyprou [mailto:stelios.kyp...@fcg.im] Sent: 15 December 2011 10:55 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Removing through the UI mode does not prompt for privileges Hello all, I have an installer built on wix 3.5.2519. It installs per machine and using WixUI_InstallDir ui. -When installing the product, it prompts the user for elevated privileges before installing. -When uninstalling via "Programs and Features", it prompts the same user for elevated privileges. -When uninstalling through the UI mode, no elevation is requested, and the uninstallation process does not complete successfully because of that. Is there something I have to set so that it prompts for elevation through the UI? I do not set anywhere the ALLUSERS anywhere. The only thing I do is set the installscope to permachine. Regards, Stelios This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. Formicary cannot guarantee that this message is secure or free of errors or viruses. -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. Formicary cannot guarantee that this message is secure or free of errors or viruses. -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.in
[WiX-users] Removing through the UI mode does not prompt for privileges
Any ideas anyone? -Original Message- From: Stelios Kyprou [mailto:stelios.kyp...@fcg.im] Sent: 15 December 2011 10:55 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Removing through the UI mode does not prompt for privileges Hello all, I have an installer built on wix 3.5.2519. It installs per machine and using WixUI_InstallDir ui. -When installing the product, it prompts the user for elevated privileges before installing. -When uninstalling via "Programs and Features", it prompts the same user for elevated privileges. -When uninstalling through the UI mode, no elevation is requested, and the uninstallation process does not complete successfully because of that. Is there something I have to set so that it prompts for elevation through the UI? I do not set anywhere the ALLUSERS anywhere. The only thing I do is set the installscope to permachine. Regards, Stelios This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. Formicary cannot guarantee that this message is secure or free of errors or viruses. -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Removing through the UI mode does not prompt for privileges
Hello all, I have an installer built on wix 3.5.2519. It installs per machine and using WixUI_InstallDir ui. -When installing the product, it prompts the user for elevated privileges before installing. -When uninstalling via "Programs and Features", it prompts the same user for elevated privileges. -When uninstalling through the UI mode, no elevation is requested, and the uninstallation process does not complete successfully because of that. Is there something I have to set so that it prompts for elevation through the UI? I do not set anywhere the ALLUSERS anywhere. The only thing I do is set the installscope to permachine. Regards, Stelios This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. Formicary cannot guarantee that this message is secure or free of errors or viruses. -- 10 Tips for Better Server Consolidation Server virtualization is being driven by many needs. But none more important than the need to reduce IT complexity while improving strategic productivity. Learn More! http://www.accelacomm.com/jaw/sdnl/114/51507609/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Can i do minor updates while having Product ID="*"?
After reading the following thread: http://stackoverflow.com/questions/114165/how-to-implement-wix-installer-upgrade (last comment on Rob Mensching's reply) I got the impression that in wix 3.6 you will be able to do Minor upgrades using burn, even if you have your Product Id set to "*" Is this correct? Thanks, Stelios This message is confidential and may be privileged. It is intended solely for the named addressee. If you are not the intended recipient, please inform us. Any unauthorised dissemination, distribution or copying hereof is prohibited. Formicary Limited registered office in England and Wales, address 1 Taillar Road, Hedon, East Yorkshire HU12 8GU, registration number 3894343, VAT number 747644304, does not guarantee that the integrity of this communication has been maintained nor that this communication is free of viruses, interceptions or interference. -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] XmlConfig in multiple MergeModules
Figured this out. It was as simple as reducing the length an XmlConfig "Id"
('ConnectorServiceRelativePathDefinition') which was too long to handle
> -Original Message-
> From: Stelios Kyprou [mailto:stelios.kyp...@formicary.net]
> Sent: 15 June 2011 12:35
> To: General discussion for Windows Installer XML toolset.
> Subject: [WiX-users] XmlConfig in multiple MergeModules
>
> Hello,
> I was wondering if it is possible to use XmlConfig in multiple merge modules,
> that will later be used in a single installer.
> For example, I have MergeModule1, which has:
>
>
> On='install'
> Action='create'
> Sequence='1'
> File='[#appConfigFile]'
>
> ElementPath="//configuration/appSettings/add[\[]@key='Modules'[\]]"
> Node="value"
> Name="value"
> Value='[MODULES]'/>
> On='install'
> Action='create'
> Sequence='2'
> File='[#appConfigFile]'
>
> ElementPath="//configuration/appSettings/add[\[]@key='ConnectorService
> FolderName'[\]]"
> Node="value"
> Name="value"
> Value='..\!(loc.ConnectorFolderName)'/>
>
>
>
> MergeModule2 has the following Component:
>
>
>
> On='install'
> Action='create'
> Sequence='1'
> File='[#file_E1F5BC4046FD48ADB558DE10AA3F4B50]'
>
> ElementPath="//configuration/appSettings/add[\[]@key='Modules'[\]]"
> Node="value"
> Name="value"
> Value='[MODULES]'/>
> On='install'
> Action='create'
> Sequence='2'
> File='[#file_E1F5BC4046FD48ADB558DE10AA3F4B50]'
>
> ElementPath="//configuration/appSettings/add[\[]@key='PrivateApiFileSer
> verRelativePath'[\]]"
> Node="value"
> Name="value"
> Value='..\!(loc.GcwaFolderNme)'/>
>
>
>
> This doesn't seem to work when I use both merge modules in an installer,
> and I get a warning when compiling:
> warning LGHT1055: The InstallExecuteSequence table contains an action
> 'SchedXmlConfig' which cannot be merged from the merge module 'blah'.
> This action is likely colliding with an action in the database that is being
> created. The colliding action may have been authored in the database or
> merged in from another merge module. If this is a standard action, it is
> likely
> colliding due to a difference in the condition for the action in the database
> and merge module. If this is a custom action, it should only be declared in
> the database or one merge module.
> warning LGHT1056: The CustomAction table contains a row with primary
> key(s) 'SchedXmlConfig' which cannot be merged from the merge module
> 'blah'. This is likely due to collision of rows with the same primary key(s)
> (but
> other different values in other columns) between the database and the
> merge module.
> warning LGHT1056: The CustomAction table contains a row with primary
> key(s) 'ExecXmlConfig' which cannot be merged from the merge module
> 'blah'. This is likely due to collision of rows with the same primary key(s)
> (but
> other different values in other columns) between the database and the
> merge module.
> warning LGHT1056: The CustomAction table contains a row with primary
> key(s) 'ExecXmlConfigRollback' which cannot be merged from the merge
> module 'blah'. This is likely due to collision of rows with the same primary
> key(s) (but other different values in other columns) between the database
> and the merge module.
>
> Obviously, when I try to install I get an error saying:
> SchedXmlConfig: Error 0x8007007a: failed to copy XmlConfig record Id
> SchedXmlConfig: Error 0x8007007a: failed to read XmlConfig table Error
> 25540. There was a failure while configuring XML files.
>
> Any tips on how to resolve this? It's far easier to have the configuration
&
[WiX-users] XmlConfig in multiple MergeModules
Hello, I was wondering if it is possible to use XmlConfig in multiple merge modules, that will later be used in a single installer. For example, I have MergeModule1, which has: MergeModule2 has the following Component: This doesn't seem to work when I use both merge modules in an installer, and I get a warning when compiling: warning LGHT1055: The InstallExecuteSequence table contains an action 'SchedXmlConfig' which cannot be merged from the merge module 'blah'. This action is likely colliding with an action in the database that is being created. The colliding action may have been authored in the database or merged in from another merge module. If this is a standard action, it is likely colliding due to a difference in the condition for the action in the database and merge module. If this is a custom action, it should only be declared in the database or one merge module. warning LGHT1056: The CustomAction table contains a row with primary key(s) 'SchedXmlConfig' which cannot be merged from the merge module 'blah'. This is likely due to collision of rows with the same primary key(s) (but other different values in other columns) between the database and the merge module. warning LGHT1056: The CustomAction table contains a row with primary key(s) 'ExecXmlConfig' which cannot be merged from the merge module 'blah'. This is likely due to collision of rows with the same primary key(s) (but other different values in other columns) between the database and the merge module. warning LGHT1056: The CustomAction table contains a row with primary key(s) 'ExecXmlConfigRollback' which cannot be merged from the merge module 'blah'. This is likely due to collision of rows with the same primary key(s) (but other different values in other columns) between the database and the merge module. Obviously, when I try to install I get an error saying: SchedXmlConfig: Error 0x8007007a: failed to copy XmlConfig record Id SchedXmlConfig: Error 0x8007007a: failed to read XmlConfig table Error 25540. There was a failure while configuring XML files. Any tips on how to resolve this? It's far easier to have the configuration within the merge module instead of the installer, since the MM's are used in multiple installers, and would not like to add the XmlConfig in every single installer if I can define it once in the MM and know that it will apply anywhere it's used Thanks, Stel This message is confidential and may be privileged. It is intended solely for the named addressee. If you are not the intended recipient, please inform us. Any unauthorised dissemination, distribution or copying hereof is prohibited. Formicary Limited registered office in England and Wales, address 1 Taillar Road, Hedon, East Yorkshire HU12 8GU, registration number 3894343, VAT number 747644304, does not guarantee that the integrity of this communication has been maintained nor that this communication is free of viruses, interceptions or interference. -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] (no subject)
I do want to run the command as the user that fired up the msi though... If I do Impersonate="no", wouldn't that run as LocalSystem (which is admin)? > -Original Message- > From: Aaron Klor [mailto:aaron.k...@gmail.com] > Sent: 07 April 2011 12:39 > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] (no subject) > > Try Impersonate="no". With that attribute set to yes, that CA tries to > impersonate the user who ran the msi, because the deferred CA is already > running as admin. > > On Apr 7, 2011 6:13 AM, "Stelios Kyprou" > wrote: > > Hello everyone, > > I am trying to deploy a SharePoint WebPart from my installer, and the way I > found to do that in WiX is to create a deferred custom action, > which: > 1) Will fire up "cmd.exe" > 2) Run a .bat file which: >i) Run "stsadm.exe" (located under "C:\Program Files\Common > Files\Microsoft Shared\Web Server Extensions\14\BIN") >ii) Execute some commands (i.e. "stsadm.exe -o displaysolution -name > "mywebPart.wsp"") > > My deferred custom action definition looks like this: > Impersonate="yes" Return="check" > ExeCommand="/c ""[#WebPartInstall]" > "[STSADM2010]" "$(var.WebPartName)" > "[#Package]""" /> > > As you can see, I have the custom action to run as the user that fires up the > installer, not as LocalSystem, but I get an "Access Denied" message. > I get the SAME result when I try to run that command DIRECTLY from > "cmd.exe", and the way to actually make it work, is to run cmd.exe "As > Administrator". > > I still haven't found a way to do this with WiX, so my commands to not > succeed when run through the installers. > Any ideas on how I can make cmd.exe to run as administrator from wix? > Or if I can't is there another way to do this? Or do I have to write a C# > custom > action in order to achieve what I'm trying to do? > > Kind regards, > Stel > > > This message is confidential and may be privileged. It is intended solely for > the named addressee. If you are not the intended recipient, please inform > us. Any unauthorised dissemination, distribution or copying hereof is > prohibited. Formicary Limited registered office in England and Wales, address > 1 Taillar Road, Hedon, East Yorkshire HU12 8GU, registration number 3894343, > VAT number 747644304, does not guarantee that the integrity of this > communication has been maintained nor that this communication is free of > viruses, interceptions or interference. > > -- > Xperia(TM) PLAY > It's a major breakthrough. An authentic gaming smartphone on the nation's > most reliable network. > And it wants your games. > http://p.sf.net/sfu/verizon-sfdev > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > -- > Xperia(TM) PLAY > It's a major breakthrough. An authentic gaming smartphone on the nation's > most reliable network. > And it wants your games. > http://p.sf.net/sfu/verizon-sfdev > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users This message is confidential and may be privileged. It is intended solely for the named addressee. If you are not the intended recipient, please inform us. Any unauthorised dissemination, distribution or copying hereof is prohibited. Formicary Limited registered office in England and Wales, address 1 Taillar Road, Hedon, East Yorkshire HU12 8GU, registration number 3894343, VAT number 747644304, does not guarantee that the integrity of this communication has been maintained nor that this communication is free of viruses, interceptions or interference. -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] (no subject)
Hello everyone, I am trying to deploy a SharePoint WebPart from my installer, and the way I found to do that in WiX is to create a deferred custom action, which: 1) Will fire up "cmd.exe" 2) Run a .bat file which: i) Run "stsadm.exe" (located under "C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\BIN") ii) Execute some commands (i.e. "stsadm.exe -o displaysolution -name "mywebPart.wsp"") My deferred custom action definition looks like this: As you can see, I have the custom action to run as the user that fires up the installer, not as LocalSystem, but I get an "Access Denied" message. I get the SAME result when I try to run that command DIRECTLY from "cmd.exe", and the way to actually make it work, is to run cmd.exe "As Administrator". I still haven't found a way to do this with WiX, so my commands to not succeed when run through the installers. Any ideas on how I can make cmd.exe to run as administrator from wix? Or if I can't is there another way to do this? Or do I have to write a C# custom action in order to achieve what I'm trying to do? Kind regards, Stel This message is confidential and may be privileged. It is intended solely for the named addressee. If you are not the intended recipient, please inform us. Any unauthorised dissemination, distribution or copying hereof is prohibited. Formicary Limited registered office in England and Wales, address 1 Taillar Road, Hedon, East Yorkshire HU12 8GU, registration number 3894343, VAT number 747644304, does not guarantee that the integrity of this communication has been maintained nor that this communication is free of viruses, interceptions or interference. -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Merge Module not identifying my fragment files
You are not allowed to add a tag under , at least in a merge module! The project is within Visual studio, so the fragment file is used in candle and light. I did though write under the tag, and that seemed to work. I guess this was working within the tags when I was building an .msi, since you reference the component group under the < Feature > tag. BUT since you don't specify Features in merge modules, I didn't have the component group referenced anywhere in the This was kind of misleading, and not documented anywhere, since I was expecting candle or light to identify the link between the 2 files without having to add the reference. Or am I thinking the wrong way? Thanks in advance, Stel > -Original Message- > From: Pally Sandher [mailto:pally.sand...@iesve.com] > Sent: 30 March 2011 16:02 > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Merge Module not identifying my fragment files > > I'm guessing it's probably because there's no reference to the Fragment so > it's not including it. Try adding a ComponentGroupRef for FooFiles under your > FOO Directory or something else which links the Fragment to your Module > Element. That should sort it out. > > Palbinder Sandher > Software Deployment Engineer > T: +44 (0) 141 945 8500 > F: +44 (0) 141 945 8501 > > http://www.iesve.com > **Design, Simulate + Innovate with the ** Integrated > Environmental Solutions Limited. Registered in Scotland No. > SC151456 > Registered Office - Helix Building, West Of Scotland Science Park, Glasgow > G20 0SP Email Disclaimer > > -Original Message- > From: Stelios Kyprou [mailto:stelios.kyp...@formicary.net] > Sent: 30 March 2011 15:06 > To: General discussion for Windows Installer XML toolset. > Subject: [WiX-users] Merge Module not identifying my fragment files > > Hello there! > I'm trying to create a simple merge module, where I define my components > in a separate .wxs file as a fragment. > My directory structure is as follows: > > > > > > > > > > My .wxs () file has a bunch of components, sitting under the > DirectoryRef tag with Id="FOO" > They are also added in a component group called "FooFiles" > > When I build the project, light gives me a warning saying that the merge > module cabinet is empty. > Adding the components directly under the < tag > works like a charm. > > Is there something I'm missing out here? Doing this in a standalone installer > works fine! > > Regards, > Stel > > > > This message is confidential and may be privileged. It is intended solely for > the named addressee. If you are not the intended recipient, please inform > us. Any unauthorised dissemination, distribution or copying hereof is > prohibited. Formicary Limited registered office in England and Wales, address > 1 Taillar Road, Hedon, East Yorkshire HU12 8GU, registration number 3894343, > VAT number 747644304, does not guarantee that the integrity of this > communication has been maintained nor that this communication is free of > viruses, interceptions or interference. > > > -- > Create and publish websites with WebMatrix Use the most popular FREE > web apps or write code yourself; WebMatrix provides all the features you > need to develop and publish your website. > http://p.sf.net/sfu/ms-webmatrix-sf > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > > > -- > Create and publish websites with WebMatrix Use the most popular FREE > web apps or write code yourself; WebMatrix provides all the features you > need to develop and publish your website. http://p.sf.net/sfu/ms- > webmatrix-sf > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users This message is confidential and may be privileged. It is intended solely for the named addressee. If you are not the intended recipient, please inform us. Any unauthorised dissemination, distribution or copying hereof is prohibited. Formicary Limited registered office in England and Wales, address 1 Taillar Road, Hedon, East Yorkshire HU12 8GU, registration number 3894343, VAT number 747644304, does not guarantee that the integrity of this communication has
[WiX-users] Merge Module not identifying my fragment files
Hello there! I'm trying to create a simple merge module, where I define my components in a separate .wxs file as a fragment. My directory structure is as follows: My .wxs () file has a bunch of components, sitting under the DirectoryRef tag with Id="FOO" They are also added in a component group called "FooFiles" When I build the project, light gives me a warning saying that the merge module cabinet is empty. Adding the components directly under the < tag works like a charm. Is there something I'm missing out here? Doing this in a standalone installer works fine! Regards, Stel This message is confidential and may be privileged. It is intended solely for the named addressee. If you are not the intended recipient, please inform us. Any unauthorised dissemination, distribution or copying hereof is prohibited. Formicary Limited registered office in England and Wales, address 1 Taillar Road, Hedon, East Yorkshire HU12 8GU, registration number 3894343, VAT number 747644304, does not guarantee that the integrity of this communication has been maintained nor that this communication is free of viruses, interceptions or interference. -- Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Merge Modules and Custom actions design
Hello, I'm new to Merge Modules, and I was trying to figure out what is the best way to create ones. Let's say I have 2 merge modules. Module A needs a database, and Module B needs to make a URL reservation. My concerns are: 1) The custom actions for doing what the Modules need (db and url creation) should be done in the merge modules, or in the installer that uses them? 2) As far as I know from reading, Merge modules should not have a UI. SO: i) The Installer should grab what is needed via the UI, and pass the properties to the Merge Modules, to use in their Custom Actions. Correct? If so, That means that there is a dependency of my merge module with the installer (i.e. the person writing the installer, HAS to know what properties to set [needed by the Module], so that the merge module works correctly). Is there a way to avoid this? Or is this the expected way? Thanks, SK This message is confidential and may be privileged. It is intended solely for the named addressee. If you are not the intended recipient, please inform us. Any unauthorised dissemination, distribution or copying hereof is prohibited. Formicary Limited registered office in England and Wales, address 1 Taillar Road, Hedon, East Yorkshire HU12 8GU, registration number 3894343, VAT number 747644304, does not guarantee that the integrity of this communication has been maintained nor that this communication is free of viruses, interceptions or interference. -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Configuration editors
Hello Everyone! A general question that might be a bit irrelevant with this mailing list: I previously tried configuring my whole application through WiX previously, but eventually I realised that This way was not maintainable, since I had lots and lots of custom action, and custom screen etc etc... So I have decided to break the installation into 2 components: -A WiX install where it dumps the files on the machine, and some minor actions like registering Event Logs. -At the end of the installation, launch a configuration tool (an executable), that will guide the user through a set of screens to configure the deployed app. Based on your experience, what are my ideal options for a framework to develop that configuration tool? It would have to do various actions, like verifying sql connections, reserving ports, editing configuration files, etc... My only thoughts up to now is winforms or wpf... Any ideas? Thanks in advance, Stelios This message is confidential and may be privileged. It is intended solely for the named addressee. If you are not the intended recipient, please inform us. Any unauthorised dissemination, distribution or copying hereof is prohibited. Formicary Limited registered office in England and Wales, address 1 Taillar Road, Hedon, East Yorkshire HU12 8GU, registration number 3894343, VAT number 747644304, does not guarantee that the integrity of this communication has been maintained nor that this communication is free of viruses, interceptions or interference. -- Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! Tap into the largest installed PC base & get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Heat harvesting
Hello all, This must have been asked S many times, but anyway here I go... WHY doesn't Heat harvest assemblies used by referenced projects within Visual Studio? Are there valid reasons? I tried finding some on the web with no success. I am using 3.5.2312.0 Thanks in advance, Shtel This message is confidential and may be privileged. It is intended solely for the named addressee. If you are not the intended recipient, please inform us. Any unauthorised dissemination, distribution or copying hereof is prohibited. Formicary Limited registered office in England and Wales, address 1 Taillar Road, Hedon, East Yorkshire HU12 8GU, registration number 3894343, VAT number 747644304, does not guarantee that the integrity of this communication has been maintained nor that this communication is free of viruses, interceptions or interference. -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Wix 3.5 RC Votive
Hello there! Does Votive in wix 3.5 rc support auto harvesting binaries now from referenced projects? If yes, do I have to define it somewhere apart from setting "Harvest" to true and Project Output Groups to e.g. All? This message is confidential and may be privileged. It is intended solely for the named addressee. If you are not the intended recipient, please inform us. Any unauthorised dissemination, distribution or copying hereof is prohibited. Formicary Limited registered office in England and Wales, address 1 Taillar Road, Hedon, East Yorkshire HU12 8GU, registration number 3894343, VAT number 747644304, does not guarantee that the integrity of this communication has been maintained nor that this communication is free of viruses, interceptions or interference. -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] [Wix-users] Having an executable in the installation directory for editing configuration files
I used eventlogs to have a concrete example, but assume that you configure "something" that changes the machine state. How would the installer undo that change since it was done in the config util in the first place, when uninstalling? An example? well on top of my head, let's say i wan't to make a url reservation for the webservice i'm going to host within my app... Through the config util, i ask the user to enter the domain and port the webservice is going to use, and then, after validation etc., i register the url namespace. When uninstalling if i don't remove the url reservation, it will stay there, leaving the machine in a "bad state" Blair wrote: > Things like event log sources are not usually set via configuration > utilities (you either have the event log setup or you don't). Instead, you > would usually configure your application's code for what/how much it logs, > and the source is always present while installed and not present when not > installed. > > Wix ships with support for things like event log sources, there is no need > to add that to your configuration tool. > > -Original Message- > From: Stelios Kyprou [mailto:stelios.kyp...@formicary.net] > Sent: Tuesday, August 03, 2010 5:12 AM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] [Wix-users] Having an executable in the > installation directory for editing configuration files > > That would be ideal, but i am concerned with one senario: > If all configuration is done via the Configuration Utility, then what > happens when i uninstall the app? > If the Configuration Utility for example creates some new EventLog > sources that the app will use when running, > they should be removed when the app is gone right? So that we can leave > the machine in the same state it was when the app was not present. > How would i handle this situation if all the configuration is done by an > external executable? > > Stelios > > Blair wrote: > >> Why not just install and launch your configuration utility to configure, >> > on > >> first installation? Then you don't: >> 1. complicate your installation with rerunning it for configuration, and >> 2. duplicate code. >> >> -Original Message- >> From: Stelios Kyprou [mailto:stelios.kyp...@formicary.net] >> Sent: Monday, July 26, 2010 10:01 AM >> To: General discussion for Windows Installer XML toolset. >> Subject: [WiX-users] [Wix-users] Having an executable in the installation >> directory for editing configuration files >> >> Hello everyone, >> >> I would like to ask your opinions on one topic. >> I have a c# application, which uses configuration files to set some >> values needed to run the application. >> These values are set by the installer through the dialogs, and all >> values are validated via custom actions (in wix 3.5) >> But in the event that the user wishes to change these (or some of the) >> values after installation, i would prefere if they did it via a GUI, >> and not directly access the .config files. >> The ideal scenario is a way to manage and reuse the wix dialogs, >> together with the custom actions to edit the values, >> but i know this is not possible.? >> >> What is the most common way of doing this? >> i.e. make an executable with a GUI? But this way i feel like i'm gonna >> duplicate what the installer is doing, both the dialogs, and teh custom >> actions. >> Any ideas? >> >> Regards, >> Stelios >> >> >> > > >> This message is confidential and may be privileged. It is intended solely >> for >> the named addressee. If you are not the intended recipient, please inform >> us. >> Any unauthorised dissemination, distribution or copying hereof is >> prohibited. >> >> Formicary Limited registered office in England and Wales, address 1 >> > Taillar > >> Road, Hedon, East Yorkshire HU12 8GU, registration number 3894343, VAT >> number >> 747644304, does not guarantee that the integrity of this communication has >> been >> maintained nor that this communication is free of viruses, interceptions >> > or > >> interference. >> >> > > >> > > >> -- >> The Palm PDK Hot Apps Program offers developers who use the >> Plug-
Re: [WiX-users] [Wix-users] Having an executable in the installation directory for editing configuration files
That would be ideal, but i am concerned with one senario: If all configuration is done via the Configuration Utility, then what happens when i uninstall the app? If the Configuration Utility for example creates some new EventLog sources that the app will use when running, they should be removed when the app is gone right? So that we can leave the machine in the same state it was when the app was not present. How would i handle this situation if all the configuration is done by an external executable? Stelios Blair wrote: > Why not just install and launch your configuration utility to configure, on > first installation? Then you don't: > 1. complicate your installation with rerunning it for configuration, and > 2. duplicate code. > > -Original Message- > From: Stelios Kyprou [mailto:stelios.kyp...@formicary.net] > Sent: Monday, July 26, 2010 10:01 AM > To: General discussion for Windows Installer XML toolset. > Subject: [WiX-users] [Wix-users] Having an executable in the installation > directory for editing configuration files > > Hello everyone, > > I would like to ask your opinions on one topic. > I have a c# application, which uses configuration files to set some > values needed to run the application. > These values are set by the installer through the dialogs, and all > values are validated via custom actions (in wix 3.5) > But in the event that the user wishes to change these (or some of the) > values after installation, i would prefere if they did it via a GUI, > and not directly access the .config files. > The ideal scenario is a way to manage and reuse the wix dialogs, > together with the custom actions to edit the values, > but i know this is not possible.? > > What is the most common way of doing this? > i.e. make an executable with a GUI? But this way i feel like i'm gonna > duplicate what the installer is doing, both the dialogs, and teh custom > actions. > Any ideas? > > Regards, > Stelios > > > This message is confidential and may be privileged. It is intended solely > for > the named addressee. If you are not the intended recipient, please inform > us. > Any unauthorised dissemination, distribution or copying hereof is > prohibited. > > Formicary Limited registered office in England and Wales, address 1 Taillar > Road, Hedon, East Yorkshire HU12 8GU, registration number 3894343, VAT > number > 747644304, does not guarantee that the integrity of this communication has > been > maintained nor that this communication is free of viruses, interceptions or > interference. > > > > -- > The Palm PDK Hot Apps Program offers developers who use the > Plug-In Development Kit to bring their C/C++ apps to Palm for a share > of $1 Million in cash or HP Products. Visit us here for more details: > http://ad.doubleclick.net/clk;226879339;13503038;l? > http://clk.atdmt.com/CRS/go/247765532/direct/01/ > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > > -- > The Palm PDK Hot Apps Program offers developers who use the > Plug-In Development Kit to bring their C/C++ apps to Palm for a share > of $1 Million in cash or HP Products. Visit us here for more details: > http://ad.doubleclick.net/clk;226879339;13503038;l? > http://clk.atdmt.com/CRS/go/247765532/direct/01/ > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > This message is confidential and may be privileged. It is intended solely for the named addressee. If you are not the intended recipient, please inform us. Any unauthorised dissemination, distribution or copying hereof is prohibited. Formicary Limited registered office in England and Wales, address 1 Taillar Road, Hedon, East Yorkshire HU12 8GU, registration number 3894343, VAT number 747644304, does not guarantee that the integrity of this communication has been maintained nor that this communication is free of viruses, interceptions or interference. -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a sha
[WiX-users] Making wixlibs for Dialogs
Hello everyone! I have a question abour wixlibs in general. If i would like to make a library with all my custom dialogs, so that i can use them in multiple projects and multiple people, what is the best way/design of doing this? Up to now, i had the custom dialogs in each project, but it's not "proper". The problem is that within my dialogs, i define Global Properties, and some buttons call Custom actions, that i have in a different CustomAction project. What i would like to end up with, is by using the library, to be able to have all the functionality of each dialog, inluding being able to access the properties, and use the custom actions being called at specific events(i.e button click) My "concerns" are: - When i use a dialog(from the wixlib), in my project i will not be aware of what Global Properties are defined in that dialog. Should i not include the properties in the dialog code? But then how can i say that TextBox foo sets a global property FOO_PROPERTY that i can use in my installer? -When i click on a button and i want to call a custom action foo_Action i would have to do it in the installuisequence in my main project. But how would a developer know what custom action to call on a button click in his/her main project? Any ideas? Regards, Stelios This message is confidential and may be privileged. It is intended solely for the named addressee. If you are not the intended recipient, please inform us. Any unauthorised dissemination, distribution or copying hereof is prohibited. Formicary Limited registered office in England and Wales, address 1 Taillar Road, Hedon, East Yorkshire HU12 8GU, registration number 3894343, VAT number 747644304, does not guarantee that the integrity of this communication has been maintained nor that this communication is free of viruses, interceptions or interference. -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Progress Text update
Hey wix users! I have an installer which uses the built in "WixUI_InstallDir" dialogs. I also have some deferred custom action running between InstallInitialize and InstallFinalize. What i am trying to do, is display an update message in the ProgressDlg when a custom action is executing. Correct me if i'm wrong, but is the following code all i need to display the message? etc. the above is defined under the tag in my main file, and the action attribute is set to the ID of each of my custom actions. Let's forget for now about updating the progress bar, is the above enough? I can't see the messages, maybe it's too fast to be able to realise that it's showing the message. Regards, Stelios -- Stelios Kyprou Systems Engineer Formicary - delivering quality financial technology solutions(TM) www.formicary.net This message is confidential and may be privileged. It is intended solely for the named addressee. If you are not the intended recipient, please inform us. Any unauthorised dissemination, distribution or copying hereof is prohibited. Formicary Limited registered office in England and Wales, address 1 Taillar Road, Hedon, East Yorkshire HU12 8GU, registration number 3894343, VAT number 747644304, does not guarantee that the integrity of this communication has been maintained nor that this communication is free of viruses, interceptions or interference. -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Using Integrated security for connectionstring in CustomAction
Agreed. I ended up doing exactly what you suggest. Impersonating local
system requires privileges that even an admin shouldn't have. So you
should not
consider adding this as a requirement in your installer.
dB. wrote:
> Someone has looked at the LocalSystem problem that you're describing for a
> rather long time and found that impersonating localsystem is a no go. Give up
> :) We did exactly that: removing test connection buttons in the LocalSystem
> scenarios.
>
> You should consider not reinventing the wheel and using the UI
> dialogs/CAs/extensions that someone else built and that have been
> production-tested release-after-release. Read this:
> http://code.dblock.org/ShowPost.aspx?id=100.
>
> Hope it helps,
> -dB.
>
> dB. @ dblock.org
> Moscow|Geneva|Seattle|New York
>
>
>
> -Original Message-
> From: Stelios Kyprou [mailto:stelios.kyp...@formicary.net]
> Sent: Wednesday, July 14, 2010 5:25 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Using Integrated security for connectionstring in
> CustomAction
>
> That would not help in my case though, since i am aiming to validate any
> user defined values entered in the UI sequence.
> So in the case where the user chooses to run the "service to be
> installed" as LocalSystem, and the connectionstring uses integrated
> security, i want to make sure that the connectionstring is correct, by
> connecting and disconnecting to the database.
> If the action does not succeed, i would like to prevent the user from
> going to the next dialog, until i'm sure that all values are correct.
>
> Now in the case where integrated security is true but the service
> account is a user account, i could go around it by impersonating that
> user and the doing the DB connect attempt.
>
> Not sure if it would be good practice to try and impersonate the local
> system account though.
>
> So there is no way around this?
> That would mean that i would provide an "incomplete" Installer since i
> can validate ALL user defined values except the case where:
> connectionstring uses Instegrated Security and the account that will be
> used based on that configuration is LocalSystem.
>
> So that is one senario where the installation completes, i run the
> installed service, but it doesn't work as excpected because the service
> can't access the DB(either because LocalSystem has no access to it, or
> the connectionstring is wrong, and i couldn't detect that error during
> installation, which i want to)...
>
> Any opinions?
>
> Blair wrote:
>
>> The custom actions used in the WixSQLExtension do not have the
>> "no-impersonate" bit set, so they never run as LocalSystem (except in the
>> rare instance that the installation were being performed by a service
>> running as LocalSystem). Thus, if you are using the WiX-supplied SQL support
>> you must launch the installation itself from an account with the desired
>> access.
>>
>> The only ways to run a custom action as LocalSystem are to run it deferred
>> with the Impersonate attribute set to "no" in the CustomAction element in
>> your authoring where the Execute attribute is set to some in-script type
>> ("deferred", "rollback", or "commit"), which cannot be run from the UI since
>> they must be between InstallInitialize and InstallFinalize in the
>> InstallExecuteSequence table.
>>
>> -Original Message-
>> From: Stelios Kyprou [mailto:stelios.kyp...@formicary.net]
>> Sent: Wednesday, July 14, 2010 12:57 PM
>> To: General discussion for Windows Installer XML toolset.
>> Subject: [WiX-users] Using Integrated security for connectionstring in
>> CustomAction
>>
>> Hello all!
>>
>> Let's say that i am using a C# custom action, to validate the database
>> connectionstring that a user has entered in a dialog.
>> If the user has selected to use Integrated Security, and the account of
>> the Windows Service that will be running the application is "Local
>> System",
>> that would mean that when the service is running, when connecting to the
>> database it would use the "Local System" to try and access it(which is
>> what i want).
>>
>> In my c# custom action, when i try and connect to the db using Integrated
>> Security, would it use the "local system" account to connect(which i think
>> is the account the installer is running as)? or will it use the account of
>> the user that is logged in the machine(which will fail to connect)?
>>
>> In the
[WiX-users] [Wix-users] Having an executable in the installation directory for editing configuration files
Hello everyone, I would like to ask your opinions on one topic. I have a c# application, which uses configuration files to set some values needed to run the application. These values are set by the installer through the dialogs, and all values are validated via custom actions (in wix 3.5) But in the event that the user wishes to change these (or some of the) values after installation, i would prefere if they did it via a GUI, and not directly access the .config files. The ideal scenario is a way to manage and reuse the wix dialogs, together with the custom actions to edit the values, but i know this is not possible.? What is the most common way of doing this? i.e. make an executable with a GUI? But this way i feel like i'm gonna duplicate what the installer is doing, both the dialogs, and teh custom actions. Any ideas? Regards, Stelios This message is confidential and may be privileged. It is intended solely for the named addressee. If you are not the intended recipient, please inform us. Any unauthorised dissemination, distribution or copying hereof is prohibited. Formicary Limited registered office in England and Wales, address 1 Taillar Road, Hedon, East Yorkshire HU12 8GU, registration number 3894343, VAT number 747644304, does not guarantee that the integrity of this communication has been maintained nor that this communication is free of viruses, interceptions or interference. -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://ad.doubleclick.net/clk;226879339;13503038;l? http://clk.atdmt.com/CRS/go/247765532/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Unable to uninstall
I ended up fixing the msi... up to now i never got to use orca, but now i see the full potential of it and i understand why everyone suggests using this tool when writing installers... Good stuff! Rob Mensching wrote: > Hmm, I would never recommend using that tool: > http://robmensching.com/blog/posts/2009/3/6/More-on-Haacks-Troubleshooting-Windows-MSI-Installers > > <http://robmensching.com/blog/posts/2009/3/6/More-on-Haacks-Troubleshooting-Windows-MSI-Installers>Use > recache/reinstall (msiexec /fv) with a fixed MSI instead. > > On Fri, Jul 23, 2010 at 4:35 AM, Ryszard Boryna > wrote: > > >> Had the same problem recently; >> http://majorgeeks.com/download.php?det=4459helped. You will need to >> manually cleanup program files etc., but this >> should let you run your (fixed :~) ) installer. >> >> >> Ryszard >> >> >> Ryszard Boryna, Solutions Architect >> Tel: 0141 280 0050 >> >> NVable is a limited company registered in Scotland. Registered number: >> SC287922. >> Suite 6/5, Skypark SP1, 8 Elliot Pl, Glasgow, G3 8EP >> >> -Original Message- >> >> From: Stelios Kyprou [mailto:stelios.kyp...@formicary.net] >> Sent: 23 July 2010 11:43 >> To: General discussion for Windows Installer XML toolset. >> Subject: [WiX-users] Unable to uninstall >> >> Hey everyone, >> I made an installer with 2 custom actions, taking care of rollback as well. >> The problem is i messed up with one of them during uninstallation, and >> every time i try to unistall, it fails and the rollback takes place. >> So i am unable to uninstall (neither from the msi nor the control panel) >> Any ideas what i can do now? >> >> Regards, >> Stelios >> >> -- >> Stelios Kyprou >> Systems Engineer >> Formicary - delivering quality financial technology solutions(TM) >> www.formicary.net >> >> >> >> >> This message is confidential and may be privileged. It is intended solely >> for >> the named addressee. If you are not the intended recipient, please inform >> us. >> Any unauthorised dissemination, distribution or copying hereof is >> prohibited. >> >> Formicary Limited registered office in England and Wales, address 1 Taillar >> Road, Hedon, East Yorkshire HU12 8GU, registration number 3894343, VAT >> number >> 747644304, does not guarantee that the integrity of this communication has >> been >> maintained nor that this communication is free of viruses, interceptions or >> interference. >> >> >> >> >> -- >> This SF.net email is sponsored by Sprint >> What will you do first with EVO, the first 4G phone? >> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first >> ___ >> WiX-users mailing list >> WiX-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/wix-users >> >> >> >> -- >> This SF.net email is sponsored by Sprint >> What will you do first with EVO, the first 4G phone? >> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first >> ___ >> WiX-users mailing list >> WiX-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/wix-users >> >> >> > > > -- Stelios Kyprou Systems Engineer Formicary - delivering quality financial technology solutions(TM) www.formicary.net This message is confidential and may be privileged. It is intended solely for the named addressee. If you are not the intended recipient, please inform us. Any unauthorised dissemination, distribution or copying hereof is prohibited. Formicary Limited registered office in England and Wales, address 1 Taillar Road, Hedon, East Yorkshire HU12 8GU, registration number 3894343, VAT number 747644304, does not guarantee that the integrity of this communication has been maintained nor that this communication is free of viruses, interceptions or interference. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Unable to uninstall
I think i can use orca to fix my problem...i actually have a custom action that tries to get a file from the installlocation, and get some data from there(while uninstalling) but i accidentally added that action after the deletefiles action. So i can change that with orca. The problem now is: I don't have the msi anymore. I have the GUID. How can i get the msi? as in where does control panel grab it from when uninstalling a program? I am using windows vista Pally Sandher wrote: > I would like to also strongly recommend Peter's advice on only using > Windows Installer clean up utilities as the very last resort when > everything else fails. We've had to rebuild a users Vista SP2 machine > recently because he took IT matters into his own inexperienced hands, > googled MSICUU.exe & broke his installation of our own software so it no > longer uninstalls properly (component reference counts are permanently > set to 1, re-installing the app sets them to 2, uninstalling won't > remove files & registry entries as the component reference counts are > only decremented to 1 with no way of decrementing them to 0). > > Also test your packages using Virtualization as Bob A. recommends on his > blog & you should catch these issues before you ship your package -> > http://www.joyofsetup.com/2007/09/24/test-your-setups-virtually/ > On a VM you don't even need to fix the below issue for that > installation, just revert the VM back to before you installed, fix your > code, build it & try again. > > Palbinder Sandher > Software Deployment & IT Administrator > T: +44 (0) 141 945 8500 > F: +44 (0) 141 945 8501 > > http://www.iesve.com > **Design, Simulate + Innovate with the ** > Integrated Environmental Solutions Limited. Registered in Scotland No. > SC151456 > Registered Office - Helix Building, West Of Scotland Science Park, > Glasgow G20 0SP > Email Disclaimer > > -Original Message- > From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] > Sent: 23 July 2010 12:47 > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Unable to uninstall > > Cleanup utilities are a last resort because they can leave the machine > in a corrupted state. You have a better option: Rebuild your msi > *exactly* as before but with the custom action corrected or removed, (or > it might be easier to edit it with orca to achieve the same result). > Reinstall and recache the new MSI with msiexec /fv and then uninstall > the now corrected version. > > Rob discussed the issue in a blog post > http://robmensching.com/blog/posts/2009/3/6/More-on-Haacks-Troubleshooti > ng-Windows-MSI-Installers > > -Original Message- > From: Ryszard Boryna [mailto:ryszard.bor...@nvable.com] > Sent: 23 July 2010 12:36 > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Unable to uninstall > > Had the same problem recently; > http://majorgeeks.com/download.php?det=4459 helped. You will need to > manually cleanup program files etc., but this should let you run your > (fixed :~) ) installer. > > > Ryszard > > > Ryszard Boryna, Solutions Architect > Tel: 0141 280 0050 > > NVable is a limited company registered in Scotland. Registered number: > SC287922. > Suite 6/5, Skypark SP1, 8 Elliot Pl, Glasgow, G3 8EP > > -Original Message- > > From: Stelios Kyprou [mailto:stelios.kyp...@formicary.net] > Sent: 23 July 2010 11:43 > To: General discussion for Windows Installer XML toolset. > Subject: [WiX-users] Unable to uninstall > > Hey everyone, > I made an installer with 2 custom actions, taking care of rollback as > well. > The problem is i messed up with one of them during uninstallation, and > every time i try to unistall, it fails and the rollback takes place. > So i am unable to uninstall (neither from the msi nor the control panel) > Any ideas what i can do now? > > Regards, > Stelios > > -- > Stelios Kyprou > Systems Engineer > Formicary - delivering quality financial technology solutions(TM) > www.formicary.net > > > > > This message is confidential and may be privileged. It is intended > solely for the named addressee. If you are not the intended recipient, > please inform us. > Any unauthorised dissemination, distribution or copying hereof is > prohibited. > > Formicary Limited registered office in England and Wales, address 1 > Taillar Road, Hedon, East Yorkshire HU12 8GU, registration number > 3894343, VAT number 747644304, does not guarantee that the integrity of > this communication has been maintained nor that this communication
[WiX-users] Unable to uninstall
Hey everyone, I made an installer with 2 custom actions, taking care of rollback as well. The problem is i messed up with one of them during uninstallation, and every time i try to unistall, it fails and the rollback takes place. So i am unable to uninstall (neither from the msi nor the control panel) Any ideas what i can do now? Regards, Stelios -- Stelios Kyprou Systems Engineer Formicary - delivering quality financial technology solutions(TM) www.formicary.net This message is confidential and may be privileged. It is intended solely for the named addressee. If you are not the intended recipient, please inform us. Any unauthorised dissemination, distribution or copying hereof is prohibited. Formicary Limited registered office in England and Wales, address 1 Taillar Road, Hedon, East Yorkshire HU12 8GU, registration number 3894343, VAT number 747644304, does not guarantee that the integrity of this communication has been maintained nor that this communication is free of viruses, interceptions or interference. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiX 3.5 C# Custom Action Project
You're propably using a 64 bit dll while using the 32 bit SFXCA. You should point to the 64 bit version of SFXCA. in my machine for example, C:\Program Files (x86)\Windows Installer XML v3.5\SDK\x64\sfxca.dll rather than C:\Program Files (x86)\Windows Installer XML v3.5\SDK\x86\sfxca.dll When you use the 64 bit, logging will say Hello, I'm your 64bit Impersonated custom action server. rather than Hello, I'm your 32bit Impersonated custom action server. At least this is how i fixed this problem when i came across it Hope it helps, Stelios ramyaragu wrote: > Hi All, > > I get the following error when trying to run VS2010 Custom Action Project > with Wix 3.5. > > Invoking remote custom action. DLL: C:\Windows\Installer\MSI24A2.tmp, > Entrypoint: ValidateSerialNumberKey > > Generating random cookie. > > Created Custom Action Server with PID 1224 (0x4C8). > > Running as a service. > > Hello, I'm your 32bit Impersonated custom action server. > > SFXCA: Extracting custom action to temporary directory: > C:\Windows\Installer\MSI24A2.tmp-\ > > SFXCA: Binding to CLR version v2.0.50727 > > > > Error: could not load custom action class CustomAction from assembly X > > System.BadImageFormatException: Could not load file or assembly 'X' or one > of its dependencies. This assembly is built by a runtime newer than the > currently loaded runtime and cannot be loaded. > > File name: 'X' > >at System.Reflection.Assembly._nLoad(AssemblyName fileName, String > codeBase, Evidence assemblySecurity, Assembly locationHint, StackCrawlMark& > stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection) > >at System.Reflection.Assembly.nLoad(AssemblyName fileName, String > codeBase, Evidence assemblySecurity, Assembly locationHint, StackCrawlMark& > stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection) > >at System.Reflection.Assembly.InternalLoad(AssemblyName assemblyRef, > Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean > forIntrospection) > >at System.Reflection.Assembly.InternalLoad(String assemblyString, > Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean > forIntrospection) > >at System.AppDomain.Load(String assemblyString) > >at > Microsoft.Deployment.WindowsInstaller.CustomActionProxy.GetCustomActionMethod(Session > session, String assemblyName, String className, String methodName) > > > > WRN: Assembly binding logging is turned OFF. > > To enable assembly bind failure logging, set the registry value (DWORD) to > 1. > > Note: There is some performance penalty associated with assembly bind > failure logging. > > To turn this feature off, remove the registry value . > > > > Action ended 0:05:31: ValidateSerialNumber. Return value 3. > > Action ended 0:05:31: INSTALL. Return value 3. > > > I am confused as to why it should bind to CLR 2.0 when i am using the target > framework as .Net 4.0 > > So,I modified the MakeSFXCA config file the following way: > > > > > > > > Then,it throws the following error: > > SFXCA: Extracting custom action to temporary directory: > C:\WINDOWS\Installer\MSI15.tmp-\ SFXCA: Failed to get requested CLR info. > Error code 0x80131700 SFXCA: Ensure that the proper version of the .NET > Framework is installed, or that there is a matching supportedRuntime element > in CustomAction.config. > > > Could some please help me with this? > > Thanks, > Ramya > > > > -- Stelios Kyprou Systems Engineer Formicary - delivering quality financial technology solutions(TM) www.formicary.net This message is confidential and may be privileged. It is intended solely for the named addressee. If you are not the intended recipient, please inform us. Any unauthorised dissemination, distribution or copying hereof is prohibited. Formicary Limited registered office in England and Wales, address 1 Taillar Road, Hedon, East Yorkshire HU12 8GU, registration number 3894343, VAT number 747644304, does not guarantee that the integrity of this communication has been maintained nor that this communication is free of viruses, interceptions or interference. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] [Wix-users] Installing a windows service based on user give account
I do this because when you try and add the localsystem account as: NT
AUTHORITY\SYSTEM, it will not check the "Local System account"
radiobutton under the "Log On" tab in the service properties.
It will instead select the "This account:" radiobutton and add NT
AUTHORITY\SYSTEM as the username.
So what i do, is when the user selects what account to use in a dialog,
i do the simple logic:
if (Local System is selected)
{
SERVICEACCOUNTFULLNAME = "LocalSystem"
}
else
{
SERVICEACCOUNTFULLNAME = "[WINDOWSDOMAIN]\[WINDOWSUSERNAME]"
}
where WINDOWSDOMAIN and WINDOWSUSERNAME are edit boxes in that dialog
with these properties.
This way, i tackle both cases.
-When i add as account "LocalSystem", it actually selects the "Local
System account" radiobutton under the "Log On" tab in the service
properties.
-When i add as account [WINDOWSDOMAIN]\[WINDOWSUSERNAME] then the user
account is added in the selected "This account:" radiobutton under the
"Log On" tab in the service properties.
This is the only way i found to handle this situation without having to
define 2 components, which i didn't like as a solution, don't ask me why
:P I don't know either :)
John Bergman wrote:
> Can I ask why you are using SERVICEACCOUNTFULLNAME as a parameter, rather
> than doing something like this?
>
> Value='[WINDOWSDOMAIN]\[WINDOWSUSERNAME]' />
>
> -Original Message-
> From: Stelios Kyprou [mailto:stelios.kyp...@formicary.net]
> Sent: Tuesday, July 20, 2010 4:20 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] [Wix-users] Installing a windows service based on
> user give account
>
> Or i realised i can use Account and give it "LocalSystem". This way you can
> have one component for both.
> In case anyone is wondering, you can do the following:
>
>SharedDllRefCount='no' KeyPath='no' NeverOverwrite='no' Permanent='no'
> Transitive='no'
> Win64='yes' Location='either' Directory="INSTALLLOCATION">
>Source="$(var.A_FilesDir)\ALM_GC.exe" />
>
>CreateUser="no" Name="[WINDOWSDOMAIN]\[WINDOWSUSERNAME]"
> LogonAsService="yes"/>
>
>Description='Liquidity Bot' Name='ALM_Bot'
> ErrorControl='normal' Type='ownProcess' Start='auto' Vital='yes'
> Account='[SERVICEACCOUNTFULLNAME]' Password='[WINDOWSPASSWORD]'
> Interactive='no'/>
>
>Start='install' Stop='both' Remove='uninstall' Wait='yes'/>
>
>
> I have 4 properties:
> WINDOWSDOMAIN
> WINDOWSPASSWORD
> WINDOWSUSERNAME
> SERVICEACCOUNTFULLNAME
>
> SERVICEACCOUNTFULLNAME
> is the combination of :[WINDOWSDOMAIN]\[WINDOWSUSERNAME] if we have a user
> account. If we have a builtin account, SERVICEACCOUNTFULLNAME
> is: "LocalSystem" (for example)
> In case of a builtin account, the Password attribute is disregarded
>
> Bob Arnson wrote:
>
>> On 7/19/2010 12:04 PM, Stelios Kyprou wrote:
>>
>>
>>> I know that i can make that happen if i don't provide Account and
>>> Password in the ServiceInstall tag, but then again it depends on what
>>> the user chooses to run the service as in a dialog.
>>>
>>>
>>>
>> Use two components with conditions based on the dialog properties.
>>
>>
>>
>
> --
> Stelios Kyprou
> Systems Engineer
> Formicary - delivering quality financial technology solutions(TM)
> www.formicary.net
>
>
>
> This message is confidential and may be privileged. It is intended solely for
> the named addressee. If you are not the intended recipient, please inform us.
> Any unauthorised dissemination, distribution or copying hereof is prohibited.
>
> Formicary Limited registered office in England and Wales, address 1 Taillar
> Road, Hedon, East Yorkshire HU12 8GU, registration number 3894343, VAT number
> 747644304, does not guarantee that the integrity of this communication has
> been
> maintained nor that this communication is free of viruses, interceptions or
> interference.
>
>
> --
> This SF.net email is sponsored by Sprint
> What will you
[WiX-users] Logging in deferred CA
Hello! I was wondering, how can i log stuff within a deferred custom action, since i can't use session.Log? Regards, Stelios -- Stelios Kyprou Systems Engineer Formicary - delivering quality financial technology solutions(TM) www.formicary.net This message is confidential and may be privileged. It is intended solely for the named addressee. If you are not the intended recipient, please inform us. Any unauthorised dissemination, distribution or copying hereof is prohibited. Formicary Limited registered office in England and Wales, address 1 Taillar Road, Hedon, East Yorkshire HU12 8GU, registration number 3894343, VAT number 747644304, does not guarantee that the integrity of this communication has been maintained nor that this communication is free of viruses, interceptions or interference. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] [Wix-users] Installing a windows service based on user give account
Or i realised i can use Account and give it "LocalSystem". This way you can have one component for both. In case anyone is wondering, you can do the following: I have 4 properties: WINDOWSDOMAIN WINDOWSPASSWORD WINDOWSUSERNAME SERVICEACCOUNTFULLNAME SERVICEACCOUNTFULLNAME is the combination of :[WINDOWSDOMAIN]\[WINDOWSUSERNAME] if we have a user account. If we have a builtin account, SERVICEACCOUNTFULLNAME is: "LocalSystem" (for example) In case of a builtin account, the Password attribute is disregarded Bob Arnson wrote: > On 7/19/2010 12:04 PM, Stelios Kyprou wrote: > >> I know that i can make that happen if i don't provide Account and >> Password in the ServiceInstall tag, but then again it depends on what >> the user chooses to >> run the service as in a dialog. >> >> > Use two components with conditions based on the dialog properties. > > -- Stelios Kyprou Systems Engineer Formicary - delivering quality financial technology solutions(TM) www.formicary.net This message is confidential and may be privileged. It is intended solely for the named addressee. If you are not the intended recipient, please inform us. Any unauthorised dissemination, distribution or copying hereof is prohibited. Formicary Limited registered office in England and Wales, address 1 Taillar Road, Hedon, East Yorkshire HU12 8GU, registration number 3894343, VAT number 747644304, does not guarantee that the integrity of this communication has been maintained nor that this communication is free of viruses, interceptions or interference. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] [Wix-users] Installing a windows service based on user give account
Hello! I am currently trying to install a windows service using ServiceInstall. The requirement i have, is that the account the service will run as, is defined by the user, in a dialog. If: 1) the user chooses Local System, the service should run as Local System 2) the user gives an account, the service should run as that account. When defining the service install, i do the following: In the case where the user chooses LocalSystem, the service that get's installed has "This account:" set in the "Log on" tab (as NT AUTHORITY/SYSTEM) instead of the "Local System account" radio box. I know that i can make that happen if i don't provide Account and Password in the ServiceInstall tag, but then again it depends on what the user chooses to run the service as in a dialog. What are my options here? Regards, Stelios -- Stelios Kyprou Systems Engineer Formicary - delivering quality financial technology solutions(TM) www.formicary.net This message is confidential and may be privileged. It is intended solely for the named addressee. If you are not the intended recipient, please inform us. Any unauthorised dissemination, distribution or copying hereof is prohibited. Formicary Limited registered office in England and Wales, address 1 Taillar Road, Hedon, East Yorkshire HU12 8GU, registration number 3894343, VAT number 747644304, does not guarantee that the integrity of this communication has been maintained nor that this communication is free of viruses, interceptions or interference. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Including referenced assemblies with a Project Output Group
Unfortunately no... By default 3.5 will not include this feature. I asked this question a while ago, and this is the replies i got from John Robbins and Rob Mensching: FYI: given the issues with auto-harvesting in WiX v3.5, that feature will be disabled before shipping. We'll try to bring it back in WiX v4.0. On Wed, Jun 30, 2010 at 5:52 PM, John Robbins wrote: > Hi, > > I had the same itch to scratch a while ago so I wrote a tool I called > Paraffin to make my life easier. > > The overview to the tool: > http://www.wintellect.com/cs/blogs/jrobbins/archive/2007/10/21/wix-a-better-tallow-paraffin.aspx > More on updates to Paraffin based on requests: > > http://www.wintellect.com/CS/blogs/jrobbins/archive/2009/06/28/paraffin3-1-new-and-improved.aspx > > http://www.wintellect.com/CS/blogs/jrobbins/archive/2010/05/11/paraffin-3-12-a-bug-fix-and-three-new-features.aspx > > The latest version: > http://www.wintellect.com/CS/files/folders/8198/download.aspx > > Hope you find it useful. >- John Robbins Rob Jarratt (MCS UK) wrote: > I am using Wix 3.5 build 1909. I have some projects which include references > to "third party" assemblies, ie not project references. Do any of the Project > Output Groups settings cause these referenced assemblies to be included? > > Thanks > > Rob > > > > -- > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > -- Stelios Kyprou Systems Engineer Formicary - delivering quality financial technology solutions(TM) www.formicary.net This message is confidential and may be privileged. It is intended solely for the named addressee. If you are not the intended recipient, please inform us. Any unauthorised dissemination, distribution or copying hereof is prohibited. Formicary Limited registered office in England and Wales, address 1 Taillar Road, Hedon, East Yorkshire HU12 8GU, registration number 3894343, VAT number 747644304, does not guarantee that the integrity of this communication has been maintained nor that this communication is free of viruses, interceptions or interference. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Using Integrated security for connectionstring in CustomAction
Yes i eventually realised that in order to do this kind of action, you
must impersonate LocalSystem in you c# custom action.
But in order to do that, you must have a priviledge called:
"Act as part of the operating system" OR "SE_TCB_NAME".
LocalSystem has this priviledge, but no users, and it's a security risk
to give it to a user account, since with this priviledge you can do almost
everything on the local machine. Plus barely anyone that will be using
the installers will have this priviledge, thus again not being able to
impersonate LocalSystem.
So it's better to not breach any security "walls", and insdead notify
the user that in the senario i described in the previous post of this
thread, the installer will not be able to verify the connectionstring.
Rob Mensching wrote:
> Forget installation for a moment. How would you do this in any program?
>
> On Wed, Jul 14, 2010 at 2:24 PM, Stelios Kyprou <
> stelios.kyp...@formicary.net> wrote:
>
>
>> That would not help in my case though, since i am aiming to validate any
>> user defined values entered in the UI sequence.
>> So in the case where the user chooses to run the "service to be
>> installed" as LocalSystem, and the connectionstring uses integrated
>> security, i want to make sure that the connectionstring is correct, by
>> connecting and disconnecting to the database.
>> If the action does not succeed, i would like to prevent the user from
>> going to the next dialog, until i'm sure that all values are correct.
>>
>> Now in the case where integrated security is true but the service
>> account is a user account, i could go around it by impersonating that
>> user and the doing the DB connect attempt.
>>
>> Not sure if it would be good practice to try and impersonate the local
>> system account though.
>>
>> So there is no way around this?
>> That would mean that i would provide an "incomplete" Installer since i
>> can validate ALL user defined values except the case where:
>> connectionstring uses Instegrated Security and the account that will be
>> used based on that configuration is LocalSystem.
>>
>> So that is one senario where the installation completes, i run the
>> installed service, but it doesn't work as excpected because the service
>> can't access the DB(either because LocalSystem has no access to it, or
>> the connectionstring is wrong, and i couldn't detect that error during
>> installation, which i want to)...
>>
>> Any opinions?
>>
>> Blair wrote:
>>
>>> The custom actions used in the WixSQLExtension do not have the
>>> "no-impersonate" bit set, so they never run as LocalSystem (except in the
>>> rare instance that the installation were being performed by a service
>>> running as LocalSystem). Thus, if you are using the WiX-supplied SQL
>>>
>> support
>>
>>> you must launch the installation itself from an account with the desired
>>> access.
>>>
>>> The only ways to run a custom action as LocalSystem are to run it
>>>
>> deferred
>>
>>> with the Impersonate attribute set to "no" in the CustomAction element in
>>> your authoring where the Execute attribute is set to some in-script type
>>> ("deferred", "rollback", or "commit"), which cannot be run from the UI
>>>
>> since
>>
>>> they must be between InstallInitialize and InstallFinalize in the
>>> InstallExecuteSequence table.
>>>
>>> -Original Message-
>>> From: Stelios Kyprou [mailto:stelios.kyp...@formicary.net]
>>> Sent: Wednesday, July 14, 2010 12:57 PM
>>> To: General discussion for Windows Installer XML toolset.
>>> Subject: [WiX-users] Using Integrated security for connectionstring in
>>> CustomAction
>>>
>>> Hello all!
>>>
>>> Let's say that i am using a C# custom action, to validate the database
>>> connectionstring that a user has entered in a dialog.
>>> If the user has selected to use Integrated Security, and the account of
>>> the Windows Service that will be running the application is "Local
>>> System",
>>> that would mean that when the service is running, when connecting to the
>>> database it would use the "Local System" to try and access it(which is
>>> what i want).
>>>
>>> In my c# custom action, when i try and connect to the db using Integrated
>>> Security, would it use the "
Re: [WiX-users] Using Integrated security for connectionstring in CustomAction
That would not help in my case though, since i am aiming to validate any
user defined values entered in the UI sequence.
So in the case where the user chooses to run the "service to be
installed" as LocalSystem, and the connectionstring uses integrated
security, i want to make sure that the connectionstring is correct, by
connecting and disconnecting to the database.
If the action does not succeed, i would like to prevent the user from
going to the next dialog, until i'm sure that all values are correct.
Now in the case where integrated security is true but the service
account is a user account, i could go around it by impersonating that
user and the doing the DB connect attempt.
Not sure if it would be good practice to try and impersonate the local
system account though.
So there is no way around this?
That would mean that i would provide an "incomplete" Installer since i
can validate ALL user defined values except the case where:
connectionstring uses Instegrated Security and the account that will be
used based on that configuration is LocalSystem.
So that is one senario where the installation completes, i run the
installed service, but it doesn't work as excpected because the service
can't access the DB(either because LocalSystem has no access to it, or
the connectionstring is wrong, and i couldn't detect that error during
installation, which i want to)...
Any opinions?
Blair wrote:
> The custom actions used in the WixSQLExtension do not have the
> "no-impersonate" bit set, so they never run as LocalSystem (except in the
> rare instance that the installation were being performed by a service
> running as LocalSystem). Thus, if you are using the WiX-supplied SQL support
> you must launch the installation itself from an account with the desired
> access.
>
> The only ways to run a custom action as LocalSystem are to run it deferred
> with the Impersonate attribute set to "no" in the CustomAction element in
> your authoring where the Execute attribute is set to some in-script type
> ("deferred", "rollback", or "commit"), which cannot be run from the UI since
> they must be between InstallInitialize and InstallFinalize in the
> InstallExecuteSequence table.
>
> -Original Message-
> From: Stelios Kyprou [mailto:stelios.kyp...@formicary.net]
> Sent: Wednesday, July 14, 2010 12:57 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: [WiX-users] Using Integrated security for connectionstring in
> CustomAction
>
> Hello all!
>
> Let's say that i am using a C# custom action, to validate the database
> connectionstring that a user has entered in a dialog.
> If the user has selected to use Integrated Security, and the account of
> the Windows Service that will be running the application is "Local
> System",
> that would mean that when the service is running, when connecting to the
> database it would use the "Local System" to try and access it(which is
> what i want).
>
> In my c# custom action, when i try and connect to the db using Integrated
> Security, would it use the "local system" account to connect(which i think
> is the account the installer is running as)? or will it use the account of
> the user that is logged in the machine(which will fail to connect)?
>
> In the latter case, any ideas on how to make it run as local system?
>
> Thanks in advance,
> Stelios
>
>
--
Stelios Kyprou
Systems Engineer
Formicary - delivering quality financial technology solutions(TM)
www.formicary.net
This message is confidential and may be privileged. It is intended solely for
the named addressee. If you are not the intended recipient, please inform us.
Any unauthorised dissemination, distribution or copying hereof is prohibited.
Formicary Limited registered office in England and Wales, address 1 Taillar
Road, Hedon, East Yorkshire HU12 8GU, registration number 3894343, VAT number
747644304, does not guarantee that the integrity of this communication has been
maintained nor that this communication is free of viruses, interceptions or
interference.
--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Using Integrated security for connectionstring in CustomAction
Hello all! Let's say that i am using a C# custom action, to validate the database connectionstring that a user has entered in a dialog. If the user has selected to use Integrated Security, and the account of the Windows Service that will be running the application is "Local System", that would mean that when the service is running, when connecting to the database it would use the "Local System" to try and access it(which is what i want). In my c# custom action, when i try and connect to the db using Integrated Security, would it use the "local system" account to connect(which i think is the account the installer is running as)? or will it use the account of the user that is logged in the machine(which will fail to connect)? In the latter case, any ideas on how to make it run as local system? Thanks in advance, Stelios -- Stelios Kyprou Systems Engineer Formicary - delivering quality financial technology solutions(TM) www.formicary.net This message is confidential and may be privileged. It is intended solely for the named addressee. If you are not the intended recipient, please inform us. Any unauthorised dissemination, distribution or copying hereof is prohibited. Formicary Limited registered office in England and Wales, address 1 Taillar Road, Hedon, East Yorkshire HU12 8GU, registration number 3894343, VAT number 747644304, does not guarantee that the integrity of this communication has been maintained nor that this communication is free of viruses, interceptions or interference. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] General global Property question
Hello everyone, I was wondering, when i have a global property which gets it's value only from let's say an Edit Field in a dialog, should i define it in my main wxs file as well? i.e or not? The reason i ask is because even if i don't add the above line, it still works. Thanks in advance, Stelios -- Stelios Kyprou Systems Engineer Formicary - delivering quality financial technology solutions(TM) www.formicary.net This message is confidential and may be privileged. It is intended solely for the named addressee. If you are not the intended recipient, please inform us. Any unauthorised dissemination, distribution or copying hereof is prohibited. Formicary Limited registered office in England and Wales, address 1 Taillar Road, Hedon, East Yorkshire HU12 8GU, registration number 3894343, VAT number 747644304, does not guarantee that the integrity of this communication has been maintained nor that this communication is free of viruses, interceptions or interference. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] WiXUI_InstallDir skipping dialogs!
Hello wix users! I have the following setup: 1 1 LicenseAcceptedOverwritten = "1" 1 1 1 VALIDWINDOWSUSERCREDENTIALS = "1" 1 OCSVALUESVALIDATED = "1" 1 SQLCONNECTIONSTRINGVALIDATED = "1" 1 When i run my installation, as soon as i click "Next" in my WinNTCredDlg Dialog, the installer jumps to the progress bar where it starts installing the files(The dialog after VerifyReadyDlg). The "Next" Control in my WinNTCredDlg is as follows: 1 1 Any ideas? Is there a limit on how many dialogs you can use in the default WixUI_InstallDir? Thanks in advance, Stelios -- Stelios Kyprou Systems Engineer Formicary - delivering quality financial technology solutions(TM) www.formicary.net This message is confidential and may be privileged. It is intended solely for the named addressee. If you are not the intended recipient, please inform us. Any unauthorised dissemination, distribution or copying hereof is prohibited. Formicary Limited registered office in England and Wales, address 1 Taillar Road, Hedon, East Yorkshire HU12 8GU, registration number 3894343, VAT number 747644304, does not guarantee that the integrity of this communication has been maintained nor that this communication is free of viruses, interceptions or interference. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Editing config files after installation
Thanks Pally, I figured it out now... I didn't know that there is a strict format on using XMLConfig i.e i thought that by ommiting On='install' would still work. But that's not the case! Just in case anyone is wondering here is how i made it work: This for example will: -access the file with id: "file_id HERE" -locate the element under the element which has an attribute "key" and it's value is "FileServerBasePath" -get that element's attribute called "value", and change the value of that to: "TestModification" Before: After: Pally Sandher wrote: > XMLConfig & XMLFile don't make changes in the InstallUISequence, only in > the InstallExecuteSequence so using the contents of Properties from the > UI sequence should be fine. Are you setting your Properties to be > Secure? If you want to pass information in Properties from the > InstallUISequence to the InstallExecuteSequence you need to set > Secure="yes" on those Properties. If you're using XMLFile with > Action="SetValue" you should be able to use Properties in the Value > attribute as it is of the Formatted type according to the documentation. > > Personally I prefer to use XMLConfig for modifying files I'm putting on > the target machine but if you paste your code for your XMLFile Element & > the appropriate Properties (and what you expect them to contain) myself > or others on the list may be able to see where the problem lies or give > suggestions on using XMLConfig. > > Palbinder Sandher > Software Deployment & IT Administrator > T: +44 (0) 141 945 8500 > F: +44 (0) 141 945 8501 > > http://www.iesve.com > **Design, Simulate + Innovate with the ** > Integrated Environmental Solutions Limited. Registered in Scotland No. > SC151456 > Registered Office - Helix Building, West Of Scotland Science Park, > Glasgow G20 0SP > Email Disclaimer > > -Original Message- > From: Stelios Kyprou [mailto:stelios.kyp...@formicary.net] > Sent: 07 July 2010 13:23 > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Editing config files after installation > > The file is installed by the installer, so i can use [#foo.config]. > When i thought of doing this approach (XMLConfig || XMLFile), i got > stuck because: > I want to do the foo.config editing after a specific dialog, i.e > EnterConfigurationDlg, so that i can grab the PROPERTIES from that > dialog and put them in foo.config. > > Following the WiX tutorial at: > http://www.tramontana.co.hu/wix/lesson6.php#6.10 > did not really help with my senario... > > Any ideas? > > Stelios > > Pally Sandher wrote: > >> If the file is installed as part of your installation you can simply >> use it's Id as a Property e.g. [#foo.config] if you set >> Id="foo.config" in it's File element (see -> >> http://msdn.microsoft.com/en-us/library/aa368609.aspx). Use that >> Property as the path for either XMLConfig or XMLFile to make your >> changes to the file. >> >> If it's put on the target machine by some other means & you can locate >> > > >> the file using normal methods such as RegistrySearch >> (http://wix.sourceforge.net/manual-wix3/wix_xsd_registrysearch.htm), >> DirectorySearch >> (http://wix.sourceforge.net/manual-wix3/wix_xsd_directorysearch.htm) >> or FileSearch >> (http://wix.sourceforge.net/manual-wix3/wix_xsd_filesearch.htm) then >> do so to set your Property for XMLConfig/XMLFile. You will need no >> Custom Actions in either of these cases which should make your code >> much more resilient. >> >> If you can't locate the file using normal methods then a Custom Action >> > > >> which sets a Property containing the path to the file is your only >> option. >> >> How is this file installed on the target system initially? If it's by >> another product you can usually use a RegistrySearch to find something >> > > >> like the InstallLocation & extrapolate the rest of the path from >> > there. > >> If you're really lucky & the other products authors thought about this >> > > >> ahead of time there may be a standard registry key set by their >> installer for you to grab the location from. >> >> Avoid using Custom Actions unless you have no other option. >> >> Palbinder Sandher >> Software Deployment & IT Administrator >> T: +44 (0) 141 945 8500 >> F: +44 (0) 141 945 8501 &
Re: [WiX-users] Changing a Global property in a custom action is not immediately affecting the installer
Thanks for that! Should have searched the mail archives before posting this question ;P Blair wrote: > This has been discussed in this list many times before. You need to set your > property to the new value of the property when the action returns before > using it in the dialog. > > Y="243"> > Validate > > > >Value="ConfirmationCustomAction">1 > 1 >Value="InvalidConfigDlg"> > > > -Original Message- > From: Stelios Kyprou [mailto:stelios.kyp...@formicary.net] > Sent: Thursday, July 08, 2010 7:03 AM > To: General discussion for Windows Installer XML toolset. > Subject: [WiX-users] Changing a Global property in a custom action is not > immediately affecting the installer > > Hello! > > I have a custom action setting a Global property in the following way: > session[VALIDATED] = "1"; > > This CA is called when a user clicks a "Validate" button in a dialog. > The control is as follows: > > Y="243"> > Validate > > > >Value="ConfirmationCustomAction">1 >Value="InvalidConfigDlg"> > > > Now i have a "Next" button in the same dialog, which is initially Disabled, > and gets enabled when the VALIDATED > property get's set to 1: > > Default="no"> > Next > > > > > > > > > > Initially the Property VALIDATE is set to "0". > > Now when i run the installer, and i click "Validate", i can see in the log > files that the Property VALIDATE is set to 1 > (PROPERTY CHANGE: Modifying VALIDATED property. Its current value is '0'. > Its new value: '1'. > Action ended 14:38:57: ConfirmationCustomAction. Return value 1.), > but when the custom action returns ActionResult.Success, > the Next button is still Disabled. > > I have a bunch of edit boxes in my dialog, each one representing a Property. > > A senario that i realised that i can enable the "Next" button is: > > 1) I fill in all the edit boxes > 2) I click Validate > 3) The CA returns ActionResult.Success (Next button STILL disabled) > 4) I re-edit an edit box > 5) When i re-edit, the next button get's enabled. (and Validate get's > disabled) > > Any ideas why this is happening? > Under normal circumstances, when the CA ends and is successfull, the Next > button should get enabled. > > Thanks in advance, > Stelios > > -- Stelios Kyprou Systems Engineer Formicary - delivering quality financial technology solutions(TM) www.formicary.net This message is confidential and may be privileged. It is intended solely for the named addressee. If you are not the intended recipient, please inform us. Any unauthorised dissemination, distribution or copying hereof is prohibited. Formicary Limited registered office in England and Wales, address 1 Taillar Road, Hedon, East Yorkshire HU12 8GU, registration number 3894343, VAT number 747644304, does not guarantee that the integrity of this communication has been maintained nor that this communication is free of viruses, interceptions or interference. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Changing a Global property in a custom action is not immediately affecting the installer
Hello! I have a custom action setting a Global property in the following way: session[VALIDATED] = "1"; This CA is called when a user clicks a "Validate" button in a dialog. The control is as follows: Validate 1 Now i have a "Next" button in the same dialog, which is initially Disabled, and gets enabled when the VALIDATED property get's set to 1: Next Initially the Property VALIDATE is set to "0". Now when i run the installer, and i click "Validate", i can see in the log files that the Property VALIDATE is set to 1 (PROPERTY CHANGE: Modifying VALIDATED property. Its current value is '0'. Its new value: '1'. Action ended 14:38:57: ConfirmationCustomAction. Return value 1.), but when the custom action returns ActionResult.Success, the Next button is still Disabled. I have a bunch of edit boxes in my dialog, each one representing a Property. A senario that i realised that i can enable the "Next" button is: 1) I fill in all the edit boxes 2) I click Validate 3) The CA returns ActionResult.Success (Next button STILL disabled) 4) I re-edit an edit box 5) When i re-edit, the next button get's enabled. (and Validate get's disabled) Any ideas why this is happening? Under normal circumstances, when the CA ends and is successfull, the Next button should get enabled. Thanks in advance, Stelios -- Stelios Kyprou Systems Engineer Formicary - delivering quality financial technology solutions(TM) www.formicary.net This message is confidential and may be privileged. It is intended solely for the named addressee. If you are not the intended recipient, please inform us. Any unauthorised dissemination, distribution or copying hereof is prohibited. Formicary Limited registered office in England and Wales, address 1 Taillar Road, Hedon, East Yorkshire HU12 8GU, registration number 3894343, VAT number 747644304, does not guarantee that the integrity of this communication has been maintained nor that this communication is free of viruses, interceptions or interference. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Editing config files after installation
The file is installed by the installer, so i can use [#foo.config]. When i thought of doing this approach (XMLConfig || XMLFile), i got stuck because: I want to do the foo.config editing after a specific dialog, i.e EnterConfigurationDlg, so that i can grab the PROPERTIES from that dialog and put them in foo.config. Following the WiX tutorial at: http://www.tramontana.co.hu/wix/lesson6.php#6.10 did not really help with my senario... Any ideas? Stelios Pally Sandher wrote: > If the file is installed as part of your installation you can simply use > it's Id as a Property e.g. [#foo.config] if you set Id="foo.config" in > it's File element (see -> > http://msdn.microsoft.com/en-us/library/aa368609.aspx). Use that > Property as the path for either XMLConfig or XMLFile to make your > changes to the file. > > If it's put on the target machine by some other means & you can locate > the file using normal methods such as RegistrySearch > (http://wix.sourceforge.net/manual-wix3/wix_xsd_registrysearch.htm), > DirectorySearch > (http://wix.sourceforge.net/manual-wix3/wix_xsd_directorysearch.htm) or > FileSearch > (http://wix.sourceforge.net/manual-wix3/wix_xsd_filesearch.htm) then do > so to set your Property for XMLConfig/XMLFile. You will need no Custom > Actions in either of these cases which should make your code much more > resilient. > > If you can't locate the file using normal methods then a Custom Action > which sets a Property containing the path to the file is your only > option. > > How is this file installed on the target system initially? If it's by > another product you can usually use a RegistrySearch to find something > like the InstallLocation & extrapolate the rest of the path from there. > If you're really lucky & the other products authors thought about this > ahead of time there may be a standard registry key set by their > installer for you to grab the location from. > > Avoid using Custom Actions unless you have no other option. > > Palbinder Sandher > Software Deployment & IT Administrator > T: +44 (0) 141 945 8500 > F: +44 (0) 141 945 8501 > > http://www.iesve.com > **Design, Simulate + Innovate with the ** > Integrated Environmental Solutions Limited. Registered in Scotland No. > SC151456 > Registered Office - Helix Building, West Of Scotland Science Park, > Glasgow G20 0SP > Email Disclaimer > > -Original Message- > From: Stelios Kyprou [mailto:stelios.kyp...@formicary.net] > Sent: 07 July 2010 11:34 > To: General discussion for Windows Installer XML toolset. > Subject: [WiX-users] Editing config files after installation > > Hello, > I suppose this question was asked before, but i couldn't find a clear > answer for it: > > When an installer runs on the target machine, and installs all the files > in the InstallDir, i would like to carry some extra actions. > -Get a config file that was installed, i.e foo.config. > -Modify that file (which is in xml format), by adding some values in the > key/value pairs. > > Now as far as i know from the search i've done, i can only do this after > InstallFinalize, because that is when the files are showing in the > InstallDir.? > > What is the ideal way of doing this? > i.e: > -are there built in wix methods to grab foo.config? > -should i use the "util:XmlFile" tag for the editing? > -what are the general steps for doing this process? e.g put all the > steps in a custom action and call it after InstallFinalize? > > Thanks in advance, > Stelios > > -- > Stelios Kyprou > Systems Engineer > Formicary - delivering quality financial technology solutions(TM) > www.formicary.net > > > > > This message is confidential and may be privileged. It is intended > solely for > the named addressee. If you are not the intended recipient, please > inform us. > Any unauthorised dissemination, distribution or copying hereof is > prohibited. > > Formicary Limited registered office in England and Wales, address 1 > Taillar > Road, Hedon, East Yorkshire HU12 8GU, registration number 3894343, VAT > number > 747644304, does not guarantee that the integrity of this communication > has been > maintained nor that this communication is free of viruses, interceptions > or > interference. > > > > > -- > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.
Re: [WiX-users] Editing config files after installation
The file is installed by the installer, so i can use [#foo.config]. When i thought of doing this approach (XMLConfig || XMLFile), i got stuck because: I want to do the foo.config editing after a specific dialog, i.e EnterConfigurationDlg, so that i can grab the PROPERTIES from that dialog and put them in foo.config. Following the WiX tutorial at: http://www.tramontana.co.hu/wix/lesson6.php#6.10 did not really help with my senario... Any ideas? Stelios > Pally Sandher wrote: >> If the file is installed as part of your installation you can simply use >> it's Id as a Property e.g. [#foo.config] if you set Id="foo.config" in >> it's File element (see -> >> http://msdn.microsoft.com/en-us/library/aa368609.aspx). Use that >> Property as the path for either XMLConfig or XMLFile to make your >> changes to the file. >> >> If it's put on the target machine by some other means & you can locate >> the file using normal methods such as RegistrySearch >> (http://wix.sourceforge.net/manual-wix3/wix_xsd_registrysearch.htm), >> DirectorySearch >> (http://wix.sourceforge.net/manual-wix3/wix_xsd_directorysearch.htm) or >> FileSearch >> (http://wix.sourceforge.net/manual-wix3/wix_xsd_filesearch.htm) then do >> so to set your Property for XMLConfig/XMLFile. You will need no Custom >> Actions in either of these cases which should make your code much more >> resilient. >> >> If you can't locate the file using normal methods then a Custom Action >> which sets a Property containing the path to the file is your only >> option. >> >> How is this file installed on the target system initially? If it's by >> another product you can usually use a RegistrySearch to find something >> like the InstallLocation & extrapolate the rest of the path from there. >> If you're really lucky & the other products authors thought about this >> ahead of time there may be a standard registry key set by their >> installer for you to grab the location from. >> >> Avoid using Custom Actions unless you have no other option. >> >> Palbinder Sandher Software Deployment & IT Administrator >> T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 >> http://www.iesve.com **Design, Simulate + Innovate with the > Environment>** >> Integrated Environmental Solutions Limited. Registered in Scotland No. >> SC151456 Registered Office - Helix Building, West Of Scotland Science >> Park, >> Glasgow G20 0SP >> Email Disclaimer >> >> -Original Message- >> From: Stelios Kyprou [mailto:stelios.kyp...@formicary.net] Sent: 07 >> July 2010 11:34 >> To: General discussion for Windows Installer XML toolset. >> Subject: [WiX-users] Editing config files after installation >> >> Hello, >> I suppose this question was asked before, but i couldn't find a clear >> answer for it: >> >> When an installer runs on the target machine, and installs all the files >> in the InstallDir, i would like to carry some extra actions. >> -Get a config file that was installed, i.e foo.config. >> -Modify that file (which is in xml format), by adding some values in the >> key/value pairs. >> >> Now as far as i know from the search i've done, i can only do this after >> InstallFinalize, because that is when the files are showing in the >> InstallDir.? >> >> What is the ideal way of doing this? >> i.e: >> -are there built in wix methods to grab foo.config? >> -should i use the "util:XmlFile" tag for the editing? >> -what are the general steps for doing this process? e.g put all the >> steps in a custom action and call it after InstallFinalize? >> >> Thanks in advance, >> Stelios >> >> -- >> Stelios Kyprou >> Systems Engineer >> Formicary - delivering quality financial technology solutions(TM) >> www.formicary.net >> >> >> >> >> This message is confidential and may be privileged. It is intended >> solely for >> the named addressee. If you are not the intended recipient, please >> inform us. >> Any unauthorised dissemination, distribution or copying hereof is >> prohibited. >> >> Formicary Limited registered office in England and Wales, address 1 >> Taillar >> Road, Hedon, East Yorkshire HU12 8GU, registration number 3894343, VAT >> number >> 747644304, does not guarantee that the integrity of this
[WiX-users] Editing config files after installation
Hello, I suppose this question was asked before, but i couldn't find a clear answer for it: When an installer runs on the target machine, and installs all the files in the InstallDir, i would like to carry some extra actions. -Get a config file that was installed, i.e foo.config. -Modify that file (which is in xml format), by adding some values in the key/value pairs. Now as far as i know from the search i've done, i can only do this after InstallFinalize, because that is when the files are showing in the InstallDir.? What is the ideal way of doing this? i.e: -are there built in wix methods to grab foo.config? -should i use the "util:XmlFile" tag for the editing? -what are the general steps for doing this process? e.g put all the steps in a custom action and call it after InstallFinalize? Thanks in advance, Stelios -- Stelios Kyprou Systems Engineer Formicary - delivering quality financial technology solutions(TM) www.formicary.net This message is confidential and may be privileged. It is intended solely for the named addressee. If you are not the intended recipient, please inform us. Any unauthorised dissemination, distribution or copying hereof is prohibited. Formicary Limited registered office in England and Wales, address 1 Taillar Road, Hedon, East Yorkshire HU12 8GU, registration number 3894343, VAT number 747644304, does not guarantee that the integrity of this communication has been maintained nor that this communication is free of viruses, interceptions or interference. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrade msi with removed components
> > Use the RemoveFile Element to get delete orphaned files with the > attribute On="both". See -> > http://wix.sourceforge.net/manual-wix3/wix_xsd_removefile.htm > > Nice! > Yes you can't use an auto-generated ProductCode for a Minor Update only > Major Upgrades. Your ProductCode needs to be unchanged for Small Update > & Minor Updates. See -> > http://msdn.microsoft.com/en-us/library/aa370579.aspx > I am aware about the product codes. What i was asking for though is Component GUIDs. Can they change with each msi? i.e. If i have and i make an update installer, where the file of this component is unchanged, what happens if i assign a new GUID to the component? > Palbinder Sandher > Software Deployment & IT Administrator > T: +44 (0) 141 945 8500 > F: +44 (0) 141 945 8501 > > http://www.iesve.com > **Design, Simulate + Innovate with the ** > Integrated Environmental Solutions Limited. Registered in Scotland No. > SC151456 > Registered Office - Helix Building, West Of Scotland Science Park, > Glasgow G20 0SP > Email Disclaimer > > -Original Message- > From: Stelios Kyprou [mailto:stelios.kyp...@formicary.net] > Sent: 02 July 2010 13:13 > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Upgrade msi with removed components > > Found the issue! > Since i'm new to wix and ma,ing Installers, i must havr broken the > component rules at one point, and that's why the component resources > where not removed. > I changed the GUID of the component that should have been removed from > version 1.0.0 to version 2.0.0, and then it was removed. > The good thing is i now know that i HAVE to always try and not break the > component rules. > > So now a new question is raised: > -Let's say a resource becomes orphaned after uninstall, how can i get > out of this state? > Because when i reinstall the product, and then uninstall it again, that > Resource will again not get uninstalled. > -Also, when i install a product, with a future plan of having both > Minor AND Major updates, the component GUID's should not be "*" right? I > can't visualise how this would work with a Minor update... > Correct me if i'm wrong? > > Stelios > > Pally Sandher wrote: > >> It should remove the file if the component is removed from a Feature. >> Have you tested it? If so have you checked a verbose log? >> >> If you're getting an orphaned file try scheduling >> RemoveExistingProducts Before InstallInitialize e.g. >> >> >> >> See http://msdn.microsoft.com/en-us/library/aa371197.aspx >> >> Palbinder Sandher >> Software Deployment & IT Administrator >> T: +44 (0) 141 945 8500 >> F: +44 (0) 141 945 8501 >> >> http://www.iesve.com >> **Design, Simulate + Innovate with the ** >> Integrated Environmental Solutions Limited. Registered in Scotland No. >> SC151456 >> Registered Office - Helix Building, West Of Scotland Science Park, >> Glasgow G20 0SP Email Disclaimer >> >> -Original Message- >> From: Stelios Kyprou [mailto:stelios.kyp...@formicary.net] >> Sent: 01 July 2010 18:06 >> To: General discussion for Windows Installer XML toolset. >> Subject: [WiX-users] Upgrade msi with removed components >> >> Hello wix users, >> a quick question! >> If i create my msi with a major version upgrade (assume i'm doing >> everything correctly, i.e change ProductCode, PackageCode, leave >> Upgradecode intact, change version number, add >> >> >> >> in InstallExecuteSequence), >> and leave the Component Guids the same, and only remove one Component >> with a file Foo.txt, isn't it supposed to be removed from the install >> location? or does it stay orphaned? >> >> Regards, >> Stelios >> >> -- >> Stelios Kyprou >> Systems Engineer >> Formicary - delivering quality financial technology solutions(TM) >> www.formicary.net >> >> >> >> -- >> -- >> >> This message is confidential and may be privileged. It is intended >> solely for the named addressee. If you are not the intended recipient, >> > > >> please inform us. >> Any unauthorised dissemination, distribution or copying hereof is >> prohibited. >> >> Formicary Limited registered office in England and Wales, address 1 >> Taillar Road, Hedon, East Yorkshire HU12 8GU, registration number >> 3894343, VAT number
Re: [WiX-users] Upgrade msi with removed components
Found the issue! Since i'm new to wix and ma,ing Installers, i must havr broken the component rules at one point, and that's why the component resources where not removed. I changed the GUID of the component that should have been removed from version 1.0.0 to version 2.0.0, and then it was removed. The good thing is i now know that i HAVE to always try and not break the component rules. So now a new question is raised: -Let's say a resource becomes orphaned after uninstall, how can i get out of this state? Because when i reinstall the product, and then uninstall it again, that Resource will again not get uninstalled. -Also, when i install a product, with a future plan of having both Minor AND Major updates, the component GUID's should not be "*" right? I can't visualise how this would work with a Minor update... Correct me if i'm wrong? Stelios Pally Sandher wrote: > It should remove the file if the component is removed from a Feature. > Have you tested it? If so have you checked a verbose log? > > If you're getting an orphaned file try scheduling RemoveExistingProducts > Before InstallInitialize e.g. > > > > See http://msdn.microsoft.com/en-us/library/aa371197.aspx > > Palbinder Sandher > Software Deployment & IT Administrator > T: +44 (0) 141 945 8500 > F: +44 (0) 141 945 8501 > > http://www.iesve.com > **Design, Simulate + Innovate with the ** > Integrated Environmental Solutions Limited. Registered in Scotland No. > SC151456 > Registered Office - Helix Building, West Of Scotland Science Park, > Glasgow G20 0SP > Email Disclaimer > > -Original Message- > From: Stelios Kyprou [mailto:stelios.kyp...@formicary.net] > Sent: 01 July 2010 18:06 > To: General discussion for Windows Installer XML toolset. > Subject: [WiX-users] Upgrade msi with removed components > > Hello wix users, > a quick question! > If i create my msi with a major version upgrade (assume i'm doing > everything correctly, i.e change ProductCode, PackageCode, leave > Upgradecode intact, change version number, add > > > > in InstallExecuteSequence), > and leave the Component Guids the same, and only remove one Component > with a file Foo.txt, isn't it supposed to be removed from the install > location? or does it stay orphaned? > > Regards, > Stelios > > -- > Stelios Kyprou > Systems Engineer > Formicary - delivering quality financial technology solutions(TM) > www.formicary.net > > > > > > This message is confidential and may be privileged. It is intended > solely for > the named addressee. If you are not the intended recipient, please > inform us. > Any unauthorised dissemination, distribution or copying hereof is > prohibited. > > Formicary Limited registered office in England and Wales, address 1 > Taillar > Road, Hedon, East Yorkshire HU12 8GU, registration number 3894343, VAT > number > 747644304, does not guarantee that the integrity of this communication > has been > maintained nor that this communication is free of viruses, interceptions > or > interference. > > > > -- > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > > > -- > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > -- Stelios Kyprou Systems Engineer Formicary - delivering quality financial technology solutions(TM) www.formicary.net This message is confidential and may be privileged. It is intended solely for the named addressee. If you are not the intended recipient, please inform us. Any unauthorised dissemination, distribution or copying hereof is prohibited. Formicary Limited registered office in England and Wales, address 1 Taillar Road, Hedon, East Yorkshire HU12 8GU, registration number 3894343, VAT number 747644304, does not guarantee that the integrity of this c
[WiX-users] Upgrade msi with removed components
Hello wix users, a quick question! If i create my msi with a major version upgrade (assume i'm doing everything correctly, i.e change ProductCode, PackageCode, leave Upgradecode intact, change version number, add in InstallExecuteSequence), and leave the Component Guids the same, and only remove one Component with a file Foo.txt, isn't it supposed to be removed from the install location? or does it stay orphaned? Regards, Stelios Anthony Wieser wrote: > I've created a Wix project, and set up some additional items for my project. > > Included is a folder named bitmaps, containing banner.jpg and dialog.jpg > > when I then export a vstemplate file, and add it as a user item, when I > create a new project based on the template the bitmaps are corrupted > (getting UTF-8 ified), replacing all non-ansi characters with something > else, as described here: > > http://social.msdn.microsoft.com/Forums/en-US/vsx/thread/0316b38f-b78f-4b31-b667-d2b189b3dbfb > > > I'm using the very latest build of Wix 3.5 > > The problem doesn't occur on the last version of WiX 3.0 on a different > machine. > > Any idea why? > > Anthony Wieser > Wieser Software Ltd > > > -- > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > -- Stelios Kyprou Systems Engineer Formicary - delivering quality financial technology solutions(TM) www.formicary.net This message is confidential and may be privileged. It is intended solely for the named addressee. If you are not the intended recipient, please inform us. Any unauthorised dissemination, distribution or copying hereof is prohibited. Formicary Limited registered office in England and Wales, address 1 Taillar Road, Hedon, East Yorkshire HU12 8GU, registration number 3894343, VAT number 747644304, does not guarantee that the integrity of this communication has been maintained nor that this communication is free of viruses, interceptions or interference. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] VS2010 automated build
Good stuff! @John: A Paraffin question: What if i want to exclude files lets say with extension: .vshost.exe, but not .exe files? I think i am not able to do that am i? Stelios Rob Mensching wrote: > FYI: given the issues with auto-harvesting in WiX v3.5, that feature will be > disabled before shipping. We'll try to bring it back in WiX v4.0. > > On Wed, Jun 30, 2010 at 5:52 PM, John Robbins wrote: > > >> Hi, >> >> I had the same itch to scratch a while ago so I wrote a tool I called >> Paraffin to make my life easier. >> >> The overview to the tool: >> http://www.wintellect.com/cs/blogs/jrobbins/archive/2007/10/21/wix-a-better-tallow-paraffin.aspx >> More on updates to Paraffin based on requests: >> >> http://www.wintellect.com/CS/blogs/jrobbins/archive/2009/06/28/paraffin3-1-new-and-improved.aspx >> >> http://www.wintellect.com/CS/blogs/jrobbins/archive/2010/05/11/paraffin-3-12-a-bug-fix-and-three-new-features.aspx >> >> The latest version: >> http://www.wintellect.com/CS/files/folders/8198/download.aspx >> >> Hope you find it useful. >> >> - John Robbins >> >> >>> -Original Message- >>> From: Stelios Kyprou [mailto:stelios.kyp...@formicary.net] >>> Sent: Wednesday, June 30, 2010 11:31 AM >>> To: General discussion for Windows Installer XML toolset. >>> Subject: [WiX-users] VS2010 automated build >>> >>> Hello everyone, >>> >>> I was wondering: >>> what is the "best" way to autogenerate fragments for a visual studio >>> >> project? >> >>> -by including it as a reference (and set harvest to TRUE) in your >>> >> .wixproj, you >> >>> can't get the referenced libraries. >>> -by doing heat.exe on the bin directory of the project, you get files not >>> needed, i.e .pdb files -by doing it manually, well...that means every time >>> >> i >> >>> change the c# project, i have to do it all over again... >>> >>> Any ideas? >>> >>> p.s: is HEAT going to add the referenced libraries in the fragment of the >>> >> c# >> >>> project the uses them (and is referenced in .wixproj) in wix 3.5 stable >>> >> release? >> >>> I'm using latest build of wix 3.5 and vs2010 >>> >>> Regards, >>> Stelios >>> >>> -- >>> Stelios Kyprou >>> Systems Engineer >>> Formicary - delivering quality financial technology solutions(TM) >>> www.formicary.net >>> >>> >>> >>> >>> This message is confidential and may be privileged. It is intended solely >>> >> for >> >>> the named addressee. If you are not the intended recipient, please inform >>> >> us. >> >>> Any unauthorised dissemination, distribution or copying hereof is >>> >> prohibited. >> >>> Formicary Limited registered office in England and Wales, address 1 >>> >> Taillar >> >>> Road, Hedon, East Yorkshire HU12 8GU, registration number 3894343, VAT >>> number >>> 747644304, does not guarantee that the integrity of this communication has >>> been >>> maintained nor that this communication is free of viruses, interceptions >>> >> or >> >>> interference. >>> >>> >>> >>> >>> ---------- >>> This SF.net email is sponsored by Sprint >>> What will you do first with EVO, the first 4G phone? >>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first >>> ___ >>> WiX-users mailing list >>> WiX-users@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/wix-users >>> >> -- >> This SF.net email is sponsored by Sprint >> What will you do first with EVO, the first 4G phone? >> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first >> _
[WiX-users] VS2010 automated build
Hello everyone, I was wondering: what is the "best" way to autogenerate fragments for a visual studio project? -by including it as a reference (and set harvest to TRUE) in your .wixproj, you can't get the referenced libraries. -by doing heat.exe on the bin directory of the project, you get files not needed, i.e .pdb files -by doing it manually, well...that means every time i change the c# project, i have to do it all over again... Any ideas? p.s: is HEAT going to add the referenced libraries in the fragment of the c# project the uses them (and is referenced in .wixproj) in wix 3.5 stable release? I'm using latest build of wix 3.5 and vs2010 Regards, Stelios -- Stelios Kyprou Systems Engineer Formicary - delivering quality financial technology solutions(TM) www.formicary.net This message is confidential and may be privileged. It is intended solely for the named addressee. If you are not the intended recipient, please inform us. Any unauthorised dissemination, distribution or copying hereof is prohibited. Formicary Limited registered office in England and Wales, address 1 Taillar Road, Hedon, East Yorkshire HU12 8GU, registration number 3894343, VAT number 747644304, does not guarantee that the integrity of this communication has been maintained nor that this communication is free of viruses, interceptions or interference. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] sfxca.dll 32 and 64 bit version in visual studio 2010 (wix 3.5)
When i build, the logs show this: *... Task "CreateProperty" Done executing task "CreateProperty". Task "CreateProperty" Done executing task "CreateProperty". Task "CreateProperty" Done executing task "CreateProperty". Task "CreateProperty" skipped, due to false condition; ( '$(SfxCADll)' == '' and '$(Platform)' == 'x64') was evaluated as ( 'C:\Program Files (x86)\Windows Installer XML v3.5\bin\..\sdk\x86\SfxCA.dll' == '' and 'x86' == 'x64'). * which means that SfxCADll get's evaluated in this line in /wix.ca.targets:/ * * So when building, the Platform is set to x86, not x64... NOTE that when i said that i set the Platform target to x64 (in my CustomActions project), i meant the option i have to set it under "General" in the Build tab (option under the "Define TRACE constant" checkbox). The "Platform" oprion on top of the Build tab, is set to "Active (x86)", which i suppose corresponds to the value used for '$(Platform)' in wix.ca.targets(?). I do not have the option to set that to x64. Any ideas? Thanks in advance, Stelios Jason Ginchereau wrote: >>> I tried setting the Platform target of the custom actions project to x64 >>> > > That should do exactly what you want. When you have set that, can you check > the build logs to see whether it is getting sfxca.dll from Program Files > (x86)\Windows Installer XML v3.5\SDK\x64 ? > > The relevant logic is on line 87 of wix.ca.targets: > > > > > -Jason- > > -Original Message- > From: Stelios Kyprou [mailto:stelios.kyp...@formicary.net] > Sent: Tuesday, June 29, 2010 9:53 AM > To: wix-users@lists.sourceforge.net > Subject: [WiX-users] sfxca.dll 32 and 64 bit version in visual studio 2010 > (wix 3.5) > > Hello wix users! > This is my first email, so if i do something wrong, please bare with me (but > DO tell me ;) > > I have a situation where i'm really stuck and want to do things the right way: > I use Wix 3.5.1811.0 in visual studio 2010. > Skipping the basic configuration stuff, i create a "c# custom action project" > and add my custom action in there. > That custom action project uses a dll that is 64bit I then use it properly in > my .wixproj by referencing the customaction project. > > The question is: > When i build the C# custom action project, it grabs sfxca.dll from C:\Program > Files (x86)\Windows Installer XML v3.5\SDK\x86 instead of C:\Program Files > (x86)\Windows Installer XML v3.5\SDK\x64. > > Thus, when i build the msi and run it, in the logs i get a > BadImageFormatException and the installation fails. > > I did a hack, where i just replaced the sfxca.dll in the X86 folder with the > 64 bit version, rebuild, and the installer runs fine. But OBVIOUSLY this is > not acceptable. > > How can i configure the project to use the 64bit version of sfxca.dll which > is under C:\Program Files (x86)\Windows Installer XML v3.5\SDK\x64 WITHIN > visual studio? > > -I tried setting the Platform target of the custom actions project to > x64 : No positive results. > -Under the "Build" tab in the custom actions project properties, the > Configuration is set to "Active(Release)" and Platform to "Active(x86)". > I have No other available options under Platform. > -Informationally, in the .wixproj, Product/Platform is set to x64 (for a > 64 bit installer). > > Any suggestions would be appreciated! > > Regards, > Stelios > > -- > Stelios Kyprou > Systems Engineer > Formicary - delivering quality financial technology solutions(TM) > www.formicary.net o : +44 (0)20 7920 7100 > > > > This message is confidential and may be privileged. It is intended solely for > the named addressee. If you are not the intended recipient, please inform us. > Any unauthorised dissemination, distribution or copying hereof is prohibited. > > Formicary Limited registered office in England and Wales, address 1 Taillar > Road, Hedon, East Yorkshire HU12 8GU, registration number 3894343, VAT number > 747644304, does not guarantee that the integrity of this communication has > been > maintained nor that this communication is free of viruses, interceptions or > interference. > > > -- > This SF.net email is sponsored by Sprint > What will you do
[WiX-users] sfxca.dll 32 and 64 bit version in visual studio 2010 (wix 3.5)
Hello wix users! This is my first email, so if i do something wrong, please bare with me (but DO tell me ;) I have a situation where i'm really stuck and want to do things the right way: I use Wix 3.5.1811.0 in visual studio 2010. Skipping the basic configuration stuff, i create a "c# custom action project" and add my custom action in there. That custom action project uses a dll that is 64bit I then use it properly in my .wixproj by referencing the customaction project. The question is: When i build the C# custom action project, it grabs sfxca.dll from C:\Program Files (x86)\Windows Installer XML v3.5\SDK\x86 instead of C:\Program Files (x86)\Windows Installer XML v3.5\SDK\x64. Thus, when i build the msi and run it, in the logs i get a BadImageFormatException and the installation fails. I did a hack, where i just replaced the sfxca.dll in the X86 folder with the 64 bit version, rebuild, and the installer runs fine. But OBVIOUSLY this is not acceptable. How can i configure the project to use the 64bit version of sfxca.dll which is under C:\Program Files (x86)\Windows Installer XML v3.5\SDK\x64 WITHIN visual studio? -I tried setting the Platform target of the custom actions project to x64 : No positive results. -Under the "Build" tab in the custom actions project properties, the Configuration is set to "Active(Release)" and Platform to "Active(x86)". I have No other available options under Platform. -Informationally, in the .wixproj, Product/Platform is set to x64 (for a 64 bit installer). Any suggestions would be appreciated! Regards, Stelios -- Stelios Kyprou Systems Engineer Formicary - delivering quality financial technology solutions(TM) www.formicary.net o : +44 (0)20 7920 7100 This message is confidential and may be privileged. It is intended solely for the named addressee. If you are not the intended recipient, please inform us. Any unauthorised dissemination, distribution or copying hereof is prohibited. Formicary Limited registered office in England and Wales, address 1 Taillar Road, Hedon, East Yorkshire HU12 8GU, registration number 3894343, VAT number 747644304, does not guarantee that the integrity of this communication has been maintained nor that this communication is free of viruses, interceptions or interference. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
