|Summary:||ReflectionTypeLoadException.LoaderExceptions has null exceptions|
|Product:||[Mono] Runtime||Reporter:||Marius Ungureanu <marius.ungureanu>|
|Component:||Reflection||Assignee:||Aleksey Kliger <aleksey>|
|Severity:||normal||CC:||kumpera, masafa, mennodeij, mono-bugs+runtime|
|Tags:||Is this bug a regression?:||---|
|Last known good build:|
Description Marius Ungureanu 2017-06-24 16:52:04 UTC
This makes it painful to debug typeload exceptions coming from a reflection context (i.e. MEF) See attached project for a repro.
Comment 1 Marius Ungureanu 2017-06-24 16:54:56 UTC
Created attachment 23099 [details] Repro Restore the nugets then build and run. It will output: Microsoft.CodeAnalysis.Workspaces.Desktop.dll 2 null null Which means there are 2 loader exceptions, both are null
Comment 2 Marius Ungureanu 2017-06-24 18:32:10 UTC
The issues are related to missing Microsoft.Build.Tasks.Core, so something related to MSBuildWorkspace and another type should be in the loader exceptions.
Comment 3 Aleksey Kliger 2017-06-26 19:20:21 UTC
Ugh this is embarrassing. I converted the wrong MonoError object into an exception. Should have a fix shortly
Comment 4 Aleksey Kliger 2017-06-27 14:50:58 UTC
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)
Comment 5 Menno 2017-07-17 08:58:42 UTC
Did this fix make it into the 220.127.116.11 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).
Comment 6 Menno 2017-07-17 13:13:13 UTC
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.
Comment 7 Aleksey Kliger 2017-07-17 14:28:38 UTC
Looking at the git hashes, the fix is not in 18.104.22.168, it is in 22.214.171.124, however.