InnoSetup - Erroneous "File in use by another process..." message while compiling
Asked Answered
M

10

16

Although I really like InnoSetup, I have been suffering with this erroneous message for some time, but my frustration has reached new heights. There are numerous posts complaining about this problem, which is most certainly an InnoSetup bug, but no useful work-arounds that I can find.

I have a very simple (signed) setup that merely copies some files and creates a shortcut. It does not even include an executable. When I try to compile the setup, I am getting this "the process cannot access the file because it is being used by another process" message - repeatedly (normally I always get the setup to compile within 3 tries), but now it seems futile after many. many tries. The file that is "in-use" is not clear from the InnoSetup output or error dialog. There are most definitely no competing processes running. (I have rebooted the machine and still get this message).

Any ideas on how to resolve this are much appreciated.

Here is the complete setup code - it is signed, but that is not a problem with other setups I have created with the same signature.

#define MyAppName "Easy-IAP for IronKey"
#define MyAppVersion "4.0"
#define MyAppPublisher "Command Post Solutions"
#define MyAppURL "http://www.commandpostsolutions.com/"

[Setup]
; NOTE: The value of AppId uniquely identifies this application.
; Do not use the same AppId value in installers for other applications.
; (To generate a new GUID, click Tools | Generate GUID inside the IDE.)
AppId={{51668D56-27F6-4C83-87F2-677328EFE808}
AppName={#MyAppName}
AppVersion={#MyAppVersion}
;AppVerName={#MyAppName} {#MyAppVersion}
AppPublisher={#MyAppPublisher}
AppPublisherURL={#MyAppURL}
AppSupportURL={#MyAppURL}
AppUpdatesURL={#MyAppURL}
DefaultDirName="\EZ-IAP"
DefaultGroupName={#MyAppName}
DisableProgramGroupPage=yes
OutputBaseFilename=IronKeySetup
SetupIconFile=C:\Users\ron\Dropbox\EZIAP\eziap.ico
Compression=lzma
SolidCompression=yes
SignedUninstaller=yes
SignTool=Standard /d $qEasy-IAP Installer$q $f                                                                   

[Languages]
Name: "english"; MessagesFile: "compiler:Default.isl"

[Files]
Source: "C:\Users\ron\Dropbox\Easy-IAP for IronKey\AccessDatabaseEngine.exe"; DestDir: "{app}"; Flags: onlyifdoesntexist
Source: "C:\Users\ron\Dropbox\Easy-IAP for IronKey\dotNetFx40_Full_x86_x64.exe"; DestDir: "{app}"; Flags: onlyifdoesntexist
Source: "C:\Users\ron\Dropbox\Easy-IAP for IronKey\Easy-IAP for IronKey\bin\Release\Easy-IAP for IronKey.exe"; DestDir: "{app}";
; NOTE: Don't use "Flags: ignoreversion" on any shared system les
[ICONS]
Name: "{drive:{app}}\Easy-IAP"; Filename: "{app}\Easy-IAP for IronKey.exe"; 
Morphophonemics answered 13/3, 2013 at 22:6 Comment(3)
Maybe copy the source files somewhere else instead of keeping them in Dropbox directory which may be locked as "for synchronization"?Ivette
As the answer is pretty much always "disable your anti virus", I beleive the same applies here.Prismatoid
Thank you for that suggestion, @Ivette – it saved my sanity! Although, in my case, what worked was keeping the source files in Dropbox, but setting Inno's OutputDir to a non-Dropbox filepath. I suppose that as soon as Dropbox sees the build file created, it locks it, and so Inno can no longer access the build that it just begun.Rare
H
6

This is not a bug, this is only bad design of application (or bad documentation) :)

Use the OutputDir directive in your [Setup] section to avoid this wrong behaviour.

OutputDir=c:\output

OutputDir specifies the "output" directory for the script, which is where the Setup Compiler will place the resulting SETUP.* files. By default, it creates a directory named Output under the directory containing the script for this.

You ask why?

If you do not use OutputDir in your script file (and many people do not use it) Inno Setup tries to create resulting setup in the "userdocs:" folder which causes a lot of troubles on all Windows systems.

Always use this parameter, even if you want to have resulting setup in current folder, in that case use:

OutputDir=output
Hollington answered 14/3, 2013 at 12:42 Comment(3)
"If you do not use OutputDir in your script file Inno Setup tries to create resulting setup in the "userdocs:" folder." No, it doesn't. If you omit this directive, InnoSetup creates output in CurrentScriptFolder\Output folder; only if the script is not yet saved and you don't use the OutputDir directive, only then the output is userdocs: folder.Bipartite
Thank you so much. You have relieved me of great distress. I truly love InnoSetup now.Morphophonemics
I'm still getting this error sometimes when I have output directory open. So I guess Windows (10) file explorer can cause this error too.Disconnected
S
34

I had the same problem. It was due to McAfee antivirus running the realtime scanning on the exe file being compiled... As it doesn't seem possible to exclude a directory from realtime scanning, I shut it down in McAfee SecurityCenter, and now it's good. Hope this help

Statesmanship answered 21/11, 2013 at 14:37 Comment(6)
Avira Antivirus has recently started to do the same ... I had to disable its Real-Time protection in order to compile setup files.Lipoma
I can't seem to find how to shut McAfee down from the Security Center?Morphophonemics
Yep, that solves the issue. But you don't have to disable real-time protection, just add it to your anti-virus' whitelistTimisoara
Thanks! I didn't understand why I had this problem and Antivirus was locked by sysadmin on my work. I needed to compile it on a virtualbox, that's why Windows sucks.Hollah
so do windows defender. I added output directory into exclusion list.Micra
mine was due to 'Spyhunter 5'... I was pulling my hair out!Haler
P
15

The problem is often an explorer window being open viewing the folder where the output files will reside.

Explorer continually opens the executable as it is built trying to fetch its icon and other metadata. Close any open explorer windows which are viewing the output folder and try again.

For this reason you are best running your inno setup file from the command line or part of a visual studio or other automated build process.

Philhellene answered 26/5, 2015 at 15:35 Comment(3)
This did it for me. Thanks... What a waste of time!Swinton
Yep that was the cause, looks like innosetup needs to lock the file properly.Wort
yessssss, thank you!Julianejuliann
H
6

This is not a bug, this is only bad design of application (or bad documentation) :)

Use the OutputDir directive in your [Setup] section to avoid this wrong behaviour.

OutputDir=c:\output

OutputDir specifies the "output" directory for the script, which is where the Setup Compiler will place the resulting SETUP.* files. By default, it creates a directory named Output under the directory containing the script for this.

You ask why?

If you do not use OutputDir in your script file (and many people do not use it) Inno Setup tries to create resulting setup in the "userdocs:" folder which causes a lot of troubles on all Windows systems.

Always use this parameter, even if you want to have resulting setup in current folder, in that case use:

OutputDir=output
Hollington answered 14/3, 2013 at 12:42 Comment(3)
"If you do not use OutputDir in your script file Inno Setup tries to create resulting setup in the "userdocs:" folder." No, it doesn't. If you omit this directive, InnoSetup creates output in CurrentScriptFolder\Output folder; only if the script is not yet saved and you don't use the OutputDir directive, only then the output is userdocs: folder.Bipartite
Thank you so much. You have relieved me of great distress. I truly love InnoSetup now.Morphophonemics
I'm still getting this error sometimes when I have output directory open. So I guess Windows (10) file explorer can cause this error too.Disconnected
A
1

I have OutputDir = x:]setup but the error still occurs. If I reboot my machine and then build as the 1st task then the build works.

Active answered 9/9, 2013 at 14:56 Comment(0)
N
1

Win 7 Pro/64, InnoSetup 5.5.5(a): I had axactly the same InnoSetup compilling problems. After changing folders properties used in projects and output by revoking sharing them all works fine. Conclusion - it is better not to use InnoSetup within shared folders.

Nunes answered 18/8, 2016 at 7:53 Comment(3)
Please don't repost existing answers. There are already many answers to this question posted 3 years ago and your doesn't bring any benefit to readers.Cullen
I disagree. My solution wasn't mentioned in answers and works in real world.Washroom
I'm absolutely shure that my post would help people who met problem mentioned in the entry as now many IDEs uses by default "..\users\documents\.." directory for creating project's folder tree. That directory has often a "shared folder" attribute. Using InnoSetup inside such environment leads to problem which brought me just here.Washroom
D
0

I had this when OutputDir="." (meaning, put the output in the same directory as the source files). It would fail every second build.

I fixed it by adding modifying my powershell build script to delete that entire output directory, then build my app (which auto-created that directory), then run iscc to create the setup.exe

Dukey answered 13/2, 2015 at 3:53 Comment(0)
U
0

The error could be caused because you are trying to copy a folder that is linked with a Windows Service.

To solve this problem, use a [Code] section instead of putting the folder in [Files]. That allows you to check if the folder exist, close the associated windows service and finally copy the folder.

Unicef answered 1/9, 2015 at 16:6 Comment(0)
F
0

I had the same problem with that the solution is already stated above and the other reason with this error comes up when the output file of the .exe you compiling has already have the same name in the directory where you put the output directory from inno setup. In order words when compiling you need some special character like '-' or '_' in creating the file name and to avoid this error message.

Fiord answered 13/4, 2018 at 7:7 Comment(0)
F
0

I tried various folders on my work machine and nothing resolved the issue. I finally had success by using:

OutputDir=C:\Users\userid\Downloads 

(Replace "userid" with your particular account)

Femineity answered 23/1, 2020 at 23:1 Comment(0)
C
0

I tried all advices from above. I could not make it. Then I switched back from version 6.2 to 6.0.2 and it fixed the problem.

Coincide answered 23/6, 2021 at 15:3 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.