CODEWITHSUNDEEP
c#.netlinqfile-io
Jeff
Jeff

Reputation: 14279

.NET assembly in current domain cannot be found

I have a project I am working that will search all loaded assemblies for any class that implements a certain interface. Then it will create an instance of that class and invoke a method of the interface. The code ran great on simple projects in testing environments. At the heart of it is the following function: 

    public static List<Type> GetLoadedTypes(Type targetType)
    {
        var types = AppDomain.CurrentDomain.GetAssemblies().ToList()
            .SelectMany(a => a.GetTypes())
            .Where(t => targetType.IsAssignableFrom(t)).ToList();
        return types;
    }

I have another project that inserted this code into and the LINQ query fails because one of the assemblies in the domain cannot be found.

System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.Practices.ObjectBuilder, Version=1.0.51206.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.

I don't directly reference this assembly in any of my projects. How can I find out which assembly references it? How did the assembly even get into the domain if it cannot be found?

EDIT: I am using Enterprise Library in the project but I am already referencing the Microsoft.Practices.ObjectBuilder2.dll. Apparently there is a difference between the two assemblies. Is that correct?

Thanks! Jeff

Upvotes: 1

Views: 2083

Answers (2)

Aliostad
Aliostad

Reputation: 81680

This is used by Microsoft's Unity. Copy the DLL to your bin at the time of build (using script, ...) or add a reference.

Update

In order to find out, you can add AppDomain's AssemblyResolve event and check RequestingAssembly property in the arguments.

Update 2

OK, here is how I would have approached it:

  • Use sysinternal's procmon to monitor your executable. You will see name of the file (objectbuilder2) popping up with a lot of FILE NOT FOUND events in there. See where it is looking for it, you need it to be there. I think DLL is being loaded in a different location
  • Make sure this specific version of the DLL exists

Upvotes: 1

k3b
k3b

Reputation: 14755

You can use the "Assembly Binding Log Viewer" (Fuslogvw.exe) that belongs to the dotnet2.0sdk (maybe also in later edition) . If logging is enabled it can show you wich assemblies are loaded and which assembly caused it to load.

For details see http://msdn.microsoft.com/en-us/library/e74a18c4(v=vs.80).aspx

Upvotes: 2

Related Questions