Sluijsens
9ab30fe2a6
Unit suites already passed individually; this is the full solution together plus what none of them could check alone: two real hosts talking to each other, a slave API key encrypted by one process and decrypted by the next one after a restart, and headers landing on actual static files instead of a simulated response.
2.5 KiB
2.5 KiB
Build Instructions
Prerequisites
- Build Tool: .NET 10 SDK, Node.js 20+, pnpm 9+
- Dependencies: NuGet packages restore automatically on build; frontend needs
pnpm install - Environment Variables: none required for a plain build/test pass.
appsettings.local.json(backend) and.env.local(frontend) are only needed to actually run a host against a real database — seeREADME.md - System Requirements: any OS .NET 10 and Node 20 support. A SQL Server instance (e.g. via Podman/Docker, per
README.md§ "Database opstarten") is only needed to run a host, not to build or run the unit-test suites
Build Steps
1. Install Dependencies
dotnet restore SlpModularCms.sln
cd frontend
pnpm install --frozen-lockfile
2. Configure Environment
No environment configuration is needed for build or unit tests. dotnet build/dotnet test do not require a database connection.
3. Build All Units
dotnet build SlpModularCms.sln -c Release
4. Verify Build Success
- Expected Output:
Build succeeded. 0 Error(s). - Build Artifacts: per-project
bin/Release/net10.0/output - Common Warnings:
NU1510("will not be pruned") onMicrosoft.Extensions.*.AbstractionsandSystem.Security.Cryptography.Xml— pre-existing, informational, not a build defect. NoNU1903(vulnerability) warnings should appear; if one does, a package has drifted below its pinned patched version (see FR-22 inrequirements.md)
Troubleshooting
Build Fails with Dependency Errors
- Cause: stale NuGet cache after a package pin change
- Solution:
dotnet nuget locals all --clearthendotnet restore SlpModularCms.sln
Build Fails with Compilation Errors
- Cause: none expected at this stage — all 7 units were individually build-verified during Code Generation (Step 13.5)
- Solution: if one appears, it indicates a cross-unit conflict (e.g. two units editing the same file inconsistently) that per-unit builds could not catch; check
git log --onelinefor the unit commits and diff the affected file
Running Two Hosts Concurrently Locks the Shared Core Build
- Cause:
SlpModularCms.ApiandSlpModularCms.Api.Slaveboth referenceSlpModularCms.Core. Startingdotnet runfor both at the same moment races onSlpModularCms.Core's build output directory - Solution: start one host, wait for it to finish building, then start the second — this only affects local
dotnet run, notdotnet build/dotnet teston the full solution