Resolve Type from Class Name in a Different Assembly

Resolve Type from Class Name in a Different Assembly

You'll have to add the assembly name like this:

Type.GetType("MyProject.Domain.Model." + myClassName + ", AssemblyName");

To avoid ambiguity or if the assembly is located in the GAC, you should provide a fully qualified assembly name like such:

Type.GetType("System.String, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089");

Get type in referenced assembly by supplying class name as string?

Maybe the referenced assembly isn't loaded at the time. Also, I understand from your question that you do not have the full type name, only the class name.

You should try something along this line then:

Type type = Assembly.Load("YourAssemblyName").GetTypes().First(t => t.Name == "ShortTypeName");

Hope I understood you correctly.

I have a C# class which i have to get the type of... but i only have the name(single name) as a string

Sadly Type.GetType(string) is quite finicky about the details it requires before it will give you the result. If the type you're looking for is in current executing assembly (or mscorlib/System.Private.CoreLib) then a fully specified name (including namespace) will get the result. If it's in a different assembly then you need to specify the assembly name.

Type type = null;

// Fails
type = Type.GetType("String");

// Succeeds from core library
type = Type.GetType("System.String");

// Fails (loading from a different assembly)
type = Type.GetType("System.Text.Json.JsonSerializer");

// Succeeds (.NET 6.0)
type = Type.GetType("System.Text.Json.JsonSerializer, System.Text.Json");

Which is all well and good until you're trying to find a type that you have exactly one piece of information about: the class name. Without namespace and assembly name you're stuck with enumerating every type until you find what you're looking for...

static Type? TypeFromName(string name) =>
    // All loaded assemblies
    AppDomain.CurrentDomain.GetAssemblies()
    // All types in loaded assemblies
    .SelectMany(asm => asm.GetTypes())
    // Return first match
    .FirstOrDefault(type => type.Name == name);

Simple, yes. Fast? Not even remotely. But you only need to do the search once and cache the results for later use.

How can I get a type from an assembly that is loaded from within another folder?

Type.GetType only searches the types in the calling assembly and the types in mscorlib.dll unless you pass the assembly qualified name of the type. See here.

EDIT

It appears that Type.GetType is only able to retrieve Type instances from assemblies in the Load context. Assemblies loaded using LoadFile are in no context and those loaded using LoadFrom are in the Load From context; neither of these contexts allow you to use Type.GetType so the resolution will fail. This article shows that Type information can be retrieved for an Assembly when the directory it is in is added as a probing privatePath since it will then end up in the Load context but will fail in other contexts.

Type.GetType(namespace.a.b.ClassName) returns null

Type.GetType("namespace.qualified.TypeName") only works when the type is found in either mscorlib.dll or the currently executing assembly.

If neither of those things are true, you'll need an assembly-qualified name:

Type.GetType("namespace.qualified.TypeName, Assembly.Name")

Passing class objects across different assembly versions

You are battling something called "Type identity", a very important DLL Hell counter-measure in the .NET framework. A type isn't just identified by its namespace name and type name, it also includes attributes of the assembly from which it came from. Specifically the assembly display name, [AssemblyVersion], [AssemblyCulture], PublicKeyToken and (indirectly) ProcessorArchitecture. You can see the 'real' type name with the Type.AssemblyQualifiedName property. The System.String class for example is System.String, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089

This stops you from faking a type in another assembly unless you can give that assembly the exact same attributes. Much easier is to simply use the existing assembly, should be no problem in your case since you only use an interface.

Notably is that this requirement was relaxed somewhat in .NET 4. Types that were auto-generated from a COM type library are equivalent if their name and [Guid] matches. Which helped eliminate PIAs and implement the "Embed interop types" feature. Nothing that applies in your case.

---

Related Topics