Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

Files in Use during a Wise Update

Created: 05 Sep 2012 | 3 comments

In my .Net Windows application, i have a button on the application menu where a user can click it to check for udpates to their software.

It essentially has some custom code that checks some ini files on our webserver that contain the latest version information as a first step, and if it realises their version is different to the current version, it executes the Wise Update that i packaged/depoloyed with the software installation. (i know that you can run Wise Update on its own, and it will check if there is a later version or not, however i want the app to check it slitentlym and only run wise update if there is an update required)

When the Wise Update runs, it detects the new version and downloads the installer exe for the new version and then runs it. However during the installation/update process, it complains that there are several files in use;

  • DF (our .net application name)
  • GLB8CBA.tmp
  • WiseUpdt

Now i understand why it would complain about our application being in use (since it is trying to update an application that is running), however it seems strange that it would complain that the TMP file and Wise Update is in use, considering Wise Update is the one that initiated the install. 

  1. Any ideas on what i might be doing wrong? Surely WiseUpdate should be seamless and not complain about itelsf running?
  2. Is there an issue if we force these processes to be killed before the update?
  3. If so, what is the best method to kill a process in Wise? ( i have seen several posts with different methods - not sure what is the best, such as PV.exe or taskkill.exe)

Comments 3 CommentsJump to latest comment

EdT's picture

What context is the Wise Update process being started in?  The initiating account needs to have admin rights. Also, if you are running WiseUpdate yourself rather than having it run from the application, you are not running it as it was designed, so it's behaviour may not be as expected in those circumstances.

However you run WiseUpdate, you first need to ensure that the existing application is closed down before you execute the update process. If you are running your own update checker, then if a newer version is detected, the user should be requested to close the application and a further check should then be performed to verify that the application is closed before kicking off the update. That way you avoid locked file issues.

This is nothing unusual - locked files are a recognised issue when installing updates and apart from ensuring that the target application is closed before updating it, other techniques such as the PendingFileRenameOperations registry key can be used to replace locked files at the next reboot.

As for killing processes, taskkill is as good as any, or if you search on the Dragonsoft Wisescript library, there are a number of process checking and closing Wisescripts that you could adapt.

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

Anthony Lisbona's picture

Thanks for your reply

What context is the Wise Update process being started in? 

  • It is being started within our .net application, so the user of the application at that point in time will be the 'initiating account'. In our situation, the user had local admin rights. In our code, we determine the path where the WiseUpdt.EXE was installed by our package, and then start it as a process.

As for the GLB8CBA.tmp file, will that automatically terminate once i kill the WiseUpdt process?

EdT's picture

The GLB8CBA.tmp file is a temporary file created by a Wise process (historically, the company that wrote Wisescript way back in the last millenium called themselves Great Lakes Business Systems, so their temp file naming convention is a throw back to their roots). When the Wise process that spawned the temp file terminates, it should clean up after itself, but if it is forced closed by a process kill, then I cannot predict whether a clean up will occur. You will need to explore this for yourself.

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.