Vamos ver quais os passos envolvidos, desde a criação de uma aplicação utilizando uma das linguagens habilitadas ao .NET, até a execução da mesma, sob o controle do CLR.

Os passos para a criação e execução de uma aplicação .NET podem ser resumidos da seguinte maneira:

• Cria a aplicação ou componente utilizando uma linguagem habilitada ao .NET (VB.NET, C#, etc).
• Compile o código da sua aplicação ou componente para gerar código MSIL. O compilador da linguagem que você está utilizando, compila o seu código fonte para MSIL e acrescenta os meta dados necessários.
• Em tempo de execução, um compilador JIT (Just In Time) do CLR, transforma o código MSIL em código nativo, COMPILADO.
• O código nativo é executado, utilizando toda a infraestrutura disponibilizada pelo CLR.

Na Figura 2.1, temos uma ilustração destes passos.

Figura 2.1 O processo de execução de código do CLR.

Conforme ilustrado na Figura 2.1 quando compilamos o código fonte criado por uma linguagem habilitada ao .NET, estamos gerando MSIL, a qual é um conjunto de instruções, independente da CPU, conjunto este que pode ser convertido (pelo JIT) para código nativo. O código MSIL inclui instruções para carregar, armazenar, inicializar e chamar métodos, instruções para operações aritméticas e lógicas, controle de fluxo do programa, acesso direto a memória, tratamento de exceções e demais operações necessárias a execução do programa.

Antes que o código MSIL possa ser executado o mesmo precisa ser convertido para código específico da CPU em questão. Isto é feito pelo JIT – Just in time compiler. O CLR disponibiliza compiladores JIT para cada arquitetura suportada pelo CLR, desta maneira o mesmo conjunto de instruções MSIL pode ser compilada e executada em qualquer arquitetura para a qual exista um compilador JIT.

Esta é a estratégia da Microsoft para fazer com que o código MSIL de aplicações .NET possa ser executado em diferentes plataformas, desde servidores Windows ou não Windows, até dispositivos móveis para os quais esteja disponível um compilador JIT. É claro que a implementação em outras plataformas que não o Windows, como por exemplo o UNIX, dependerá da implementação de terceiros. Por exemplo, a HP pode querer implementar um compilador JIT que rode no HP-UX, fazendo com que aplicações .NET possam rodar nesta plataforma. Se surgirão implementações para outras plataformas é uma questão que somente o tempo e o mercado dirão.

Quando o compilador de uma linguagem habilitada ao .NET produz o código MSIL, o mesmo também cria os meta dados necessários. O código MSIL e os meta dados estão contidos em um arquivo PE – portable executable. O portable significa que este arquivo pode, em tese, ser compilado e executado em qualquer plataforma para a qual existe um compilador JIT. A presença dos meta dados, juntamente com o código MSIL torna o código auto descritivo, o que significa que não temos mais a necessidade de “bibliotecas de tipo” (type libraries) ou IDL – Interface Definition Language; dispositivos que eram necessários ao funcionamento de componentes baseados no modelo COM/COM+. Voltamos a salientar este ponto, o componente criado para o .NET possui, na forma de meta dados, toda a informação necessária ao seu funcionamento e necessária para que possa ser acessado por outros componentes. O CLR localiza e extrai os meta dados do arquivo PE durante a execução, a medida que isso vai sendo necessário.

Mais algumas observações sobre o JIT.

O processo de compilação utilizado pelo JIT procura fazer uma série de otimizações, para tornar o código nativo gerado, o mais enxuto e veloz possível.

O JIT detecta se algum método ou propriedade não será utilizado durante a execução do programa. Ao invés de converter todo o código MSIL, contido no arquivo PE, o JIT converte apenas o código que realmente será necessário para a execução do programa. Isso faz com que a compilação seja mais rápida, com que sejam poupados recursos como por exemplo memória e o código resultante é otimizado, tanto em termos de tamanho quanto de velocidade de execução.

Como parte da compilação do MSIL para código nativo, o código deve passar por um processo de verificação, a não ser que foi definida uma política de segurança que permite ao código passar pela verificação. O processo de verificação faz uma análise do código MSIL e dos meta dados, para definir se o código pode ser definido como “type safe”. Para que o código possa ser definido como type safe, o mesmo somente deve acessar regiões de memória para as quais o mesmo tem autorização. Este processo é necessário para garantir que os objetos estão isolados uns dos outros, de tal maneira que um objeto não tente alterar ou corromper dados de outros objetos. Na plataforma Windows 9x, quando um programa tenta acessar a área de memória utilizada por outro programa, é gerada uma “Falha Geral de Proteção”, com a famigerada mensagem “Você Executou uma Operação Ilegal e o seu programa será fechado”.

Para que o código passe no teste de “type safe”, o mesmo deve atender as seguintes condições:

• Todas as referências feitas a um determinado tipo são compatíveis com o tipo que está sendo referenciado.
• Somente operações devidamente definidas são invocadas pelo objeto.
• É possível verificar e confirmar a identidade do objeto. Isso evita que um componente, por exemplo um vírus, se faça passar por um componente válido, porém com um comportamento bem diferente do verdadeiro componente.

O processo de verificação também faz uma análise do código MSIL, para ver se o mesmo foi corretamente gerado. Se as políticas de segurança da nossa aplicação definem que o código deve passar na verificação de “type safe” e o código não passar nesta verificação, uma exceção será gerada quando o código for executado.

O mecanismo de verificação do código é um exemplo típico de funcionalidade disponibilizada pelo Framework .NET, a qual, nos modelos anteriores precisava ser desenvolvida pelo programador.

Um detalhe importante é que nem todo o código MSIL é compilado para código nativo, de uma só vez. A compilação acontece a nível de método. Quando um método é chamado, o código MSIL do mesmo é compilado, o código nativo é gerado pelo JIT e o método é executado. O código nativo gerado é mantido. Quando o método for chamado pela segunda vez, o código nativo gerado na primeira chamada será executado, evitando, com isso, que o código do método tenha que ser compilado a cada chamada do mesmo, o que acarretaria em uma perda considerável de desempenho.