3

Assembly.GetTypes() throws a ReflectionTypeLoadException when there are types which cannot be loaded.

That exception has a Types[] property which lists the types which successfully loaded, and an LoaderExceptions[] property listing the exceptions for types which failed to load.

My question: How do I get the types themselves which correspond to the LoaderExceptions?

Edit: I'm actually looking for the name of the type which failed to load. Sorry for any confusion there.

Peter Drier
  • 1,327
  • 1
  • 11
  • 11
  • you will have to resolve the LoaderExceptions. what are they? – Mike Zboray Apr 04 '12 at 17:28
  • did you look at this http://stackoverflow.com/questions/2658275/c-sharp-assembly-gettypes-reflectiontypeloadexception - that seems to be a strange error, what is that you're doing exactly, where assembly comes from, is it yours or 3rd party etc. Did you try a reflector or similar. – NSGaga-mostly-inactive Apr 04 '12 at 18:27
  • LoaderExceptions are FileLoadExceptions in this case, and it only happens on an end user's machine I don't have access to. The FileLoadException is on a 3rd party dll. I literally have to do a production build and get this guy to run it and fail just to get more logs so I can debug. It's been 3 rounds of this to get this much info out. – Peter Drier Apr 17 '12 at 15:04

2 Answers2

4

This is just not possible. The CLR failed to create the Type objects which is why you got the set of LoaderExceptions. There is simply no Type object to describe a Type which failed to load.

JaredPar
  • 733,204
  • 149
  • 1,241
  • 1,454
  • Fair enough, I should have worded it as "How do I get the type names of the types that failed to load?" In this case, the LoaderExceptions have FileLoadExceptions which have an associated fusion log, but alas nothing that actually says "type Peters.BrokenClass" failed to load due to this exception:.. just that assembly Something.From.MS.dll failed to load... – Peter Drier Apr 17 '12 at 14:53
  • @PeterDrier it is a frustrating exception to work with. I usually just go straight to using fuslogvw to track down the errors as it will occasionally have a bit more helpful information http://msdn.microsoft.com/en-us/library/e74a18c4(v=VS.71).aspx – JaredPar Apr 17 '12 at 14:54
  • If only I had access to the machine having the problem. It's out in the field, and the user isn't one of our happier ones. The only real option is to code in extra debugging, and log back to the server enough results to hopefully figure out the problem. – Peter Drier Apr 17 '12 at 15:06
0

This error mostly occurs when the Dll you are loading from a location has already referred in your application or parent application. If the Dll is already in reference then loop through your application's Assemblies.

foreach (var asm in AppDomain.CurrentDomain.GetAssemblies())
{
      if (asm.ManifestModule.FullyQualifiedName.EndsWith("YourDllName.dll"))
      {
            foreach (var Type in asm.GetTypes())
            {
                  // Apply your logic here
            }                
            break;
      }
}
Sarath Subramanian
  • 20,027
  • 11
  • 82
  • 86