Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on
GitHub to continue tracking issues. Bugzilla will remain
available for reference in read-only mode. We will continue to work
on open Bugzilla bugs, copy them to the new locations
as needed for follow-up, and add the new items under Related
Our sincere thanks to everyone who has contributed on this bug
tracker over the years. Thanks also for your understanding as we
make these adjustments and improvements for the future.
Please create a new report on
GitHub or Developer Community with
your current version information, steps to reproduce, and relevant error
messages or log files if you are hitting an issue that looks similar to
this resolved bug and you do not yet see a matching new report.
There is a macios test which you can run from the xamarin-macios repository with
(cd tests && (MONO_LOG_MASK=asm MONO_LOG_LEVEL=debug ./common/mac/TestProjects/ImmutableCollection_Test/ImmutableCollection_Test/bin/Debug/ImmutableCollection_Test.app/Contents/MacOS/ImmutableCollection_Test))
It builds a mac app which references System.Collections.Immutable. The mac app has mono and directly and indirectly referenced assemblies such as System.Collections.Immutable copied into it. When you build the app using the mono-2017-04 branch of xamarin-macios (the first to contain strong assembly naming rules) and run the app, it fails saying it cannot find System.Runtime:
If you look carefully, the reason this happens is because the version of System.Runtime copied into the .app is 184.108.40.206, but whoever referenced it used the 220.127.116.11 strong name at build time.
Our understanding is that this is not a bug in the assembly loaders but is a problem with the BCL we are distributing. Aleksey and Koeplinger believe this is something to do with the version numbers we assign facades. The possibility was raised that the facades are not in the remap table and this is the problem. It also might be that this is an early canary for a problem which will get more noticeable once strong name restrictions are added to all assembly loading paths.
I think https://github.com/mono/mono/pull/4730 could address this issue too
Yes, this will be fixed by that PR.
Fixed on mono master https://github.com/mono/mono/commit/25bcd22d15d47ff50503631901fb851c97bb03c7
Fixed on mono 2017-04 https://github.com/mono/mono/commit/59ffe0a31618b00da0cc08166bad0d4d33864bf6
Fixed in xamarin-macios mono-2017-04 https://github.com/xamarin/xamarin-macios/pull/1960/commits/677d5f7fc455c82b142fd3a1c3243f3ab2e01c37