Etapa 4: Localizando que o Assembly através de bases de código ou investigação

Artigo
08/01/2011

Após a versão correta do assembly tiver sido determinada usando as informações de referência do assembly de chamada e nos arquivos de configuração, e depois ele deu no global assembly cache (apenas para assemblies de nome forte), o common language runtime tenta localizar o assembly. O processo de localização de um assembly envolve as seguintes etapas:

Se um <codeBase> elemento encontrado no arquivo de configuração do aplicativo, o runtime verifica o local especificado. Se uma correspondência for encontrada, o assembly é usado e nenhuma investigação ocorre. Se o assembly não for encontrado, haverá falha na solicitação de ligação.
O tempo de execução e testes para o assembly referenciado usando as regras especificadas posteriormente nesta seção.

Observação

Se você tiver várias versões de um assembly em um diretório e você deseja fazer referência a uma determinada versão do assembly, você deve usar o <codeBase> elemento em vez da privatePath atributo o <probing> elemento.Se você usar o <probing> elemento, o runtime deixa de verificar a na primeira vez que ele encontra um assembly que coincide com o nome simples do assembly referenciado, seja ela uma correspondência correta ou não.Se for uma correspondência correta, o assembly é usado.Se não for uma correspondência correta, paradas de investigação e ligação falhar.

Localizando o Assembly através de bases de código

Codebase informações podem ser fornecidas usando um <codeBase> o elemento em um arquivo de configuração. Esta base de código sempre é verificada antes de tentativas de runtime para investigar o assembly referenciado. Se um arquivo de diretiva de editor contendo o redirecionamento de versão final também contém um <codeBase> elemento, que <codeBase> elemento é o que é usado. Por exemplo, se o seu arquivo de configuração do aplicativo especifica uma <codeBase> elemento e um arquivo de diretiva de editor que está substituindo as informações do aplicativo também especifica uma <codeBase> elemento, o <codeBase> o elemento no arquivo de diretiva de Editor é usado.

Se nenhuma correspondência for encontrada no local especificado pelo <codeBase> elemento, a solicitação bind falhará e nenhuma outra etapa será efetuada. Se o tempo de execução determina se um assembly coincide com os critérios do assembly de chamada, ele usa esse assembly. Quando o arquivo especificado pelo determinado <codeBase> elemento é carregado, o runtime verifica para certificar-se de que o nome, versão, cultura e chave pública correspondem o assembly da chamada de referência.

Observação

Os assemblies referenciados fora do diretório raiz do aplicativo deve ter nomes fortes e deve ser instalados no cache global de assemblies ou especificado usando o <codeBase> elemento.

Localizando o Assembly por meio de investigação

Se não houver nenhum <codeBase> o elemento no arquivo de configuração do aplicativo, o runtime investiga assembly usando quatro critérios:

Base do aplicativo, que é o local da raiz onde o aplicativo está sendo executado.
Cultura, o atributo de cultura do assembly referenciado.
Nome, que é o nome do assembly referenciado.
O privatePath atributo o <probing> elemento, que é a lista de subdiretórios em um local da raiz definido pelo usuário. Este local pode ser especificado no arquivo de configuração do aplicativo e em código gerenciado usando o AppendPrivatePath a propriedade para um domínio de aplicativo. Quando especificado no código gerenciado, o código gerenciado privatePath é analisada pela primeira vez, seguido do caminho especificado no arquivo de configuração do aplicativo.

A Base do aplicativo e os diretórios de cultura de investigação

O runtime sempre começa a investigação na base de dados do aplicativo, que pode ser uma URL ou diretório da raiz do aplicativo em um computador. Se o assembly referenciado não for encontrado na base do aplicativo e nenhuma informação de cultura for fornecida, o runtime procura todas as subpastas com o nome do assembly. Os diretórios analisados incluem:

[base do aplicativo] / [nome do assembly]. dll

[base do aplicativo] / [nome do assembly] / [nome do assembly]. dll

Se as informações de cultura for especificadas para o assembly referenciado, somente os seguintes diretórios serão investigados:

[base do aplicativo] / [cultura] / [nome do assembly]. dll

[base do aplicativo] / [cultura] / [nome do assembly] / [nome do assembly]. dll

A sondagem com o atributo de privatePath

Juntamente com os subdiretórios de cultura e as subpastas nomeadas para o assembly referenciado, o runtime também investiga diretórios especificados usando o privatePath atributo o <probing> elemento. Os diretórios especificados usando o privatePath atributo deve ser subdiretórios do diretório de raiz. do aplicativo Os diretórios analisados variam dependendo se as informações de cultura estão incluídas na solicitação do assembly referenciado.

O tempo de execução pára na primeira vez que ele encontra um assembly que coincide com o nome simples do assembly referenciado, seja ela uma correspondência correta ou não de investigação. Se for uma correspondência correta, o assembly é usado. Se não for uma correspondência correta, paradas de investigação e ligação falhar.

Se a cultura for incluída, os seguintes diretórios serão investigados:

[base do aplicativo] / [binpath] / [cultura] / [nome do assembly]. dll

[base do aplicativo] / [binpath] / [cultura] / [nome do assembly] / [nome do assembly]. dll

Se as informações de cultura não for incluídas, os seguintes diretórios serão investigados:

[base do aplicativo] / [binpath] / [nome do assembly]. dll

[base do aplicativo] / [binpath] / [nome do assembly] / [nome do assembly]. dll

Exemplos de investigação.

Considerando as seguintes informações:

Nome do assembly referenciado: myAssembly
Diretório raiz do aplicativo: http://www.Code.microsoft.com
<probing> o elemento no arquivo de configuração especifica: Lixeira
Cultura: de

O tempo de execução testes seguintes URLs:

http://www.Code.microsoft.com/de/MyAssembly.dll

http://www.Code.microsoft.com/de/myAssembly/MyAssembly.dll

http://www.Code.microsoft.com/bin/de/MyAssembly.dll

http://www.Code.microsoft.com/bin/de/myAssembly/MyAssembly.dll

Vários Assemblies com o mesmo nome.

O exemplo a seguir mostra como configurar vários assemblies com o mesmo nome.

   <dependentAssembly>
      <assemblyIdentity name="Server" publicKeyToken="c0305c36380ba429" /> 
         <codeBase version="1.0.0.0" href="v1/Server.dll"/>
         <codeBase version="2.0.0.0" href="v2/Server.dll"/>
   </dependentAssembly>

Outros locais analisados

Local do assembly pode ser determinada utilizando o contexto atual de ligação. Isso normalmente ocorre quando o Assembly.LoadFrom método é usado e, em cenários de interoperabilidade COM. Se um assembly usa o LoadFrom método para fazer referência a outro assembly, o local de chamada do assembly é considerado como uma dica sobre onde encontrar o assembly referenciado. Se uma correspondência for encontrada, o assembly foi carregado. Se nenhuma correspondência for encontrada, o tempo de execução continua com sua semântica de pesquisa e em seguida, o Windows Installer para fornecer o assembly de consulta. Se nenhum assembly for fornecido, que corresponda à solicitação de ligação, uma exceção é lançada. Essa exceção é um TypeLoadException em código gerenciado, se um tipo foi referenciado, ou um FileNotFoundException se um assembly que está sendo carregado não foi encontrado.

Por exemplo, se Assembly1 faz referência a Assembly2 e Assembly1 tiver sido baixado de http://www.code.microsoft.com/utils, esse local é considerado para ser uma dica sobre onde encontrar Assembly2.dll. O tempo de execução e testes para o assembly em http://www.code.microsoft.com/utils/Assembly2.dll e http://www.code.microsoft.com/utils/Assembly2/Assembly2.dll. Se Assembly2 não for encontrado em um desses locais, o runtime consultará o Windows Installer.