Skip to content

[Java.Interop] Keep transitive System.IO.Hashing out of tool output#11969

Open
simonrozsival wants to merge 1 commit into
mainfrom
dev/simonrozsival/fix-sourcelink-system-io-hashing
Open

[Java.Interop] Keep transitive System.IO.Hashing out of tool output#11969
simonrozsival wants to merge 1 commit into
mainfrom
dev/simonrozsival/fix-sourcelink-system-io-hashing

Conversation

@simonrozsival

Copy link
Copy Markdown
Member

Problem

Microsoft.SourceLink.GitHub 10.0.300 is a build-time-only package (referenced with PrivateAssets="All"), but its dependency Microsoft.Build.Tasks.Git 10.0.300 pulls System.IO.Hashing 10.0.8 in as a runtime asset.

JI tools/libraries that reference System.IO.Hashing only transitively (via SourceLink) therefore ship a System.IO.Hashing 10.0.8 assembly:

  • class-parse, generator, jcw-gen, logcat-parse, param-name-importer
  • Java.Interop.Tools.Generator, Java.Interop.Tools.Maven

These are staged into the shared .NET for Android SDK pack tools/ directory alongside the build tasks (Xamarin.Android.Build.Tasks, Microsoft.Android.Build.BaseTasks), which reference System.IO.Hashing 10.0.9 directly. System.IO.Hashing bumps its AssemblyVersion every patch (10.0.0.8 vs 10.0.0.9), so the single System.IO.Hashing.dll that wins in tools/ can mismatch what the build tasks were compiled against, producing at build time:

error XACRP7000: System.MissingMethodException: Method not found:
  'Int32 System.IO.Hashing.Crc64.Hash(ReadOnlySpan<Byte>, Span<Byte>)'.
   at Microsoft.Android.Build.Tasks.Files.HashBytes(Byte[])
   at Xamarin.Android.Tasks.AndroidComputeResPaths.RunTask()

Because AndroidComputeResPaths runs in every app build, this breaks the affected builds (observed intermittently on Windows CI lanes — the failure depends on which System.IO.Hashing.dll copy wins in the shared tools/ directory).

The existing <PackageReference Update="System.IO.Hashing" Version="10.0.9" /> pins do not cover these projects, because Update= only applies to packages a project references directly — these projects reference it only transitively.

Fix

These tools do not use System.IO.Hashing themselves — it only rides in as an unused runtime asset of build-time SourceLink. Exclude SourceLink's runtime assets so the unused assembly is never emitted:

<PackageReference Update="Microsoft.SourceLink.GitHub" Version="10.0.300" ExcludeAssets="runtime" />

Verified locally: with this change, System.IO.Hashing resolves to the empty lib/**/_._ placeholder (no runtime DLL) for the affected exes and libraries (both net10.0 and netstandard2.0).

  • Source linking is unaffected — it runs via SourceLink's build/buildTransitive assets, not runtime assets.
  • The build tasks that legitimately use System.IO.Hashing are unaffectedMicrosoft.Android.Build.BaseTasks has a direct <PackageReference Include="System.IO.Hashing" /> (→ 10.0.9), which an ExcludeAssets on SourceLink does not touch.

Follow-up

external/xamarin-android-tools needs the same change for Xamarin.Android.Tools.AndroidSdk, which floats to System.IO.Hashing 10.0.8 by the identical transitive-SourceLink path. That is a separate upstream (dotnet/xamarin-android-tools) change + submodule bump.

Notes

This is a pre-existing, latent issue on main (not specific to any feature branch); the version-pin files are unchanged. It surfaces intermittently depending on tools/-directory copy order.

Microsoft.SourceLink.GitHub 10.0.300 is a build-time only package
(PrivateAssets="All"), but its dependency Microsoft.Build.Tasks.Git
10.0.300 brings System.IO.Hashing 10.0.8 in as a runtime asset. JI tools
and libraries that reference System.IO.Hashing only transitively
(class-parse, generator, jcw-gen, logcat-parse, param-name-importer,
Java.Interop.Tools.Generator, Java.Interop.Tools.Maven) therefore ship a
System.IO.Hashing 10.0.8 assembly.

These are staged into the shared .NET for Android SDK pack tools/
directory alongside the build tasks (Xamarin.Android.Build.Tasks,
Microsoft.Android.Build.BaseTasks) which reference System.IO.Hashing
10.0.9 directly. Because System.IO.Hashing bumps its AssemblyVersion on
every patch (10.0.0.8 vs 10.0.0.9), the single System.IO.Hashing.dll that
wins in tools/ can mismatch what the build tasks were compiled against,
producing MissingMethodException on System.IO.Hashing.Crc64.Hash at build
time (surfaced as error XACRP7000 from AndroidComputeResPaths via
Files.HashBytes).

Since these tools do not use System.IO.Hashing themselves, exclude
SourceLink's runtime assets so the unused 10.0.8 assembly is never
emitted. Source linking is unaffected (it runs via SourceLink build
assets, not runtime assets); the build tasks keep their direct 10.0.9
reference.

Note: external/xamarin-android-tools needs the same change for
Xamarin.Android.Tools.AndroidSdk, which floats to 10.0.8 the same way.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot AI review requested due to automatic review settings July 3, 2026 09:13

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Adjusts Java.Interop’s shared build configuration so build-time-only SourceLink dependencies don’t leak runtime assemblies into the produced tool outputs, preventing intermittent System.IO.Hashing assembly-version collisions in the shared .NET for Android SDK tools/ directory.

Changes:

  • Excludes runtime assets from Microsoft.SourceLink.GitHub via a central PackageReference Update=... to prevent transitive System.IO.Hashing from being emitted.
  • Adds detailed in-file documentation explaining the failure mode (10.0.0.8 vs 10.0.0.9 AssemblyVersion) and why the exclusion is safe.
Show a summary per file
File Description
external/Java.Interop/Directory.Build.targets Centralizes ExcludeAssets="runtime" for Microsoft.SourceLink.GitHub to keep transitive System.IO.Hashing out of tool outputs and avoid runtime assembly conflicts.

Copilot's findings

  • Files reviewed: 1/1 changed files
  • Comments generated: 0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants