A primeira coisa a falar do novo .Net Framework é uma que entendo como fundamental: é possível rodar versões diferentes do CLR em um mesmo processo. Mas antes de explicar isso, deixa eu explicar outra coisa. Pra quem não lembra, não é todo lançamento do .Net Framework que atualizou o CLR. Na versão 4.0 houve uma nova versão de CLR, e ela é na verdade a quarta versão pública, mas na verdade é a terceira grande versão. A figura abaixo exemplifica isso:

Versões do CLR

Notem que a versão 1.0, lançada em 2002, teve um CLR, e que a 1.1, que foi um pequeno ajuste e foi lançada em 2003, teve outro CLR. Então aguardamos até 2005 para o lançamento da versão 2.0 do framework, com um novo CLR, desta vez um grande update. As versões seguintes, 3.0, 3.5, e 3.5SP1, lançadas em 2007, 2008 e 2009 não tiveram um CLR, rodavam sobre o CLR da 2.0. E antes que você comente, eu também acho essa nomenclatura de numeração confusa. De qualquer forma, a versão 4.0, lançada agora em 2010, possui um novo CLR. Se o Deus da numeração quiser, a próxima versão do .Net vai ser a 5, e não alguma 4.x (ou 6, né, vai saber…).

O CLR é responsável por rodar a aplicação. Ele contém os principais componentes de infraestrutura, como os que gerenciam a alocação da memória e sua coleta, segurança, tratamento de erro, gerenciamento de threads, etc.

O Common Language Runtime (CLR)

Esse é o motivo que quando você vai no IIS configurar um application pool, deve escolher a versão do CLR:

Edit Application Pool do IIS mostrando as versões do CLR disponiveis

E não existe opção para versão do .Net Framework. No meu exemplo, há o CLR 2.0, e o CLR 4.0. Não existe, e vocês nunca vão ver, as opção 3.0, ou 3.5, porque não há CLR 3.0 ou 3.5.

E essa caixa de diálogo existe porque antes era impossível rodar duas versões do CLR em uma mesma aplicação. Por exemplo, se você fizesse um add-in para o Outlook com .Net 2.0, 3.0 ou 3.5, que rodam sobre a CLR 2, não seria possível rodar em paralelo outro add-in feito com a CLR 1. O add-in que subisse primeiro iria carregar junto sua CLR, e o seguinte não iria rodar:

CLR 1 e 2 juntos não pode

O mesmo acontecia com o IIS 6, quando eram configuradas em uma mesma application pool aplicações ASP.Net que trabalhavam com versões diferentes do CLR. Quando uma aplicação 1.0 subia, as 2.0 não subiam. E vice-versa.

Notem que isso não significa que uma aplicação .Net 2.0 não podia referenciar componentes feitos com .Net 1.0. Nesse caso, tudo rodava no CLR 2.0.

O .Net 4 não resolve os conflitos da CLR 1 com a CLR 2, mas ele resolve o conflito dele mesmo e qualquer uma destas CLRs. Agora é possível rodar em um mesmo processo algo feito com a versão 4 e com a versão 2, ou feito com a versão 4 e com a versão 1:

CLR 4 e 2 juntos pode!

Ainda não é possível rodar as versões 1 e 2 juntas.

De qualquer forma, imagino que aquela caixinha do IIS vai perder sentido em alguns anos. É um grande avanço, e muito bem vindo.

tags

.NETCLR

Giovanni Bassi

Arquiteto e desenvolvedor, agilista, escalador, provocador. É fundador e CSA da Lambda3. Programa porque gosta. Acredita que pessoas autogerenciadas funcionam melhor e por acreditar que heterarquia é mais eficiente que hierarquia. Foi reconhecido Microsoft MVP há mais de dez anos, dos mais de vinte que atua no mercado. Já palestrou sobre .NET, Rust, microsserviços, JavaScript, TypeScript, Ruby, Node.js, Frontend e Backend, Agile, etc, no Brasil, e no exterior. Liderou grupos de usuários em assuntos como arquitetura de software, Docker, e .NET.