LOTRAOM/Directory.Build.props at dev · haterade22/LOTRAOM · GitHub

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
<Project>

  <!--
    Repository-wide build settings.

    WHY THIS EXISTS
    ===============
    "Zero Warnings — Build must produce 0 warnings. BHA0001 = broken Harmony patch at
    runtime" is listed in CLAUDE.md under Critical Rules (NEVER VIOLATE). Nothing enforced
    it, and on 2026-08-07 the mod solution built with 58 warnings. A NEVER-VIOLATE rule that
    the build does not check is a preference, not a rule.

    This is the same move as Abseil's absl/copts/copts.py: one source of truth for warning
    configuration, applied to every target, with -Werror on. Their relaxations are an explicit
    named list scoped to test targets (ABSL_GCC_TEST_ADDITIONAL_FLAGS) rather than a blanket
    silence across the whole codebase — see .editorconfig for the same split applied here.

    SCOPE
    =====
    Every .NET project in the repo picks this up: the mod, its tests, Diagnostics, the
    launcher, the servers and the tooling. All 14 launcher/server projects were verified
    warning-clean before this was switched on; the only warnings in the repo were in the mod
    solution and both are addressed below.
  -->

  <PropertyGroup>
    <!--
      Compiler warnings are errors. This is the actual enforcement of the Zero Warnings rule.

      Deliberately NOT MSBuildTreatWarningsAsErrors: that promotes warnings from the build
      engine and from NuGet restore as well, which turns a transient package-resolution
      warning on someone else's machine into a hard build failure. Abseil's -Werror is a
      compiler flag and stops at the compiler; this stops in the same place. MSB* and NU*
      warnings remain warnings and should still be driven to zero — just not by a gate that
      fires on infrastructure the repo does not control. See environment-failures.md.
    -->
    <TreatWarningsAsErrors>true</TreatWarningsAsErrors>

    <!--
      An escape list, not a silence. Anything added here must carry its reason on the line.
      Empty today; keep it that way if you can.
    -->
    <WarningsNotAsErrors></WarningsNotAsErrors>

    <!--
      CS0168 from third-party generated code, demoted to a message.

      Bannerlord.BuildResources declares an inline MSBuild task, which RoslynCodeTaskFactory
      compiles from a generated file in %TEMP%. That file has an unused `catch (Exception ex)`
      and reports CS0168 against whichever project pulled the package in. It is not our source,
      we cannot edit it, and it appears only when MSBuild's task cache is cold — which is what
      makes it worse than a steady warning: the build alternates between 0 and 1 warnings for
      no reason a reader can see, and "zero warnings" stops being a checkable claim.

      Main/LOTRAOM.csproj already carried this exact line; it is lifted here so Diagnostics
      gets it too. Suppressing diagnostics from third-party code is what Abseil does, by
      passing `per_file_copt=external/.*@-w` on every CI build.

      This does not weaken anything for our own code: .editorconfig already sets CS0168 to
      severity `none` repo-wide, so our source never reported it in the first place. Narrowing
      that .editorconfig rule to test files is tracked in the CHANGELOG as separate work.
    -->
    <MSBuildWarningsAsMessages>$(MSBuildWarningsAsMessages);CS0168</MSBuildWarningsAsMessages>
  </PropertyGroup>

  <PropertyGroup>
    <!--
      Silences MSB3270, which accounted for 114 of the 118 warning lines in the mod solution.

      The projects build as MSIL while the TaleWorlds assemblies they reference are AMD64, and
      MSBuild warns that this "may cause runtime failures". Here it cannot: the mod is loaded
      into Bannerlord's own 64-bit process, so an AMD64 reference is the only correct one, and
      the test host that loads the same assemblies is 64-bit too — the suite passes.

      This is the documented property for referencing platform-specific assemblies from a
      platform-agnostic project. It is a targeted answer to one known-benign warning, which is
      why it sits in its own PropertyGroup with its own reason rather than becoming another
      opaque number in a NoWarn list.
    -->
    <ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>None</ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>
  </PropertyGroup>

</Project>