Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/WiiLink24/WiiLink24-Patcher/llms.txt

Use this file to discover all available pages before exploring further.

Building WiiLink Patcher from source is useful if you want to verify the code before running it, contribute changes, or produce a custom build for a specific platform. The project ships ready-to-use build scripts for both Windows (PowerShell) and Linux/macOS (Bash), and every step below uses tooling that is freely available.

​
Prerequisites

Before you build, make sure the following are installed on your system:
  • .NET 9 SDK — version 9.0.103 or later is required.
  • Git — to clone the repository.
Clone the repository and change into the CLI project directory: 
git clone https://github.com/WiiLink24/WiiLink24-Patcher.git
cd WiiLink24-Patcher/WiiLink-Patcher-CLI

​
Build Scripts

The recommended way to build the project is through the provided platform scripts. They handle the dotnet publish invocation and name the output binary automatically.
EnableWindowsTargeting=true is set in the project file, which allows the Windows target framework moniker (net9.0-windows10.0.22621.0) to be used when compiling on Linux or macOS. This means you can cross-compile Windows binaries from any host without a Windows machine.
# Build for all platforms
.\build.ps1

# Build for a specific platform
.\build.ps1 -b win-x64

# Build a nightly release
.\build.ps1 -n -v v213
Flags
FlagAliasDescription
-b <platform>--build <platform>Build for a specific platform identifier
-n--nightlyMark the build as a nightly release
-v <version>--version <version>Set the version string (e.g. v213 for 2.1.3)
-h--helpShow usage help and exit
When -n / --nightly is used, a version string is required via -v / --version. The version must start with v followed by a number (e.g. v100 for 1.0.0, v213 for 2.1.3).

​
Platform Identifiers

Pass one of the following identifiers to -b / --build to target a specific platform:
Platform IDDescription
win-x64Windows 64-bit
win-x86Windows 32-bit
win-arm64Windows ARM64
osx-x64macOS Intel 64-bit
osx-arm64macOS Apple Silicon
linux-x64Linux 64-bit
linux-arm64Linux ARM 64-bit
linux-armLinux ARM 32-bit
When no platform is specified, the build scripts compile for all eight platforms listed above in sequence.

​
Manual Build with dotnet CLI

If you prefer to invoke the compiler directly, use dotnet publish with the Release configuration and the desired runtime identifier. The /p:AssemblyName property controls the output executable name. 
dotnet publish -c Release -r linux-x64 /p:AssemblyName="WiiLinkPatcher_Linux-x64"
Replace linux-x64 and the assembly name suffix with the platform you are targeting. For example, to build for Windows 64-bit: 
dotnet publish -c Release -r win-x64 /p:AssemblyName="WiiLinkPatcher_Windows-x64"

​
Build Output

After a successful build, the finished executable is placed under: 
bin/Release/net9.0-windows10.0.22621.0/<rid>/publish/
For example, a linux-x64 build lands at: 
bin/Release/net9.0-windows10.0.22621.0/linux-x64/publish/WiiLinkPatcher_Linux-x64
The project is configured for single-file, trimmed publish, so the entire patcher is compiled into one self-contained executable with no runtime prerequisites on the target machine. Dependencies bundled at publish time include:
  • libWiiSharp.dll — bundled local reference for WAD manipulation
  • Newtonsoft.Json 13.0.3
  • Spectre.Console 0.47.0
  • VCDiff 4.0.1
On Windows, the build scripts automatically open the output folder in Explorer. On Linux and macOS, they attempt to open the folder with xdg-open or open respectively.
macOS arm64 binaries built on non-Apple hardware must be code-signed on Mac hardware before they will launch on Apple Silicon Macs. Build the osx-arm64 target on a real Mac and sign the binary there, or instruct end users to install Rosetta and use the osx-x64 build in the meantime.
The official CI pipeline builds all platforms automatically on every push to main. You can inspect the full workflow — including which runners are used and how artifacts are packaged — at the GitHub Actions workflow file.

Build docs developers (and LLMs) love

Get started for freeTalk to us