Problem Updating Service

More info:

1. When I double click on wyUpdate.exe, it correctly indicates there are updates on the server.2. The service IS using the right wyUpdate.exe file, because if I rename it throws 'cannot find specified file' exception.

Just to make sure - does return code '0' always mean no updates? Or will I get the same code if the program can't locate client.wyc file?

You're not giving us enough information to help you debug your problem. wyUpdate isn't saying there's no update (when wyUpdate fails before things can get initialized then wyUpdate will return 0 -- this is fixed in the next version of wyUpdate).

Tell me how you're launching wyUpdate.exe from your service. Paste the exact code you're using. Also, you can use the /outputinfo commandline option (if used correctly) to output the error.

Also:

- What operating system are you on?- What version of wyUpdate are you using?- What type of service is it (LocalSystem / LocalService)?

Here's the code I'm using (it'd be nice if you could enable BBCode for the boards, so we could use code tags for formatting):

Here's a screenshot of the code from within Visual Studio, it's more readable that way:http://oi45.tinypic.com/2i1ikwk.jpg

public enum UpdateCheckResult { Exception = -1, NoUpdate = 0, Error = 1, NewUpdate = 2, UpdateCanceled = 3 }

UpdateCheckResult CheckForUpdates() { ProcessStartInfo processInfo = new ProcessStartInfo(); processInfo.WorkingDirectory = Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location); processInfo.FileName = "wyUpdate.exe"; processInfo.Arguments = "/quickcheck /justcheck /noerr"; processInfo.WindowStyle = ProcessWindowStyle.Normal;

try { Process process = Process.Start(processInfo); process.WaitForExit(); return (UpdateCheckResult)process.ExitCode; } catch (Exception e) { return UpdateCheckResult.Exception; } }

1. The return is always 0 (which I have enum defined as NoUpdate).2. I tried using the following arguments to get debug output, but no file was created. I'm pretty sure the service has write rights, because it creates other text log files just fine:processInfo.Arguments = "/quickcheck /justcheck /noerr /outputinfo=\"C:\\Test\\log.txt\"";3. I'm on Windows 7 Ultimate, 64 bit4. wyUpdate.exe - version 2.6.18.45. The service is LocalSystem account, but I also tried using LocalService (using credentials of logged in admin user), and that didn't work either.

Hmmm.... this is very odd. Your code looks good, and we can't reproduce this problem here. Do you mind checking out the latest wyUpdate source code from subversion and building a debug build:

svn checkout http://wyupdate.googlecode.com/svn/trunk/ wyupdate-read-only

First, just run your service with the latest build from source. That should return the correct error code. Now, the question becomes *why* you're getting an error (because on the surface everything looks correct). The way you can debug this is to add a "DebugMode()" like function to the start of wyUpdate's execution (near the top of the frmMain contructor.

If you don't know how to do any of this I can schedule a time to debug this remotely for you.

I haven't used SVN before, so not sure if I did it right. I got TortoiseSVN and checked out the code using the following URL of repository:http://wyupdate.googlecode.com/svn/trunk/

Here's the screenshot of the SVN checkout window:http://oi48.tinypic.com/73c4ec.jpg

I work with VS2008, targetting 3.5, so I had to modify your functions that were using default arguments, and remove unit testing project. After that I was able to compile debug version. The assembly still has the same revision (2.6.18.4) - is that correct?

After that I replaced original wyUpdate.exe in my service folder with the debug one I just built.

The return value was still 0. I even logged the exact value returned just in case there were some screw-ups with enum casting, but that was also 0.

It sounds like wyUpdate is working correctly, but you're referencing the wrong exe. Firstly, make sure the correct wyUpdate.exe is being run. Replace this:

processInfo.WorkingDirectory = Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location);processInfo.FileName = "wyUpdate.exe";

With this:

processInfo.FileName = Path.Combine(Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location), "wyUpdate.exe");

Then try it again. If you're still getting an error, try the same exact code in a console app -- do you get the same response.

It's definitely referencing the right exe, because when I rename it, I get an exception. I put in your fully specified FileName code change anyway, and it still returns 0.

When I double click on the wyUpdate.exe it finds the update correctly.

Will try running the same code from a test Windows forms application next, though I suspect it will work then. Has to be something with the service interaction.

I ran the same code under my windows forms application that I use for debugging the service classes, and as expected it worked fine, correctly returning 2 (updates found).

Here's another clue. When running my forms application, if I deleted client.wyc file, wyUpdate returns 0 again, behaving the same way as the service. This brings me back to my original assumption, that wyUpdate can't find the client.wyc file when it's being ran from inside the service. I know services working directory behavior is a little strange, unless set explicitly, so perhaps that has something to do with it.

I added NLog logger to your wyUpdate code, to try to narrow down the issue. I logged the path (clientFileLoc) it passes to the following function, and it's correct:

update.OpenClientFile(clientFileLoc, clientLang, forcedLanguageCulture, updatePathVar, customUrlArgs);

Turns out I was wrong about the service wyUpdate not being able to find client.wyc file. Based on my log trace, it finds it and loads InstalledVersion data from it properly (1.0.15).

Finally found the problem. While trying to attach to the wyUpdate process to debug it, I noticed there was one already running under Session 0. It must've been launched by my service yesterday and somehow never closed. Since I haven't restarted my PC since, it just stayed hidden under Session 0 desktop.

Looking at your code, you use a mutex to handle that case by setting the focus to the previous instance and returning default mainForm.ReturnCode, which happens to be 0. I took that for 'no updates' found, when it was in fact 'another instance of wyUpdate.exe already running'. It would be nice if you could return a different code in that case (like '4').

Here's the code I'm talking about:

if (mutex.WaitOne(TimeSpan.Zero, true)) { Application.Run(mainForm);

mutex.ReleaseMutex(); } else { FocusOtherProcess(); return 4; //this is what I would add (or something to that effect) }

return mainForm.ReturnCode;

You're absolutely right. We'll fix that. Thanks for pointing it out.