Reputation: 1297
I had an issue that code Type.GetType(myTypeName)
was returning null
because assembly with that type is not current executing assembly.
The solution I found for this issue is next:
var assemblies = AppDomain.CurrentDomain.GetAssemblies();
Type myType = assemblies.SelectMany(a => a.GetTypes())
.Single(t => t.FullName == myTypeName);
The problem is that the first run of this code causes exception "Sequence contains no matching element"
. When I call this part of code again - everything is ok and needed Type is loaded.
Can anyone explain such behavior? Why in the scope of first call no needed assembly/type found?
Upvotes: 6
Views: 3789
Reputation: 18749
Another answer shows the best way for obtaining (at runtime) a Type
defined in an Assembly
that might not be loaded:
var T1 = Type.GetType("System.Web.Configuration.IAssemblyCache, " +
"System.Web, " +
"Version=4.0.0.0, " +
"Culture=neutral, " +
"PublicKeyToken=b03f5f7f11d50a3a");
As you can see, unfortunately that method requires you to supply the full AssemblyQualifiedName of the Type
and will not work with any of the abbreviated forms of the assembly name that I tried. This somewhat defeats our main purposes here. If you knew that much detail about the assembly, it wouldn't be that much harder to just load it yourself:
var T2 = Assembly.Load("System.Web, " +
"Version=4.0.0.0, " +
"Culture=neutral, " +
"PublicKeyToken=b03f5f7f11d50a3a")
.GetType("System.Web.Configuration.IAssemblyCache");
Although these two examples look similar, they execute very different code paths; note for example, that the latter version calls an instance overload on Assembly.GetType
versus the static call Type.GetType
. Because of this, the second version is probably faster or more efficient. Either way, though, you seem to end up at the following CLR internal method, and with the second argument set to false
, and this is why neither method goes to the trouble of searching for the required assembly on your behalf.
[System.Runtime.Remoting.RemotingServices]
private static RuntimeType LoadClrTypeWithPartialBindFallback(
String typeName,
bool partialFallback);
A tiny step forward from these inconveniences would be to instead call this CLR method yourself, but with the partialFallback
parameter set to true. In this mode, the function will accept a truncated version of the AssemblyQualifiedName
and will locate and load the relevant assembly, as necessary:
static Func<String, bool, TypeInfo> LoadClrTypeWithPartialBindFallback =
typeof(RemotingServices)
.GetMethod("LoadClrTypeWithPartialBindFallback", (BindingFlags)0x28)
.CreateDelegate(typeof(Func<String, bool, TypeInfo>))
as Func<String, bool, TypeInfo>;
// ...
var T3 = LoadClrTypeWithPartialBindFallback(
"System.Web.Configuration.IAssemblyCache, System.Web",
true); // <-- enables searching for the assembly
This works as shown, and also continues to support specifying the full AssemblyQualifiedName
as in the earlier examples. This is a small improvement, but it's still not a fully unqualified namespace search, because you do still have to specify the short name of the assembly, even if it might be deduced from the namespace that appears in the type name itself.
Upvotes: 1
Reputation: 10931
BTW if you do know the FullName
of the assembly containing the type (or an assembly containing a TypeForwardedToAttribute
for the type) you can use Type.GetType
. Specifically, Type.GetType(Assembly.CreateQualifiedName(assembly.FullName, myTypeName))
which will look something like:
Type.GetType("Some.Complete.Namespace.myTypeName, Some.Assembly.Name, Version=1.2.3.4, Culture=neutral, PublicKeyToken=ffffffffffffffff");
This will load the assembly if it is not already, assuming the framework can resolve the location of the assembly.
Here's my sample LinqPad query confirming the parenthetic TypeForwardedToAttribute
remark:
var u = (from a in AppDomain.CurrentDomain.GetAssemblies()
let t = a.GetType("System.Lazy`2")
where t != null
select t).FirstOrDefault();
(u?.AssemblyQualifiedName).Dump();
u = Type.GetType("System.Lazy`2, System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a");
(u?.AssemblyQualifiedName).Dump();
Output:
null
System.Lazy`2, System.ComponentModel.Composition, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
Upvotes: 0
Reputation: 1497
Problem you are facing is caused by design of GetAssemblies method of AppDomain
class - according to documentation this method:
Gets the assemblies that have been loaded into the execution context of this application domain.
So when in your program type fails to be found first time - its assembly isn't obviously loaded by the application yet. And afterwards - when some functionality from assembly that contains type in question had been used - assembly is already loaded, and same code can already find missing type.
Please try loading assemblies directly. Instead of using:
var assemblies = AppDomain.CurrentDomain.GetAssemblies();
you can use:
List<Assembly> assemblies = Assembly.GetEntryAssembly().GetReferencedAssemblies().Select(assembly => Assembly.LoadFrom(assembly.Name)).ToList();
Upvotes: 4
Reputation: 1164
And if you exlucde mscorlib assembly?? , you can try this:
var assemblies = AppDomain.CurrentDomain.GetAssemblies().Where(asb=>!asb.FullName.StartsWith("mscorlib")).ToList();
Type myType = assemblies.SelectMany(a => a.GetTypes())
.Single(t => t.FullName == myTypeName);
Upvotes: 0
Reputation: 14672
It is possible that the type is in an assembly that has not yet been loaded. Later in your program it then is. If you look at the output window this should give you sn idea of when the assemblies are being loaded.
Upvotes: 2