Rune- There are two camps of thinking when it comes to installers. One is imperative scripting using pretty much any framework you want ( NullSoft Installer, InstallScript, PowerScript, Wise / SMS, InnoSetup et al ) and the other is a declarative approach that provides a consistent experience with such things as transactional installations and upgrades ( Windows Installer ( MSI ), WiX, InstallShield, InstallAware, Wise and so on ). The data driven approach also allows administrators to create "transforms" to allow the MSI to be customized to meet their needs.
This mailing list ( and myself included ) is clearly in the camp of declarative. I did script installs from 1997 - 2003 and in 2003 I switched over to MSI and saw the light. I can speak from vast experience in saying there are really good reasons to not do any of the things that you suggest. From an MSI perspective they are all anti patterns. MSI installers that do nothing except copy files and then call out of process custom action never end well. They don't scale and they are brittle as all heck. For Installer class custom actions, they are horrible because they 1) Run out of process with no ability to access the MSI handle to query tables, get/set properties and write to the log. This means they will never be data driven and are useless to debug when ( not if ) they fail. 2) Tattoo the MSIEXEC process with a specific version of the CLR causing subsequent custom actions to fail. ( Yes, I've witnesssed this. ) 3) They throw up a modal dialog when they fail, even when the installer is supposed to be running silently. 4) When paired with Visual Studio Deployment Projects they encourage developers to reinvent the wheel with fragile out of process custom actions. MSI already has the ability to create services and event logs / sources. Do you really think your code will be better? PS- If an old school admin is dumb enough to delete a service without first recording it's values or creating a snapshot and thinks it's too slow to press 'repair' to save his neck, well I think he should just be let go. Repair is meant to be the standardized approach to resolving these problems rather then guessing some EXE is a service and what the command line to install it should be. --- Christopher Painter, Author of Deployment Engineering Blog Have a hot tip, know a secret or read a really good thread that deserves attention? E-Mail Me ----- Original Message ---- From: Rune Moberg <jjfl...@gmail.com> To: General discussion for Windows Installer XML toolset. <wix-users@lists.sourceforge.net> Sent: Sun, February 13, 2011 2:52:12 PM Subject: Re: [WiX-users] WCF server cannot connect to the remote database. On Sun, Feb 13, 2011 at 5:48 PM, Rob Mensching <r...@robmensching.com> wrote: > The Installer class is an anti-pattern in setup. You shouldn't use it for > anything. Could you expand on this? Speaking purely as an end-user, I will make the following observations: 1) Windows services should be able to be installed using -i as a command line switch (more and more developers seem to ignore this, but it doesn't make it right) 2) Putting code to register a service in multiple locations is a maintenance nightmare 3) The Installer class allows a fairly OK way to implement a -i switch, while at the same time being easily accessible from a custom action in the installer (search for a class with the RunInstaller(true) attribute would be an elegant solution) 4) Do not forget to set up the event log... (also neatly provided by the ServiceInstaller class) If an old-school network admin accidentally removes the service using 'sc delete', he'd welcome a way to quickly put it back without running an installer. (5 second fix vs however long it takes to run your installer -- which can be quite time consuming these days) If an old school admin is dumb enough to type sc delete without creating a snapshot -- Rune ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ____________________________________________________________________________________ Finding fabulous fares is fun. Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains. http://farechase.yahoo.com/promo-generic-14795097 ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
