Replacement for AppDomain.CurrentDomain.GetAssemblies()


I am trying to port my serializer to .NET Core

And loading the assemblies is the last stumbling block…
I got 2 options:

  1. Ideally I would like to load the assemblies automatically? how do I do that?
  2. I will have to add a manual “RegisterAssemblies()” method :’(


I’ve started to work on using dynamic loading in .net core. There is some basic core in my minimal repo.

For a basic loading of dll in core, you can refer to:

Currently, in 1.0, it seems there’s a bug in assembly load context. See if you use the assembly.resolve I use in line #L195.

It’s supposedly fixed in the github core repo (I tried to download the Corefx and coreclr to recompile all, but was not able to get the test setup correctly yet) and there is workarounds (i.e. Load like I do in lines 222) or write your own LoadContext as mentioned in the issue, although I haven’t managed to get that to work.

Is that any help?

Also there is which although slightly outdated might give you keywords and calls you need.

Btw, beautiful code you have in your repo. Commented, looks clean and all.


Thanks, I hope it’s gonna get used, so I did my best to make it appealing! :slight_smile:

Your code is full of idea… I will try o put them to good use soon, we shall see!

I had a quick initial look already, AssemblyLoadContext seems perfect for loading plugin.
But how about, say, the current assembly, or assembly already loaded?



I found a piece of code that tells you the loaded assemblies:


        using Microsoft.Extensions.DependencyModel;
        using Microsoft.DotNet.InternalAbstractions;


        var runtimeId = RuntimeEnvironment.GetRuntimeIdentifier();
        var assemblies = DependencyContext.Default.GetRuntimeAssemblyNames(runtimeId);

        foreach (var assembly in assemblies)

Is this what you are looking for?


What a timely comment! (Just doing debugging .NET core version right now…) :slight_smile:

My problem is to implement Type.GetType(typename, assemblyName)
Unfortunately Type.GetType() only works with fully qualified assembly name (with version number and assembly hash) hence I am trying to write my replacement method that go through assembly…

From your code it looks like I can find:

  1. all file path for assembly in use
  2. (re?)load those assembly from (discovered) paths

it seems (without testing… just debugging right now) that these

  1. might work
  2. might be overkill !! (unless, that is, the runtime cache the assembly by location?) do you know?

Thanks for all the feedback hey! :slight_smile:

Gonna test that anyway once I crushed bugs which only appeared on .NET core! :confused:


If you check line 223 in my code above, the Type.GetType doesn’t need the fully qualified assembly name.

Do you have a snippet of code / reference to a file on github of what exactly you are trying to do?


Mm… to tell you the whole story I just kept this thread in the back of my mind for when I will get to that…
Yesterday I did performance optimization and today I was solving new bugs which appeared on the .NET core…

At any rate, as you suggested Type.GetType() shold work, I thought I could as well give it a quick try…
So I wrote this utterly simple test

    var TC = typeof(TypeConverter);
    var name = $"{TC.FullName},{TC.GetTypeInfo().Assembly.GetName().Name}";
    var t = Type.GetType(name);

Imagine my surprise!
This work perfectly fine on .NET core!!, i.e. t is typeof(TypeConverter) instead of null!

For the record it doesn’t work on the full desktop framework! :sweat:
Thanks again for your feedback! :slight_smile:


Thank you very much.its right

.NET Foundation Website | Blog | Projects | Code of Conduct