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.
Created attachment 16677 [details]
Repro Solution Project
The attached repro project fails running unit-tests with a non-descript "Internal error" in the test results pane. Using Xamarin Cycle 6 latest stable with this same project does work as it should (test passes).
Workaround: Apparently this can be worked around by setting the NunitRepro project's reference to System.Net.Http.dll to _not_ " Local Copy" and adding an app.config to NunitRepro project with the following content:
<?xml version="1.0" encoding="utf-8"?>
<assemblyIdentity name="System.Net.Http.Primitives" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-188.8.131.52" newVersion="184.108.40.206" />
<assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-220.127.116.11" newVersion="18.104.22.168" />
I consider this bug a regression from Release Cycle 6, likely an issue in Mono or in the build engine to do with assembly loading / reference resolution.
Environment used to test:
Xamarin Studio Business
Version 6.0.1 (build 9)
Installation UUID: 3cbf1b60-0560-4942-8de5-aedf17c5251e
Mono 4.4.1 (mono-4.4.0-branch-c7sr0/4747417) (64-bit)
GTK+ 2.24.23 (Raleigh theme)
Package version: 404010000
The runtime is crashing: https://gist.github.com/slluis/d218dddb0bba878e8d2f6384afc80cae
The crash was fixed in mono 4.6.0.
The issue in this case is that result of the build process includes an invalid assembly with no IL.
Marek, could this be the current issue we're experiencing?
Alexander, can you work out if it's netstandard?
This has nothing to do with netstandard. Import part is XS step
Copying file from '/Users/xxx/mono/lib/mono/4.5-api/System.Net.Http.dll' to '/Users/xxx/Downloads/NunitRepro/bin/Debug/System.Net.Http.dll'
which is wrong as 4.5-api is only api dll so XS (or xbuild) has to translate this path when user check 'Local Copy' on assembly reference
fwiw VS doesn't translate the path either, it simply copies the reference assembly as well. It seems to work on .NET because there the GAC wins first when loading an assembly.
A feature in the runtime like https://bugzilla.xamarin.com/show_bug.cgi?id=39047 to prevent loading of ref asms would make this easier to diagnose.
In any case, it is not an XS issue. XS does not copy the assemblies.
This is due to runtime not recognising special ReferenceAssemblyAttribute
With sample like
// compile with -t:lib x-lib
public class XX
// compile with -r:x-lib.dll
public class MM
public static void Main ()
new XX ();
Unhandled Exception: System.BadImageFormatException: Could not load file or assembly 'x-lib, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. Reference assemblies should not be loaded for execution. They can only be loaded in the Reflection-only loader context. (Exception from HRESULT: 0x80131058) ---> System.BadImageFormatException: Cannot load a reference assembly for execution.
--- End of inner exception stack trace ---
Mono loads the assembly.
Note: This is just simple example. The intended behaviour is to skip ReferenceAssembly whenever they appear in execution loading binder.
*** Bug 39047 has been marked as a duplicate of this bug. ***
Fixed on mono master with commit c8287cd329b33b18309ca038c1b7b4be957faf39
Fixed on mono mono-4.6.0-branch with commit bdce6068d50f0db1a69687cc883bf1bf519f25fa
since C8 is now closed, and is shipping this week, I will move this but to the C8SR1 milestone. We'll continue working on the issue seeking it's resolution as soon as possible.
*** Bug 43449 has been marked as a duplicate of this bug. ***
Fixed on mono master https://github.com/mono/mono/commit/bb4b0ff4fc2877a3fd5d784348368ec832fb82c7
Fixed on mono mono-4.8.0-branch
Hit a deadlock in mono_assembly_load_reference (). Needs some followup work.
Follow up work to get rid of deadlock issue from Comment 14
Haven't seen any more issues since Comment 15. I'm gonna say this one is finally done.