Re: [WiX-users] Installing Wix 3.7 - Root Certs Needed
This update (http://support.microsoft.com/kb/931125) has a lot of certs. Can
we isolate this down at all?
-Original Message-
From: keith.doug...@statcan.gc.ca [mailto:keith.doug...@statcan.gc.ca]
Sent: Tuesday, October 15, 2013 8:23 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Installing Wix 3.7 - Root Certs Needed
My server support colleagues discovered that at least for 200*3* R2 we needed
to install KB931125 to get matters to work. I'm not sure which certificates
that installs, however.
Keith Douglas
Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6
Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A 0T6
keith.doug...@statcan.gc.ca Telephone | Téléphone 613-951-4405 Facsimile |
Télécopieur 613-951-1966 Government of Canada | Gouvernement du Canada
-Original Message-
From: Ring, Matthew [mailto:ring.matt...@principal.com]
Sent: October-15-13 9:19 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Installing Wix 3.7 - Root Certs Needed
I wanted to follow up on a related thread:
http://sourceforge.net/mailarchive/message.php?msg_id=31445162
I have a TFS build server running Windows Server 2008 R2 and am trying to
install WiX 3.7 on it. It is also pretty locked down from the internet for
security reasons. I am getting the same errors as described in the related
thread and it looks like it is a certificate issue. My question is, does anyone
know what certificate (or certificates) WiX is looking for to be installed? I
don't want to just blanket-install a bunch of certs on the server to get it
working because there are security implications with doing that.
Any help would be appreciated.
Thanks,
Matt Ring
IT Application Analyst - Senior | IS Development Support | Principal Financial
Group
-Message Disclaimer-
This e-mail message is intended only for the use of the individual or entity to
which it is addressed, and may contain information that is privileged,
confidential and exempt from disclosure under applicable law.
If you are not the intended recipient, any dissemination, distribution or
copying of this communication is strictly prohibited. If you have received this
communication in error, please notify us immediately by reply email to
conn...@principal.com and delete or destroy all copies of the original message
and attachments thereto. Email sent to or from the Principal Financial Group or
any of its member companies may be retained as required by law or regulation.
Nothing in this message is intended to constitute an Electronic signature for
purposes of the Uniform Electronic Transactions Act (UETA) or the Electronic
Signatures in Global and National Commerce Act ("E-Sign") unless a specific
statement to the contrary is included in this message.
While this communication may be used to promote or market a transaction or an
idea that is discussed in the publication, it is intended to provide general
information about the subject matter covered and is provided with the
understanding that The Principal is not rendering legal, accounting, or tax
advice. It is not a marketed opinion and may not be used to avoid penalties
under the Internal Revenue Code. You should consult with appropriate counsel or
other advisors on all matters pertaining to legal, tax, or accounting
obligations and requirements
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
___
Re: [WiX-users] Using WPF for standard MSI dialogs
Even better http://blogs.msdn.com/b/windows_installer_team/archive/2008/04/01/windows-installer-4-5-ui-enhancements-embedded-ui.aspx -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Using-WPF-for-standard-MSI-dialogs-tp7589733p7589743.html Sent from the wix-users mailing list archive at Nabble.com. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Using WPF for standard MSI dialogs
Hi Brian :) MsiSetExternalUI Tomer -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Using-WPF-for-standard-MSI-dialogs-tp7589733p7589742.html Sent from the wix-users mailing list archive at Nabble.com. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] What is the downside to this?
2013/10/15 Walter Dexter : > some of my actions are things like "create user escschd as an administrator, http://wixtoolset.org/documentation/manual/v3/xsd/util/user.html > then create six scheduled tasks to be run by escschd" You'll probably need a custom action for that, but "done properly" (table-driven, handling rollback correctly, etc) it could be contributed to WiX. > "create these three network shares." http://wixtoolset.org/documentation/manual/v3/xsd/util/fileshare.html -- Nicolás -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] What is the downside to this?
Oh, thanks. More reading. :) In a quick skim of them, I realize that most of my custom actions would be what he calls "System modification custom actions." I'm not doing software that we release to the public; I'm doing packages that will ultimately get installed onto 14,000 identical systems, and some of my actions are things like "create user escschd as an administrator, then create six scheduled tasks to be run by escschd" or "create these three network shares." The more I gaze into the MSI pond, the deeper I realize the water to be. On Tue, Oct 15, 2013 at 8:59 AM, Pally Sandher wrote: > Rob M. wrote some articles on the subject a few years ago: > > > http://robmensching.com/blog/posts/2007/8/3/zen-and-the-art-of-custom-actions > > http://robmensching.com/blog/posts/2007/8/10/zataoca-classes-of-custom-actions > > http://robmensching.com/blog/posts/2007/8/17/zataoca-custom-actions-are-generally-an-admission-of-failure > > http://robmensching.com/blog/posts/2007/9/13/zataoca-custom-actions-should-be-data-driven > > Palbinder Sandher > Software Platform 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: Walt Dexter [mailto:wfdex...@gmail.com] > Sent: 15 October 2013 14:20 > To: chr...@iswix.com; General discussion for Windows Installer XMLtoolset. > Cc: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] What is the downside to this? > > I think I need to better understand how custom actions really work before > I'll understand why it's a bad idea. Based on what i know now, I don't > understand how you get all five things if its a truly custom custom action. > > Guess I'll work on doing that. > > On Oct 15, 2013, at 6:35 AM, "Christopher Painter" > wrote: > > > Walter, > > > > In reply to your "yes, but.." comment earlier. No, sorry, no buts. > > I've worked at a number of places over the years both on the ISV side and > > the Enterprise side. I'm currently the deployment architect for a > certain > > well known big box retailer that loves the color orange. We probably > have > > more then a few stores where you live and see our commercials all day > long > > while watching football. :-) On the store side we have somewhere > around > > 130,000 desktops and in the total enterprise around 300,000 instances of > > windows. We have countless applications and for each of those we > require > > 1) Install, 2) Uninstall, 3) Upgrade, 4) Downgrade 5) Rollback ( for all > 4 > > actually ) to be fully supported and tested before handing off to > > operations for deployment. There is very little tolerance for failure > from > > the business because a screw up results in lost sales. We don't achieve > > this level of excellence using Wise, InstallScript, NSIS, InnoSetup or > > others. We achieve it using properly designed MSIs and occasionally AppV > > packages. A lot of our working is spent "fixing" what other vendors send > > us as what they think are passable installer experiences. > > > > Yes, sorry, it is a lot of work to learn MSI. I was writing > InstallScript > > installers for 7 years and was not initially impressed with MSI. In > fact, > > you could say I was a late adopter since I didn't pick it up until 2003. > > It took me 6 months of banging my head against the wall trying to get it > to > > do what I wanted before I felt comfortable. It was another 6 months > before > > I had that "been there done that" feeling. > > > > Regards, > > Chris > > > > > > From: "Walter Dexter" > > Sent: Tuesday, October 15, 2013 12:51 AM > > To: "General discussion for Windows Installer XML toolset." > > > > Subject: Re: [WiX-users] What is the downside to this? > > > > Rob- > > > > Thanks for the lengthy reply. I feel like I need to read it about a dozen > > times more to have a chance of getting everything in there. Not tonight, > > though. > > > > On Tue, Oct 15, 2013 at 12:25 AM, Rob Mensching > > wrote: > > > >> If all you're going to do is exec a bunch of batch files and vbscripts > > then > >> the InnoSetup executable is probably a *far* better idea. Those > > scripting > >> platforms are not the way to go to create a robust installation. > >> > >> However, if you were to integrate fully with the Windows Installer > > (which > >> is admittedly more work and requires a lot more understanding) then > > you'd > >> get functionality like rollback, error reporting, patching, resource > >> sharing, publishing/assigning. You'd also end up with a far less complex > >> installer... once you got the declarative parts all in place. > >> > >> It is too bad that the WiX toolset doesn't come with Ini file > > manipulation > >> extens
Re: [WiX-users] Using WPF for standard MSI dialogs
Assuming you have .NET 3.0+ (Vista+) and Windows Installer 4.5 (Vista SP1+) it's possible to use WiX DTF to create a managed embedded UI handler to do just this. There is a sample of such a beast in the WiX source tree at $/src/DTF/Samples/EmbeddedUI. If you have target machines that don't have this then you need a bootstrapper to install .NET and MSI updates and you might as well just go back to burn at that point. I always thought this would be a really cool project but then people started moving towards managed bootstrapper applications via Burn and Suite installers instead. My installers at my day job are all installed silently so I just carry on with Native MSI UI for the time being. Chris From: "Brian C" Sent: Tuesday, October 15, 2013 9:47 AM To: "wix-users@lists.sourceforge.net" Subject: [WiX-users] Using WPF for standard MSI dialogs All, Is there any way to use WPF/C# to make the GUI for standard msi dialogs? I know I can do a Bootstrapper to do this, but, I was hoping to avoid that overhead and just deliver an .msi with GUI designed with WPF. Thanks in advance, Brian -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Using WPF for standard MSI dialogs
All, Is there any way to use WPF/C# to make the GUI for standard msi dialogs? I know I can do a Bootstrapper to do this, but, I was hoping to avoid that overhead and just deliver an .msi with GUI designed with WPF. Thanks in advance, Brian -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] [SPAM] Invalid package type
I was able to resolve this by changing WixBA.Plan(LaunchAction.UpdateReplace) to WixBA.Plan(LaunchAction.Install) per http://stackoverflow.com/questions/17676657/wix-burn-bootstrapper-majorupgrade On 2013-10-15 08:32, dirt wrote: > Well, it's back. My first upgrade test didn't have any Errors, now my > subsequent tests have the 'Invalid package type' error below. > > What causes this? > > Thanks, > -dirt > > On 2013-10-15 08:17, dirt wrote: >> I was able to resolve this by re-installing the new weekly build >> released last night (v3.8.1014.0). >> >> On 2013-10-14 18:11, dirt wrote: >>> I apparently made too many changes at once and now when I try to >>> install an updated version of the bootstrapper I get 'Invalid >>> package >>> type': >>> >>> = >>> [0FB4:0C24][2013-10-14T18:05:31]i199: Detect complete, result: 0x0 >>> [0FB4:0C24][2013-10-14T18:05:31]i200: Plan begin, 7 packages, >>> action: >>> UpdateReplace >>> [0FB4:0C24][2013-10-14T18:05:31]i000: [DEBUG-Progress] PlanBegin: >>> [0FB4:0C24][2013-10-14T18:05:31]e000: Error 0x8000: Invalid >>> package >>> type. >>> [0FB4:0C24][2013-10-14T18:05:31]e000: Error 0x8000: Failed to >>> plan >>> execute package. >>> [0FB4:0C24][2013-10-14T18:05:31]i000: [DEBUG-Progress] >>> PlanPackageComplete: >>> [0FB4:0C24][2013-10-14T18:05:31]e000: Error 0x8000: Failed to >>> process update package. >>> [0FB4:0C24][2013-10-14T18:05:31]e000: Error 0x8000: Failed to >>> plan >>> update. >>> [0FB4:0C24][2013-10-14T18:05:31]i000: [DEBUG-Install] PlanComplete: >>> [0FB4:0C24][2013-10-14T18:05:31]i000: [DEBUG-Model] ApplyAction: 0 >>> [0FB4:0C24][2013-10-14T18:05:31]i299: Plan complete, result: >>> 0x8000 >>> [0FB4:0C24][2013-10-14T18:05:31]i300: Apply begin >>> [0FB4:0C24][2013-10-14T18:05:31]i000: [DEBUG-Install] ApplyBegin: >>> [0FB4:0C24][2013-10-14T18:05:31]w380: Apply skipped, no planned >>> actions >>> [0FB4:0C24][2013-10-14T18:05:31]i000: [DEBUG-Install] ApplyComplete: >>> Result: 0 >>> [0FB4:0C24][2013-10-14T18:05:31]i000: [DEBUG-Install] ApplyComplete: >>> Display: Full >>> [0FB4:0C24][2013-10-14T18:05:31]i000: [DEBUG-Install] ApplyComplete: >>> PlannedAction: UpdateReplace >>> = >>> >>> Variables.wxs: >>> >>> >>> >>> >> "029B62E4-4AFE-4D74-837D-D0E79622BD97" >>> ?> >>> >>> Product.wxs: >>> >>>>> UpgradeCode="$(var.GUID_PRODUCTUPGRADE)" >>> Name="$(var.ProductName)" >>> Version="$(var.ProductVersion)" >>> Manufacturer="$(var.Manufacturer)" >>> Language="1033"> >>> >>> >> InstallScope="perMachine" InstallPrivileges="elevated" /> >>> >>> >>> >>> >>Schedule="afterInstallFinalize"/> >>> >>> >>>>>IncludeMinimum="no" >>>OnlyDetect="yes" >>>Language="1033" >>>Property="NEWERVERSIONDETECTED" /> >>>>>IncludeMinimum="yes" >>>Maximum="$(var.ProductVersion)" >>>OnlyDetect="no" >>>IncludeMaximum="no" >>>Language="1033" >>>Property="OLDERVERSIONBEINGUPGRADED" /> >>> >>> >>>>>Maximum="$(var.ProductVersion)" >>> Minimum="$(var.ProductVersion)" >>>IncludeMinimum="yes" IncludeMaximum="yes" >>> OnlyDetect="yes" /> >>> >>> >>> = >>> >>> Thanks, >>> -dirt >>> >>> >>> >>> >>> -- >>> View this message in context: >>> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Invalid-package-type-tp7589708.html >>> Sent from the wix-users mailing list archive at Nabble.com. >>> -- >>> October Webinars: Code for Performance >>> Free Intel webinars can help you accelerate application performance. >>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the >>> most from >>> the latest Intel processors and coprocessors. See abstracts and >>> register > >>> http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk >>> ___ >>> WiX-users mailing list >>> WiX-users@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/wix-users >> >> -- >> October Webinars: Code for Performance >> Free Intel webinars can help you accelerate application performance. >> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the >> most from >> the latest Intel processors and coprocessors. See abstracts and >> register > >> http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk >> ___ >> WiX-users mailing list >> WiX-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/wix-users > > -
Re: [WiX-users] What is the downside to this?
Rob M. wrote some articles on the subject a few years ago: http://robmensching.com/blog/posts/2007/8/3/zen-and-the-art-of-custom-actions http://robmensching.com/blog/posts/2007/8/10/zataoca-classes-of-custom-actions http://robmensching.com/blog/posts/2007/8/17/zataoca-custom-actions-are-generally-an-admission-of-failure http://robmensching.com/blog/posts/2007/9/13/zataoca-custom-actions-should-be-data-driven Palbinder Sandher Software Platform 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: Walt Dexter [mailto:wfdex...@gmail.com] Sent: 15 October 2013 14:20 To: chr...@iswix.com; General discussion for Windows Installer XMLtoolset. Cc: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] What is the downside to this? I think I need to better understand how custom actions really work before I'll understand why it's a bad idea. Based on what i know now, I don't understand how you get all five things if its a truly custom custom action. Guess I'll work on doing that. On Oct 15, 2013, at 6:35 AM, "Christopher Painter" wrote: > Walter, > > In reply to your "yes, but.." comment earlier. No, sorry, no buts. > I've worked at a number of places over the years both on the ISV side and > the Enterprise side. I'm currently the deployment architect for a certain > well known big box retailer that loves the color orange. We probably have > more then a few stores where you live and see our commercials all day long > while watching football. :-) On the store side we have somewhere around > 130,000 desktops and in the total enterprise around 300,000 instances of > windows. We have countless applications and for each of those we require > 1) Install, 2) Uninstall, 3) Upgrade, 4) Downgrade 5) Rollback ( for all 4 > actually ) to be fully supported and tested before handing off to > operations for deployment. There is very little tolerance for failure from > the business because a screw up results in lost sales. We don't achieve > this level of excellence using Wise, InstallScript, NSIS, InnoSetup or > others. We achieve it using properly designed MSIs and occasionally AppV > packages. A lot of our working is spent "fixing" what other vendors send > us as what they think are passable installer experiences. > > Yes, sorry, it is a lot of work to learn MSI. I was writing InstallScript > installers for 7 years and was not initially impressed with MSI. In fact, > you could say I was a late adopter since I didn't pick it up until 2003. > It took me 6 months of banging my head against the wall trying to get it to > do what I wanted before I felt comfortable. It was another 6 months before > I had that "been there done that" feeling. > > Regards, > Chris > > > From: "Walter Dexter" > Sent: Tuesday, October 15, 2013 12:51 AM > To: "General discussion for Windows Installer XML toolset." > > Subject: Re: [WiX-users] What is the downside to this? > > Rob- > > Thanks for the lengthy reply. I feel like I need to read it about a dozen > times more to have a chance of getting everything in there. Not tonight, > though. > > On Tue, Oct 15, 2013 at 12:25 AM, Rob Mensching > wrote: > >> If all you're going to do is exec a bunch of batch files and vbscripts > then >> the InnoSetup executable is probably a *far* better idea. Those > scripting >> platforms are not the way to go to create a robust installation. >> >> However, if you were to integrate fully with the Windows Installer > (which >> is admittedly more work and requires a lot more understanding) then > you'd >> get functionality like rollback, error reporting, patching, resource >> sharing, publishing/assigning. You'd also end up with a far less complex >> installer... once you got the declarative parts all in place. >> >> It is too bad that the WiX toolset doesn't come with Ini file > manipulation >> extension already. I think many people must create private one off >> solutions and never consider contributing back to the WiX toolset so no > one >> ever has to implement that again. >> >> Back in 2001 I wrote custom actions for configuring IIS, SQL, users, > file >> shares. I contributed them to the WiX toolset and for over a decade > others >> have benefited with all the functionality I described above (rollback, >> patching, resource sharing, etc) by just adding a few lines of XML. > We've >> had some contributions since (Bob did gaming extension and internet >> shortcut, and Fredrik gave us COM+ and MSMQ) but there are many more >> opportunities for people to contribute and make each other's future > lives >> much better. >> >> So, anyway, the answer is
Re: [WiX-users] What is the downside to this?
Here's a good place to start: http://www.installsite.org/pages/en/isnews/200108/ I'll admit the first time I read this I filed it away in the "I don't really understand this but I can tell it's important" folder. In the optimal case, a custom action: (quick list not fully complete) 1) Doesn't reinvent the wheel. Don't use CA's to write to an INI or start a service or register a COM object when MSI can already do this for you better then you can do it yourself. 2) Remains true to the declarative nature of MSI. Don't write a function DoSomething() and then call DoSomething(A); DoSomething(B); DoSomething(C). Put A, B and C in a custom table and use a custom action to query the table to generate a list of actions to be performed by DoSomething(). 3) Usually Opaque. There are times you really need DoSomething() to be private but usually it's best if an end administrator can work out what DoSomething() does in case there is a problem with it. I recently had to do this with the MSIs authored by AppV 5.0. Fortunately they used a WiX DTF custom action written in C# and I was able to have my way with it to make the outcome better. 4) Remains true to the transactional nature of MSI. Rollback, Install, Commit as shown in the link above. The user can hit cancel at any time and confidently get back to their initial state. This is sometimes really difficult when working with APIs that don't support transactional changes such as publishing a file to the GAC or changing a users password. Always do your best to provide the ultimate user experience. 5) Remains true to security / elevation model of MSI. Strive for UAC compliant MSI packages that can be advertised by an administrator and installed by standard user. 6) Minimize dependencies / fragility. Be careful on the dependencies you take on. They may force you to preinstall something or they may be fragile and cause your installer to fail. .NET, ActiveScript (VBScript/JScript), FileSystemObject, WMI et al. There may be valid scenarios where say .NET is acceptable to one person (like myself) but unacceptable to another person (say someone distributing a C++ app targeting XP as a minimum. ). Custom actions need to be bullet proof and feel like a natural extension of MSI itself. Not some kludge hack tacked on to make something work. Regards, Chris From: "Walt Dexter" Sent: Tuesday, October 15, 2013 8:16 AM To: "chr...@iswix.com" , "General discussion for Windows Installer XMLtoolset." Subject: Re: [WiX-users] What is the downside to this? I think I need to better understand how custom actions really work before I'll understand why it's a bad idea. Based on what i know now, I don't understand how you get all five things if its a truly custom custom action. Guess I'll work on doing that. On Oct 15, 2013, at 6:35 AM, "Christopher Painter" wrote: > Walter, > > In reply to your "yes, but.." comment earlier. No, sorry, no buts. > I've worked at a number of places over the years both on the ISV side and > the Enterprise side. I'm currently the deployment architect for a certain > well known big box retailer that loves the color orange. We probably have > more then a few stores where you live and see our commercials all day long > while watching football. :-) On the store side we have somewhere around > 130,000 desktops and in the total enterprise around 300,000 instances of > windows. We have countless applications and for each of those we require > 1) Install, 2) Uninstall, 3) Upgrade, 4) Downgrade 5) Rollback ( for all 4 > actually ) to be fully supported and tested before handing off to > operations for deployment. There is very little tolerance for failure from > the business because a screw up results in lost sales. We don't achieve > this level of excellence using Wise, InstallScript, NSIS, InnoSetup or > others. We achieve it using properly designed MSIs and occasionally AppV > packages. A lot of our working is spent "fixing" what other vendors send > us as what they think are passable installer experiences. > > Yes, sorry, it is a lot of work to learn MSI. I was writing InstallScript > installers for 7 years and was not initially impressed with MSI. In fact, > you could say I was a late adopter since I didn't pick it up until 2003. > It took me 6 months of banging my head against the wall trying to get it to > do what I wanted before I felt comfortable. It was another 6 months before > I had that "been there done that" feeling. > > Regards, > Chris > > > From: "Walter Dexter" > Sent: Tuesday, October 15, 2013 12:51 AM > To: "General discussion for Windows Installer XML toolset." > > Subject: Re: [WiX-users] What is the downside to this? > > Rob- > > Thanks for the lengthy reply. I feel like I need to read it about a dozen > times more to h
Re: [WiX-users] Installing Wix 3.7 - Root Certs Needed
My server support colleagues discovered that at least for 200*3* R2 we needed
to install KB931125 to get matters to work. I'm not sure which certificates
that installs, however.
Keith Douglas
Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6
Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A 0T6
keith.doug...@statcan.gc.ca
Telephone | Téléphone 613-951-4405
Facsimile | Télécopieur 613-951-1966
Government of Canada | Gouvernement du Canada
-Original Message-
From: Ring, Matthew [mailto:ring.matt...@principal.com]
Sent: October-15-13 9:19 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Installing Wix 3.7 - Root Certs Needed
I wanted to follow up on a related thread:
http://sourceforge.net/mailarchive/message.php?msg_id=31445162
I have a TFS build server running Windows Server 2008 R2 and am trying to
install WiX 3.7 on it. It is also pretty locked down from the internet for
security reasons. I am getting the same errors as described in the related
thread and it looks like it is a certificate issue. My question is, does anyone
know what certificate (or certificates) WiX is looking for to be installed? I
don't want to just blanket-install a bunch of certs on the server to get it
working because there are security implications with doing that.
Any help would be appreciated.
Thanks,
Matt Ring
IT Application Analyst - Senior | IS Development Support | Principal Financial
Group
-Message Disclaimer-
This e-mail message is intended only for the use of the individual or entity to
which it is addressed, and may contain information that is privileged,
confidential and exempt from disclosure under applicable law.
If you are not the intended recipient, any dissemination, distribution or
copying of this communication is strictly prohibited. If you have received this
communication in error, please notify us immediately by reply email to
conn...@principal.com and delete or destroy all copies of the original message
and attachments thereto. Email sent to or from the Principal Financial Group or
any of its member companies may be retained as required by law or regulation.
Nothing in this message is intended to constitute an Electronic signature for
purposes of the Uniform Electronic Transactions Act (UETA) or the Electronic
Signatures in Global and National Commerce Act ("E-Sign") unless a specific
statement to the contrary is included in this message.
While this communication may be used to promote or market a transaction or an
idea that is discussed in the publication, it is intended to provide general
information about the subject matter covered and is provided with the
understanding that The Principal is not rendering legal, accounting, or tax
advice. It is not a marketed opinion and may not be used to avoid penalties
under the Internal Revenue Code. You should consult with appropriate counsel or
other advisors on all matters pertaining to legal, tax, or accounting
obligations and requirements
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Installing Wix 3.7 - Root Certs Needed
I wanted to follow up on a related thread:
http://sourceforge.net/mailarchive/message.php?msg_id=31445162
I have a TFS build server running Windows Server 2008 R2 and am trying to
install WiX 3.7 on it. It is also pretty locked down from the internet for
security reasons. I am getting the same errors as described in the related
thread and it looks like it is a certificate issue. My question is, does anyone
know what certificate (or certificates) WiX is looking for to be installed? I
don't want to just blanket-install a bunch of certs on the server to get it
working because there are security implications with doing that.
Any help would be appreciated.
Thanks,
Matt Ring
IT Application Analyst - Senior | IS Development Support | Principal Financial
Group
-Message Disclaimer-
This e-mail message is intended only for the use of the individual or
entity to which it is addressed, and may contain information that is
privileged, confidential and exempt from disclosure under applicable law.
If you are not the intended recipient, any dissemination, distribution or
copying of this communication is strictly prohibited. If you have
received this communication in error, please notify us immediately by
reply email to conn...@principal.com and delete or destroy all copies of
the original message and attachments thereto. Email sent to or from the
Principal Financial Group or any of its member companies may be retained
as required by law or regulation.
Nothing in this message is intended to constitute an Electronic signature
for purposes of the Uniform Electronic Transactions Act (UETA) or the
Electronic Signatures in Global and National Commerce Act ("E-Sign")
unless a specific statement to the contrary is included in this message.
While this communication may be used to promote or market a transaction
or an idea that is discussed in the publication, it is intended to provide
general information about the subject matter covered and is provided with
the understanding that The Principal is not rendering legal, accounting,
or tax advice. It is not a marketed opinion and may not be used to avoid
penalties under the Internal Revenue Code. You should consult with
appropriate counsel or other advisors on all matters pertaining to legal,
tax, or accounting obligations and requirements
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] What is the downside to this?
I think I need to better understand how custom actions really work before I'll understand why it's a bad idea. Based on what i know now, I don't understand how you get all five things if its a truly custom custom action. Guess I'll work on doing that. On Oct 15, 2013, at 6:35 AM, "Christopher Painter" wrote: > Walter, > > In reply to your "yes, but.." comment earlier. No, sorry, no buts. > I've worked at a number of places over the years both on the ISV side and > the Enterprise side. I'm currently the deployment architect for a certain > well known big box retailer that loves the color orange. We probably have > more then a few stores where you live and see our commercials all day long > while watching football. :-) On the store side we have somewhere around > 130,000 desktops and in the total enterprise around 300,000 instances of > windows. We have countless applications and for each of those we require > 1) Install, 2) Uninstall, 3) Upgrade, 4) Downgrade 5) Rollback ( for all 4 > actually ) to be fully supported and tested before handing off to > operations for deployment. There is very little tolerance for failure from > the business because a screw up results in lost sales. We don't achieve > this level of excellence using Wise, InstallScript, NSIS, InnoSetup or > others. We achieve it using properly designed MSIs and occasionally AppV > packages. A lot of our working is spent "fixing" what other vendors send > us as what they think are passable installer experiences. > > Yes, sorry, it is a lot of work to learn MSI. I was writing InstallScript > installers for 7 years and was not initially impressed with MSI. In fact, > you could say I was a late adopter since I didn't pick it up until 2003. > It took me 6 months of banging my head against the wall trying to get it to > do what I wanted before I felt comfortable. It was another 6 months before > I had that "been there done that" feeling. > > Regards, > Chris > > > From: "Walter Dexter" > Sent: Tuesday, October 15, 2013 12:51 AM > To: "General discussion for Windows Installer XML toolset." > > Subject: Re: [WiX-users] What is the downside to this? > > Rob- > > Thanks for the lengthy reply. I feel like I need to read it about a dozen > times more to have a chance of getting everything in there. Not tonight, > though. > > On Tue, Oct 15, 2013 at 12:25 AM, Rob Mensching > wrote: > >> If all you're going to do is exec a bunch of batch files and vbscripts > then >> the InnoSetup executable is probably a *far* better idea. Those > scripting >> platforms are not the way to go to create a robust installation. >> >> However, if you were to integrate fully with the Windows Installer > (which >> is admittedly more work and requires a lot more understanding) then > you'd >> get functionality like rollback, error reporting, patching, resource >> sharing, publishing/assigning. You'd also end up with a far less complex >> installer... once you got the declarative parts all in place. >> >> It is too bad that the WiX toolset doesn't come with Ini file > manipulation >> extension already. I think many people must create private one off >> solutions and never consider contributing back to the WiX toolset so no > one >> ever has to implement that again. >> >> Back in 2001 I wrote custom actions for configuring IIS, SQL, users, > file >> shares. I contributed them to the WiX toolset and for over a decade > others >> have benefited with all the functionality I described above (rollback, >> patching, resource sharing, etc) by just adding a few lines of XML. > We've >> had some contributions since (Bob did gaming extension and internet >> shortcut, and Fredrik gave us COM+ and MSMQ) but there are many more >> opportunities for people to contribute and make each other's future > lives >> much better. >> >> So, anyway, the answer is you'd end up with a far more robust installer > by >> doing as the others suggested. It will take more work up front because > no >> one has contributed the Ini custom actions already. If you wanted to do > the >> work and get Ini custom actions created, feel free to jump on the >> wix-d...@lists.sourceforge.net mailing list. That's where people the > below >> were pointing you. >> >> Or you could just hack it and deal with the issues you'll probably see. > In >> that case, I encourage you to test install, install rollback, uninstall, >> uninstall rollback, repair, repair rollback, and major upgrade. There > are >> probably more scenarios to think about but I don't tend to remember them >> all since I try to write the custom actions as the Windows Installer SDK >> recommends and then it all just works together. >> >> By the way, these recommendations aren't unique to the Windows > Installer. >> They're applicable to any installation technology you use. It's just > people >> using the Windows Installer tend to expect all tho
Re: [WiX-users] Possible bug with WixUI_InstallDir?
http://wixtoolset.org/documentation/manual/v3/wixui/dialog_reference/wixui_installdir.html Palbinder Sandher Software Platform 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: Yonatan [mailto:nir_j...@hotmail.com] Sent: 15 October 2013 08:28 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Possible bug with WixUI_InstallDir? I'm creating a program which is being installed by Wix, using VS 2010 and I've already got the product.wxs ready. In my wxs file, I've got directory definitions which looks like this: And then I got these file installation definitions: ... And it continues in that manner and the files for the "ICONS" directory are defined as well. I am also using the WixUI_InstallDir dialog set and I got these lines present as well: The problem I'm facing is that when the user installs the program and changes the value of the installation folder, the files of the "Bin" and "Icons" are installed to their correct location as the user wanted, but the Myapp target is installed to a constant location no matter what which is to this directory that was defined earlier: Why does only the bin and icons files are installed to the correct folder the user wanted, but the myapp target does not? How can I fix this? -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Possible-bug-with-WixUI-InstallDir-tp7589722.html Sent from the wix-users mailing list archive at Nabble.com. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] [SPAM] Invalid package type
Well, it's back. My first upgrade test didn't have any Errors, now my subsequent tests have the 'Invalid package type' error below. What causes this? Thanks, -dirt On 2013-10-15 08:17, dirt wrote: > I was able to resolve this by re-installing the new weekly build > released last night (v3.8.1014.0). > > On 2013-10-14 18:11, dirt wrote: >> I apparently made too many changes at once and now when I try to >> install an updated version of the bootstrapper I get 'Invalid package >> type': >> >> = >> [0FB4:0C24][2013-10-14T18:05:31]i199: Detect complete, result: 0x0 >> [0FB4:0C24][2013-10-14T18:05:31]i200: Plan begin, 7 packages, action: >> UpdateReplace >> [0FB4:0C24][2013-10-14T18:05:31]i000: [DEBUG-Progress] PlanBegin: >> [0FB4:0C24][2013-10-14T18:05:31]e000: Error 0x8000: Invalid >> package >> type. >> [0FB4:0C24][2013-10-14T18:05:31]e000: Error 0x8000: Failed to >> plan >> execute package. >> [0FB4:0C24][2013-10-14T18:05:31]i000: [DEBUG-Progress] >> PlanPackageComplete: >> [0FB4:0C24][2013-10-14T18:05:31]e000: Error 0x8000: Failed to >> process update package. >> [0FB4:0C24][2013-10-14T18:05:31]e000: Error 0x8000: Failed to >> plan >> update. >> [0FB4:0C24][2013-10-14T18:05:31]i000: [DEBUG-Install] PlanComplete: >> [0FB4:0C24][2013-10-14T18:05:31]i000: [DEBUG-Model] ApplyAction: 0 >> [0FB4:0C24][2013-10-14T18:05:31]i299: Plan complete, result: >> 0x8000 >> [0FB4:0C24][2013-10-14T18:05:31]i300: Apply begin >> [0FB4:0C24][2013-10-14T18:05:31]i000: [DEBUG-Install] ApplyBegin: >> [0FB4:0C24][2013-10-14T18:05:31]w380: Apply skipped, no planned >> actions >> [0FB4:0C24][2013-10-14T18:05:31]i000: [DEBUG-Install] ApplyComplete: >> Result: 0 >> [0FB4:0C24][2013-10-14T18:05:31]i000: [DEBUG-Install] ApplyComplete: >> Display: Full >> [0FB4:0C24][2013-10-14T18:05:31]i000: [DEBUG-Install] ApplyComplete: >> PlannedAction: UpdateReplace >> = >> >> Variables.wxs: >> >> >> >> > ?> >> >> Product.wxs: >> >>> UpgradeCode="$(var.GUID_PRODUCTUPGRADE)" >> Name="$(var.ProductName)" >> Version="$(var.ProductVersion)" >> Manufacturer="$(var.Manufacturer)" >> Language="1033"> >> >> > InstallScope="perMachine" InstallPrivileges="elevated" /> >> >> >> >> >Schedule="afterInstallFinalize"/> >> >> >>>IncludeMinimum="no" >>OnlyDetect="yes" >>Language="1033" >>Property="NEWERVERSIONDETECTED" /> >>>IncludeMinimum="yes" >>Maximum="$(var.ProductVersion)" >>OnlyDetect="no" >>IncludeMaximum="no" >>Language="1033" >>Property="OLDERVERSIONBEINGUPGRADED" /> >> >> >>>Maximum="$(var.ProductVersion)" >> Minimum="$(var.ProductVersion)" >>IncludeMinimum="yes" IncludeMaximum="yes" >> OnlyDetect="yes" /> >> >> >> = >> >> Thanks, >> -dirt >> >> >> >> >> -- >> View this message in context: >> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Invalid-package-type-tp7589708.html >> Sent from the wix-users mailing list archive at Nabble.com. >> -- >> October Webinars: Code for Performance >> Free Intel webinars can help you accelerate application performance. >> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the >> most from >> the latest Intel processors and coprocessors. See abstracts and >> register > >> http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk >> ___ >> WiX-users mailing list >> WiX-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/wix-users > > -- > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the > most from > the latest Intel processors and coprocessors. See abstracts and > register > > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
Re: [WiX-users] [SPAM] Invalid package type
I was able to resolve this by re-installing the new weekly build released last night (v3.8.1014.0). On 2013-10-14 18:11, dirt wrote: > I apparently made too many changes at once and now when I try to > install an updated version of the bootstrapper I get 'Invalid package > type': > > = > [0FB4:0C24][2013-10-14T18:05:31]i199: Detect complete, result: 0x0 > [0FB4:0C24][2013-10-14T18:05:31]i200: Plan begin, 7 packages, action: > UpdateReplace > [0FB4:0C24][2013-10-14T18:05:31]i000: [DEBUG-Progress] PlanBegin: > [0FB4:0C24][2013-10-14T18:05:31]e000: Error 0x8000: Invalid > package > type. > [0FB4:0C24][2013-10-14T18:05:31]e000: Error 0x8000: Failed to plan > execute package. > [0FB4:0C24][2013-10-14T18:05:31]i000: [DEBUG-Progress] > PlanPackageComplete: > [0FB4:0C24][2013-10-14T18:05:31]e000: Error 0x8000: Failed to > process update package. > [0FB4:0C24][2013-10-14T18:05:31]e000: Error 0x8000: Failed to plan > update. > [0FB4:0C24][2013-10-14T18:05:31]i000: [DEBUG-Install] PlanComplete: > [0FB4:0C24][2013-10-14T18:05:31]i000: [DEBUG-Model] ApplyAction: 0 > [0FB4:0C24][2013-10-14T18:05:31]i299: Plan complete, result: > 0x8000 > [0FB4:0C24][2013-10-14T18:05:31]i300: Apply begin > [0FB4:0C24][2013-10-14T18:05:31]i000: [DEBUG-Install] ApplyBegin: > [0FB4:0C24][2013-10-14T18:05:31]w380: Apply skipped, no planned > actions > [0FB4:0C24][2013-10-14T18:05:31]i000: [DEBUG-Install] ApplyComplete: > Result: 0 > [0FB4:0C24][2013-10-14T18:05:31]i000: [DEBUG-Install] ApplyComplete: > Display: Full > [0FB4:0C24][2013-10-14T18:05:31]i000: [DEBUG-Install] ApplyComplete: > PlannedAction: UpdateReplace > = > > Variables.wxs: > > > > ?> > > Product.wxs: > > UpgradeCode="$(var.GUID_PRODUCTUPGRADE)" > Name="$(var.ProductName)" > Version="$(var.ProductVersion)" > Manufacturer="$(var.Manufacturer)" > Language="1033"> > >InstallScope="perMachine" InstallPrivileges="elevated" /> > > > > Schedule="afterInstallFinalize"/> > > >IncludeMinimum="no" >OnlyDetect="yes" >Language="1033" >Property="NEWERVERSIONDETECTED" /> >IncludeMinimum="yes" >Maximum="$(var.ProductVersion)" >OnlyDetect="no" >IncludeMaximum="no" >Language="1033" >Property="OLDERVERSIONBEINGUPGRADED" /> > > >Maximum="$(var.ProductVersion)" > Minimum="$(var.ProductVersion)" >IncludeMinimum="yes" IncludeMaximum="yes" > OnlyDetect="yes" /> > > > = > > Thanks, > -dirt > > > > > -- > View this message in context: > http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Invalid-package-type-tp7589708.html > Sent from the wix-users mailing list archive at Nabble.com. > -- > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the > most from > the latest Intel processors and coprocessors. See abstracts and > register > > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] What is the downside to this?
Walter, In reply to your "yes, but.." comment earlier. No, sorry, no buts. I've worked at a number of places over the years both on the ISV side and the Enterprise side. I'm currently the deployment architect for a certain well known big box retailer that loves the color orange. We probably have more then a few stores where you live and see our commercials all day long while watching football. :-) On the store side we have somewhere around 130,000 desktops and in the total enterprise around 300,000 instances of windows. We have countless applications and for each of those we require 1) Install, 2) Uninstall, 3) Upgrade, 4) Downgrade 5) Rollback ( for all 4 actually ) to be fully supported and tested before handing off to operations for deployment. There is very little tolerance for failure from the business because a screw up results in lost sales. We don't achieve this level of excellence using Wise, InstallScript, NSIS, InnoSetup or others. We achieve it using properly designed MSIs and occasionally AppV packages. A lot of our working is spent "fixing" what other vendors send us as what they think are passable installer experiences. Yes, sorry, it is a lot of work to learn MSI. I was writing InstallScript installers for 7 years and was not initially impressed with MSI. In fact, you could say I was a late adopter since I didn't pick it up until 2003. It took me 6 months of banging my head against the wall trying to get it to do what I wanted before I felt comfortable. It was another 6 months before I had that "been there done that" feeling. Regards, Chris From: "Walter Dexter" Sent: Tuesday, October 15, 2013 12:51 AM To: "General discussion for Windows Installer XML toolset." Subject: Re: [WiX-users] What is the downside to this? Rob- Thanks for the lengthy reply. I feel like I need to read it about a dozen times more to have a chance of getting everything in there. Not tonight, though. On Tue, Oct 15, 2013 at 12:25 AM, Rob Mensching wrote: > If all you're going to do is exec a bunch of batch files and vbscripts then > the InnoSetup executable is probably a *far* better idea. Those scripting > platforms are not the way to go to create a robust installation. > > However, if you were to integrate fully with the Windows Installer (which > is admittedly more work and requires a lot more understanding) then you'd > get functionality like rollback, error reporting, patching, resource > sharing, publishing/assigning. You'd also end up with a far less complex > installer... once you got the declarative parts all in place. > > It is too bad that the WiX toolset doesn't come with Ini file manipulation > extension already. I think many people must create private one off > solutions and never consider contributing back to the WiX toolset so no one > ever has to implement that again. > > Back in 2001 I wrote custom actions for configuring IIS, SQL, users, file > shares. I contributed them to the WiX toolset and for over a decade others > have benefited with all the functionality I described above (rollback, > patching, resource sharing, etc) by just adding a few lines of XML. We've > had some contributions since (Bob did gaming extension and internet > shortcut, and Fredrik gave us COM+ and MSMQ) but there are many more > opportunities for people to contribute and make each other's future lives > much better. > > So, anyway, the answer is you'd end up with a far more robust installer by > doing as the others suggested. It will take more work up front because no > one has contributed the Ini custom actions already. If you wanted to do the > work and get Ini custom actions created, feel free to jump on the > wix-d...@lists.sourceforge.net mailing list. That's where people the below > were pointing you. > > Or you could just hack it and deal with the issues you'll probably see. In > that case, I encourage you to test install, install rollback, uninstall, > uninstall rollback, repair, repair rollback, and major upgrade. There are > probably more scenarios to think about but I don't tend to remember them > all since I try to write the custom actions as the Windows Installer SDK > recommends and then it all just works together. > > By the way, these recommendations aren't unique to the Windows Installer. > They're applicable to any installation technology you use. It's just people > using the Windows Installer tend to expect all those fundamental scenarios > to work so the bar is a bit higher. That's why corporations tend to > standardize on the Windows Installer. The Windows Installer makes their > life easier. That seems fair to me. Hopefully, there are (many, manymore > people installing your software than there are building it... which means > saving the customer problems by taking on the work in development is a good > trade (economically speaking). > > > On Mon, Oct 14, 2013 at 9:59 PM, Walter Dexter
[WiX-users] Error while creating wix pyro
HI, When i try to create an pyro it is giving error called _ Multiple entry sections found. Only one entry section may be present in a single targe_t How to solve this issue ?? I checked some of the articles but i didnt get answer. -- Thanks & Regards, Chaitanya. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Possible bug with WixUI_InstallDir?
I'm creating a program which is being installed by Wix, using VS 2010 and I've already got the product.wxs ready. In my wxs file, I've got directory definitions which looks like this: And then I got these file installation definitions: ... And it continues in that manner and the files for the "ICONS" directory are defined as well. I am also using the WixUI_InstallDir dialog set and I got these lines present as well: The problem I'm facing is that when the user installs the program and changes the value of the installation folder, the files of the "Bin" and "Icons" are installed to their correct location as the user wanted, but the Myapp target is installed to a constant location no matter what which is to this directory that was defined earlier: Why does only the bin and icons files are installed to the correct folder the user wanted, but the myapp target does not? How can I fix this? -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Possible-bug-with-WixUI-InstallDir-tp7589722.html Sent from the wix-users mailing list archive at Nabble.com. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
