Partilhar via


Diretrizes para criar assemblies lado a lado

As diretrizes a seguir discutem como criar seus próprios assemblies COM ou Win32 lado a lado. Talvez você não precise criar seus próprios assemblies lado a lado se a funcionalidade necessária for fornecida por um dos assemblies lado a lado da Microsoft com suporte. Nesse caso, use os assemblies fornecidos pela Microsoft e siga os procedimentos para usar assemblies lado a lado em Usando aplicativos isolados e assemblies lado a lado.

Primeiro, considere se o componente é um candidato adequado para um assembly lado a lado. Para obter mais informações, consulte Você deve fornecer um componente compartilhado como um assembly lado a lado?

Para criar um assembly lado a lado, siga estas diretrizes:

  • Decida quais recursos incluir no assembly. Tenha em mente que um assembly consiste em um ou mais arquivos que sempre são fornecidos a aplicativos e clientes juntos. O assembly serve como a unidade fundamental usada para nomenclatura, associação, controle de versão, implantação e configuração padrão. Como regra geral, quando incerto sobre se dois recursos pertencem ao mesmo assembly, é recomendável que eles sejam criados para entrar em assemblies separados. Normalmente, um assembly lado a lado consiste em uma única DLL.
  • Crie um manifesto do assembly para o assembly. O manifesto deve descrever o objeto COM ou as bibliotecas de tipos no assembly. Para obter mais informações sobre o que deve ser criado em um manifesto do assembly, consulte manifestos do assembly.
  • Avalie o uso de objetos quando mais de uma versão do assembly for executada no sistema. Determine se diferentes versões do assembly exigem estruturas de dados separadas, como arquivos mapeados em memória, pipes nomeados, mensagens e classes registradas do Windows, memória compartilhada, semáforos, mutexes e drivers de hardware. Todas as estruturas de dados usadas em versões de assembly devem ser versões compatíveis com versões anteriores. Decida quais estruturas de dados podem ser usadas entre versões e quais estruturas de dados devem ser privadas para uma versão. Determine se as estruturas de dados compartilhados exigem objetos de sincronização separados, como semáforos e mutexes.
  • Crie sua DLL para funcionar bem como um assembly lado a lado, aderindo às diretrizes em Criação de uma DLL para um assembly lado a lado.
  • Crie um conjunto de arquivos de cabeçalho e funções auxiliares para fornecer uma maneira fácil de ver as chaves do Registro que contêm o estado do assembly. Os assemblies geralmente salvam suas configurações de estado em chaves do Registro. As configurações do Registro devem ser gravadas em uma versão individual para isolar várias versões de assembly que podem ser executadas ao mesmo tempo. Crie o assembly lado a lado e a DLL para armazenar e manipular corretamente o estado do assembly durante cenários de compartilhamento lado a lado. Siga as diretrizes em Criação de armazenamento de estado para assemblies lado a lado.
  • Os desenvolvedores de aplicativos que usam assemblies privados devem proteger o diretório do aplicativo. Se o aplicativo estiver instalado usando o Windows Installer, o diretório do aplicativo poderá ser protegido usando a tabela LockPermissions. Normalmente, o sistema recebe acesso de leitura, gravação e execução a assemblies privados; todos os outros processos recebem apenas acesso de execução e leitura.
  • Teste o assembly usando cenários com compartilhamento lado a lado para garantir que ele seja um assembly lado a lado válido. A instalação bem-sucedida do assembly não é suficiente para garantir que ele funcionará conforme o esperado.
  • Adote um método para numerar atualizações para seu assembly. Cada assembly é associado a um número de versão de quatro partes. Da esquerda para a direita, as partes principais, secundárias, de build e de revisão são separadas por períodos. Altere o número principal ou secundário de um assembly para uma versão incompatível com versões anteriores. Altere apenas as partes de build e revisão para alterações compatíveis com versões anteriores no assembly. Por exemplo, um desenvolvedor pode adotar um método de numeração no qual todos os números de versão 1.0.0.* se referem a versões de atualização para o assembly versão 1.0.0.0.