Strange error updating an in-use file

[GregSohl]

While trying to update an in-use file, I'm getting a "decompression" error.

[B]Error[/B]: c:\Program Files (x86)\xxx\xxx\MyFile.dll  A decompression error has occurred (#2026)

The "Suppress In-Use Notice" box is NOT checked on the file.

The help says about that flag, "If unchecked, a message will appear to warn the user if the file is in use and will ask them to shut down any running programs."

I verified with Process Monitor that the last access to that file, immediately before the error is shown, shows a action of SetDispositionInformationFile with Delete:True and a result of "CANNOT DELETE".

Is this a bug?

[Ulrich]

Is this file set as readonly, perhaps? If this is the case, you need to reset the attribute before you attempt to overwrite the file, in the On Pre Install...

Ulrich

[GregSohl]

Nope, not readonly. All files in that folder are set to Archive. If I ignore the error, I get it for all the others in that folder that are also in use. It is my "updater" stub program that is being updated.

[Ulrich]

I am not sure why, but it appears that the check if the file is in use is failing. Assuming incorrectly that the file is not in use, the prompt to close the corresponding application is not shown during the installation...

In the On Pre Install, it might be worth to perform a test with File.IsInUse() and ask the user to close the program before proceeding. If this action should also fail to perceive the program as running, you could use System.EnumerateProcesses() and look for your file, again asking to close the program in case it is found on the list.

Ulrich

[GregSohl]

Can't ask the user to close the program. It is my "updater stub" program that launches the setup.exe that is being updated while "in-use". My main app is already closed at that point. I need to count on Setup Factory to be able to handle that.

[Ulrich]

If Setup Factory can't detect successfully that a file is running, then it will attempt to overwrite it during the installation. This appears to be your problem, right?
In your case, if you know that the file is expected to be in use (using for example one of the methods I just mentioned), then you can take care of things with File.MoveOnReboot() and the _NeedsReboot variable, replacing those files at the next reboot.

Ulrich

[GregSohl]

Okay, so I could, for updating my "updater stub", have its files "installed" to a temp location, then in the On Post Install run File.MoveOnReboot commands for each of them to their final destination. That means a user will still need a reboot to get the "updater stub" updated, but it will solve the problem. Does that sound reasonable?

BTW Ulrich - you do a great job in these forums answering questions from folks from a million different contexts and perspetives!

Greg

[Ulrich]

Okay, so I could, for updating my "updater stub", have its files "installed" to a temp location, then in the On Post Install run File.MoveOnReboot commands for each of them to their final destination. That means a user will still need a reboot to get the "updater stub" updated, but it will solve the problem. Does that sound reasonable?

It certainly looks acceptable to me, but it is your call... I would use a temporary folder in your %AppFolder% for storing the files, instead of using the %TempFolder%, in case you were thinking about placing the files there. The default temp folder may be cleared during the boot by tools like CCleaner and others, which could prevent the file replacement from working as expected. Also, as your installer won't deploy the files directly to their final location, you probably want to check the "Never remove" option for them, so their (temporary) location isn't included in the list of files to be removed during an uninstall. You may need to handle them differently during the product removal.

BTW Ulrich - you do a great job in these forums answering questions from folks from a million different contexts and perspetives!

Thank you - just trying to help.

Ulrich

[GregSohl]

Sounds like a plan. Thanks again.

[GregSohl]

For what its worth, I did some research on how our old MSI (Wise) based install replaced the in-use "updater stub", using ProcMon and some detective work. I certainly don't have all the answers/details, but it appears that it

• Uses Windows Side-By-Side Component capabilites to...
• Moves the in-use files, I think to c:\Config.msi, to some temp names
• Creates FileMap entries for them in winsxs
• Deletes the originals
• All while the app that is using the files (exe and dll files) is still running
• Install new ones in their place
• Deletes the FileMap entries at the end of the install
• Deletes c:\Config.msi folder at the end of the install

Nice. Can't find any doc on how they do this. Found some references saying the API for Side-By-Side Component stuff is undocumented

Would be cool if Setup Factory (or any of the rest of us) could do that!

[GregSohl]

I may as well share my other discoveries here, as they may help someone else.

We are using the Microsoft Application Updater Block (UAB) as part of our automatic update process. It was during its use that my original issue arose in trying to update my "updater stub" program. I've mentioned already that it worked fine with MSI technology, but not with Setup Factory.

I discovered (in this beast I recently inherited) that the UAB has the ability to run its indicated tasks (for us that means launching the SetupFactory-built setup.exe) after a specified process has exited. It does this by extracting a stub EXE and BAT file, and causing them to run the tasks separately, then allowing the originating process to die. The task entry in the manifest file for this is a "WaitForApplicationExitProcessor"type.

I think this will allow me to update my "updater stub" without requiring a reboot - using File.MoveAfterReboot - in Setup Factory. I've got a plan worked out and my fingers crossed.

- Greg