Resolving System.TypeLoadException RRS feed

  • Question

  • My application loads dlls and runs some reflection on them

    Assembly asm = Assembly.LoadFrom("full/path/to/my.dll");
    var types = asm.GetExportedTypes(); // Throws System.TypeLoadException
    //Could not load type 'System.Runtime.InteropServices.StandardOleMarshalObject' from assembly 'System, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089'.

    and I get a System.TypeLoadException. I'm not sure why the dll (in this case Mono's System.Windows.Form) is _exporting_ that, but it seems that I can't even inherit from StandardOleMarshallObject, I mean, it compiles, but then at runtime fails to load the type:

    class Whatever : System.Runtime.InteropServices.StandardOleMarshalObject
        public Whatever(){}
    var x = new Whatever();

    According to the documentation StandardOleMarshallObject lives in 

    System.dll, System.Runtime.InteropServices.dll

    Both of which I can confirm reside in /usr/local/share/dotnet/shared/Microsoft.NETCore.App/2.2.3

    I'm using .net core 2.0 on OSX, fwiw.

    What can I do to resolve the load error?



    Wednesday, August 21, 2019 8:03 AM

All replies

  • What can I do to resolve the load error?

    Try running the Fusion Log Viewer (FUSLOGVW.EXE). You can launch it from a Visual Studio command prompt, but make sure to run it as Administrator, otherwise its options will be disabled on screen.

    From the Fuslogvw screen, enable the Log.

    Then run your program until it produces the load error.

    Go back to Fuslogvw and click Refresh. It should display a list of successful loads and/or errors (depending on the options that you enabled). Double-click on an error, and it will open a screen explaining what exactly it was trying to load and where it looked for it. This should give you some helpful information for solving your issue.

    Wednesday, August 21, 2019 10:44 AM
  • You're trying to use mono's assembly? That is probably built against a different version of the framework than your code. When the runtime tries to load the system assembly it will fail because the system assembly is already loaded. Note that this may be caused by the LoadFrom context you're using as well.

    Since you mentioned .NET Core I'm going to wager you're trying to load a .NET Framework assembly (mono's stuff) in a .NET Core app which probably isn't going to work out well. There are thunks and other stuff that .NET Core does to get things to work and I doubt this is a valid use case for it. You should post your question in the CoreFx repo to get their assistance.

    Michael Taylor

    Wednesday, August 21, 2019 2:02 PM
  • Thanks

    The load from doesn't fail, the GetExportedTypes does.

    For reference I'm not trying to call anything from the loaded DLL, only reflect on it (and .NET core can't load assemblies in reflection only context, hence the use of LoadFrom) , the DLL's I'm loading happen to be from Mono. I don't think Mono is directly the problem because I use Mono's Cecil & CompilerServies.SymbolWriter with no problem.

    I guess it is entirely possible that, given the dependence on System.dll & friends that it is using the wrong one i.e. .NET core's System.dll, instead of Mono's?

    Is there a way to firewall (for want of a better term) the dynamically loaded DLLs (i.e. the ones from the program arguments, that I load with LoadFrom) from the ones loaded to execute the program (the ones referenced from the application)? Is this what AppDomain or AssemblyLoadContext is for?

    Thursday, August 22, 2019 4:12 AM
  • My understanding for .NET Core is that AssemblyLoadContext is the way to go because it doesn't support multiple AppDomains. But I've never worked with a load context in Core. You should probably ask in the Corefx repo.

    Michael Taylor

    Thursday, August 22, 2019 1:59 PM
  • Thanks for the hint. I can't actually test that because I seem to have fallen into the pits of DLL hell.

    So, it turns out that I was using mono's csc (probably because I couldn't find dotnet's csc, I have now) to build and dotnet to run (IDK how that originally worked but anyhoo...), I also use mono's Mono.CompilerServices.SymbolWriter for code generation (since dotnet's can't save dlls).

    Using dotnet's csc lead to lots of "CS0518 (Predefined type 'System.{Object,String,Void,Boolean}' is not defined or imported" despite adding /reference:/paths/to/{System{.Runtime},mscorlib,netcore}.dll, as well as "CS0246 The type or namesapce 'Assembly' could not be found (are you mising a using directive or reference assembly?)"

    If I use mono's csc to compile and add /reference:/path/to/system.runtime.loader.4.3.0/ref/netstandard1.5/System.Runtime.Loader.dll from nuget I get it seems to be wanting to link to .net framework ("CS0012: 'Object' is defined in an assembly that is not referenced. you must add a reference to assembly 'System.Runtime, Version=, ...") which I guesss makes sense if it is for .net framework.

    Amusingly I also get "CS0115 'MyAssemblyLoadContext.Load(AssemblyName)' no suitable method found to override" _and simultaneously_ "CS0534 'MyAssemblyLoadContext' does no implement inherited abstract member 'AssemblyLoadContext.Load(AssemblyName)'". I copied the example straight from the MS docs on AssemblyLoadContext...

    Since .net core seems to come with a System.Runtime.Loader, it would seem that if I can get it to cooperate with Mono.CompilerServices.SymbolWriter I can test if AssemblyLoadContext  fixes my problems. Any ideas how to get dotnet's csc to behave?

    Tuesday, August 27, 2019 9:32 AM
  • Hi Nicholas Wilson ---,

    Thank you for posting here.

    For your question, you get an exception:

    >>Could not load type'System.Runtime.InteropServices.StandardOleMarshalObject'

    I note that StandardOleMarshalObject class only support 3.0 Preview 8 in .NET Core.

    I suggest you update .NET Core 2.2 to .NET Core 3.0 Preview 8.

    Best Regrads,

    Xingyu Zhao

    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact

    Friday, August 30, 2019 3:04 AM