Fix assembly count when satellite assemblies are present

[grendello]

NOTE: should be backported to net8

Fixes: #8789

The old method of satellite assembly counting relied on the
RelativePath MSBuild item metadata, which appears to have gone
missing somewhere in .NET8+. Update the code to check for presence
of the following metadata, in order given, to determine assembly's
culture, if any:

• Culture
• RelativePath
• DestinationSubDirectory

Failure to count satellite assemblies can, and sometimes will,
result in a segfault since we generate a number of native code
arrays based on the assembly count and the runtime assumes that
what the build told it is true.

[akoeplinger]

nit: it'd be pretty weird if Culture contained any slashes, might be ok to return it unmodified nevermind I just saw a binlog that had a Culture with a slash :D

[grendello]

I learned the hard way... :)

[akoeplinger]

So I checked the history and there was some discussion around RelativePath here: #7823 (review)

Not sure how that would've been set for satellite assemblies though, I can't find where it'd be set.

I'm only seeing Culture (for satellite assemblies in the current project) or DestinationSubDirectory (for satellites from referenced projects) being set.

Instead of checking every assembly can you only look at the satellite assemblies? you're already passing those to the GeneratePackageManagerJava task

[grendello]

Yeah, we possibly should do that, but not until after #8478 is merged (it changes a lot in this area, and all the optimizations and tweaks to the code should be done only after the merge)

[jonpryor]

Is there any way to add a unit test for this?

[grendello]

Is there any way to add a unit test for this?

We have tests that check the presence in the archive after build, but we have no on-device tests which actually use satellite assemblies it seems. I think it would be good to add a test, but I'd like to do it in a separate PR, which will implement better build-time handling of discrepancies.

[dellis1972]

Is there any way to add a unit test for this?

We have tests that check the presence in the archive after build, but we have no on-device tests which actually use satellite assemblies it seems. I think it would be good to add a test, but I'd like to do it in a separate PR, which will implement better build-time handling of discrepancies.

The Localisation tests should use Satallite assemblies

[grendello]

Is there any way to add a unit test for this?

We have tests that check the presence in the archive after build, but we have no on-device tests which actually use satellite assemblies it seems. I think it would be good to add a test, but I'd like to do it in a separate PR, which will implement better build-time handling of discrepancies.

The Localisation tests should use Satallite assemblies

Hm, interesting. They should have failed without this fix... Maybe we were just lucky with them, as this error may not happen if the satellite assembly hashes are in the upper part of the sorted array of hashes we generate at build time.

[dellis1972]

Hm, interesting. They should have failed without this fix... Maybe we were just lucky with them, as this error may not happen if the satellite assembly hashes are in the upper part of the sorted array of hashes we generate at build time.

The tests add a bunch of resx files via https://github.com/xamarin/xamarin-android/blob/main/tests/MSBuildDeviceIntegration/Tests/LocalizationTests.cs#L49. That should generated satallite dlls.
Perhaps it needs updating to add the types of files that cause the problem. Is it satallites from library projects that cause the issue?

[grendello]

@dellis1972 Unfortunately, it's a bit of a gamble when/if that happens. At build time we generate an array of xxHash hashes using several forms of assembly names as input (with and without extension) and then sort that array in ascending order. At run time, we search through that array with binary search. If the number of entries in that array is smaller than what we counted at build time, we may have a crash when binary search tries to access entries outside (above) that range. But if we're lucky, some assemblies might not be loaded/used during the time the test/app runs and if the used/loaded assemblies have their hashes fall within the actual hash array limits, we won't get the crash.

A correct test for this would be one where we're sure that all of the assemblies, including the satellite ones, are loaded on every run. The test would have to change the UI culture during single execution to make sure all satellite assemblies are loaded. I will work on a test like this, but only after the per-RID PR is merged, since it touches the way satellite assemblies are handled and I'd like to add a way to ensure, at build time, that we have the correct number of entries in each of the arrays. I don't want to add it to #8478 which is already big enough, but I also don't want to keep rebasing it on top of main changes too much.

[jonpryor]

As #8478 has been merged, this PR (#8790) is no longer directly applicable to main.

Please update the PR to target the release/8.0.2xx branch.

[grendello]

@jonpryor I think it might be good to merge it into main as well. I will need to open a separate PR for the net8 branch, as the changes don't apply cleanly