Disclosure Update

Shortly after posting this and feedback from the OBS discord. Most of this problem seems a "non-issue" as the script are used fo CI and not supposedly used for local build. The plugin here is in need of update to be on-par with the template good practice. Which might be needed sooner than later. Enjoy the read.

This is still valid if you want to do your build locally.

Discussion Goal

As this problem might come from either this plugin or the main obsproject script, this discussion goal is to clear most of the possible other issue from the plugin/system before raising it to the OBS Project.

I will try to describe my process and reasoning finding this, as this might help others diagnose other issues.

Context

In a CLEAN dev environment on Windows, the build can fail with error like : iscc command not found.
This is the case even after restarting.

Reason of the error

A require build tools are not installed or accessible.

"The term 'iscc' is not recognized as a name of a cmdlet"

The Path to cmake or iscc (Inno Setup) are not in the Environment variables.
This can be verified by checking manually in the windows settings or in Powershell

$Env:Pat

Workaround

NB: You MUST restart your system before any of this workaround are effective.

Add Inno Setup to your Environment variable PATH

Install Inno Setup Manually

Install the required build tool (ie.: cmake and Inno Setup) manually. As in "the old manual way".

1. Get on the official website
2. Download the installer
3. Install
4. Reboot
5. Run the build again - Should work.

The root cause?

The build script Install-BuildDependencies.ps1 (coming from the obs-plugintemplate in our case. does not find the app required path in the environment variable, nor find the install folder.

The script will look in the common App installation folder

'x64' = ${Env:ProgramFiles}
'x86' = ${Env:ProgramFiles(x86)}
'arm64' = ${Env:ProgramFiles(arm)}

That seems logical and sufficient. Correct when installed manually, but not that true anymore when the app are installed via the Windows Package Manager.

Windows Package Manager

The Windows Package Manager (aka winget) is a great tool for effortless app installation. The repository is community suported and everyone can submit update tfor new application of new version or new ways supported for the App installation.

By default it is assumed that the application will install like any regular installation, in it's obvious "Program Files" directory.

Well..
True until you start installing the app in the "user" scope (in opposition to "for all users", also called "machine scope")

The user scope is really useful for easy app install that only 1 user on the computer will use, it also help to not prompt the user for admin elevation in some cases..
In "user" scope the installation will happen in the User Profile folder, that only this user have access (aka the App will not be installed in the common "Program Files" folder)

A research dead-end ?

During my research I was already "too-many-hours deep" and at a loss, very few report about it (#968 ), and nothing about this on the official OBS plugin template or project. This is also why I discuss it here first because it seems no one else raised that error

At this point there is :

• The build fail because iscc is not found
• But Inno Setup is installed (via the Install-BuildDependencies.ps1
• Reinstall via winget command & reboot do not change naything
• This seems to work for some users, and some not
• We know this is because it is not set in the Path
• We know that manully installing it and adding to the Path fix the problem.
• There is no report of that issue (at least with iscc) before 2023

What could have changed that make this fail?

At this point I start doubting everything...

• I try with the previous major veriosn of inno setup installed and run the build (without the workaround) - same issue.
• I try the new script version - same type of error (on top fo some other but thats a different topic)
• I test on other system ( win 10, win 11, win 10 fresh install...)

I am not a developer, so it takes me a lot of time to understand what code does and mess up with it, debug and break things where I need.

At this point i pretty much ruled out that this was a "me" problem and more of a "something else" problem. It's time ot get to the script internal for real. After checking what is called out and when i end up on the Install-Build-Dependencies.ps1 script and utimately the winget command that install innosetup / cmake.

winget install --accept-package-agreements --accept-source-agreements innosetup

Nothing fancy here, this is similar to my install behavior (winget install "package moniker or Name" ) and we already confirmed earlier taht install / reinstall via winget does not help with the issue, only a full manual install (see Workaround).

After hours (wasted...) It is clear that the installation via winget does not install the applciation (Inno Setup) in the expected folder.

The fix for this Script is simple (at first sight, I have not tested / submitted it as i wrote this) : Adapt the script to add the UserProfile folder to be detected (might be the best way).

Investigating the real root cause

Fixing it and closing the research book was too easy, I went too deep to let go on it.
"Why, When, and how did this happen ? Can this be something impacting other projects or requirement as well ?"

Thank to transaprency the winget repo is public and I could trace back this change :
microsoft/winget-pkgs@078cc84
and things became clearer.

Without diving deep into winget internals, here is the TL;DR

There has been some change in the way the Inno Setup App is installed via winget.
That change add the support for installing "for all users" (=scope machine) or for the current user only" (=scope user). This is fine and a good way to let the user have this option. BUT!

That change also removed the default "scope" (machine) added back a year before microsoft/winget-pkgs@18b6b0c in favor of a more implicit one. It seems (tbc) that for winget the scope by default is:

• Non administrative Priviledge / scripts : scope=user
• Run as Admin / Elevated priviledge : scope=machine

So why not jsut "Run the build script as admin with the scope=machine" ?
Well because this does not work in the scripts (and the winget error is not helpful)

winget install --accept-package-agreements --accept-source-agreements --scope machine innosetup
Failed to open the predefined source; please report to winget maintainers.
An unexpected error occurred while executing the command:
0x80070005 : Access is denied.

Confirming the root cause of the root cause

Launching Winget from an elevated prompt (Run As Admin), this install the application in the expected common "Program Files" folder and the script can run, add the required Patht ot the environment variable and move on.

This confirm the initial root casue of that bug :
**

The winget installation package default behavior changed from scope machine to user leading to a different installation folder not supported/detecte by the Build-dependencies Script.
**

Solution ?

What not to do

• I do not think reverting the package installation behavior on winget is a solution (because you cannot install on scope machine unless you are admin, might not work for some users, etc.)
• Complaining about it without a suggested solution will bring 0 added-value to any of the projects involved
• Just expecting people to "just install it manually" will not bring adde-value either (Especially as we all gain from automated build :D)

What to do ?

Suggest update to the Install-BuildDependencies.ps1 to take the user scope isntallation folder into account.
Simplest, fastest, less intrusive change.

Feedback welcome

• Is this type of topci with process details useful to understand diagnositics logic ?
• Did you experience similar challenges ?
• Did you learn anything ?

Note : Thanks to the contributors on the different bits used on the project and referenced in this piece. This is a simple example of the difficulty to identify all the usage of an app.