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:

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.

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

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:

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:

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.

A Microsoft anunciou, em um post do time de ADO, que não vai mais desenvolver seu provider de ADO.Net para Oracle. A última versão é a que sai agora no .Net 4.0, e todas as classes estarão marcadas como obsoletas. No .Net vNext, todo o provider não vai mais existir no BCL.

A Oracle faz o próprio provider dela, o ODP.Net, e ele é gratuito e funciona bem. Em diversos pontos é melhor que o da Microsoft, em outros pior.

A Microsoft não anunciou, e pelo que vejo, nunca vai anunciar, um provider para Entity Framework para o Oracle.

O que isso tudo significa?

Na minha visão isso significa que a Microsoft aprendeu, já quando lançou o EF1, que não deve fazer o trabalho de outras empresas, incluindo aí o da concorrente Oracle. As empresas querem um provider para Oracle para o ADO.Net ou para o EF, que pressionem a Oracle para que entregue um.

Exigir da MS que faça um provider de Oracle para o ADO.Net é como exigir que ela faça um player de Flash para o IE, e não a Adobe, ou uma VM de Java para o Windows, e não a Sun (ou qualquer outra empresa que implemente as especificações do Java). No caso, ela até fazia uma JVM própria, mas parou com isso. Agora foi a vez do provider do Oracle.

O que eu acho disso tudo?

Acho mais do que certo. Primeiro porque não é do interesse de uma empresa ficar fazendo software para suportar aplicações de outras empresas. Segundo porque o time de ADO vai estar livre para investir mais no ADO. Terceiro porque libera a Microsoft de ter que ficar polindo um produto que pode ter bugs, e os bugs muitas vezes nem são seus, ou nem deviam estar sob responsabilidade dela para começar. Quarto porque a Microsoft dá claros sinais de fortalecimento ao ecossistema de parceiros quando faz esse tipo de coisa, já que algum parceiro poderá implementar o provider. E quinto, a Microsoft para de reinventar a roda, assumindo que o que há no mercado é bom o suficiente, e por isso ela não tem que ter a versão dela da tecnologia xyz.

(Esse quinto motivo é meio complicado. Muitas empresas não usam software se não for marcado a ferro com a marca Microsoft. É o caso de componentes de Mock, onde a Microsoft não possui uma alternativa. Muita empresa não usa porque a Microsoft não incentiva oficialmente – descontado o P&P, não fomenta o uso, já que não tem um produto para atender.)

Eu sei que algumas empresas vão sofrer, porque utilizam o provider da Microsoft. Então fica aqui a recomendação: se você usa, pare de usar já. Comece a migrar para o ODP.Net ou para outras alternativas, praticamente todas pagas (o lado bom é que algumas suportam EF). Quem começar a pensar nisso agora tem uns bons anos pela frente, já que a Microsoft ainda nem deve ter entrado em fase de concepção do .Net vNext.

Além do mais, código legado vai continuar funcionando e compilando. O único problema será quando você converter uma solução de .Net 4 ou inferior para o .Net vNext. Nesse caso, você vai ter que substituir o provider. Ainda que o ADO.Net abstraia todo o conceito de objetos concretos, eu pouquíssimas vezes vi alguém usando um DbCommand no lugar de um OracleCommand. Dá-lhe mão de obra para arrumar isso.

Aproveitando o problema que esse tipo de coisa vai gerar, deixo aqui algo para reflexão: se você sofrerá com isso, lembre-se que não teria tido problema se adotasse um ORM (se possível). Quem sabe não é a hora?

Acaba de sair hoje o Service Pack 1 do Framework 3.5, juntamente com o SP1 do VS 2008. Você pode baixá-los aqui e aqui. O SP do Visual Studio também pode ser baixado em formato ISO, o que te permite otimizar o download se você tem um download manager. O ISO está aqui.

Alguns links legais para quem quer saber um pouco mais sobre o release:

1. Por que o VS 2008 SP1 não se chama VS 2009, no blog da Mary Jo Foley.
2. Post do Somasegar, que sempre detalha bem o que está saindo de novo.

Com o SP 1 o Visual Studio 2008 passa a suportar também o SQL Server 2008. Eu havia tido problemas ao tentar instalar o SQL Server 2008, porque ele pedia o VS 2008 SP1. Imagino que agora consigo instalar. Cheguei a questionar se o RTM do SQL Server 2008 trabalhava com o Beta do VS 2008 SP1. Na verdade, os releases foram separados somente alguns dias, o que levou a essa confusão.

Já tem também alguns brasileiros falando, como o Renato Guimarães, sempre ligadaço.

O que você ganha de significativo, na minha opinião, com o SP1 para o VS 2008:

• Melhorias no designer do WPF;
• Suporte ao SQL Server 2008;
• ADO.NET Entity Designer;
• Melhorias no Visual Studio Team System Team Foundation Server (TFS), melhorando o versionamento, performance, integração de e-mail, e suporte ao SQL Server 2008;
• Mais suporte ao javascript (mais?? inacreditável);
• Mais AJAX.

E com o SP 1 do .Net Framework:

• Melhorias de performance entre 20 e 45% para aplicações WPF (sem mecher no código);
• Mais controle sobre o WCF;
• ADO.NET Entity Framework;
• ADO.NET Data Services;
• Suporte às novidades do SQL Server 2008.

Há suporte ao ASP.Net MVC Preview 3. Será que o P4 funciona? Depois atualizo vocês com o que eu descobrir.

É… e eles lançaram mesmo o Entity Framework do jeito que estava. Mesmo com as criticas fortes da comunidade ao EF, não houveram grandes mudanças. Cheguei até a bater uma bola com o Otavio Pecego Coelho, arquiteto da Microsoft, no blog dele, sobre o EF. Ele ficou de colocar um exemplo mostrando que eu poderia ver as coisas de outra maneira com relação ao EF, estou aguardando.

Concordo com a Mary Jo Foley quando ela sugere chamar o VS 2008 de VS 2009. Mas acho que, na prática, ia ser difícil vender uma versão nova depois de apenas 8 meses, e esse deve ter sido um dos grandes motivos da manutenção do nome e ter feito da atualização um SP. Mas que tem muita novidade para ser um Service Pack, tem. Não é só um monte de correções de bugs, como pode-se notar. Tem um monte de coisa nova. Enfim, os nomes dos softwares relacionados ao .Net continuam confusos.

Meu SP 1 está neste momento em processo de instalação. Fiquem atentos à ferramenta de limpeza do Hotfixes do Visual Studio 2008. Vocês podem precisar dar uma faxinada no seu ambiente antes de instalar o SP 1.

E assim que terminar de instalar, vou terminar minha instalação de SQL Server 2008.

E vou matar uma VM, que agora ficou inútil, já que só servia para os testes do SP 1.

E vocês quando pretendem instalar?

A Microsoft estará lançando em breve o SP1 do .Net Framework 3.5/Visual Studio 2008. Lançou a pouco tempo o Beta 1(baixe aqui, se você ainda não o fez), e a versão final não deve passar de Junho. Um monte de gente, aqui e lá fora já falou sobre isso, entre eles: ScottGu, Somasegar, obviamente Scott Hanselman (do que esse cara não falou?), Renato Guimarães e Cezar Guimarães.

Eu já instalei o meu, funcionou direitinho em uma VM com o VS 2008 instalado do zero, e deu um problema estranho bem no final da instação (que não permitiu terminar) para uma instalação existente já com um monte de outros betas que eu tinha instalado e desinstalado (por isso eu nunca instalo bits muito quentes em minhas máquinas principais, somente VMs feitas pra isso).

Mas não era isso que eu queria falar. O que que eu acho estranho é essa nomeação confusa que a Microsoft anda criando. Vejam só:

• .Net Framework, Versão 1.0 - Ok, perfeito, primeira versão.
• Versão 1.1 - ok, versão de updates de bugs, novo minor number, poucos breaking changes, e na prática é a versão que todo mundo usou até a versão seguinte, que é a...
• Versão 2.0 - wow, grandes atualizações, novo CLR, tudo certo, novo major number.
• Versão 3.0 - não tivemos um novo CLR, mas tivemos 5 grandes tecnologias, ok, até compreendo o novo major number. Não sei se vocês lembram, mas não ia ser um major, mas um minor number (ia ser versão 2 ponto alguma coisa - 2.x), a própria Microsoft falou sobre isso algumas vezes. O objetivo era dar importância ao release. Começou a ficar estranho...
• Versão 3.5 - novamente não há um novo CLR (o atual continua muito bom). Mas não é um grande upgrade da versão 3.0. Houveram melhorias no WCF, no WF, no WPF, etc... mas porque pulou do 3.0 para o 3.5??? Novamente acredito que é para dar importância ao release, mas porque não fizeram então chamando a versão de 4.0 de uma vez?
• Versão 3.5 SP1 - há atualizações de segurança, mas há também uma série de novidades. O Routing, o Dynamic Data, controles novos no AJAX, melhorias no Click Once, entre várias outras. Essa numeração agora ficou realmente confusa. Porque não chamaram de 3.6, ou 4.0?

Esse negócio vai ficar confuso de gerenciar. Alguém pergunta: "Que versão você tem do Framework?", você responde "a versão 3.5", e vem uma nova pergunta "Qual delas?" ou "Com Service Pack?".

Eles poderiam serguir uma numeração mais clara e menos marketeira, mas enfim, vai entender. No fim, todas as tecnologias novas são excelentes, e vão fazer uma grande diferença.

Quem já instalou? Quem já estava pondo a mão nos brinquedos novos (Routing, Dynamic Data, etc)? Comentem aqui ou me mandem um e-mail.