Autoupdate process hangs

Hey Alexander,

There's not enough information to help you. For starters, what version of the AutomaticUpdater is your app using? What version of wyUpdate is your app using? And are you using custom versions of either?

Next, can you reproduce this (even intermittently)?

For starters, what version of the AutomaticUpdater is your app using? What version of wyUpdate is your app using?

Both are 2.6.18.4.

And are you using custom versions of either?

We use only the standard version.

Next, can you reproduce this (even intermittently)?

No, I can't, it's reproduced only for some our clients, but on developer machines works normally. So I was interested in the possibility to collect advanced logs.

We don't have logging in the AutomaticUpdater. If you can reproduce this let us know so we can track down the problem.

We understood how to reproduce this situation, it occurs when wyUupdate.exe is located in the directory, whose path contains a # and space (for example, d:\my prog#1\).

The point is *we* need to be able to reproduce the error. Give us an example app that reproduces this error. Send it to support@wyday.com

Hi,

I sent a letter with example application on June 30 to support@wyday.com, is there any suggestions how to solve the problem?

Thanks!

Oh, sorry, it got caught in our spam filters. We've found it and we'll look into it shortly.

You didn't give the source code for the example app. *That's* what we need so we can see how you're using the AutomaticUpdater.

Just try to unzip archive to folder whose name contains # and start Studio.Update.exe without using third-party source code. After the update will be downloaded, on the next step, you'll get an error http://clip2net.com/s/5mnhVo with request to close the same process.

Again, I need the source code to help you. But from the looks of it your app is still running in the background. Hence wyUpdate telling you it needs to close it. So, do what wyUpdate wants and close your app.

If you should me source code I can tell you what you're doing wrong.

At this point, we still don't use the our application, we just downloaded the files client.wyc and wyUpdate.exe (wich is named Studio.Update.exe) and start the update process manually, just running wyUpdate.exe from explorer, there are no ours application on computer, only wyUpdate.exe with custom name. I don't check for updates from our application and don't start the update from it, I just start the updater from explorer.Updater downloads the last updates from the server, tries to extract files and gives an error. Code of our program has never been executed and we don't have any other running process with the same name. It can't extract files, and says that we should close themselves. Have you tried to put files from attachment to folder (like d:\s#\) and run the updater?

It doesn't want to close our application, wyUpdate wants to close itself because Studio.Update.exe isn't our application, it is wyUpdate app with custom file name.

Send me your *.wyp file. It sounds like you're including wyUpdate.exe (or whatever you've renamed it to) in your wyBuild project. You should not do that.

I sent the letter with wyp project file. All versions of updates don't include a Studio.Update.exe, only the mail app that called Studio.exe. Why the update succeeds, then the path does not contain a symbol '#'?

The *.wyp file somehow helped to clarify the situation on the problem?

Sorry, I thought we'd answered this here (this question pops up a lot). The solution to your problem is don't put wyUpdate.exe (or whatever you renamed it to) in your wyBuild project file. wyUpdate has to be updated separately. See: How to make a custom version of wyUpdate.

It seems that we don't understand each other.

All versions in wyBuild project doesn't contain file Studio.Update.exe, it contains only Studio.exe and Studio.exe.config. You can see it in Studio.wyp which was sent earlier. If I need to update Studio.Update.exe or client.wyc - the user download it from our site manually.

As well, previously I wrote that all works fine when my path doesn't contain symbol '#', for example:1. If I unzip files (Studio.Update.exe and client.wyc) to d:\S\ - works fine2. If I unzip the same files to d:\S#\ - update process hangs

What's the difference?

This shouldn't happen -- wyUpdate doesn't treat folders with "#" in their name any differently than an other folder. But we'll look into it, nevertheless.

I has already look into it myself. After a little research of source code for wyUpdate project, it was possible to find such error. When the path to the executable file contains the #, property VersionTools.SelfLocation (and System.Windows.Forms.Application.ExecutablePath) returns wrong path to the current application, for example, D:\test#/wyUpdate.EXE instead of D:\test#\wyUpdate.EXE, so wyUpdate file isn't excluded from the list of processes that need to be closed.

Any news? I think it is a critical bug. Does wyDay have a plans to fix it or wyUpdate isn't supportable yet?

We haven't been able to reproduce this. We're working on finding it.

We haven't been able to reproduce this. We're working on finding it.

It is very easy to reproduce. Just try to run the installer, for example, in the folder C:\C#. Installer will go in infinitive waiting.

I'm not a topic starter BTW. So you may treat it as a second report for the same issue.

Here is https://wyday.com/forum/t/2019/autoupdate-process-hangs/#post-10989 a bug fix in your code. Will your support your product or it not yet supportable?

Like I said, we haven't been able to reproduce it. Yes, we've created folders just like the original poster. If we had more information we could reproduce this bug, but the original poster has been unwilling to give us information on how he's calling wyUpdate.

Thus, we're left to guess what the cause of the bug is. We're exploring avenues, but, again, we haven't been able to reproduce this bug.

Now if you can give us more information on how to reproduce this bug, then please do. It would be a great help. Some useful information would be:

1. What version of wyUpdate.exe are you running?
2. How are you launching wyUpdate.exe? (Give me the exact code you're using to reproduce this bug).
3. Language details would be useful in reproducing this bug (what language is your Windows version)?

Will your support your product or it not yet supportable?

We're working on a number of large features and other reproducible bugs. Short answer: yes, of course.

Hi,

What version of wyUpdate.exe are you running?

wyUpdate version was specified here (2.6.18.4).

How are you launching wyUpdate.exe? (Give me the exact code you're using to reproduce this bug).

It was specified here. It starts manually from Explorer, without any additional parameters.

Language details would be useful in reproducing this bug (what language is your Windows version)?

English, Russian and English with Russian MUI.

wyBuild sample project can be downloaded here http://yadi.sk/d/EsHwOHnv9Fowv All paths configured to d:\temp, just extract to this path and try to start wyUpdate\wy#\wyUpdate.exe

Hello again

When the fix will be available?

We still haven't been able to reproduce it. But we've commit code in subversion that should fix it for you. Compile wyUpdate from subversion and it should all work.

The fix will be included in the next wyUpdate.

The fix will be included in the next wyUpdate.

When it will be happen?

No hard date. If you need it now, build wyUpdate from source. See: How to make a custom version of wyUpdate.

No hard date. If you need it now, build wyUpdate from source. See: How to make a custom version of wyUpdate.

Your build is signed with your company ID. We do not have own digital key for that right now.

It is very sad and unprofessional. Your are fixing bug for 2 month. Now you propose to build my own build with fixes.Too sad.

Your are fixing bug for 2 month.

We've never been able to reproduce this bug (we *still* can't reproduce it). Only you have had it. Plus we've never had anyone else report it.

My guess is that something is screwed up in your windows configuration. If you can reproduce it with a clean Windows machine (and provide us with the steps to reproduce this) then we'll give priority to this bug. But as it is now, we've committed an untested fix to an un-reproducible bug. Hence, holding the release until our larger features and bug fixes are committed.

My guess is that something is screwed up in your windows configuration. If you can reproduce it with a clean Windows machine (and provide us with the steps to reproduce this) then we'll give priority to this bug. But as it is now, we've committed an untested fix to an un-reproducible bug. Hence, holding the release until our larger features and bug fixes are committed.

It is very easy to reproduce. And I write now you can do it. Most of your users have the same issue. So the problem is not in my Window configuration.

Did you tried to lunch installed from directory with # symbol? Did you tried to lunch build the the author sent you?

You receive the archive several times. But you never notice that you can't reproduce this issue. Just silence in response.

It is very sad. And seems wyUpdate that has last build one year ago now is not supportable. Very sad.

It is very easy to reproduce. And I write now you can do it. Most of your users have the same issue.

No, they don't. This thread is the first time we've heard about it.

Did you tried to lunch installed from directory with # symbol?

Yes, of course. This was explained earlier in the thread.

Did you tried to lunch build the the author sent you?

We don't launch EXEs sent to us (for fairly obvious security reasons). Hence the request for source. If you're making a custom build of wyUpdate then you need to debug it on your own.

You receive the archive several times. But you never notice that you can't reproduce this issue. Just silence in response.

We've tried to reproduce it your way, it didn't work. Thus we started digging into possible ways to reproduce this. That takes time.

And seems wyUpdate that has last build one year ago now is not supportable.

We're working on the next version. Developing software that's used by millions takes time.

It is very sad.

You can keep saying that, or you can help us reproduce this and we can actually solve the problem.

No, they don't. This thread is the first time we've heard about it.

Sorry, our users. We are also creating a mass product. So bug report for your update comes every time.

We don't launch EXEs sent to us (for fairly obvious security reasons). Hence the request for source. If you're making a custom build of wyUpdate then you need to debug it on your own.

No we didn't any custom builds. BTW as I know you also received an archive with wyBuild proj files. But you still ignore it.

We've already been over this a few times. We asked for the wyBuild project file to see if you made any mistakes that might cause a problem. We ruled that out rather quickly.

Look, if you want us to make progress on this bug, like I've already said:

1. Give us a way to reproduce this bug.
2. Or test our committed, but untested, fix and see if it fixes your problem. If it does I'll send you a signed wyUpdate.exe build from subversion.

Sorry

But

Did you review the archive pointed in that message https://wyday.com/forum/t/2019/autoupdate-process-hangs/#post-11138 ?

It seems you are ignore this bug report. It which format users should to send his files for starting your investigation?

Did you review the archive pointed in that message https://wyday.com/forum/t/2019/autoupdate-process-hangs/#post-11138 ?

Yes.

It seems you are ignore this bug report. It which format users should to send his files for starting your investigation?

We're not ignoring anything. We can't reproduce the bug here on any of our computers. Why? I don't know, but insisting we're ignoring the bug, then getting mad at us doesn't solve anything.

So like I've said a dozen times in this thread: help us find the bug if you want it fixed.

Did you review the archive pointed in that message https://wyday.com/forum/t/2019/autoupdate-process-hangs/#post-11138 ?

Yes.

And what? Please can you explain you answer? Did you tried to assembly updated? Did you launched it? Can you upload your build for testings us?

I'm trying to help you. But you are systematically ignore all request. How we can help you in that case?

And what? Please can you explain you answer?

I have, many, many times:

We can't reproduce the bug here on any of our computers.

That means that yes, we tried the methods you've suggest and we can't reproduce the bug. I'm not sure how I can make that any clearer.

And what? Please can you explain you answer?

I have, many, many times:

We can't reproduce the bug here on any of our computers.

That means that yes, we tried the methods you've suggest and we can't reproduce the bug. I'm not sure how I can make that any clearer.

Please, read my messages fully. Please, do not ignore it.

I'm quoting my self -((

Did you tried to assembly updated? Did you launched it? Can you upload your build for testings us?

Can I download your build?

Good news everyone! We have completed tests and my colleague said that you latest fix (something about detecting execution directory) resolved the issue. Now I have only one question - when the update will be happen?