Skip to content

fix(build): stable AssemblyVersion — cures the migration binding crash (#143) #144

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
rbuergi merged 1 commit into from
Jul 1, 2026
Merged

fix(build): stable AssemblyVersion — cures the migration binding crash (#143) #144

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 13 additions & 4 deletions Directory.Build.props
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -99,10 +99,19 @@
is the Graph MVID now, not this string, so a stable local value is safe. -->
<InformationalVersion Condition="'$(CIRun)' == 'true'">$(Version)+build.$([System.DateTime]::UtcNow.Ticks)</InformationalVersion>
<InformationalVersion Condition="'$(CIRun)' != 'true'">$(Version)</InformationalVersion>
<!-- AssemblyVersion + FileVersion = 3.0.0.<build> (numeric only — the -rc1 label is not
allowed here); changes every build for MSBuild's CopyToOutputDirectory heuristic (else
test bins hold stale framework DLLs and re-runs exercise old code). -->
<AssemblyVersion>$(_VersionNumeric).$(_BuildNumber)</AssemblyVersion>
<!-- 🔴 AssemblyVersion is STABLE (3.0.0.0) — it is the RUNTIME ASSEMBLY-BINDING identity, so it
MUST be identical across every assembly in a coherent build. `_BuildNumber` is
seconds-since-midnight/2 evaluated PER PROJECT at MSBuild time, so a time-based
AssemblyVersion drifts a few seconds (→ a different number) between projects built in the
same run. That made `Memex.Database.Migration` reference `MeshWeaver.Documentation,
Version=3.0.0.280` while the packaged DLL had a different `3.0.0.<other>` → FileNotFoundException
at startup → the migration CrashLoopBackOff'd, the schema stuck at v39, and Space creation
failed (issue #143). Binding identity must not depend on wall-clock time.
FileVersion KEEPS the per-build number — that (plus build timestamps) drives MSBuild's
CopyToOutputDirectory heuristic so test bins don't hold stale framework DLLs; it does NOT
participate in assembly binding, so it can vary freely. NodeType ABI identity uses the Graph
MVID and the self-updater keys on the image tag (ci.N) — neither uses AssemblyVersion. -->
<AssemblyVersion>$(_VersionNumeric).0</AssemblyVersion>
<FileVersion>$(_VersionNumeric).$(_BuildNumber)</FileVersion>
</PropertyGroup>
<ItemGroup>
Expand Down
Loading