InnoSetup Compile Error

Frustrated as heck - same .iss file has run several times successfully, on the same computer. Now when I run it, I get the compiler error message:

“The process cannot access the file because it is being used by another process.”

I rebooted my system and tried again - same result.

Has anyone run into this issue before?

Hi Mark,

I just ran an iss update on a program that I use frequently at work, and it worked well.

What versions are you running? I am running:
Inno: 5.5.3(a)
Windows 8.1
Xojo 2013 r 3.1

Sincerely,

Eugene

Is it possible that the installer file it is trying to create is in use? Maybe try giving it a different output name to see if that changes anything?

Only six days old. Hopefully not too old to bump.

InnoSetup has some bizzare bugs. Whenever I use it and try to compile & run then I get this error - even if the program or computer is fresh. You just have to keep clicking. After the 20th time or so it seems to work. Sometimes closing and then reopening also helps.

I researched the problem online and one person claimed it is because it doesn’t have an Output folder declared, but mine did and even after making sure it was declared the problem persisted.

At least you aren’t alone. If you figure out what it is, I’d love to know the solution.

Does it make a difference if there is an existing output file there or not? Meaning, if you delete the old setup file does it then work?

I’ve used InnoSetup on countless projects and never had any trouble with it. In fact, I often run it using CrossOver Office directly from OS X because it is so reliable.

Regardless, if it’s not working well for you, perhaps Advanced Installer might be a good alternative.

One cause which I have encountered myself, is having an Explorer window open, and showing the existing setup.exe file.
Close the explorer window, and it works.

Another would be possibly virus checkers holding the file open while checking it.

@Bob Keeney I’d tried deleting the existing output file already, it didn’t help.

@Jeff Tullin I think the virus idea has merit. I just tried with a fresh started PC (only Chrome open) and opened the .iss. Compiled and ran, it worked fine. Changed a line of code and tried to compile again and then I get the process is in use error message. I checked the output folder and it’s empty. I try again, get the same error. However, after writing this post and then trying it again it compiled without the error. It’d seem that a certain period of time needs to elapse before the process is freed. It’d make sense that the cause is the virus scanner holding it open or something, because absolutely nothing else is running on the PC aside from Chrome at the moment.

@Paul Lefebvre Thanks Paul but I like InnoSetup as well. I’ll stick with it, even if I have to wait 3 minutes between compiling. Even after changing the output name of the file it still has the error. That’d make me think that it doesn’t have anything to do with the output file itself… especially since after deleting the old one and still got the error. Maybe a program that InnoSetup uses to compile is what’s still in use and is causing the error?

I have ran into situations like this numerous times, most recently with my backup service. Twice recently when I tried to save my Real Studio project, my cloud backup app had not terminated the previous backup session from the previous run which is scheduled to check that directory once an hour and incrementally backup as needed. RS didn’t complain, but an hours work simply didn’t save. Happened twice and I have seen similar behavior when my virus scanner is holding on to something.

If your virus software will allow, you may want to mark that project directory as safe and not needed to scan and see if that solves it. I have used INNO for 12 years and never had a problem like you are having.

I had the same issues, every single compile. Very frustrating. Fortunately I finally traced it down to McAfee antivirus. When I switch McAfee realtime scanning off, no compile problems anymore.

Yup, virus scanner seems to be the issue. It’s good that we got to the bottom of this. Thanks to everyone for your contributions.