wyUpdate on a Terminal Server

When i run wyUpdate on this machine, it hangs at the "Closing Processes" stage. What is this stage doing and is it having any ill effect on other users on the server?

wyUpdate doesn't touch any of the processes, it just reads them to see if any processes are running that are associated with files that will be updated. This is to give the user a chance to close any conflicting running processes before they update.

Any particular reason why it would hang? The terminal server has around 650 running processes, would this overwhelm the step?

If your server is running thousands of processes this could take a bit longer than usual. But it's not freezing, right? The spinner is still spinning, and it eventually updates, correct?

Is there anyway to bypass it?

No, but we could add it if you wanted it. There are downsides to skipping the closing processes step. For instance, let's say your user is still running "YourApp.exe", but you opt to skip the closing processes step, wyUpdate will still detect that it can't replace the file because it's running. And wyUpdate will still give a prompt to the user to let them cancel and rollback the update if they want to. However, let's say before wyUpdate gets around to updating "YourApp.exe" it updates a file "YourConfig.xml". If "YourApp.exe" dynamically reads this file everytime it's changed then your running app could load this file and be in a bad state.

Of course this make several assumptions which are probably not true -- that is, your app loads changed files dynamically. However, we prepare for the worst case scenario. That's why wyUpdate detects running processes before continuing with your update.

That being said, we'll add the ability to skip the process checking step if you want to. Is this what you want?

Hello there,

Thanks for the information. I ran it again and let it run to completion. You are right, it didn't hang, but simply took a long time to complete. The step took about 3min to complete (660 processes) vs < 1sec on a regular desktop (70 processes). In that time, it appeared to be doing work (constant CPU and slow growth in memory usage)

I agree that skipping the step might not be the best way to tackle it. Our users are notorious for leaving things running, especially on the terminal server. I think I will first try grabbing the source code for wyUpdate and seeing if I can isolate where things are getting chewed up in this particular environment. I'll let you know if I find anything.

thanks,

Myles

Hi there,

I was able to fix it by optimizing the process test to only look for processes with the same as those in the package. Hopefully there are not too many gotchas with this approach. I changed ProcesssesNeedClosing in InstallUpdate.Processes.cs (as well as the equivalent in frmProcesses.cs) to this:

List<Process> rProcesses = new List<Process>();

foreach (FileInfo filename in baseFiles){ Process[] aProcess = Process.GetProcessesByName(filename.Name.Replace(filename.Extension, ""));

foreach (Process proc in aProcess) { try { //are one of the exe's in baseDir running? if (proc.MainModule != null && proc.MainModule.FileName.ToLower() == filename.FullName.ToLower()) { rProcesses.Add(proc); } } catch { } }}

return rProcesses;

It's great that this piece is open source. Clickonce was a pain because it's bugs were a black box with no way for us to really get to the bottom of them.

We'll add something similar to the next version of wyUpdate. Thanks for spotting this.

We've added this to wyUpdate 2.6.12 (now out).

It works great! Thanks for the quick update.

Myles