Microsoft.OpenApi.OData.Reader.dll ships unversioned (0.0.0.0) since the 2026-01-16 releases

Comienza con src/Build.props, Directory.Build.props y la reciente eliminación de los archivos de versionado de herramientas; revisa el argumento de versión comentado en .github/workflows/ci-cd.yml. Reproduce el problema inspeccionando un .nupkg publicado con los comandos de PowerShell proporcionados y, después, verifica que los atributos de versión elegidos estén estampados en la DLL empaquetada sin cambiar involuntariamente la compatibilidad de AssemblyVersion.

Summary

Since the releases published on 2026-01-16, the Microsoft.OpenApi.OData.Reader.dll assembly inside the
Microsoft.OpenApi.OData package carries no version information at all — AssemblyVersion, Win32
FileVersion and ProductVersion are all 0.0.0.0, and there is no informational-version attribute. The
package version exists only in the NuGet metadata, never in the binary.

Every currently supported line is affected, including the v1 line, so there is no published version that
both is current and carries a version stamp.

Affected versions

Measured by reading the assembly identity out of each .nupkg (AssemblyName.GetAssemblyName for
AssemblyVersion, FileVersionInfo for FileVersion):

Version	Published	AssemblyVersion	FileVersion
1.7.5	2025-03-31	1.0.9.0	1.0.9.60331
2.0.0	2025-07-10	1.0.9.0	1.0.9.60710
3.0.0	2025-11-12	1.0.9.0	1.0.9.61112
3.1.0	2026-01-16	0.0.0.0	0.0.0.0
2.1.0	2026-01-16	0.0.0.0	0.0.0.0
2.2.0 / 2.2.1	2026-03-19 / 2026-04-14	0.0.0.0	0.0.0.0
3.2.0 / 3.2.1	2026-03-19 / 2026-04-14	0.0.0.0	0.0.0.0
1.7.6	2026-04-14	0.0.0.0	0.0.0.0

Last stamped release: 3.0.0. First unstamped: 3.1.0 and 2.1.0, both 2026-01-16.

Likely cause

The version attributes used to come from a custom MSBuild chain rather than from the SDK:

• src/Build.props sets <GenerateAssemblyInfo>false</GenerateAssemblyInfo> (added Oct 2019), with the
  comment "Disable GenerateAssemblyInfo to use the auto-generated AssemblyInfo.cs".
• The attributes themselves were supplied via tool/Build.props → tool/versioning.props +
  tool/After.Common.targets, which hardcoded 1.0.9 and computed the revision as a build-date code —
  matching the observed 1.0.9.6MMdd pattern above.
• Commit 0fb398e9 (PR #766, "ci: removes outdated compilation files causing failure", merged
  2026-01-06) deleted tool/versioning.props, tool/After.Common.targets, tool/Build.props and
  tool/Before.Common.targets, and removed the import from the root Build.props — but left
  GenerateAssemblyInfo=false in place.

With assembly-info generation still suppressed and the custom chain gone, nothing emits version
attributes. Directory.Build.props's <Version> reaches only the NuGet package version. The first
releases after that commit are the first unstamped ones, and main today would still build unstamped.

For contrast, the sibling repo microsoft/OpenAPI.NET does not set GenerateAssemblyInfo, so it defaults
to true and Microsoft.OpenApi stamps correctly (3.9.0 → 3.9.0.0). The two repos do not appear to share
build infrastructure.

Reproduction

# any version from 2026-01-16 onward
nuget install Microsoft.OpenApi.OData -Version 3.2.1 -OutputDirectory .
$dll = "Microsoft.OpenApi.OData.3.2.1\lib\net8.0\Microsoft.OpenApi.OData.Reader.dll"
[System.Reflection.AssemblyName]::GetAssemblyName((Resolve-Path $dll)).Version   # 0.0.0.0
[System.Diagnostics.FileVersionInfo]::GetVersionInfo((Resolve-Path $dll))        # FileVersion 0.0.0.0

Repeat with -Version 3.0.0 to see 1.0.9.0 / 1.0.9.61112.

Impact

• Windows Installer upgrades can lose the file. MSI never overwrites a file with a lower or equal
  version. A DLL whose version reads 0.0.0.0 is therefore skipped on every upgrade: the installed copy
  is never refreshed however stale it becomes, and if the file's component identity changes between
  releases it can be removed by RemoveExistingProducts and never reinstalled — i.e. the file disappears
  from the upgraded installation. Any product that ships this assembly inside an MSI has to work around
  this in its installer authoring (e.g. by making the file a companion of another versioned file).
• Support diagnosability. A deployed binary no longer identifies which release it came from, so
  "which version is actually installed?" cannot be answered from the file itself.
• Tooling that inventories or compares assembly/file versions (patch pipelines, SBOM/asset scanners,
  drift detection) sees 0.0.0.0 for every release.

Suggested fix

Either restore stamping, or let the SDK do it:

• Remove <GenerateAssemblyInfo>false</GenerateAssemblyInfo> from src/Build.props so the existing
  <Version> in Directory.Build.props flows into AssemblyVersion / AssemblyFileVersion /
  AssemblyInformationalVersion; or
• keep generation suppressed and pass the version explicitly (the commented-out /p:Version= in
  .github/workflows/ci-cd.yml suggests this was once the intent), or reinstate an equivalent of the
  deleted versioning.props.

The stale comment in src/Build.props referring to the now-deleted machinery is worth removing either way.

One caution on AssemblyVersion specifically: it was pinned at a constant 1.0.9.0 on every stamped
release, so it never tracked the package version. Changing it now would alter the strong-name identity and
break existing binding redirects for consumers, which may not be desirable in a patch release. Stamping
AssemblyFileVersion and AssemblyInformationalVersion while leaving AssemblyVersion deliberately
stable would resolve the practical problems above without that breaking change — though aligning
AssemblyVersion on a major release would be reasonable too. Maintainers' call.

Environment

• Package: Microsoft.OpenApi.OData (verified across 1.7.0–3.2.1, listed and unlisted)
• Assembly inspected: lib/*/Microsoft.OpenApi.OData.Reader.dll from the published .nupkg
• Versions read with System.Reflection.AssemblyName and System.Diagnostics.FileVersionInfo