MBR IT/.NET 247 : Assembly.Load() with alternate subdirectory for other assemblies which have dependencies on microsoft.public.dotnet.framework.clr

Assembly.Load() with alternate subdirectory for other assemblies which have dependencies

Messages

Related Types

This message was discovered on microsoft.public.dotnet.framework.clr.
Responses highlighted in red are from those people who are likely to be able to contribute good, authoratitive information to this discussion. They include Microsoft employees, MVP's and others who IMHO contribute well to these kinds of discussions.

Post a new message to this list...

Jim

I have a question about dependent assemblies of asseblies that are
loaded with Assembly.Load(). I have a directory structure with the
following format:

C:\temp\
-> myApp.exe
-> OurCompany.Common.dll (version 1.5.0.0 with common routines,
strongly signed)

C:\temp\ExternalLibrary
-> ExternalLibrary.dll
-> OurCompany.Common.dll (version 1.2.0.0 with common routines,
strongly signed)

From "myApp.exe", the following code is used:

Assembly loaded = Assembly.Load( "ExternalLibrary" ) ;
object classToUse =
loaded.CreateInstance("ClassInsideExternalLibrary") ;

.... the loading of the assembly seems to work just fine, but when
CreateInstance() is called, it fails because it can not find
OurCompany.Common.dll with version 1.2, which is a dependency in
ExternalLibrary.dll's manifest. From my understanding, it should have
been loaded since it resides inside the Load() context. Is this
correct? If not, any suggestions of how to make this work without the
GAC would be appreciated. I can temporarily resolve this issue by
using a <bindingRedirect> in the myApp.exe.config file. This is much
less usefull as it makes a central location with all of the detailed
knowledge of each of the loaded assemblies.

Thanks in advance...

Reply to this message...

David Levine

Before you load any assembly with a dependency on the common.dll or loading
it directly, call
AppDomain.CurrentDomain.AppendPrivatePath("ExternalLibrary");

This tells the runtime where it can look below the application base
directory for other assemblies, and avoids needing to explicity load the
assembly using LoadFrom.

"Jim" <Click here to reveal e-mail address> wrote in message
news:Click here to reveal e-mail address...
[Original message clipped]

Reply to this message...

Christian Heide Damm (VIP)

One solution would be to load OurCompany.Common.dll v1.2.0.0 _before_ you
load ExternalLibrary.dll - that way it doesn't have to look for it when it
needs it.

Another way would be to subscribe to the AppDomain.AssemblyResolve event.
When that event is raised for the "OurCompany.Common.dll, version 1.2.0.0,
...." assembly, you load it from c:\ExternalLibrary. This is the lazy variant
of the first solution.

Reg. the question about load contexts...

First of all, I don't understand how you can load ExternalLibrary.dll by
Assembly.Load("ExternalLibrary"). I would think you'd need to say

AssemblyName externalLibraryName = new AssemblyName("ExternalLibrary");
// include version etc. if you want
externalLibraryName.Location = @"c:\temp\ExternalLibrary";
Assembly.Load(externalLibraryName);

Anyway, it looks like it's loaded in the LoadFrom context - in which case I
would actually expect it to find ExternalLibrary.dll v1.2.0.0 because it is
in the same directory. If it is in fact loaded in the Load context, I would
NOT expect it to find ExternalLibrary.dll v1.2.0.0.

Christian

---

"Jim" <Click here to reveal e-mail address> wrote in message
news:Click here to reveal e-mail address...
[Original message clipped]

Reply to this message...

	System.AppDomain
	System.Reflection.Assembly
	System.Reflection.AssemblyName

MBR BootFX
Best-of-breed application framework for .NET projects, developed by Matthew Baxter-Reynolds and MBR IT

	Copyright © Matthew Baxter-Reynolds 2001-2008. '.NET 247 Software Development Services' is a trading style of MBR IT Solutions Ltd.
	Contact Us - Terms of Use - Privacy Policy - www.dotnet247.com