I’m getting started with Xojo and I must say there are many things that I did not expect coming from RealBasic in the early 2000’s. One thing that I do not experience with RB that I do in Xojo is that 90% of the time if I build or run an app from the IDE and that I quickly find and fix a bug, say under a minute or two, the Xojo IDE will prevent me from building or running again!
I can see a very briefly flashing window that says “Done assembling code” with a progress bar halfway filled, then everything disappears and nothing is built or run.
I have to sit in front of my computer doing nothing for 1-2 minutes then I hit the build or run button again and it works. It does that almost every time I build twice in the same 1-2 minutes range.
This is extremely annoying. Is there a way to fix this? I can fire up RealBasic from 20 years ago and it never does that, it never happened not even once throughout probably 20,000 builds and test runs I did back in the day.
Similar to this issue is that I cannot rename, move or delete the .exe that Xojo produces even after I exited the built app. There is nothing running in the processes and the app exited cleanly. It remains locked or something. Not sure if it’s related to above issue, but again, I have to sit doing nothing for a minute or two until Windows lets me delete the .exe.
You need everything in the folder, including all the DLLs. Not sure why you would want to, but renaming after the fact also requires the Libs folder to be renamed.
“Virus checker” – I have thought about the antivirus causing the locking, but it happens even when I disable it, so this is not the source of the problem.
Windows 7 – I’ll be honest, I have had zero issue with Windows 7 after January 2021 and note that this 1-2 minute .exe locking does not happen when building with RealBasic 2005. It only happens with Xojo. Your website clearly states that the minimum requirements for using the current Xojo release is “Windows 7 SP1 Platform Update 64-bit” and that is what I use. My Windows 7 environment runs exceptionally well with 32GB of RAM. I only reboot this machine once every couple MONTHS or when there is a power outage. It almost runs as good as a Linux environment! Gaslighting or blaming an old OS won’t solve the issue. It does not happen elsewhere than when using Xojo.
“You need everything in the folder” – I must have explained it wrong. What I meant is that I cannot delete the app and/or the libs/resources folders for 1-2 minutes, even after the app has cleanly exited. It no longer shows in the running processes but Windows does not want to move it to the trash as it seems to still be in use (it’s not). 1-2 minutes after this, I can delete it or move it elsewhere, normally. I’m making a parallel here with the other issue which is when I run or build inside Xojo, if I build twice in under like 60 seconds, the second time, the build progress window quickly flashes but nothing gets built and/or the app does not run. I have to wait 1-2 minutes, then I can press the build and/or run button and it will work fine.
I quit the built app calling Quit() in a method, yes. That’s what I mean by exit cleanly. It does not crash and/or raise an exception and I do NOT end the task using the task manager, no.
I do not see my app in the Process Explorer app that you suggested. Windows still doesn’t want me to delete the file for 1-2 minutes, so unfortunately that does not help. Thanks anyway.
I switched from 32-bit to 64-bit and now the DLL’s are ALL OVER THE PLACE, there are a couple DLL’s in the Libs folder and a bunch of them OUTSIDE the Libs folder. Why isn’t that consistent with the 32-bit builds? Why aren’t DLL’s all in the same folder?
OK so it seems the 64-bit build solves half of the problem. The resulting .exe does not lock for 1-2 minutes after the app is quit. This is good progress. But I’m still having the aforementioned issue in the Xojo IDE where if I build more than 1 time in under 1-2 minutes, the IDE can’t build/run again for 1-2 minutes. (Build progress window quickly flashes and nothing gets built)
64-Bit builds use a completely new compiler called LLVM as opposed to the one that’s used for the older 32-bit apps on mac, windows & linux which was something custom that was written by the company (Real/Xojo)
As far as all the DLLs, Xojo is following the guidelines that Microsoft provides about what DLLs should go where… and this is all about compatibility with newer OSs (Windows Vista and later). It’s not really Xojo’s fault in this matter.
Now, the number of DLLs you see is highly dependent on how your project is configured. If you click on the Windows Build Settings in the Navigator
You’ll see an option for Include Runtime DLL’s. Modern Xojo apps (like most other apps out there) are dependent on the Microsoft Visual C++ 2022 libraries and they either need to be included with your app or better yet, installed on the user’s machine separately. You can either check this option or include the installer from the Extras/Windows Runtime/Installers folder in with your app when you distribute it.
I concur with the rest of the replies you’re getting here. This really sounds like an antivirus or anti-malware program acting up. I’ve got three VMs here that I test on for Windows 7, Windows 10 and Windows 11 and I can’t say that I’ve ever encountered what you are describing here.
Usually, people (who nearly enver reboot their computer) do not like this advice:
Set the Plane mode Off (disable WiFi/Bluetooth); Power Off your computer, drink a cup of Coffee (or tea), reboot and try again.
Is your boot hard disk nearly full ? Or the HD where the application is built ?
What happens when you run the appliocation in the IDE ?
Did you checked the integrity of your hard disk(s) ?
Of course if I reboot and start Xojo, the first build will work, but then the second build will do the same. Yes, my SSD is fine and no, it’s not full I’ve been in the IT business since the 90’s. Never had a problem with my computer. As previously stated, I have a 2 weeks old project that builds just fine under RB 2005 and I ported it to Xojo and this random build issue happens only in Xojo, not in RealBasic or ANYWHERE ELSE in the computer It’s really a Xojo thing. If it were an antivirus thing, it would fail to build under RealBasic 2005, it’s the same project except for deprecated keywords that needed to be updated after porting to Xojo. Anyway, I see nobody truely knows why Xojo does that. I’ll learn to live with it, I guess… or switch back to RB 2005. Thanks all.
It really isn’t that. Since you have an IT background, you surely know how hard it is to fix something that you can’t reproduce. Everyone here is throwing out ideas to try to help you solve your issue based on similar experiences that they or someone else has had over the years, but in the end, it’s still going to have to be you that does the trial and error work.
Having read back through this thread and your latest message about it working correctly once after each reboot got me thinking though… the directory where your project lives… it wouldn’t happen to be a network drive, Dropbox, iCloud, Google Drive or something else like that, would it? Inconsistent file locking can sometimes cause strange issues like this.
Also, I didn’t see anyone asking this question, for this project are you using the build folder?
No, it’s all local on my hard drive. I do not have or use OneDrive or any cloud storage/sync of any kind (no DropBox or nothing like that). Thanks for the ideas. I understand the sync might be locking files and that is precisely why I do not use any of it. I only have a 4.5mbps internet link (yes, in 2022 I cannot have anything faster than that) so you can imagine why I cannot use Windows 10 or cloud storage, it would be a nightmare to work in such an environment with no high speed internet and W10 constantly updating and syncing files.
About the build folders, I tried all combinations, with the build folder, without the build folder and it does not make any difference. The Windows lock timeout seems pretty random ranging from none to up to 10 minutes. At first I thought it was only 1-2 minutes, but I’ve had a severe case yesterday where Windows would not allow me to delete the .exe I built with Xojo for 10 minutes!
I’m beginning to think it might be a security feature in Windows 7 where it contacts Microsoft’s server to send the executable hash and/or verify bits of its code or something. Windows 10 does that systematically to all .exe for which it does not have verified the hash. I think they call it SmartScreen?
What absolutely infuriates me is that when I build with RealBasic 2005 it does not lock the .exe files! And RB includes the DLL inside the .exe too, so in theory it should even be more suspicious than the Xojo builds, right?!
At the moment, the only other thing I can think of is to try running the Xojo IDE from a cmd.exe prompt and see if any errors are printed to the terminal when the build fails.
I don’t know how to do that, but I’m pretty sure the error is going to be “access denied” since that’s what you get if you try to move, rename or delete the .exe within like 1-2 minutes after building it. I’m sure both the build process that immediately and silently fails and the .exe that cannot be deleted within the first 1-2 minutes are the same issue.
I’ve been in the IT business since the 90’s. Never had a problem with my computer. As previously stated, I have a 2 weeks old project that builds just fine under RB 2005 and I ported it to Xojo and this random build issue happens only in Xojo, not in RealBasic or ANYWHERE ELSE in the computer 
It’s really a Xojo thing. If it were an antivirus thing, it would fail to build under RealBasic 2005, it’s the same project except for deprecated keywords that needed to be updated after porting to Xojo. Anyway, I see nobody truely knows why Xojo does that. I’ll learn to live with it, I guess… or switch back to RB 2005. Thanks all.