Development setup

Everything needed to work on REDbridge, in order. A fresh machine should be able to follow this top to bottom. The shared tools (Git, Python, winget) are the same as in REDnode’s setup guide.

Reference machine: Windows 11 Home (build 26200), 16 GB RAM, no administrator session available.

1. Base tools

Git needs long paths on Windows, because WolvenKit’s generated type files exceed the default limit. Without it a clone stops with “Filename too long” and leaves the checkout incomplete.

git config --global core.longpaths true

2. .NET SDK

WolvenKit targets .NET 10 (global.json asks for SDK 10.0.302 or a later feature band).

The per-user install uses Microsoft’s dotnet-install.ps1. It needs no UAC prompt, so it works over a remote session. It puts the SDK in %LOCALAPPDATA%\Microsoft\dotnet, about 770 MB.

$dl = "$env:TEMP\dotnet-install"; New-Item -ItemType Directory -Force $dl | Out-Null
Invoke-WebRequest https://dot.net/v1/dotnet-install.ps1 -OutFile "$dl\dotnet-install.ps1"
$root = "$env:LOCALAPPDATA\Microsoft\dotnet"
& "$dl\dotnet-install.ps1" -Channel 10.0 -InstallDir $root -NoPath
# make it the default dotnet for this user; new shells only
[Environment]::SetEnvironmentVariable('Path', "$root;" + [Environment]::GetEnvironmentVariable('Path','User'), 'User')
& "$root\dotnet.exe" --list-sdks

Do not set DOTNET_ROOT as a user or machine environment variable. Every .NET program on the machine then looks only in that folder, and the per-user folder has only .NET 10: Vortex’s .NET 9 check failed that way on the owner’s laptop. Set it per process instead (next sections).

A machine-wide dotnet.exe in C:\Program Files\dotnet may exist as a runtime only. It does not see the per-user SDK, so the per-user folder must come first on PATH. With administrator rights, winget install --id Microsoft.DotNet.SDK.10 -e is the simpler route.

3. WolvenKit source

REDbridge builds against WolvenKit’s headless libraries at a pinned commit, wired as a git submodule with project references. WolvenKit’s binaries are never committed or redistributed by this repo; a build produces them.

Headless projects: WolvenKit.Core, WolvenKit.Common, WolvenKit.RED4, WolvenKit.Modkit. The WPF projects (WolvenKit, WolvenKit.App) are not needed and not built.

Building the libraries

The submodule is not built on its own. Building the bridge (section 5) builds Core, RED4, Common and Modkit from external/WolvenKit as project references. After a plain git clone, fetch the submodule first:

git submodule update --init

Build one project at a time with parallelism off and without the shared compiler server: the parallel build was killed for lack of memory on the 16 GB laptop, and the single-threaded build is fast anyway. These flags are already in the bridge build command in section 5.

What the Modkit output contains

WolvenKit.Modkit/bin/Release/net10.0: 129 MB, 25 files. This is the set a bridge that references all four libraries has to ship, before trimming.

The ClearScript V8 native library (ClearScriptV8.win-x64.dll) is not in this build output. It is expected to appear on a runtime-specific publish (dotnet publish -r win-x64). Unverified until C5, when the script host is built.

4. Repository and GitHub

git clone --recurse-submodules https://github.com/Edgemodders/REDbridge.git
cd REDbridge
git config user.name  "CyberbuildsAI"
git config user.email "340969962+CyberbuildsAI@users.noreply.github.com"

The submodule is added in C1. Until then there is nothing to build in this repo.

5. Building and running the bridge

From clone to a working bridge. Verified on both reference machines on 2026-10-11.

git clone --recurse-submodules https://github.com/Edgemodders/REDbridge.git
cd REDbridge
npm run build:full                              # dotnet restore, then dotnet build
npm run probe -- "<Cyberpunk 2077 folder>"      # runs tools\probe.py against the Release build

Day to day:

Notes:

• git pull and a plain git clone do not fetch submodule contents; npm run update and git submodule update --init do. WolvenKit is large, so the first fetch takes a few minutes. If it stops with “Filename too long”, run git config --global core.longpaths true and repeat.
• The build compiles WolvenKit’s Core, RED4, Common and Modkit from the submodule, then the bridge: about 45 s to a minute single-threaded. -v q hides the 394 nullability warnings from WolvenKit’s RED4 project, which are expected. Output: src\REDbridge\bin\Release\net10.0\REDbridge.exe with about 200 MB beside it.
• The probe starts the bridge with the game folder, loads the archive indexes (the game does not need to be running) and calls every method: list and search, CR2W to JSON and back with a byte comparison, texture to PNG, hashing. About 5 to 8 s. Output goes to probe-out, which git ignores.
• Do not build the WolvenKit projects on their own with paths like WolvenKit.Modkit/WolvenKit.Modkit.csproj; those paths exist only inside external\WolvenKit, and the bridge build covers them.
• The npm scripts run dotnet through tools/dotnet.mjs, which prefers DOTNET_ROOT, then the per-user SDK in %LOCALAPPDATA%\Microsoft\dotnet, then dotnet on PATH. So the per-user install from section 2 works without changing PATH. The probe still needs DOTNET_ROOT for the per-user runtime (next section).
• The REDcode extension checks the bridge’s version at startup and says when the bridge is older than it needs. npm run update here fixes that.

.NET runtime location

With a machine-wide SDK (winget install --id Microsoft.DotNet.SDK.10 -e) nothing more is needed. With the per-user SDK from section 2, REDbridge.exe needs DOTNET_ROOT in the environment of whatever starts it, or it fails to find a runtime. Set it for that process only, never for the user (see section 2):

$env:DOTNET_ROOT = "$env:LOCALAPPDATA\Microsoft\dotnet"   # this shell only

REDcode (redcode.dotnetRoot) and REDdeck (reddeck.dotnetRoot, which defaults to the per-user folder when it has .NET 10) pass it to the bridge process themselves.

Oodle

On first run the bridge copies the game’s oo2ext_7_win64.dll to %LOCALAPPDATA% and loads it from there, as WolvenKit does, and logs “Using the game’s Oodle library”. Without it WolvenKit falls back to the bundled kraken.dll and warns that results may differ.

6. Docs site and brand images

The site at https://edgemodders.github.io/REDbridge/ is built by .github/workflows/pages.yml on every push to main. Settings > Pages > Source must be GitHub Actions.

.\tools\brand\render.ps1   # banner, social preview, icon, badges