views:

354

answers:

2

Our application dynamically loads a set of private assemblies that each reside under their own sub-directory. They each have their own dependencies which are also in that same sub-directory. Each assembly is strongly named and the dependencies are the same library, but different versions.

MyApp
|-> Folder1\
|          |->PrivateAssembly1.dll
|          |->Dependency.dll                   Version 1.0.0.0
|
|-> Folder2\
|          |->PrivateAssembly2.dll
|          |->Dependency.dll                   Version 2.0.0.0
|
...

Since we're doing xcopy deployment so we don't use the GAC.

We also have probing privatePath defined to "Folder1;Folder2" to solve any issue of not finding the private assemblies.

The problem is that PrivateAssembly1.dll seems to find its dependency, but PrivateAssembly2.dll does not. Or rather, it seems to be trying to use Dependency.dll from Folder1 in stead of Folder2.

I know these issues can be manually resolved by using the AssemblyResolve event, however this isn't the cleanest approach. Are there other solutions I am overlooking?

Thanks for any and all ideas.

Update:

The output of the Fusion Log tool:

LOG: DisplayName = Dependency, Version=1.0.0.0, Culture=neutral, PublicKeyToken=#########
 (Fully-specified)
LOG: Appbase = file:///C:/Workspaces/Shell/MyApp/bin/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = NULL
...
LOG: Attempting download of new URL file:///C:/Workspaces/Shell/MyApp/bin/Dependency.DLL.
LOG: Attempting download of new URL file:///C:/Workspaces/Shell/MyApp/bin/Dependency/Dependency.DLL.
LOG: Attempting download of new URL file:///C:/Workspaces/Shell/MyApp/bin/Folder2/Dependency.DLL.
LOG: Assembly download was successful. Attempting setup of file: C:\Workspaces\Shell\MyApp\bin\Folder2\Dependency.dll
LOG: Entering run-from-source setup phase.
LOG: Assembly Name is: Dependency, Version=2.0.0.0, Culture=neutral, PublicKeyToken=#######
WRN: Comparing the assembly name resulted in the mismatch: Major Version
ERR: The assembly reference did not match the assembly definition found.
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.

So basically, it finds a Dependency.dll in Folder2, attempts to Load it only to see that the version doesn't match. I would assume it would try Folder1 next, but it just stops there...

+1  A: 
Richard
Thanks, I have added the log to the question.
Yannick M.
A: 

The reason why .NET objects to this is that you are trying to load different versions of the same assembly into the appdomain. You have to decide if you can let PrivateAssembly1.dll and PrivateAssembly2.dll actually use the same library version. This will save you quite a lot of trouble if it is possible.

It is indeed possible to force both versions of Dependency.dll to load into your appdomain by adding a custom resolver that loads it, but be aware that you are entering a rather narrow path if you do this. For instance, there will be different versions of any static variables in both versions, and also the types created in the Folder1\Dependency.dll assembly will not be recognized by the Folder2\Dependency.dll assembly, and vice versa, even though the types might seem to be "the same".

norheim.se
We are aware of the implications, however the PrivateAssemblies are the only ones that use their specific version of the Dependency.dll. The Dependency.dll is actually a framework library on which both applications are built (PrivateAssembly1, PrivateAssembly2). Since this framework library and the applications are going to be developed independently, it is quite possible that applications work with different versions of the lib.
Yannick M.