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.
This makes it painful to debug typeload exceptions coming from a reflection context (i.e. MEF)
See attached project for a repro.
Created attachment 23099 [details]
Restore the nugets then build and run. It will output:
Which means there are 2 loader exceptions, both are null
The issues are related to missing Microsoft.Build.Tasks.Core, so something related to MSBuildWorkspace and another type should be in the loader exceptions.
Ugh this is embarrassing. I converted the wrong MonoError object into an exception.
Should have a fix shortly
Fixed on mono master https://github.com/mono/mono/commit/af2b3eb197868b4aa8a223260ad64373ce8605f8
Fixed on mono 2017-06 https://github.com/mono/mono/commit/a6612b4c648390665750353b99199c3065ba8cbc
Fixed on mono 2017-04 https://github.com/mono/mono/commit/e8e38c4370e6b4b3d658cbb32b3acce974e5d65d
(The master commit also removed a stale file from System.Reflection)
Did this fix make it into the 188.8.131.52 beta version? I am still seeing this problem with that version, which was released 18 days ago (the commits were 20 days ago, so I'm a bit at a loss trying to track whether or not the fix went into the .196 release).
I just confirmed that the problem has been solved in the current mono/master source tree (just had to build mono from source and execute the same executable).
Apparently, the fix did not make it into .196.
Looking at the git hashes, the fix is not in 184.108.40.206, it is in 220.127.116.11, however.