first commit

2026-09-03 04:45:36 +03:00
commit d5f52cc3d3
1038 changed files with 169579 additions and 0 deletions
@@ -0,0 +1,47 @@
+---
+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.