Inno Setup Dependency Installer, one line per prerequisite in your setup script

What the project does and how it is put together

The Inno Setup Dependency Installer downloads and installs the dependencies of your application, such as .NET, Visual C++ or SQL Server, before your application is installed. The promise is that you add one code line per dependency, that dependencies already installed are skipped, that more than 60 dependencies are built in, and that you can add your own.

The implementation is unusually simple for what it does. There is a single script, CodeDependencies.iss, that you copy next to your setup script and include at the start of your code section. Everything else is generated at compile time. The repository top level has CodeDependencies.iss, an ExampleSetup.iss that exercises every dependency, an example/ directory with prebuilt executables for three architectures, and a tools/ directory.

That shape is the design. You are not taking a dependency on a framework or a runtime; you are copying one file into your project. There is no library to install, no build step of your own beyond what Inno Setup already does, and no version of the script to keep in step with anything, because the script is just text sitting in your repository.

The requirement is Inno Setup 6.7 or newer. The licence is MIT, in a LICENSE.md file, and the last push was on 2026-10-14.

What is notable is the two CI workflows. There is a compile check workflow and an install test workflow, and having an install test at all is the interesting part, because the project is fundamentally about running installers on a machine, and testing that means actually running an installer and checking what happened on the machine afterwards. The example/ directory with an x64, an x86 and an ARM64 executable of the same program exists so the install test has something to install.

The primary language is recorded as Inno Setup, with Pascal mentioned in the topics, which makes sense since Inno Setup scripts are Pascal dialect.

Setting it up in your own installer

The getting started steps are four and they are quick.

First, download the repository and copy CodeDependencies.iss next to your setup script. Second, include it at the start of your code section and add the dependencies in the InitializeSetup event function, choosing them from the supported list. If your script already has that function, the calls go there instead. The example is:

[Code]
#include "CodeDependencies.iss"

function InitializeSetup: Boolean;
begin
  Dependency_AddVC14;             // Visual C++ Redistributable
  Dependency_AddDotNet100Desktop; // .NET Desktop Runtime for WPF and Windows Forms apps

  Result := True;
end;

Third, set two values in the setup section:

[Setup]
; dependencies are installed for all users, which needs administrative rights
PrivilegesRequired=admin
; installs 64-bit dependencies on x64 and ARM64 Windows
; remove this line if your application and its dependencies are 32-bit only
ArchitecturesInstallIn64BitMode=x64compatible or arm64

The PrivilegesRequired line is a direct consequence of what the script does. Installing a redistributable or a runtime for all users needs administrative rights, and a per-user installation of the same dependency is a different set of files with a different registry state. The comment says so plainly rather than leaving you to work it out when the install fails.

The architecture line is the other half. The script selects the x86, x64 or ARM64 build of each dependency automatically, and the mode line is what tells Inno Setup that this is a 64-bit installation, so the right one gets picked. The comment notes that you remove it if the application and its dependencies are 32-bit only.

Fourth, compile the setup. That is the whole integration, and the fact that it is four steps is the main practical argument for the project.

The catalogue of what it can install

The supported list is long enough to be the main argument for using the project, because each entry is a case where a Windows installer would otherwise have to tell the user to go and install something themselves.

The .NET range is the largest group. It covers the .NET Framework versions from 3.5 Service Pack 1 through 4.8.1, then the .NET Core and .NET 5 through 10 era, each split into the plain runtime, the ASP.NET Core runtime, the ASP.NET Core hosting bundle and the desktop runtime where those exist. The hosting bundle is the one worth noting, because it is the piece a self-hosted ASP.NET Core application actually needs and it is the one people forget.

The Visual C++ redistributables run from 2005 Service Pack 1 through 2012 Update 4, 2013 Update 5, and then a combined v14 entry covering 2015 through 2026, which is the pragmatic choice since every developer linking against a modern runtime needs the same v14 redistributable.

The SQL Server group is the Express editions, from 2008 R2 Service Pack 2 through 2025, along with the OLE DB Driver 19 and the ODBC Driver 18 for SQL Server, and the Access Database Engine 2016. Express rather than the full editions is the sensible scope for a dependency installer, since the full editions need a licence key and a configuration step that no silent installer should attempt.

Then there are the runtime and platform dependencies that modern Windows applications need. WebView2 Runtime, which is what a .NET application embedding a web view depends on. The Windows App SDK Runtime across versions 1.6, 1.7, 1.8 and 2 for WinUI 3 applications. The DirectX End-User Runtime, the Visual Studio 2010 Tools for Office Runtime for applications that drive Office from .NET, OpenJDK at versions 8, 11, 17, 21 and 25, with the Temurin build for 8 and the Microsoft build of OpenJDK for the rest, and then Python 3.13, Python 3.14 and PowerShell 7.

Two things stand out about the catalogue. The JDK and Python entries are relatively recent additions to a project that started as a .NET and Visual C++ helper, which shows it broadening. And the entries are all things that have a single official download URL and a single quiet or silent install path, which is the constraint that makes automatic installation possible at all.

What happens during setup, and adding your own dependency

The flow during setup is described in three steps, and the middle one is where the care is.

First, InitializeSetup checks each dependency and keeps only the missing ones, and the Ready to Install page lists them. So the user sees what is about to be installed before anything happens, and something already present is silently skipped.

Second, after the user clicks Install, each installer is downloaded from its official source, and every built-in download is checked against a SHA-256 checksum, so a changed or broken file is never run. That is the part that makes this project different from a set of scripts that fetch an installer and execute it, because fetching an executable from the network and running it is a supply chain decision, and the checksum is what turns it into a checked one.

The third step is the install itself, with a failure handler for the download, and the README is explicit that a failed download is handled rather than leaving a half-installed state on the machine.

Adding your own dependency is the other half of the value, and the README explains that the tool is a starting point rather than a closed list. The structure of the built-in entries is the model to copy: a function that detects whether the dependency is present, a download from the vendor's official URL, a checksum, and a silent install invocation with the right architecture variant.

The constraint to keep in mind when you write your own is the one the built-ins live within. Every entry is something with an official download, a known silent install switch, and a way to detect its presence. A dependency without those three things cannot be automated this way, and the sensible fallback for it is still the check-and-prompt approach that the script replaces for everything else.

The overall judgement is that this is a small, well-scoped piece of engineering that removes a real and tedious part of shipping a Windows application. The checksum verification is the detail that makes it responsible, and the one-file integration is the detail that makes it adoptable in a project that is otherwise a plain Inno Setup script.

Editorial conclusion

Adopt this script if you ship a Windows installer with prerequisites and want the setup to install them rather than printing a list of things the user must handle first. Skip it if your application has no dependencies beyond what Windows ships, since the extra setup is not free. Verify first by adding one dependency to a test setup script, compiling it on a machine that lacks that prerequisite, and confirming the download is verified and the install completes before you rely on it for a release.

Frequently asked questions

Official sources

1. DomGries/InnoDependencyInstaller on GitHub
2. Issues
3. License: MIT
4. README