Why isn't the fully functional assembly name used in the private assembly opener, but rather the filename?
Our application dynamically loads a set of private assemblies, each under their own subdirectory. They each have their own dependencies, which are also in the same subdirectory. Each assembly has a strong name, 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 are doing xcopy deployment, so we are not using the GAC.
We also have probing privatePath
one specific "Folder1;Folder2"
to solve any problem of not finding private assemblies.
The problem is that PrivateAssembly1.dll seems to find its dependency, but PrivateAssembly2.dll does not. Rather, it tries to use Dependency.dll from Folder1 instead of Folder2.
I know these problems can be solved manually using the AssemblyResolve event, however this is not the cleanest approach. Are there any other solutions I am missing?
Thanks for any ideas.
Update:
Fusion Log tool output:
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.
Basically, it finds Dependency.dll in Folder2, tries to load it only to see that the version is not matched. I would suggest it tries Folder1 next, but it just stops there ...
source to share
The first thing to do is use the Fusion Log Viewer " FUSLOGVW.exe
" 1 to enable assembly load logging. This will show you where the CLR is trying to load dependencies. This should confirm that something is missing and let you know what you are missing in .config
.
[Edit: Now with log]
Once a matching assembly name is found, no more (file) is searched. That is, keep the assembly names unique.
(This is similar to C ++ method overload resolution, the best match is found first and then availability is checked, so weaker parameter access will not be considered.)
1 NB. If you are on a 64-bit system, you can split 32 and 64-bit versions of this tool: make sure you are using the correct one.
source to share
The reason .NET refers to this is because you are trying to load different versions of the same assembly in the appdomain. You must decide if you can allow PrivateAssembly1.dll and PrivateAssembly2.dll to use the same version of the library. This will save you a ton of hassle if possible.
Indeed, it is 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. For example, both versions will have different versions of any static variables, and types created in the Folder1 \ Dependency.dll assembly will not be recognized by the Folder2 \ Dependency.dll assembly, and vice versa, although the types may appear "the same".
source to share