Weird Installation Problem

[01010100]

The problem doesn't seem to be debug vs release but running inside the IDE vs runing outside the IDE, given that running in release mode inside the IDE does not show the problem.

[Jovus]

Simple fix: just package your IDE with the executable.

What? Why isn't that a good idea?

[MasonMac]

There's no way to know if the difference is truly because of the IDE. So I recommend that an image of Steve's OS installation should come with it instead.

[AlitarSemiramis]

This sounds like it could be an anti-virus or Windows Defender issue.  I would try excluding the folder from Windows Defender to see if it makes a difference:

- Windows Defender -> Virus & threat protection settings -> Manage Settings -> Exclusions -> Add or remove exclusions

[Jason]

Assuming a file from a known good environment works, does the installer understand the sqlite file is binary, not ascii. 

[Steve Walmsley (OP)]

There's no way to know if the difference is truly because of the IDE. So I recommend that an image of Steve's OS installation should come with it instead.

More weirdness.

If I close the IDE and run the exe that sits within the release folder of the build, it runs fine.

If, rather than installing, I simply move those same files from the release folder into a new location on the C drive, it is back to 5 minutes.

[Steve Walmsley (OP)]

This sounds like it could be an anti-virus or Windows Defender issue.  I would try excluding the folder from Windows Defender to see if it makes a difference:

- Windows Defender -> Virus & threat protection settings -> Manage Settings -> Exclusions -> Add or remove exclusions

I tried disconnecting from internet and then turning off the anti-virus. No difference.

[littleWolf]

5 minutes  first run in new folder, or any next run ?
Maybe some database files created outside of "release" or "debug" folder.  After you copy folder content to another location,  SQLite  must create new database (Or maybe your database useabsolute patch for files)

1. Try run executable and inspect his activity (CPU, Memory, Disk usage) by  "Resources Inspector" on Windows - for "bottleneck" detecting.

2. Make Virtual Mashine  with clean Windows, and test your installer on VM.

[Steve Walmsley (OP)]

It is folder related. If I move the install files from C:/Program Files/Aurora to C:/Aurora it works fine. That is true for both my main PC and my laptop.

No idea what is going on there.

Anyway, that means the installation process is working, but it can't be installed in program files.

[Mini]

Windows doesn't like things in C:/Program Files being edited, so if the database is in the same folder as the rest of the program then it's likely that protection is what is causing the long waits. Making sure it doesn't get installed in program files would fix it, as would having the database be somewhere else. %appdata% is commonly used for this sort of thing.

[littleWolf]

Do you have x64 Windows ?    And you compile x64  Aurora ?

If Windows x64 and Aurora  compiled by 32-bit (x86) compilator, he must be install to  C:/Program Files (x86)  folder

   

[Bughunter]

Windows doesn't like things in C:/Program Files being edited, so if the database is in the same folder as the rest of the program then it's likely that protection is what is causing the long waits. Making sure it doesn't get installed in program files would fix it, as would having the database be somewhere else. %appdata% is commonly used for this sort of thing.

Yes, got this as my prime suspect too.

[Korsar13]

It is folder related.  If I move the install files from C:/Program Files/Aurora to C:/Aurora it works fine.

Please, check %APPDATA%\Local\VirtualStore folder.

[Steve Walmsley (OP)]

Do you have x64 Windows ?    And you compile x64  Aurora ?

If Windows x64 and Aurora  compiled by 32-bit (x86) compilator, he must be install to  C:/Program Files (x86)  folder
 

I'm going to create both 32 and 64 bit versions. In testing, the 32 bit is actually faster but I suspect that will change for larger games.

For this example, I compiled 32 bit and installed to C:/Program Files (x86) folder.

[Tikigod]

Great to hear you found a cause.

Personally I can't imagine many people still put things in program files unless it's simply the default path directory and they can't be bothered to change it. Heck I'd be surprised if many people even install Aurora on their system drive outside of those where that's their only option.

When I first started playing VB Aurora I had it installed on my system drive as I wasn't sure on the amount of read/writing the game would involve due to how it's structured and figured the SSD on my system drive may help in certain cases, but after a while realised it really makes no difference with Aurora, I can only imagine C# with the removal of the constant writing state to disk will make it matter even less, so it's definitely going on my secondary HDD rather than my SSD so I can keep it stored alongside my usual game library collection.