Ссылки на Microsoft Application block DLL V2 и V4.1 - PullRequest
Новая
       21

Ссылки на Microsoft Application block DLL V2 и V4.1

0 голосов
/ 07 июля 2010

Мое приложение ссылается на библиотеку Microsoft Enterprise V4.1, в то время как одна из более старых DLL (внешнее приложение) требует ссылки на библиотеку Microsoft Enterprise V2.0.Я точно знаю, что могу зарегистрировать обе эти сборки в GAC, и приложение начнет читать соответствующую DLL по мере необходимости, но это не решение для нас, поскольку наш эксперт по безопасности не согласен с принятием этого решения.

Есть ли способ использовать webconfig, где я могу указать, что Старая DLL использует V2.0, а все приложение использует 4.V0.

Примечание: мы используем Asp.net visual Studio C #

Помощь нужна отчаянно!Спасибо

Обновление:

Попробовал решение с использованием проверки privatePath: 

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

В моей веб-папке теперь есть папка ExtDLL, которая содержит V2.0.0.0 DLL для Microsoft Enterpriseбиблиотека, но я все еще получаю следующее исключение, как только я вызываю функцию внешней DLL, которая использует сборку 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)

Ответы [ 2 ]

1 голос
/ 20 июня 2011

Вы пробовали что-то подобное? В настоящее время это метод, который я использую для поддержки нескольких версий DLL в приложении, избегая при этом 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>

Убедитесь, что у вас есть:

  1. Ваши DLL строго названы
  2. соответствующая структура каталогов (v1 / MyLibrary.dll и v2 / MyLibrary.dll) находится в вашей двоичной папке
  3. Ни одна из библиотек DLL, которые появляются в этих «подпапках», не должна отображаться непосредственно в вашей двоичной папке.

Это простое решение, но я бы порекомендовал, чтобы вы на самом деле называли свои подпапки такими же, какими они будут в GAC, например:

. / 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 (это пример сборки, которая локализованные, спутниковые сборки всегда будут выглядеть так)

0 голосов
/ 07 июля 2010

Мне не удалось загрузить обе версии Enterprise Library с использованием конфигурации probing / privatePath или codebase.

Единственный способ заставить его работать - использовать настраиваемое разрешение сборочных нагрузок.

Я поместил сборки 2.0 в каталог bin приложения. Затем я поместил сборки 4.1 в каталог с именем EL41 в bin (bin \ EL41). Затем я добавил собственный обработчик событий, чтобы попытаться разрешить сборку, добавив 

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

к коду запуска и затем созданию 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");
}

Это определенно будет работать. Вы можете поместить путь в конфигурацию, чтобы избежать жесткого кодирования местоположения, но оно все равно кажется мне неправильным. Интересно, есть ли менее навязчивый способ делать то, что вы хотите.

...