Conforme descrito no Capítulo 1, chegou o momento de apresentarmos mais alguns detalhes sobre Assemblies e sobre o formato (ou quem sabe anatomia) de uma aplicação .NET.

Uma definição em poucas palavras.

Para aplicações tradicionais do Windows, anteriores ao modelo .NET, a aplicação final é um arquivo executável ou um arquivo executável mais um conjunto de .DLL e componentes. Uma DLL pode conter um objeto COM/COM+ eu uma biblioteca de tipos (typelib).

Para o Framework .NET, os diversos componentes de uma aplicação são “empacotados” através da utilização de assemblies. Um assembly contém todo o código MSIL gerado pelo compilador, os meta dados e os demais arquivos necessários ao funcionamento da aplicação. Cada assembly também contém um “manifesto”. O manifesto contém as seguintes informações:

• Uma lista dos arquivos contidos no assembly.
• A definição de quais tipos e recursos do assembly podem ser acessados por outros componentes ou programas.
• Um mapeamento entre os tipos e recursos disponibilizados pelo assembly e os arquivos que contém os tipos e recursos.
• Uma lista de outros assemblies, dos quais o assembly depende para o seu correto funcionamento.
• Informações sobre a identidade do assembly, incluindo o nome e a versão do assembly.
• Se o assembly for público, como por exemplo um Web Service, o manifesto também pode conter a chave pública do assembly. Este é um mecanismo semelhante, em funcionalidade, a utilização de um Certificado Digital, para identificar a origem de um controle ActiveX.

Um assembly contém toda a informação necessária ao seu funcionamento. Ao definirmos um assembly o mesmo pode estar contido em um único arquivo ou em múltiplos arquivos. A vantagem de utilizar múltiplos arquivos é que as diferentes partes do assembly podem ser carregadas e executadas a medida que as mesmas forem sendo utilizadas.

Funções do assembly:

Pela descrição anterior podemos concluir que o assembly é um elemento fundamental na criação de aplicações .NET. Os assemblies foram projetados, principalmente, para simplificar o processo de distribuição de aplicações e para solucionar o problema do controle de versões existente no modelo COM/COM+. Um assembly é responsável pelas seguintes funções:

• Contém o código executado pelo CLR. O código MSIL contida em um arquivo PE (portable executable) não poderá ser executado se o mesmo não estiver associado a um manifesto.
• É a unidade básica para atribuição de permissões e configurações de segurança. Podemos definir, a nível de assembly, quem pode acessa o assembly e com que nível de acesso.
• É uma unidade de referência, pois as informações contidas no manifesto do assembly, são utilizadas para resolver tipos e para atender requisições de outros assemblies. Estas informações definem quais os métodos e propriedades que são visíveis externamente. O manifesto também contém informações a respeito de quais assemblies, o assembly em questão depende.
• É uma unidade para definição de versão. A atribuição de um número de versão é feita a nível de assembly.
• É uma unidade de distribuição das aplicações .NET. Quando uma aplicação é inicializada, somente o assembly chamado na inicialização da aplicação precisa estar disponível. Outros assemblies somente são chamados a medida que forem sendo utilizados. Essa é uma característica muito importante, principalmente para aplicações Web, onde a velocidade das conexões é sempre um fator muito importante a ser considerado.

Assemblies podem ser estáticos ou dinâmicos. Assemblies estáticos podem incluir tipos do Framework .NET (interfaces e classes), além dos recursos utilizados pelo assembly (bitmaps, .jpg files, arquivos de som ou imagem, etc). Assemblies estáticos são gravados em disco em arquivos PE. Na verdade um arquivo PE pode ser gravado na forma de um EXE ou uma DLL.

Assemblies dinâmicos rodam diretamente da memória a não são salvos no disco antes de serem executados. Após a execução podemos salvar assemblies dinâmicos em disco.

Componentes do assembly

Um assembly estático é formado pelos seguintes componentes:

• Manifesto, o qual contém meta dados do assembly.
• Meta dados sobre os tipos do assembly (Type metadata).
• Código MSIL.
• Demais recursos necessários, como por exemplo arquivos gráficos, arquivos de vídeo, etc.

Podemos agrupar todos os elementos constituintes do assembly em um único arquivo, conforme ilustrado na Figura 2.2.

Figura 2.2 Assembly e seus componentes em um único arquivo.

Os componentes do assembly também podem estar divididos em diversos arquivos. Estes arquivos podem conter módulos de código compilado, recursos (como por exemplo arquivos gráficos ou de vídeo) ou qualquer outro arquivo necessário ao funcionamento da aplicação .NET.

Existem duas razões para a colocação dos componentes de um assembly em múltiplos arquivos:

• Quando precisamos combinar, na mesma aplicação, componentes ou módulos criados em diferentes linguagens.
• Para otimizar o Download dos componentes de uma aplicação, de tal maneira que os componentes ou módulos, menos utilizados somente sejam carregados quando forem necessários. Esta é uma alternativa importante, principalmente para aplicações Web.

Na Figura 2.3 temos o exemplo de um assembly composto de quatro arquivos:

• Um arquivo é o módulo principal. – criado em VB.NET.
• Outro arquivo é o módulo com funções (Criado em C#) usadas pelo assembly principal .
• Um arquivo .bmp.
• Um arquivo .jpg.

Figura 2.3 Um assembly vários arquivos.

O que temos no “Manifesto”?

O Manifesto contém o seguinte conjunto de informações (meta dados):

• Qual a relação entre os diferentes componentes do assembly.
• Informações sobre a versão do assembly.
• Escopo.
• Informações para resolver referências a outras classes e componentes.

O manifesto pode estar contido em um arquivo PE – Portable executable (pode ser um .exe ou uma .dll), juntamente com o código MSIL ou pode estar em um arquivo PE separado, o qual contém somente o manifesto. Esta última situação acontece quando temos um assembly formado de diversos arquivos.

As informações contidas no manifesto são responsáveis pelas seguintes funções:

• Relação dos arquivos que compõem o assembly.
• Gerencia o mapeamento entre os tipos e recursos disponibilizados pelo assembly e os arquivos onde estão contidas as declarações e implementações dos respectivos tipos e recursos.
• Relaciona os assemblies dos quais o assembly em questão é dependente.

Em resumo, reforçando o que já foi comentado no Capítulo 1, este conjunto de informações fornece uma autonomia ao assembly, de tal maneira que o mesmo contém toda a informação necessária ao seu funcionamento. Isso evita que o assembly tenha que ser registrado. Com estes recursos, o processo de instalar uma aplicação .NET está resumido a copiar os arquivos necessários, como diriam os ainda apaixonados pelo DOS, voltamos ao estilo “xcopy” de instalação, em referência ao comando xcopy, o qual é utilizado para copiar arquivos ou pastas.