Jump to content


Photo

Um Pouco De Arquitetura – Clr – Msil E Assemblies


  • Faça o login para participar
Nenhuma resposta neste tópico

#1 MACUL

MACUL

    Doutor

  • Usuários
  • 770 posts
  • Sexo:Masculino
  • Localidade:SP

Posted 08/04/2005, 11:09

Um pouco de arquitetura – CLR – MSIL e Assemblies
Autor: Rubens Araújo Guimarães – Especialista em tecnologia aplicada ao mercado


Faremos a seguir uma análise às tecnologias que estão por traz do .NET. Estas tecnologias são responsáveis por compilar, processar e gerenciar a tecnologia .NET

O Framework se tornou uma plataforma indispensável para gerenciar códigos e tecnologias .NET. Com uma estrutura inteligente, o Framework marca sua presença na comunidade de TI e mostra que será a inspiração das tecnologias da próxima geração.

Um dos principais componentes da .NET Framework é a Common Language Runtime ou CLR. A CLR fornece vários benefícios para o desenvolvedor, tais como tratamento de erros, segurança, depuração e controle de versão, e estes benefícios estão disponíveis em qualquer linguagem criada para a CLR. Isto quer dizer que a CLR pode servir a uma variedade de linguagens e pode oferecer um conjunto comum de ferramentas para estas linguagens. A Microsoft criou o VB .NET, C++ .NET, e C# como as principais linguagens para a CLR, o que significa que estas três linguagens dão total suporte para a CLR. Em adição, outras empresas têm sinalizado que fornecerão implementações de outras linguagens, tais como Perl, Python e COBOL.

Quando um compilador compila para a CLR, o código é chamado de código gerenciado. Código gerenciado é simplesmente código que tira vantagem dos serviços oferecidos pela CLR. Para que a CLR funcione com o código gerenciado, este código deve conter metadados. Estes metadados são criados durante a compilação por compiladores que visam a CLR. Os metadados são armazenados com o código compilado e contêm informações sobre os tipos, membros e referências no código. Entre outras coisas, a CLR usa os metadados para:

- Localizar classes
- Carregar classes
- Gerar código nativo
- Fornecer segurança

Se você pensar sobre isto, as tarefas acima costumam ser feitas pelo COM e o registry. Uma das metas da .NET é permitir que as aplicações sejam distribuídas sem a necessidade de usar o registry. De fato, os componentes .NET podem ser copiados para um diretório e usados, sem a necessidade de um processo de registro. .NET trata de localizar e carregar os objetos do componente, o que substitui o trabalho que costumava ser feito pelo COM.

A CLR também cuida do tempo de vida dos objetos. Assim como COM/COM+ forneciam contagem de referências para objetos, a CLR gerencia referências a objetos e os remove da memória quando todas as referências desaparecem através de um processo chamado garbage collection . Embora garbage collection lhe dê um pouco menos de controle do que aquele que você tinha no VB, você ganha alguns importantes benefícios. Por exemplo, seus erros diminuirão porque o número de objetos que permanecem na memória apenas por estarem envolvidos em referências circulares será reduzido ou completamente eliminado, porque o .NET tem lógica para lidar com objetos que estão presos a referências circulares. Além disto garbage collections acabam sendo muito mais rápidas que o modo antigo de destruição de objetos no VB. Instancias de objeto que você cria e que são gerenciados pelo CLR são chamados dados gerenciados. Você pode interagir tanto com dados gerenciados como com dados não gerenciados na mesma aplicação, embora só os dados gerenciados lhe dão todos os benefícios da CLR.

A CLR também define um sistema de tipos padrão para ser usado por todas as linguagens que suportam a CLR. Isto significa que as linguagens do tipo CLR terão os integers e longs de mesmo tamanho, e elas terão todas o mesmo tipo de string - sem mais preocupações com BStrs e CStrs! Este sistema padrão de tipos abre as portas para uma poderosa interoperabilidade entre linguagens. Por exemplo, você pode passar uma referência de uma classe de um componente para outro, mesmo se estes componentes sejam escritos em linguagens diferentes. Você também pode derivar uma classe no C# de uma classe base escrita em VB .NET, ou qualquer outra combinação de linguagens criadas para a CLR. Não esqueça que COM também tem um conjunto de tipos padrão, mas são padrões binários. Isto significa que com COM, você tem interoperabilidade de linguagens em tempo de execução. Com o padrão .NET , você tem interoperabilidade entre linguagens em tempo de design.

Após ter sido compilado, o código gerenciado contém metadados, os quais contêm informação sobre o componente em si, e os componentes usados para criar o código. A CLR pode verificar para se certificar de que os recursos de que você depende estão disponíveis. Os metadados eliminam a necessidade de armazenar informações sobre componentes no registry. Isto significa que, mover um componente de uma máquina para outra não necessita de registro (a menos que seja um assembly global).

Como você pode ver, a Common Language Runtime fornece um número de benefícios que não só são novos, mas que enriquecem a experiência de criar aplicações.


Execução Gerenciada

Para entender como suas aplicações VB .NET funcionam, e como diferem do código escrito em VB 6.0 para outras aplicações, é importante entender código gerenciado e como ele funciona. Para usar a execução gerenciada e ganhar os benefícios da CLR, você precisa usar uma linguagem que tenha sido criada para o runtime. Felizmente para você, o VB .NET está entre estas linguagens.

O runtime é um ambiente neutro do ponto de vista de linguagem de programação, o que significa que qualquer fabricante pode criar uma linguagem que tira vantagem das características do runtime. Compiladores diferentes podem expor o runtime em diferentes graus para o programador, assim a ferramenta que você usa e a linguagem na qual você codifica podem parecer funcionar algo diferente. A sintaxe de cada linguagem é diferente, naturalmente, mas quando o processo de compilação se inicia, todo o código deve ser compilado em algo compreensível pelo runtime.


Microsoft Intermediate Language (MSIL)

Um dos aspectos mais interessantes da .NET é que quando você compila seu código, você não compila em código nativo. Antes que vocês desenvolvedores em VB entrem em pânico e temam estar retornando aos dias de código interpretado, saibam que o processo de compilação traduz o código em algo chamado Microsoft Intermediate Language, que é chamado de MSIL ou simplesmente IL. O compilador também cria a necessária meta-informação (informação que descreve informação) e a compila no componente. Este código resultante é independente de CPU.

Após a IL e as meta-informações serem gravadas em um arquivo, este arquivo compilado é chamado de PE, que e abrevia "portable executable" ou "physical executable". Porque o PE contém a IL e as meta-informações, ele é auto-descrito, eliminando a necessidade de uma type library ou interfaces especificadas com a Interface Definition Language (IDL). A meta-informação é tão completa que qualquer linguagem .NET pode herdar das classes contidas neste PE. Lembre-se que a .NET é compatível em tempo de design, e isto permite que, enquanto você desenvolve em VB .NET, você possa herdar de classes criadas no C#, e você terá total acesso ao IntelliSense e outros recursos do Visual Studio .NET.

O Compilador Just-In-Time

O seu código não permanece em IL por muito tempo, contudo. A IL é independente de plataforma. porque o arquivo PE contendo a IL pode ser distribuído e instalado com a CLR rodando na .NET Framework em qualquer sistema operacional para o qual exista a .NET Framework. Quando você roda a IL, contudo, ela é compilada em código nativo para a plataforma alvo. Portanto, você ainda está executando código nativo; você não está voltando aos tempos de código interpretado. A compilação para código nativo ocorre via uma outra ferramenta da .NET Framework: o compilador Just-In-Time (JIT).

Com o código compilado, ele poderá rodar dentro do Framework e tirar vantagem das características de baixo nível tais como gerenciamento e proteção de memória. O código compilado é nativo para a CPU na qual a .NET Framework esteja rodando, significando que você está seguramente rodando código nativo e não código interpretado. Um compilador JIT será disponibilizado para cada plataforma na qual a .NET Framework rodar, assim você sempre terá código nativo em qualquer plataforma que rode a .NET Framework.

Curiosamente, o compilador JIT não compila a IL toda quando o componente é chamado pela primeira vez. Ao contrário, cada método é compilado somente na primeira vez que é chamado. Isto evita que você compile seções de código que nunca são chamadas. Após o código ter sido compilado, naturalmente, chamadas posteriores usarão a versão compilada do código. Este código nativo compilado irá permanecer na memória. Contudo, a Microsoft criou um compilador Pré-JIT que compila todo o código de uma vez e armazenar a versão compilada em disco. Esta ferramenta é chamada ngen.exe e pode ser usada para pré-compilar toda a IL. Se a CLR não encontra uma versão pré-compilada do código, ela inicia o compilador JIT para fazer a compilação.

Assemblies
Uma das novas estruturas que você criará no VB .NET é o "assembly". Um assembly é uma coleção de um ou mais arquivos físicos. Os arquivos são quase sempre de código, tais como as classes que você cria, mas eles também podem ser de imagens, arquivos de recursos, e outros arquivos binários associados ao código. Tais assemblies são conhecidos como estáticos, porque você os cria e armazena em disco. Assemblies dinâmicos são criados em tempo de execução e não costumam ser armazenado em disco (embora possam sê-lo).

Um assembly representa a unidade de distribuição, controle de versão, reuso e segurança. Se isto soa como as DLLs que você tem criado em Visual Basic nos últimos seis anos, é similar. Assim como uma DLL padrão de COM tem uma type library, o assembly tem um manifesto que contem a meta-informação para o assembly, tais como as classes, tipos e referências contidas na IL. O assembly frequentemente contém uma ou mais classes, assim como uma DLL COM. Na .NET, as aplicações são construídas usando assemblies. assemblies não são aplicações no sentido completo.

Talvez o ponto mais importante sobre assemblies é que: Toda aplicação deve ser constituída de um ou mais assembly.
*************** M ** A ** C ** U ** L ***************

*************************************************




0 user(s) are reading this topic

0 membro(s), 0 visitante(s) e 0 membros anônimo(s)

IPB Skin By Virteq