Update actions questions

Where are the update actions stored?

The update actions are stored in the update files. So if you set a new update action, rebuild your updates and upload them to your server.

Also, what is meant by service name? Is it the actual name of the exe (as shown in the "file in use" dialog) or the human readable name that appears in the Service control panel?

Neither -- the service name is the internal name used to install and start/stop the service. You can find the name by going into the service source code.

Well, since I didn't develop the service I wouldn't know the name. Anyway killing the service is way too drastic. Since the app I'm updating is asp.net running off the desktop I'm now trying to run custom tasks from the temporary folder. I'm not having any luck either.

I have two task: one "before" update and one "after" update, both are batch files. The doc states that the files are executed in the order of appearance but since I have only one "before" and one "after" task that wouldn't matter, would it?

My batch files are simple. The "before" batch file is to unregister the application:

echo offcall %1\RegisterWithCassini.batpause

The "after" task is similar:

echo offcall %1\RegisterWithCassini.batpause

Both batch file assumes that the first parameter is the installation path. I use %basedir% as command line switch in wyBuild. The path passed through %basedir% will contains spaces.

Nothing so far has worked and I think it's because I do not have enough information on how parameters are passed to the batch files (from wyUpdate.exe). For example, should I call as above (no quotes) or like this:

call "%1"\RegisterWithCassini.bat

or

call "%1\RegisterWithCassini.bat"

or with no path at all, like so:

call RegisterWithCassini.bat

Can you please provide more insights about how things are being passed, if there is a working directory is being set, so on and so forth.

Thank you!

Well, since I didn't develop the service I wouldn't know the name.

You can find out the name using the SC utlity, see: Determining the Name of a Service.

The doc states that the files are executed in the order of appearance but since I have only one "before" and one "after" task that wouldn't matter, would it?

That's correct.

Both batch file assumes that the first parameter is the installation path. I use %basedir% as command line switch in wyBuild. The path passed through %basedir% will contains spaces.

Did you put quotes around the %basedir% commandline option in wyBuild? Also, you might have to remove the quptes being passed into the batch files (see: http://ss64.com/nt/syntax-esc.html).

The problem is elsewhere. The batch files wyUpdate is supposed to call contain "pause" command and their DOS window should be shown when executed as I set the Start Style to "normal". No dos windows show up on screen. wuUpdate creates the batch files all right in the temp folder but I run a file monitor trace and there is no evidence that the batch files are being executed. Only wyUpdate.exe manipulates the files.

If I start the same batch files manually and use file monitor I can see bunches of entries that reference the batch file (from the explorer.exe and cmd.exe processes) which are absent when I trace wyupdate. Is there a wyUpdate log that would show what's going on?

While the "file in use" dialog is displayed, if I manually start the unregister batch file from the application's installation folder, the waiting wyUpdate will eventually detect that the file is no longer in use and run the batch files!!

So I think that wyUpdate.exe checks for "files in use" before executing the "before update" task which completely defeats its purpose in my case since I want to disable the process that uses that file in the first place by using the "before update" task... Catch 22 and I'm stuck.

Is there any way to fix that through wyUpdate? Could some kind of option be made available to allow to run before "file in use" check?

Is there a wyUpdate log that would show what's going on?

No.

So I think that wyUpdate.exe checks for "files in use" before executing the "before update" task which completely defeats its purpose in my case since I want to disable the process that uses that file in the first place by using the "before update" task... Catch 22 and I'm stuck.

Why are the files in use? Are you talking about a service exe that's running?

The problem file is an access database that is used by an asp.net application hosted under a web server (in my case I use Ultidev Cassini and yes, Cassini is a service). I do not wish to stop the web server service since that would disable all applications hosted under it. I want to just unregister the target application using a command line utility provided by the developer of Cassini and then update. I've implemented a work around using a batch file that wraps the unregistration, call to wyUpdate and re-registration but it's clunky. I'd rather have eveything integrated into wyUpdate, if the "before update" task could be run before the "file in use" check.

The only way to do this is to put the service outside the folder being updated. Because as it is, wyUpdate is seeing the service process running and knows it probably needs to be closed/shutdown in order for the application update to complete successfully.

Hi,

I don't think we understand each other. The web server I use to "host" my application is not related to our application. It is installed and resides in its own folder and runs by it own. My application installer "calls" the web server service through a command line utility - provided by the maker of the web server - to register the application with the server. When it is time to update, I have to unregister the application from the server using the same utility so that the .accdb gets freed), update, and re-register the application to make it available again. The web server service should not be touched as it would disable *all* applications hosted by it which would be highly undesirable.

What is needed is a way to unregister my application (using the command line utility/batch file) from the web server before the .accdb file is seen as "in use" by wyUpdate. The mechanics of tasks from the temp folder in wyBuild would be perfect for that but the timing is wrong in *wyUpdate*. The check for "in use" on the accdb file is done *before* the "pre-update" task to unregister the application gets called. I've confirmed this visually (with pauses in the batch files) and using procmon.

There has to be a way to execute a task before this "file in use" check is performed.

Well, I guess, the question I should've asked is what file or process is in-use (I assumed it was Cassini)? Because, when wyUpdate executes files before an update it only complains about processes in the current app directory that are still being run. So what process is still running? And why?

I think it's this line in InstallUpdate.Extract.cs (ln 72) that is causing the problem:

using (FileStream original = File.OpenRead(FixUpdateDetailsPaths(file.RelativePath)))

...as the exception handler report a sharing violation through the ReportProgress handler and the extract is done after the download but before the update (and thus the pre-update tasks).

The procmon trace shows other instance of the .accdb file being opened successfully. When I search the code for File.OpenRead, only the instances in the above file show up (and a couple of instances in InstallUpdate.selfupdate.cs). Otherwise it's always File.Open. Which leads me to think that File.Open is working but not File.OpenRead.

The details of the failed I/O (sharing violation) from procmon are:

Access : generic readDisposition: openOptions: Sync I/O Non-alert, non-directory file, open no recallAttributes: n/aShare mode: read

The details of the successfull I/O from procmon are:

Access : generic readDisposition: openOptions: No buffering, Sync I/O Non-alert, non-directory fileAttributes: NShare mode: read write deleteOpen result: Opened

Both of these are from the same wyUpdate process but not the same thread.

I replaced the line mentioned in my previous reply with this:

using (FileStream original = File.Open(FixUpdateDetailsPaths(file.RelativePath),FileMode.Open, FileAccess.Read, FileShare.ReadWrite))

I recompiled and preliminary tests shows that it now works where it used to fail on a single win7 computer.

I'm continuing my testing.

You're right, this is a better way to handle patching. Sorry about that. We'll include this fix in wyupdate 2.6.18.

Perfect, thanks. Do you have a release date?

Soon. We're wrapping up a couple other bugs and features. We're trying to get it out ASAP. I don't have a hard date, sorry.