Just noticed an issue with 2016R4.1. It cannot be the same as what happens in macOS. Or can it ?
46532 - debug exe is not deleted
OS: Windows 10
Xojo: Xojo 2016r4.1
Steps: Do a debug run
Quit
The Debug folder remains, and inside, the .exe.
Libs and Resources folders are correctly removed.
Expected Result:
The entire debug folder is removed
Actual Result:
Debug folder remains with the exe inside.
Does this persist through a restart?
(Bless anyone that puts up with the IDE on Windows)
No luck. I even verified with another program in case the issue was due to a plugin.
BTW the same issue presents on macOS with web apps.
About putting up with the Windows IDE, I would consider highly unprofessional to pretend selling Windows apps without doing the last mile on a real, physical PC. Even if most of the app was developed on Mac.
Did you refresh the Explorer? That’s a known issue on Win 10 the explorer doesn’t refresh on deletes some times.
It is not a display issue. The folder and file are really present.
Any news on thios issue?
I ran into this just this week. And what made it worse is that I couldn’t delete it manually - it just kept giving me permission errors. The only way around it was to literally rename the output executable.
This would work a few debug cycles and then I had to change the name to something else. So MyApp became MyApp1 and then after that wouldn’t delete I’d change it back to MyApp and it would work.
I’ve run into this on the Mac side with sockets but this Windows app was super simple. This was on Windows 10 running on an Admin account. So something weird was going on but because I was in the middle of training I didn’t have the time to look into it more.
FWIW, I did a complete restart on Windows and the issue continued. So perhaps some new security BS on Windows 10?
It comes and go. This is really annoying.
I have the same problem, but I’ve never had a problem deleting…YET
With remote debugging 2017r1.1 to Win10, I see debug.exe continuing to run in the Task Manager after the app is quit. This prevents a 2nd debug attempt until the first process is manually killed. Happens quitting from both from the menu, and X’ing the window. Might be related…
Also, same app and debugger runs and quits as expected with 2016r3 (and flickers a lot less as a bonus
The problem exists still in the latest beta.
I have been trying to reproduce the issue reliably in order to make a feedback report, no luck so far. I usually succeeded to remove references through a restart and then delete the file. SFC and DISM on Windows 10 can help repair debug exe with corrupted security parameters. (I had one such case). Perhaps a force remove using Powershell would work, I haven’t tried.
An inconvenient but reliable work-around for me in this case has been to:
Pretty weird…
Nope. It happens steadily with web apps, no matter the kind of quit.
Running 2019R1.1 Win10 - running into the same problem all the time.
Seems that only projects containing the HTMLviewer (subclassed or not) suffer from this weird behavior.
I requested to reopen FB 46532.
Cannot upgrade beyond 2019R1.1 and this behavior frustrates me all day. (nearly every run)
have you tried to close the window with the HTMLViever before quit ?
If it do not have a window without an HTMLViever, add one and test. If it works, it will be a good workaround:
in app.Close, you will add a close for that/these window(s)
This came up in my mind also but doesn’t work out.
I am running a html-page with quite some javascript in the htmlviewer. As long as I don’t load this content there seems to be no problem. Once loaded, the problem occurs 8 out of 10 times.
Are you running Native or Webkit?
Webkit (have to)
I took this post down and tested the following code as it didnt seem to work in newer versions but I notice you only need it in 2019r1.1 so it should work there. It probably doesn’t work as expected in newer versions due to recent changes to the webkit browser to stop it crashing. I’ll have a look at it another time if needs be but it might work for you, I don’t have the time right now to diagnose that issue.
Try running this in your app.close
https://www.dropbox.com/s/pdbit6x5ug1iifx/cefCleaner.xojo_binary_project?dl=0
Call cefCleaner.Clean() to invoke.
It will search for and terminate any running cefsubproc.exe’s before your app closes so that they are terminated before the IDE tries to do its thing. A slow shutdown of them might be causing the hitch.