Re: [WiX-users] ServiceInstall/ServiceControl name attribute restrictions
Trying that again... When I pass a variable reference such as [FOO]_[BAR] to the name attribute of both a ServiceInstall and ServiceControl element the package installs fine however when uninstalling the service is left running without being stopped and removed. When I pass a literal string, the package uninstalls fine. The docs do not indicate any restrictions, does anyone know of any reason this may occur? Thanks, jlc -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] ServiceInstall/ServiceControl name attribute restrictions
http://robmensching.com/blog/posts/2010/5/2/the-wix-toolsets-remember-property-pattern/ _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: Joseph L. Casale [mailto:jcas...@activenetwerx.com] Sent: Thursday, March 5, 2015 1:06 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] ServiceInstall/ServiceControl name attribute restrictions Trying that again... When I pass a variable reference such as [FOO]_[BAR] to the name attribute of both a ServiceInstall and ServiceControl element the package installs fine however when uninstalling the service is left running without being stopped and removed. When I pass a literal string, the package uninstalls fine. The docs do not indicate any restrictions, does anyone know of any reason this may occur? Thanks, jlc -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] ServiceInstall/ServiceControl name attribute restrictions
http://robmensching.com/blog/posts/2010/5/2/the-wix-toolsets-remember-property-pattern/ Much appreciated, this installer at a later must support multiple instances at which point then this will all fit together, no need for a static location as I assume we can compile an extension to enumerate the instances installed at invocation time? Thanks! jlc -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Where is the v3.10 feed?
I get a 404 when going to http://wixtoolset.org/releases/feed/v3.10, and the bundle can't access it either. -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] DetectRelatedMsiPackage - confused about args.
I have been researching 'cool bobs', and while I have come to the conclusion
that this post is not directly related to the use of 'bundle of bundles', I
just had to use that acronym.
In the course of the above research I added handlers for all of the
DetectXxx and PlanXxx events to my mba. In each handler I log all of the
EventArgs. My bundle includes MsiPackages for a multiplatform-multicultural
project. So in this case there are 14 MSI packages from the same project
with the same UpgradeCode, and version (for a particular build of the
bundle), but each has a different ProductCode as a result of the Wix batch
build process. There are seven packages that are x64 and seven that are
x86. The MsiPackage/@InstallCondition is defined to assure that the correct
culture and platform is installed for the native OS, i.e x86 is never
installed on x64 OS. Only one package can be installed, hence the common
UpgradeCode.
The DetectRelatedMsiPackage log entries (when run on a x64 target system)
are:
[0A68:008C][2015-03-05T09:50:58]i103: Detected related package:
{F703A7CD-F1D1-4697-A461-849B850E6953}, scope: PerMachine, version:
9.1.168.0, language: 0 operation: MajorUpgrade
[0A68:008C][2015-03-05T09:50:58]i000: DetectRelatedMsiPackage: e.Operation:
MajorUpgrade, e.PackageId: msi_x86_de_DE, e.PerMachine: True, e.ProductCode:
{F703A7CD-F1D1-4697-A461-849B850E6953}, e.Result: 9.1.168.0, e.Version:
9.1.168.0
[0A68:008C][2015-03-05T09:50:58]i103: Detected related package:
{F703A7CD-F1D1-4697-A461-849B850E6953}, scope: PerMachine, version:
9.1.168.0, language: 0 operation: MajorUpgrade
[0A68:008C][2015-03-05T09:50:58]i000: DetectRelatedMsiPackage: e.Operation:
MajorUpgrade, e.PackageId: msi_x86_en_US, e.PerMachine: True, e.ProductCode:
{F703A7CD-F1D1-4697-A461-849B850E6953}, e.Result: 9.1.168.0, e.Version:
9.1.168.0
There is a similar DetectRelatedMsiPackage for each of the _x86 cultures.
In each case the e.ProductCode is the correct code for the msi_x64_en_US
package, which is the only package that the Plan shows has been, and for
Repair, will be installed.
The source (docs) has these comments:
/// The identity of the package detecting.
/// The identity of the related package detected.
/// Whether the detected package is per machine.
/// The version of the related package detected.
/// The operation that will be taken on the detected package.
So I am left wondering:
1) Why is the version string returned in e.Result (I checked my mba code for
typos)?
2) Why is the ProductCode the package the (in this case x64_en_US) package
that is installed? Am I just confused by the use of 'related' in the source
comment?
3) (related to #2) Are the not listed x64 packages 'related' to the
x64_en-US package installed? (I assume that they are not listed because in
most cases it would be too much noise.)
I am not sure of the purpose of DetectRelatedMsiPackage. (I also never
understood the concept of ForwardCompatible packages. I also never could
get DetectMsiFeature to fire, which is what started this journey). I say
that because I am not sure how to ask the above questions, and appreciate
any comments that might help me to understand Burn. Thanks Phill
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/DetectRelatedMsiPackage-confused-about-args-tp7599478.html
Sent from the wix-users mailing list archive at Nabble.com.
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] ServiceInstall/ServiceControl name attribute restrictions
When I pass a variable reference to the name attribute of both a ServiceInstall and ServiceControl -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Burn: Are chained MSI packages required at build time?
Hello, to my current knowledge, the MSI packages referenced as MsiPackage elements within a chain must be available at build time, regardless of whether they shall be compressed into the bootstrapper or not. Is there a way to circumvent this? Does Burn read vital information (Product codes etc.) from the msi packages at build time, and can this information be entered later e.g. via Burn variables? My goal is to provide an easy way to create bundles for several packages with identical logic, but different content, and my favourite workflow would be to build an adapted version of the bootstrapper first and copy in the packages later. (BTW: With ISChainer, this works...) Best regards Matthias -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn: Are chained MSI packages required at build time?
Yes, for ExePackage, not today for MsiPackage. There is a lot of information gathered for MsiPackage that RemotePayload cannot represent. Not sure if there is already feature request tracking it... _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: Reuss, Matthias [mailto:matthias.mr.re...@sivantos.com] Sent: Thursday, March 5, 2015 1:10 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Burn: Are chained MSI packages required at build time? Hello, to my current knowledge, the MSI packages referenced as MsiPackage elements within a chain must be available at build time, regardless of whether they shall be compressed into the bootstrapper or not. Is there a way to circumvent this? Does Burn read vital information (Product codes etc.) from the msi packages at build time, and can this information be entered later e.g. via Burn variables? My goal is to provide an easy way to create bundles for several packages with identical logic, but different content, and my favourite workflow would be to build an adapted version of the bootstrapper first and copy in the packages later. (BTW: With ISChainer, this works...) Best regards Matthias -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Bootstrapper Show conditional message box or String without cancel Installation
Custom BA could. _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: RonnyS [mailto:ronnys.cod...@gmail.com] Sent: Thursday, March 5, 2015 2:47 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Bootstrapper Show conditional message box or String without cancel Installation Hello, is there some way to show in the boostrapper a message box or string in UI due to some condition but *continue* installation? At the moment i have this: bal:Condition Message=#(loc.FailtureVersionNTisXP) VersionNT v5.1 /bal:Condition but it terminates the Installation if an user have Windows XP. I need to show a MessageBox at start the Bootstrapper if user has WinXP or a conditional String in HyperlinkTheme.xml without cancel the installation. Page Name=Install Text X=11 Y=121 Width=-11 Height=71 FontId=3 #(loc.InstallWelcomeMsg)/Text I found a sample on this page from Jakob S. http://stackoverflow.com/questions/8239188/wix-show-conditional-message-box-without-cancel . But the sample works at me only in the msi not in the bootstrapper. I hope someone has an idea. -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Bootstrapper Show conditional message box or String without cancel Installation
Hello, is there some way to show in the boostrapper a message box or string in UI due to some condition but *continue* installation? At the moment i have this: bal:Condition Message=#(loc.FailtureVersionNTisXP) VersionNT v5.1 /bal:Condition but it terminates the Installation if an user have Windows XP. I need to show a MessageBox at start the Bootstrapper if user has WinXP or a conditional String in HyperlinkTheme.xml without cancel the installation. Page Name=Install Text X=11 Y=121 Width=-11 Height=71 FontId=3 #(loc.InstallWelcomeMsg)/Text I found a sample on this page from Jakob S. http://stackoverflow.com/questions/8239188/wix-show-conditional-message-box-without-cancel . But the sample works at me only in the msi not in the bootstrapper. I hope someone has an idea. -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Bug 3421 | Burn uninstalls upgraded MSIs during rollback
I have a bundle (built with v3.9) with a custom managed BA with 3 packages in the Chain- what the packages contain is not important so let's call them PackageA, PackageB and PackageC. I install v1 of my bundle, which installs v1 of each package. I then start an upgrade to v2. It upgrades PackageA to v2 (which translates to an install of PackageA v2), and starts the upgrade of PackageB, but then I hit cancel[1]. PackageB rolls itself back without intervention from the bundle. PackageC never got called because the bundle never got that far, so doesn't need rolling back. PackageA, however, completed its install transaction, so needs to be rolled back by the bundle. Because its initial action on upgrade was an Install, the rollback translates to uninstall. This leaves the environment without either version of PackageA. At this point, I think a bundle repair is needed to reinstall that package. I think this is a manifestation of Wix bug 3421 http://wixtoolset.org/issues/3421/ . I was wondering whether anyone could point me to the best way to trigger a repair / reinstall of the old related bundle post rollback during an upgrade. [1] I suppose some other error condition at this point might cause the same behaviour - the point is that a rollback is caused ThanksJohn -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Bug-3421-Burn-uninstalls-upgraded-MSIs-during-rollback-tp7599475.html Sent from the wix-users mailing list archive at Nabble.com. -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Where is the v3.10 feed?
Thanks, fix should be published in 15 min or so. First time we had two digits and the redirect regex didn't expect that. Oops. _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: Sean Hall [mailto:r.sean.h...@gmail.com] Sent: Thursday, March 5, 2015 5:14 PM To: General discussion about the WiX toolset. Subject: [WiX-users] Where is the v3.10 feed? I get a 404 when going to http://wixtoolset.org/releases/feed/v3.10, and the bundle can't access it either. -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
