---
kind: build_system
name: .NET Solution Build & CI Pipeline
category: build_system
scope:
    - '**'
source_files:
    - ClassicAssist.sln
    - appveyor.yml
    - azure-pipelines.yml
    - .github/workflows/staging.yml
    - .github/workflows/linux.yml
    - ClassicAssist/ClassicAssist.csproj
    - ClassicAssist.Avalonia/ClassicAssist.Avalonia.csproj
    - ClassicAssist.Shared/ClassicAssist.Shared.csproj
---

The project uses a Visual Studio solution (ClassicAssist.sln) composed of multiple .NET projects built with MSBuild and the modern SDK-style .csproj format. The build system targets both Windows (WPF) and cross-platform (Avalonia) UI shells, sharing a netstandard2.0 core library.

Solution structure:
- ClassicAssist.Shared — shared runtime (netstandard2.0), consumed by all other projects; contains game data, networking, MVVM base classes, and macro command implementations.
- ClassicAssist — WPF client host targeting net48, references Shared plus native cuoapi.dll.
- ClassicAssist.Avalonia — Avalonia desktop shell targeting net48 and netcoreapp3.1; conditionally pulls Linux/macOS native assets when building under the Linux configuration.
- ClassicAssist.Launcher / ClassicAssist.Updater — standalone WPF helpers for launching ClassicUO clients and updating the app from GitHub releases.
- ClassicAssist.Tests — MSTest suite exercising agents, filters, macros, packets, etc.
- Tools/ExportCommands — documentation generator that reflects macro commands into Markdown files.

Configurations and target frameworks:
- Four configurations are defined across the solution: Debug, Release, Develop (adds DEVELOP constant), and Linux (enables Linux-specific packages like HarfBuzzSharp.NativeAssets.Linux).
- All binaries are emitted to Output/ at the repository root; the WPF/Avalonia outputs land in Output/net48/.
- Versioning is computed per-project via MSBuild expressions: 0.3.<days-since-2020-07-03>.<build-number>, giving an ever-increasing patch component without manual bumping.

CI pipelines:
- AppVeyor (appveyor.yml) — builds on Visual Studio 2019 against master, restores NuGet packages, builds the solution, runs ExportCommands.exe to regenerate docs, writes a MANIFEST.json with file hashes, pushes updated wiki Markdown to a separate GitHub wiki repo, then publishes the Output\net48 folder as a GitHub Release artifact tagged with the computed version.
- Azure Pipelines (azure-pipelines.yml) — triggered on the devel branch, restores NuGet, builds with MSBuild, runs VSTest, and publishes Output/net48 as a container artifact.
- GitHub Actions (.github/workflows/) — staging.yml builds the solution on windows-latest using MSBuild and runs tests against ClassicAssist.Tests.dll; linux.yml builds with dotnet build -c Linux on a matrix of macos-latest, ubuntu-latest, and windows-latest, uploading artifacts per OS.

Native dependencies and packaging:
- cuoapi.dll (and zlib32.dll / zlib64.dll) are shipped as checked-in native DLLs referenced via HintPath and copied to output.
- Avalonia's macOS/Linux native libraries are pulled from NuGet and copied into the output directory via a custom MSBuild CopyNativeLibs target when building the Avalonia project under the Linux configuration.

Conventions developers should follow:
- Add new configurations only through the existing Debug|Release|Develop|Linux set; avoid introducing new platform targets outside what CI already covers.
- Keep all build outputs under Output/ so CI artifact publishing paths remain valid.
- Use the SDK-style PackageReference pattern for NuGet dependencies rather than packages.config.
- When adding native libraries, reference them via HintPath and ensure they are copied to output or handled by a custom target.
- Do not manually edit version numbers — rely on the MSBuild date-based expression so AppVeyor can compute a unique tag.