Download Inno Setup Compiler

[Arlyne Doepner]

AlthoughI 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).

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

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.

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.

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.

I had the same problem with that the solution is already stated aboveand 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.

I have a program which I converted with py2exe to an exe. After that I tried to make an installer with Inno Setup. I included all necessary files like .dll, .pyd, .gif, .wav, the tlc folder (tcl8.5, tk8.5) etc. But after installing the program it gives me this error:

By default the compiler skips empty directories when it recursessubdirectories searching for the Source filename/wildcard. This flagcauses these directories to be created at install time (just like ifyou created [Dirs] entries for them).

Since Jordan Russell wasn't satisfied with InstallShield Express which he had received upon purchase of Borland Delphi, he decided to make his own installer.[3] The first public version was 1.09.[citation needed]

To make an installation package with version 1.09, an "ISS.TXT" file needed to be created in the installation directory. In the file, the user needed to supply variables and values which are still used in Inno Setup today. These variables served as the configuration of the installation package but many other features could not be changed. The installation compiler had no editor and was more of a shell to compile scripts.

Inno Setup grew popular due to being free for both commercial and non-commercial use,[4] many software companies switched to the tool.[citation needed] Since Inno Setup was based around scripting, fans of Inno Setup started ISTool and ScriptMaker to aid in visual and simpler ways to make installations for Inno Setup.

Many people have taken Inno Setup source code and used it to develop third-party versions of Inno Setup.[6] An example is My Inno Setup Extensions by Martijn Laan, which was incorporated into Inno Setup in June 2003.[7]

ISCmplr.dll is a compiler required by Inno Script Studio to compile scripts. It is maintained by Jordan Russell. Therefore, you will want to also download the compiler from Jordan's website, located here:

I had this exact same problem recently. There are 2 ways to get Inno Script Studio. You can download it directly from kymoto ( -script-studio/), or you can get it from jrsoftware in the Quick Start Pack ( ). If you get it from jrsoftware then it will automatically install the latest Inno Setup as well, but if you get it directly from kymoto it will not.

Assuming you are able to download and install it, you now need to tell Inno Script Studio where it is. Launch Inno Script Studio and go to Tools > Options. In the new window go to Compiler Settings and select the directory where the ISCmplr.dll is ("C:\Program Files (x86)\Inno Setup 6" for me). It was initially blank for me regardless of where I got Inno Script Studio from.

Fast forward 2019 I came looking for an answer. compiler directory is no longer in Program Files. Latest Inno Setup 6.0.3 you will find it in AppData. C:\Users\YOUR USERNAME\AppData\Local\Programs\Inno Setup 6 and the ISCmplr.dll is there.

I was trying to make my programs installer file, but I made a terrible mistake. I forgot to add the OutputDir settings to the script but I've already compiled my script and I can't find my setup file.

I asked ChatGPT and it said if the compiler couldn't find the OutputDir settings then it will make the setup file in the same directory where the setup script is located, but I didn't find any .exe files in my USB. Plus, I used the find command to find the .exe file but it took too long and what it found before I aborted the process were all Windows 10, 11 system or setup files.

I am using a .iss script to build an exe file inside Inno Setup Compiler. I need to package some node_modules into this application so I have a line under [Files] which looks like this:

So, it appears to be running fine up until it aborted. My initial thought was that the browser.js doesn't exist but after double checking, this is not the case. Also, I'm using a wildcard in the source path so the compiler knows the file exists, but it seems to be having trouble compressing it.

One other thing that could be causing the issue is the file path length. Node modules usually end up having ridiculous file path lengths due to nested dependencies. In this case, the path length is 260. Assuming this is what's causing the problem, is there any way to get around it?

A common workaround is prefixing the path with \\?\ (again see the Microsoft article above). The prefix can be used for absolute paths only. But Inno Setup compiler chokes on that with the Source attribute. It looks for : and it accepts only path that either have a drive letter only before the : or that use compiler: or userdocs: prefixes.

And then you will have the same problem with a long path with the DestDir attribute, while installing (not when compiling). There, there's no problem with the colon, so you can simply use the \\?\ prefix.

Of course, if the problem is caused by a root path being too long already, you can fix the problem simply be moving the source files to a folder with a shorter path. Or you can use subst to create a virtual drive or you can create a symlink/directory junction.

NB1: Careful, once associated, it is difficult to navigate upper paths directly within the .iss script because A:\.. is still A:\ ! (I fall into the issue, so worth to know). Association should then be made with closest top-most folder of all required files directly in precompile.bat.

Note finally that [PreCompile] and [PostCompile] sections will execute from the IDE only. They won't execute from the command line (at least with inno 5.5.9), I also fall into this... so complete compilation from command line should look like:

NB: I think calling Compil32.exe /cc "myscript.iss" (IDE compiler) instead of ISCC.exe (command-line compiler) should run [PreCompile] and [PostCompile] sections but in my case I had to pass extra /D options to the compiler so it was not possible to call Compil32.exe directly.

I need to pass a parameter value from compiler to the [Files] section of my compiled script, such as one can do at setup runtime using the param:... constant in their script. My idea is compiling my script e.g. this way (which fails to execute):

You can build your setup by using ISCC compiler passing it the path through the /D parameter. That will declare a public #define for your script. Since the #define can be redeclared by the script, you need to ensure its conditional declaration for the default value you want to have. For example:

We're getting a strange "out of memory" error trying to recompile an InnoSetup script using the InnoSetup action in Finalbuilder. This does not appear to be related to any of the "out of memory" errors previously encountered in InnoSetup's earlier versions.

If I replace the InnoSetup action with a generic "Execute Program" action, running the ISCC.EXE compiler directly, then our InnoSetup script compiles successfully without any such errors. We would much rather use the InnoSetup action so as to be sure that errors etc are reported correctly rather than relying on our configuration of a generic "Execute Program" action (what should we be testing for in terms of ERRORLEVEL from the ISCC.EXE etc?)

This was originally found using InnoSetup 5.2.3 but I have subsequently upgraded our build process to the latest InnoSetup (5.3.5) to ensure that the problem was not related to using an older version of InnoSetup and the problem still occurs.

If I change the Compression type used in the project to a method that has a lower memory requirement then the compression phase of the project progresses further but still eventually fails with an Out Of Memory error before completing.

What I don't understand is that with Compression set to lzma/ultra64, compiling the project with the ISCC.EXE command line compiler results in memory use for the compiler process (running in a cmd.exe) escalates to 700MB+ but completes successfully. Running the exact same script using the InnoSetup action in FinalBuilder halts on the very first file in the compression phase, but memory use (as reported by Task Manager) of the FinalBuilder process does not increase beyond 48MB.

3a8082e126