Odd Aut2Exe errors.

[Mat]

We haven't figured out what the exact root-cause is but it looks like the explorer reads the new EXE file's properties while the process isn't finished yet and still need to update the EXE's resources.

I find closing scite helps aswell... That does help a lot though.

As a solution, can aut2exe not lock the file itself?

[Shafayat]

So, if the compiler compiles to a file with fake extension and then rename it then it wont cause this problem?

[Jos]

I find closing scite helps aswell... That does help a lot though.

As a solution, can aut2exe not lock the file itself?

Do not understand how closing SciTE would help as that only has the source open and the issue is with the EXE.

It is not really AUT2EXE having the problem but it is probably the shelled UPX that has the issue when using the aut2exe directly.

The reported resupdate error has nothing to do with AUT2EXE but is performed in AutoIt3Wrapper itself.

Sequence of events in the 2 different scenario's"

1. Running AUT2EXE:

• AUT2EXE puts the Bin and Script together into a EXE and updates the ICON when requested.
• AUT2EXE shells UPX when that is set

2. F7 from SciTE with the full installer:

AutoIt3Wrapper is shelled which will:

• Optionally Run_Before defined commands
• Run AU3Check on the source
• Optionally Run Obfuscator and au3check on obfuscated source.
• Run AUT2EXE which puts the Bin and Script together into a EXE and updates the ICON when requested.
• Optionally Update program version resources
• Optionally Add other files to resources
• Optionally Run UPX
• Optionally Run_After defined commands

When the Explorer is open we see the update of the resources failing on a regular basis.

Edited May 9, 2010 by Jos

[Jos]

So, if the compiler compiles to a file with fake extension and then rename it then it wont cause this problem?

This is one of the option that could be tested and might work.

[Mat]

Do not understand how closing SciTE would help as that only has the source open and the issue is with the EXE.

It is not really AUT2EXE having the problem but it is probably the shelled UPX that has the issue when using the aut2exe directly.

The reported resupdate error has nothing to do with AUT2EXE but is performed in AutoIt3Wrapper itself.

---

When the Explorer is open we see the update of the resources failing on a regular basis.

I see it fail when hitting f7 fairly often, thats when I first noticed the problem.

[Jos]

I see it fail when hitting f7 fairly often, thats when I first noticed the problem.

That is what I described but just wanted to make the point that closing SciTE will not help in my mind.

[Mat]

That is what I described but just wanted to make the point that closing SciTE will not help in my mind.

Ok, I see your point now, but I was still getting the problems when explorer windows were all closed.

[DavidRogers]

For what it's worth - Running 3.3.6.1 on Windows 7 ultimate, fully patched I can rarely complie a script with Windows Explorer open but have no problems when explorer is closed.

[Jos]

For what it's worth - Running 3.3.6.1 on Windows 7 ultimate, fully patched I can rarely complie a script with Windows Explorer open but have no problems when explorer is closed.

This was indeed identified by others too.

Having Explorer open in the Script directory could indeed cause problems compiling.

[whim]

Never had any trouble compiling (Win7 HP x64 / using AutoIt 3.3.6.1 x86), and I always have an explorer

window open on the project dir containing both au3 and exe ....

I would suggest investigating if disabling Windows Search and indexing service makes a difference,

i've always had them disabled.

Edited December 10, 2010 by whim

[fxm]

Windows XP/SP3.

I'm late to this old thread but I wanted to add a comment about the error message from Aut2Exe "unable to create compiled archive" (and other errors/failures discussed above).

In my case a completely effective workaround was to disable the

[ ] Use UPX

option. So long as that option is enabled, it appears than an AV rule [in Microsoft Security Essentials I think] blocks the .exe file from being written.

I also experienced intermittent compile failures [using SciTE and GUI wrapper directives] which were completely eliminated by making sure that when the folder containing the source happens to be open in Explorer at the time of compilation, the file being compiled does not have the focus.

Edited February 20, 2011 by fxm

[fxm]

/

Edited February 20, 2011 by fxm