1

Our application is deployed to the target machine with an msi file. All works nicely. Our tester has gone through his plan, and one of the tests requires deleting the application's configuration file. The application is designed to alert the user with a dialog on startup saying "missing config". However, what happens is that - somehow! - the software starts the installer again and retrieves the missing file from the msi! Which is nice, but not what we want. How do we disable that behaviour?

Stein Åsmul
  • 39,960
  • 25
  • 91
  • 164
Julian Gold
  • 1,246
  • 2
  • 19
  • 40
  • What tool are you using to author your .MSI? – Christopher Painter Mar 06 '14 at 19:19
  • Visual Studio Setup Project (hangs head in shame) in VS2010. The Installshield LE thing was horrible, so we stuck to 2010. It's a small project really as it's for an embedded (Standard 7) device. – Julian Gold Mar 07 '14 at 11:10
  • 1
    Email me if you'd like a free demo using WiX and IsWiX. I think you'll find it a great gateway to the full power of MSI. There are a lot of good answers below. The problem is your tool won't expose any of them to you. Shortcuts are always advertised in VDPROJ. We had to write build automation to tweak the MSI post build to fix this and many other things. – Christopher Painter Mar 07 '14 at 11:28
  • [**How can I determine what causes repeated Windows Installer self-repair?**](http://stackoverflow.com/questions/5501028/how-can-i-determine-what-causes-repeated-windows-installer-self-repair/6066263#6066263) – Stein Åsmul Sep 07 '14 at 03:21

4 Answers4

3

without going into much depth of the windows installer mechanics (if you interested in that there a plenty of articles about this), the shortcut of the software is probably advertised, which means the windows installer checks if everything is in its place before the software is started.

if you can edit the msi, make the shortcut non advertised. if you can't, install it with DISABLEADVTSHORTCUTS

e.g. msiexec /i myMsi.msi DISABLEADVTSHORTCUTS=1

please note that this is only a quick (and dirty) workaround, to fix this proper you need to understand the whole windows installer advertising (also called repair or self resiliency) mechanism. but explaining all the causes and the mechanism of the repair is far beyond this answer and there are quite some articles and posts about that on the internet (and especially on MSDN and stackoverflow)

weberik
  • 2,636
  • 1
  • 18
  • 11
  • There is more then one path to repair. – Christopher Painter Mar 06 '14 at 18:05
  • yes i know, but i assume the repair starts when the application starts – weberik Mar 06 '14 at 18:07
  • 1
    Yes, and he'll think his problem is fixed until something else triggers it down the road. Course someone will come along and say disable the windows installer service or run msizap.... that would fix it. :) – Christopher Painter Mar 06 '14 at 18:42
  • you are right, i edited my post. whats even better than msizap is replacing all component guids with empty strings, that actually works.... after working with this black magic and misunderstood technology called windows installer for a while we have all seen quite some tricks ;) – weberik Mar 06 '14 at 18:49
  • I've got a $100 that his tool doesn't allow him to do that. I've been doing MSI for 15 years and I've used all the tools. I can frequently tell you exactly what tool you are using just by the problems you encounter. – Christopher Painter Mar 06 '14 at 18:50
  • now i'm keen to hear what tool they are using, btw its not me adding all those downvotes! (i never vote down unless its total nonsense) – weberik Mar 06 '14 at 18:55
  • let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/49173/discussion-between-christopher-painter-and-weberik) – Christopher Painter Mar 06 '14 at 19:31
2

There is a more correct answer to this, and it is NOT DISABLEADVTSHORTCUTS. You set the component id to null in the MSI file to prevent repair of that individual file. See ComponentId comments here:

http://msdn.microsoft.com/en-us/library/aa368007(v=vs.85).aspx

Edit the MSI file with Orca to delete the Componenty ID, and write an uninstall custom action to delete the file at uninstall if it's there.

In addition, that's a redundant test. Windows will restore that file for you if it's missing, so the idea that you need a test to notify that it's missing is pointless. The true test should be that Windows will restore the file if it's lost, and your app needs to do potentially nothing about the missing file.

PhilDW
  • 20,260
  • 1
  • 18
  • 28
  • 1
    This is correct, and I have used it myself. However I prefer to create a non-advertised shortcut on the desktop by passing a QAINSTALL=1 to the msiexec.exe command line. This will launch the app without self-repair issues. The tester can also learn to manually create a shortcut or launch the exe directly from the installation folder. All assumes there is an exe though. – Stein Åsmul Mar 06 '14 at 22:39
  • There was a series of comments out here that was moved to chat. The point is there is more then one path to repair. :) – Christopher Painter Mar 06 '14 at 23:08
  • Yes I somewhat prefer the "replace if lost" option. Still, the test plan is the test plan :-) – Julian Gold Mar 07 '14 at 11:06
  • As Chris keeps saying, there is more than one path to repair, and disabling advertised shortcuts will not eliminate repair of that file in the way that a null component id will. Also, why disable repair of the entire product just to avoid repair of a single file? – PhilDW Mar 07 '14 at 18:57
1

You don't mention what tool you are using to make your MSI but I'm going to go out on a limb and guess Visual Studio Deployment Projects (.VDRPOJ).

One of the (many) horrible things about this tool was that it fails to expose the foundational concept of components. Instead it makes every file a key file of it's own component and hides the existence of the component from you. I say 'was' because Microsoft killed this project type in VS. There are around 50k people complaining on UserVoice to bring this tool back and I'm guessing that 49,990 of them don't know what a key path is.

Windows Installer has a concept called the component rules and each component has a keypath. The keypath teaches MSI how to handle repair scenarios. But your tool has to allow you to be able to control this to make it work.

Windows Installer is functioning exactly the way it's supposed to function. You just aren't up to speed on what that is.

However, if you want to ignore Windows Installer best practices and continue using the tool you use today, the trick is to install the app.config file as a different file. Then have the application copy the file to the real file name on run. Windows Installer won't service what it didn't install.

Christopher Painter
  • 54,556
  • 6
  • 63
  • 100
  • 2
    Down me all you want, I'm only trying to save you the pain I experienced for an entire year trying to make this tool work. We were doing product line development for dozens of applications on dozens of branches where each installer had around 200 features, 2000 merge modules and 20,000 files. It just doesn't work. I wish I could have back every late night I ever spent in the lab trying to fix repair issues. – Christopher Painter Mar 06 '14 at 18:44
  • I agree with Chris. Don't use any visual studio deployment projects or any other method from visual studio (except for Wix). I'd say nobody can deliver a quality MSI with only Orca or Visual Studio in a reasonably timely manner. There is way too much complexity and ideosyncrazies involved. – Stein Åsmul Mar 06 '14 at 22:45
1

Several answers have been provided that can work:

  • You can install the file with a blank guid. Then you need to remove it on uninstall using the RemoveFile feature. You will also run into issues if you want to replace it during an upgrade. Could be tricky at times.
  • You can disable the advertised shortcut(s), but this affects too much in my opinion.
  • Finally you can use my suggestion to install a separate non-advertised shortcut to use to launch the application. Such a shortcut bypasses the self-repair check. It may still be invoked by other means such as missing file associations, COM registration or similar, but those are exception states.

However, my preference is that an application can start without a config file present, if at all possible. I always suggest a good startup routine with "internal defaults" available. The startup routine should also degrade gracefully if faced with any file system access denied conditions.

Most importantly you should place this config file in the userprofile so you can generate the file on first launch for the user in question. It can even be copied from a read-only copy in the main installation directory.

When you generate a file from internal defaults and put it in a userprofile location, the file will have no interference with Windows Installer at all. The issues that results is how to clean up user data on uninstall. I discussed this with Stefan Kruger (MSI MVP) at one point, and I agree with his notion that user data is indeed user data and should not be automatically dealt with by your installer at all. Leave it installed, and clean it up via system administrator tools if necessary - for example logon scripts.

Stein Åsmul
  • 39,960
  • 25
  • 91
  • 164
  • 1
    A discussion of handling userprofile data and cleanup can be found here: http://forum.installsite.net/index.php?showtopic=21552 . A bit long-winded, but do read it if you chose to save config data in the user profile. – Stein Åsmul Mar 07 '14 at 11:10