In-use files not updated by MSI-installer (Visual Studio Installer project)

Question

I'm using the Visual Studio Installer Projects extension to build the MSI-installer for my application. However, my application is meant to be running at all times, and if it's open when the user is installing a new version of my software, the open files are not overwritten, and very little to nothing is actually updated (although there are no installer-errors).

I've found that using the installer project's "Custom Actions" to run a script that closes the application doesn't help, as none of the actions are called before the files are replaced.

Is there a good way to make sure the open/locked files gets terminated before the files are supposed to be overwritten?

Caspian

Did you find anything interesting in the log files? – Kirtle

@SteinÅsmul Didn't get to the log files, due to the closed system that this installer is. – Caspian

MSI files can always be logged? You have no access to the server in question maybe? – Kirtle

Have you tried the Visual Studio Installer Projects before...? – Caspian

I have tried VS Installer projects, yes, and traumatic they can be indeed. However MSI logging should always work - I just tested with a Visual Studio Installer project now to confirm. If you have a solution with Advanced Installer that is great, and the VS Installer Projects have never been recommended by me or most other deployment guys. Maybe you used custom actions to install files in the VS Installer project MSI? Regular file overwriting (not done via custom actions) should work regardless of what tool was used to create the MSI. – Kirtle

Answer 1

This isn't a solution to the problem, but rather another solution; the one requiring the least work in the end.

I ended up not using 'Visual Studio Installer Projects' for my installer. Instead I looked to Advanced Installer, which just works with no issues. Things like this is taken into account, and custom actions allow for more options.

If your project is open source, you can write to them about a free open source "professional" license, equal to their "professional" plan, which is normally $399 (onetime purchase).

Caspian

There is also a free edition from Advanced Installer which you can use for as long as you want within VS. You can access it be creating the "Simple" project type. – Librettist

Answer 2

We had this problem, and the solution we came up with was to create two apps; the user app and an updater app. The MSI installs both. Each app checks if the other needs updating and, if it does, closes the other app, downloads the other app's updater, runs it, then relaunches the other app. Additionally, each app monitors if the other app is running and, if it isn't, launches it.

Subsolar

I wonder if you would find the restart manager approach any better? Perhaps you have tried it? Details in my answer. – Kirtle

I thought of the same, however, I would like to avoid this approach if possible (which it doesn't seem to be). A batch/vbs file downloading the files from my web-server, closing everything, deleting the old and renaming the files to their original names is a possibility, but it should really be the installer's job to do this :/ – Caspian

Interesting answer @Stein, but our apps did not require restarts. – Subsolar

Answer 3

It would be useful to know more about your application and how you are doing the upgrade because:

1. You will normally see a FilesInUse dialog saying that files are in use, prompting the user to shut them down, but not if the install is silent.

2. Visual Studio setups have no built-in support for shutting down and restarting services, so if your app is a service you'll need extra work.

3. Files that actually do need to be replaced will prompt the user for a reboot (if they are not previously shut down) in order to replace them at reboot time.

So if you're not seeing reboot requests or FilesInUse dialogs in a UI install then something else is going on. So you need to be sure that:

a. You are really doing an upgrade where the version of the setup project has been incremented, the UpgradeCode is the same (and the ProductCode changes when you increment the setup project's version). Your symptoms could be the result of the upgrade not working and you're seeing just a repair.

b. The definition of "new version" is that you have an upgrade as in a., AND, the file versions of the binaries have been incremented. The default overwrite rules for installs require incremented file versions, so if they haven't been incremented you'll see no updates, and Windows will not attempt to show FilesInUse dialogs or reboot because there are no files that need replacing.

Extenuate

Yes, we need to know the command line they install with I guess? These VS installer projects really seem like black sheep in the semi-dysfunctional MSI family, don't they? :-). You'd think Seth MacFarlane designed them. – Kirtle

No message/popup is shown. The installer says "success/complete", and thinks it's done. However the files in use haven't been replaced, and are still open. When I make a new update, I simply change the version-number from eg. 1.0 to 1.1, say "yes" when it asks if I want to change the ProductCode. – Caspian

Are you sure you are installing to the same folder as before? – Kirtle

Yes I am @SteinÅsmul – Caspian

Answer 4

REBOOT: How are you installing this MSI? What command line? If you set REBOOT=ReallySuppress on the command line, you will not be prompted for a reboot even if one is required to complete the installation of the product.

msiexec.exe /i MySetup.msi /QN REBOOT=ReallySuppress

If you are using a distribution system I suppose suppressing reboot prompts could be standard behavior. Then your product files should be put in place after a reboot (PendingFileRenameOperations or perhaps some newer mechanism).

It is also possible that Visual Studio Installer Projects do something strange that I am not aware of.

---

Log: I would try to create a good log file for the install, to determine what is going on:

msiexec.exe /i C:\Path\Your.msi /L*v C:\Your.log

Log All MSIs: Personally I like to enable logging for all MSI installations - as described in the "Globally for all setups on a machine" section in the above link.

Interpreting an MSI log: interpreting a log file can be challenging sometimes. Here is an answer with some links to help with this.

---

Reboot Manager: Reboot management is a very complex topic, and Windows features functionality - in the form of the restart manager feature - to try to minimize the need for reboots, by instead shutting down and restarting applications as part of an installation in an "auto-magical" fashion (application listens for messages and shuts itself down gracefully when told to, and the system may restart the application after the install - if configured to do so).

Updating your application to comply with the restart manager is the only real fix for such problems that you see, in my opinon.

• The section "Restart Manager" in this question tries to summarize how to implement such support (maybe just read the yellow section a bit down the page).
• The Advanced Installer guys have a very nice, technical article about this: How do I add support for Windows Restart Manager to my application? Also linked to in the link directly above - still worth a direct link here I think.

Ornithology

The .MSI is opened by double-clicking it, like any normal user opens a file. No "command lines". The Visual Studio Installer Project extension (which is linked to in the post), doesn't allow the user to edit any code - it's all UI (and not a good one), with some settings. And in the "auto-magical" part of your post, you mention my question as an answer, when it's actually the problem. – Caspian

"I mention your question as an answer"? I don't understand what that means. And did you actually try to make a log file to see what is really going on? – Kirtle

"(...) instead shutting down and restarting applications as part of an installation in an "auto-magical" fashion (application listens for messages and shuts itself down gracefully when told to (...)". The problem is the execution of this. Making my application "shut down gracefully". As far as I know, nothing I do in the installer requires a restart (like mentioned in the first answer's comments). My question is; what is the best way to shut down my application, before the installer tries replacing the old (open) files with the new ones. – Caspian

I think Phil is right that there is something else wrong here. Hence my suggestion to create a proper log file first of all. Then you will have something to start with - some debugging ideas. Apart from that: an application that supports restart manager should not experience problems with files not being replaced - that is the whole idea of automatic application shutdown (and restart). Are your files versioned? Or are they files without a version property? (for example text files, photos, etc...). – Kirtle

Answer 5

According to below link

https://social.msdn.microsoft.com/Forums/windows/en-US/0b40b367-3341-43d8-b82e-1ace546969f8/how-can-installation-stop-and-restart-existing-service-?forum=winformssetup

"There is no good support in VS installs to stop and start services. During install, the issue is that custom actions run after everything is installed so it's too late to stop a service that you are upgrading or replacing. Yes, they have names like "BeforeInstall" but they really are not before the install."

Chiromancy