Files
mxaccessgw/src/Directory.Build.props
T
Joseph Doherty 0152180929 build(tst-11): stop Windows builds stamping git stderr into InformationalVersion (NEXT-09)
MSBuildThisFileDirectory ends in a backslash, which escaped the closing quote
of the Exec command on Windows; git then failed and, because the target runs
with ContinueOnError + ConsoleToMSBuild (which mixes stderr into
ConsoleOutput), the failure text was stamped as the source revision — an
observed stamp read '0.1.2+fatal: cannot change to ...'. Append '.' to the
quoted path so the trailing separator can no longer escape the quote, and
gate SourceRevisionId on a short-SHA shape so no future git failure text can
become the revision either. Windows verification runs on windev with the
rest of this batch; macOS stamp confirmed unchanged (0.2.0+75c71ad).
2026-08-10 05:49:44 -04:00

59 lines
3.2 KiB
XML

<Project>
<PropertyGroup>
<LangVersion>latest</LangVersion>
<Nullable>enable</Nullable>
<ImplicitUsings>enable</ImplicitUsings>
<TreatWarningsAsErrors>true</TreatWarningsAsErrors>
<AnalysisLevel>latest</AnalysisLevel>
<EnforceCodeStyleInBuild>true</EnforceCodeStyleInBuild>
<Deterministic>true</Deterministic>
</PropertyGroup>
<!-- TST-11: single-source the .NET-side version for Server, Worker, Contracts, and tests
(they otherwise stamp the SDK default 1.0.0, so a deployed gateway cannot be correlated
to a release). Server/Worker/Tests stay at this default. CLI-39 (2026-08-07) moved the
published `ZB.MOM.WW.MxGateway.Contracts` and `.Client` nuget packages to 0.2.0 via an
explicit <Version> override in Contracts.csproj (MSBuild property-last-write-wins over
this Directory.Build.props default) — Server/Worker assembly stamping and the published
client packages are deliberately decoupled; a broader 0.2.0 alignment for Server/Worker
is a separate, not-yet-made decision. The git short SHA is appended to
InformationalVersion (0.1.2+<sha>) so support can map a running binary to a commit; the
query is guarded so a build outside a git checkout still succeeds. -->
<PropertyGroup>
<Version>0.1.2</Version>
</PropertyGroup>
<Target Name="StampSourceRevision"
BeforeTargets="GetAssemblyVersion;GenerateAssemblyInfo"
Condition="'$(SourceRevisionId)' == ''">
<!-- The trailing "." is load-bearing: $(MSBuildThisFileDirectory) ends in a path
separator, and on Windows that trailing backslash escapes the closing quote,
mangling the command so git's stderr got stamped as the revision (NEXT-09). -->
<Exec Command="git -C &quot;$(MSBuildThisFileDirectory).&quot; rev-parse --short HEAD"
ConsoleToMSBuild="true"
StandardOutputImportance="Low"
ContinueOnError="true"
IgnoreExitCode="true">
<Output TaskParameter="ConsoleOutput" PropertyName="_StampedGitSha" />
</Exec>
<PropertyGroup>
<!-- Accept only something that looks like a git short SHA; Exec's ConsoleOutput
mixes in stderr, so any git failure text must never become the revision. -->
<SourceRevisionId Condition="$([System.Text.RegularExpressions.Regex]::IsMatch('$(_StampedGitSha.Trim())', '^[0-9a-f]{7,40}$'))">$(_StampedGitSha.Trim())</SourceRevisionId>
</PropertyGroup>
</Target>
<!-- GHSA-2m69-gcr7-jv3q (NU1903, high) on the native SQLitePCLRaw.lib.e_sqlite3, pulled in
transitively by Microsoft.Data.Sqlite.
The suppression that used to live here said "No patched e_sqlite3 release exists yet
(2.1.11 is latest) ... Remove once an upstream fix ships." That fix HAS shipped: 2.1.12
patches this advisory within the 2.1.x line. Suppression removed 2026-07-18, so the
advisory is audited again instead of silenced.
The Server project already resolved 2.1.12, but only incidentally — transitively via
ZB.MOM.WW.Auth.ApiKeys. The pin in that project makes the floor intentional, so a change
to the Auth dependency graph cannot silently drop it back to the vulnerable 2.1.11.
Verified: forced restore with no suppression reports no NU1903. -->
</Project>