Microsoft Application bloc DLL V2 et références V4.1

Question

Mon application fait référence à la bibliothèque Microsoft Enterprise V4.1 alors que l'une des anciennes DLL (application externe) nécessite une référence à la bibliothèque Microsoft Enterprise V2.0. Je sais avec certitude que je peux enregistrer ces deux assemblages dans le GAC et que l'application commencera à lire les DLL pertinentes, mais ce n'est pas une solution car notre expert en sécurité n'accepte pas d'accepter cette solution.

Est-il possible d'utiliser le webconfig où je peux spécifiquement spécifier que la DLL plus ancienne utilise V2.0 tandis que l'application entière utilise 4.V0.

Note: Nous utilisons Visual Studio Asp.net C#

Besoin d'aide désespérément! Merci

Mise à jour:

Essayé la solution d'utiliser privatePath sondage:

<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> 
     <probing privatePath="bin;ExtDLL"/> 
    </assemblyBinding> 

Mon dossier Web a maintenant le dossier qui contient ExtDLL v2.0.0.0 Dlls pour la bibliothèque Microsoft Enterprise, mais je reste obtenir l'exception suivante dès que j'appelle la fonction DLL externe qui utilise l'ensemble de v2.0.0.0:

...System.IO.FileLoadException: Could not load file or assembly 'Microsoft.Practices.EnterpriseLibrary.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040) 

Answer 1

J'étais una ble de pouvoir charger les deux versions de la bibliothèque d'entreprise en utilisant la configuration de sondage/privatePath ou de base de code.

La seule façon de le faire fonctionner était d'utiliser custom resolving of assembly loads..

J'ai placé les assemblys 2.0 dans le répertoire bin de l'application. Puis j'ai placé les assemblages 4.1 dans un répertoire appelé EL41 sous bin (bin \ EL41). J'ai ensuite ajouté gestionnaire d'événements personnalisé pour tenter de résoudre l'ensemble en ajoutant

AppDomain.CurrentDomain.AssemblyResolve += newResolveEventHandler(MyResolveEventHandler); 

au démarrage code, puis la création de la MyResolveEventHandler

private static Assembly MyResolveEventHandler(object sender, ResolveEventArgs args) 
{ 
    string[] assemblyInfo = args.Name.Split(','); 
    return Assembly.LoadFrom(@"file:///C:/Documents and Settings/My Documents/Visual Studio 2008/Projects/App/bin/EL41/" + assemblyInfo[0] + ".dll"); 
} 

Cela va certainement travailler. Vous pouvez placer le chemin en configuration pour éviter de coder en dur l'emplacement, mais cela me semble encore mal. Je me demande s'il existe une façon moins intrusive de faire ce que vous voulez.

Answer 2

Avez-vous essayé quelque chose dans quelque chose comme ça? C'est actuellement la technique que j'utilise pour supporter plusieurs versions de DLL dans une application, tout en évitant le GAC.

<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> 
    <dependentAssembly> 
    <assemblyIdentity name="MyLibrary" publicKeyToken="605f591b87e816bd"/> 
    <codeBase version="1.0.0.0" href="./v1/MyLibrary.dll"/> 
    <codeBase version="2.0.0.0" href="./v2/MyLibrary.dll"/> 
    </dependentAssembly> 
</assemblyBinding> 

Le assurez-vous que:

1. Vos DLL sont fortement nommés
2. la structure de répertoire approprié (v1/v2 MyLibrary.dll et/MyLibrary.dll) est dans votre dossier binaire
3. Aucune des DLL qui apparaissent dans ces 'sous-dossiers' ne doit apparaître directement dans votre dossier binaire.

Ceci est une solution simple - mais je recommande que vous nommez actuall vos sous-dossiers sont les mêmes, ils seraient dans le GAC, tels que:

./MyLibrary/1.0.0.0__605f591b87e816bd/ MyLibrary.dll

./MyLibrary/2.0.0.0__605f591b87e816bd/MyLibrary.dll

./MyLibrary/2.0.0.0_en_605f591b87e816bd/MyLibrary.dll (ceci est un exemple d'une construction qui est localisée, ensembles de satellites aurait apparaissent toujours comme ceci)