Для каждого конфигурационного файла приложения bindingRedirect не применяется к Dlls - PullRequest
Новая
       29

Для каждого конфигурационного файла приложения bindingRedirect не применяется к Dlls

3 голосов
/ 28 августа 2009

Я создал простое Win32-приложение для демонстрации UXtheme на XP, включив явную зависимость от версии 6 commctl32.dll Затем я создал простой Win32 dll, собрал его с ISOLATION_AWARE_ENABLED и протестировал его со встроенным манифестом, указав версии 5 и 6 Comctl32.dll

Я успешно получил exe и dll для использования различных версий comctl32.dll с использованием этого метода. И с exe, использующим 5, и с dll версией 6, и наоборот.

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

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<configuration>
  <windows>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" processorArchitecture="amd64" publicKeyToken="6595b64144ccf1df"/>
        <bindingRedirect oldVersion="5.82.7100.0" newVersion="6.0.0.0"/>
      </dependentAssembly>
    </assemblyBinding>
  </windows>
</configuration>

Теперь, когда я запускаю свое приложение, приложения явно перенаправляются в commctl v6 - диалоговые окна четко отображаются с использованием включенной XP UXTheme. Тем не менее, dll не перенаправляется и использует non themed ver 5 из commctl.

В документации не упоминаются файлы конфигурации per-dll для выполнения bindingRedirects. И попытка создать ничего не делает.

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

Как перенаправить версию зависимой сборки dll?

Ответы [ 2 ]

4 голосов
/ 20 октября 2011

А в Windows Vista даже нет доступа к файлам .manifest или .config, которые добавляются позже, поскольку он кэширует их существование вместе с датой штамп для отл.

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

3 голосов
/ 31 августа 2009

Итак, на этот вопрос дан ответ.

  • Я использовал Process Monitor для отслеживания доступа к файлам,
  • После понимания того, что доступ к файлам .manifest и .config происходит из csrss.exe, а НЕ из моего собственного процесса,
  • А в Windows Vista даже нет доступа к файлам .manifest или .config, которые добавляются позже, поскольку она кэширует их существование вместе с отметкой даты и времени для exe.

После всего, что я обнаружил, LoadLibrary проверяет файл .config при загрузке dll: 

full_path_to_dll\dllname.dll.2.config

Переадресация привязок в этом файле будет обработана.

...