Pergunta

Criei um aplicativo Win32 simples para demonstrar uxtheMe no XP, incluindo uma dependência manifesta do ver 6 Commctl32.dll, criei uma DLL Win32 simples, construí -a com ISOLATION_AWARE_ENABLED, e testou com um manifesto incorporado, especificando a versão 5 e 6 do COMCTL32.DLL

Consegui com sucesso o EXE e o DLL para usar versões diferentes do COMCTL32.DLL usando esse método. Tanto com o EXE usando 5 quanto a versão 6 da DLL e o contrário.

Em seguida, redefini o aplicativo e a DLL para ter uma dependência manifestada do Comctl ver 5. E introduziu um arquivo de configuração de aplicativo:

<?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>

Agora, quando executo meu aplicativo, os aplicativos estão sendo claramente redirecionados para o CommCTL V6 - as diálogos são claramente exibidas usando o XP UxTheme ativado. No entanto, a DLL não está sendo redirecionada e está usando o ver 5 de Commctl não temático.

Não há menção aos arquivos de configuração por DLL para fazer o BindingReDirects na documentação. E tentar criar um não faz nada.

Eu também sei que fazer um BindingRedirect de uma versão principal de uma montagem para outra não é um cenário suportado, mas estou realmente usando o CommCTL32 como uma maneira óbvia fácil de testar a mecânica.

Como faço para redirecionar a versão de uma montagem dependente de uma DLL?

Foi útil?

Solução 2

Então, esta pergunta foi respondida.

  • Eu usei o Monitor do Processo para rastrear o acesso ao arquivo,
  • Depois de perceber que os acessos a.
  • E o Windows Vista nem acessará os arquivos .Manifest ou .config que são adicionados posteriormente, pois armazenam sua existência junto com um carimbo de data para o EXE.

Depois de tudo o que descobri que o Loadlibrary investiga um arquivo .config ao carregar DLLs:

full_path_to_dll\dllname.dll.2.config

Os redirecionamentos de ligação neste arquivo serão processados.

Outras dicas

E o Windows Vista nem acessará os arquivos .Manifest ou .config que são adicionados posteriormente, pois armazenam sua existência junto com um carimbo de data para o EXE.

Descobri que o login/On parece limpar os gatilhos que o arquivo de configuração é lido novamente.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top