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.