On Mon, Feb 14, 2011 at 1:34 AM, Christopher Painter <chr...@deploymentengineering.com> wrote: > 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. )
These two points seem to contradict eachother. How can it be out-of-process, while at the same time loading up the .Net runtime in-process? > 3) They throw up a modal dialog when they fail, even when the installer is > supposed to be running silently. I have not observed this when using the ServiceInstaller class. Compiling the executable as a non-console app by accident might, but then you have other/bigger problems. > 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? Creating a service is a simple operation. And yes, my code is better. :) As I said, I need the ability to install my services from the console. The idea of having a duplicate method of registering my service in the installer is not tempting. Having access to this functionality from the console is vital, both for us developers as well as the network admins. And I also need to allow the admin to install some of my services at a later point without rerunning the installer. I have set up a few <feature>s that refer to empty <component>s that will trigger my custom action. (because had I used <ServiceInstall>, the user would get all or nothing) > 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 Do you have much experience administrating servers that serve thousands of users? And deploying software to such servers? (I helped run about 30-40 servers at one point, serving 5000 customers -- intimate knowledge of what software a server runs is important when you only have one or two fallbacks and a couple of thousand customers are running the risk of not receiving nasdaq or nyse trade information) Snapshots are not a good solution. Keep It Simple... -- 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
