fbpx
Uma parte do que você precisa saber sobre o Microsoft vNext
Publicado em: domingo, 18 de maio de 2014

[EDITADO]

Olá, como vai você? Espero que esteja tão excitado com as novidades da Microsoft quanto eu, mas se não estiver, vou tentar mostrar um pouquinho da revolução que estamos vivendo em nossa plataforma.

Nessa semana rolou o TechEd North America 2014 e nele muita coisa legal foi apresentada. Aqui faço um compilado da história da plataforma e dos posts mais interessantes, da própria galera da Microsoft e da galera que esteve por lá conferindo as sessões!

Não perca!

ASP

Primeiro, eu sou Luiz Carlos, acho que já me conhece um pouco. Eu aprendi a desenvolver com livros, antes de fazer alguns pequenos cursos, meus primeiros contatos com desenvolvimento foram com VB4/5. Com a falta de cursos de VB5, para um garoto que estava cursando a 8ª série do ensino fundamental, tive de optar pelo Delphi, pois havia um cursinho na minha cidade. Então comecei a programar em Delphi e nunca mais parei… e nem pretendo parar! Do Delphi tive, por causa da Petrobras, de migrar para ASP, no início sofri muito com a quebra de paradigma e senti falta de muita coisa. Eu já tinha um bom conhecimento sobre XML e dediquei boa parte do meu tempo na Petrobras à criação de alguns componentes para ASP. Nada complicado para quem conhecia HTTP, JavaScript, VBScript, mas absurdamente complexo para galera do ctrl-c ctrl-v. Na Petrobras eles têm até hoje em produção o GaGrid (lembrando que Gago é meu apelido).

Bom, isso era 2003, a plataforma .Net já estava bem encaminhada, firme, mas pela morosidade das grandes corporações, tínhamos contato, mas não oficial. Somente por volta de 2004, os primeiros projetos surgiram, oficiais, com a nova plataforma. Isso na Petrobras, claro.

ASP NET WEB FORMS

Com a chegada do .Net, o ASP.NET Web Forms me encantou, as eu sentia que havia uma parafernalha de processamento necessário para aquilo rodar. É impossível algo ser escalável com aquele tanto de camadas e com um ciclo de vida tão grande, mas… enfim, funcionou por anos. Independente da plataforma, quando você começa a construir frameworks e componentes de infraestrutura, inevitavelmente você terá contato com detalhes técnicos que vão dar pistas de como as coisas são feitas. Por sorte, a maioria (talvez todos) os assemblies do .Net Framework não venham criptografados, o que ajuda muito no entendimento de muitos fluxos e padrões. Assim, não é muito difícil quando se está criando componentes para o ASP.NET que você se depara com o ciclo de vida do ASP.NET. Olhando com um pouco mais de carinho para o System.Web, é possível entender que todo aquele pipeline poderia ter sido feito por você, por mim, ou por qualquer pessoa. Em resumo, é uma daquelas coisas que todos os seus amigos puristas diriam ser uma merda, mas que no final ganharia um prêmio nobel. Na prática o ASP.NET sempre esteve sobre o bom e velho HTTP e usando tudo o que o HTTP sempre ofereceu. Forms, Cookies e requisições baseadas em verbos. Talvez hoje, com o html5 pudesse ser mais fácil fazer o ASP.NET, mas definitivamente ele foi muito importante para a plataforma. A facilidade com que o desenvolvimento flui é extremo, mas ao mesmo tempo que traz produtividade, traz desinformação e muitas vezes leva profissionais à preguiça. Admito que o mais absurdo que eu via em alguns desenvolvedores, amigos meus, que haviam iniciado suas carreiras com o desenvolvimento para a web usando ASP.NET Web Forms, era a ausência de conhecimentos básicos sobre HTTP, Web Server. Coisas simples como POST, Request, QueryString, passavam longe dessa galera. Não era difícil, na equipe de Suporte ao Desenvolvimento, na Petrobras, ver alguém perguntando porque uma variável (que na verdade era um parâmetro, passado por querystring) não estava setado no server side, em uma classe qualquer. Enfim, não eram sêniors, mas a senioridade na plataforma .Net sempre foi algo questionável, principalmente pelo apelo da Microsoft para entubar sua RAD, com muito drag-and-drop, para a criação de sistemas imanuteníveis, desenvolvidos em poucas horas.

Por sorte, o mercado foi aprendendo com os erros, e em pouco tempo era fácil distinguir quem sabia ou não o que estava fazendo.

MVC

Em 2007, a Microsoft lança, no último mês do ano uma bomba: Uma nova forma de se fazer Web, um tal de ASP.NET MVC. Diferente do que eu havia visto no passado, vi muita empresa grande torcendo o nariz, principalmente pela necessidade de conhecimentos, requisitos básicos para o desenvolvimento Web, mas que por causa da forma como o ASP.NET Web forms havia sido deixado de lado, em muitos casos ignorado. É como se formássemos profissionais de engenharia que não soubessem calcular.

Mesmo com uma parte da comunidade, mais conservadora, torcendo o nariz, muita galera nova, que estava se aventurando com Python, Ruby gostou da ideia. Alguns bons hipsters se aventuraram sem prá-conceito, afinal, o pattern é bem velho. A minha visão sobre a coisa era bem simples: Com as experiências que eu via da Microsoft fazendo o Linq to SQL, Entity Framework e Unity, eu realmente não acreditei que o ASP.NET MVC fosse algo bom, mas de fato foi. A quebra de paradigma ajudou a comunidade. Outro ponto relevante, e dessa vez, por parte do mercado, e culminou com o lançamento do ASP.NET MVC, é a demanda por usabilidade. Nunca vimos usuários tão preocupados com UX. Por esse ponto de vista, temos realmente algo muito bom a oferecer saindo do Web Forms.

SOA

Nessa mesma época, SOA havia sido adotada como buzzword da década, mas estava prestes a morrer como unidade, deixando uma infinidade de padrões e flexibilizações bem mais reais que seu modelo inicial. Saía de um desenho full stack para um modelo adaptativo e mais flexível. Seus ensinamentos ficaram e perduram ao longo dos anos, e ganham força, novamente, com a adoção de Cloud Computing, mas ainda, com a flexibilidade dos dias atuais.

Podemos considerar SOA como um vírus que nasceu fadado à morte, mas seu RNA tende a se perpetuar pela eternidade. Ele não nasceu para prosperar, mas para mudar a forma como desenvolvemos software. SOA se foi, mas suas ideias nunca morrerão

Após o boom do SOA, não vimos grandes evoluções na plataforma, nos assemelhávamos ao mercado de telefonia móvel, sem Steve Jobs: Opaco. Nenhum grande lançamento, apenas updates de tudo o que já tínhamos disponível ha anos.

Nesse período temos o boom dos smartphones e assim das plataformas para desenvolvimento mobile. Movimentou bastante o mercado, mas não o mundo Microsoft. O movimento visto era de desenvolvedores, cada vez mais, experimentando novas plataformas de desenvolvimento mobile, e cada vez mais dedicando a maior parte do seu tempo a esses projetos, criando uma debandada natural. Num mar de efervescência de plataformas, serviços e cloud, ficou muito mais fácil brincar com outras plataformas e assim, tocar projetos em Objective-C, por exemplo, era como passar uma temporada fazendo UI: Algo diferente, trabalhoso, mas que no final das contas, seria gratificante.

 

2013 – 2015 .Net RevolutionNet

Bom estamos nos anos mágicos do .Net e se você não está up-to-date com a plataforma e seus lançamentos dos últimos anos, lamento, você já é um dinossauro. Inclusive acredito que deva deixar de assinar esse blog aqui para assinar um desses aqui: Dicas de Cobol, Fortran!!

Brincadeiras à parte, é uma realidade. A plataforma vem mudando muito e está em plena migração de conceito. Eu nunca havia sentido tanta excitação em falar das novidades da plataforma no passado. Incrivelmente estava sentindo que as coisas andavam paradas desde o framework 3.0 e 3.5 e sentia falta das grandes evoluções. Bom, agora é fácil entender, são 3 anos no desenvolvimento do Roslyn e outras soluções que culminaram no .Net Foundation e muita coisa interessante já chegou e está chegando.

Vou compilar o que foi dito em diversos blogs e comentar ao final ao longo do texto.

.Net Web Development and Tools Blog

ASP.NET MVC: Já foram lançadas 5 versões, mas definitivamente a mais empolgante está por vir. A versão 6 do, onde toda a dependência do System.Web deve morrer. No blog .NET Web Development and Tools Blog

  • MVC, Web API, and Web Pages sofrerão merge em um único framework chamado MVC 6. MVC 6 não dependerá do System.Web.
  • ASP.NET vNext incluirá novas versões do MVC 6, SignalR 3, e Entity Framework 7 otimizadas para nuvem.
  • ASP.NET vNext terá suporte verdadeiro para deployment side-by-side para todas as dependêncas, incluindo .NET para nuvem. Nada mais estará no GAC.
  • ASP.NET vNext será host agnostic. Você poderá hospedar sua aplicação no IIS, ou self-hosted em um custom process.
  • Dependency injection agora estará presente no framework.
  • Web Forms, MVC 5, Web API 2, Web Pages 3, SignalR 2, EF 6 terão total suporte no ASP.NET vNext
  • .NET vNext (Cloud Optimized) será um subset do the .NET vNext Framework, otimizado para a núvem e para server workloads.
  • MVC 6, SignalR 3, EF 7 sofrerão com quebras grandes mudanças:
    • Novo modelo de projetos (project.json)
    • Novo modelo de configuração
    • O merge entre MVC, Web API e Web Pages, usará um conjunto comum de abstrações de HTTP, routing, action selection, filters, model binding, e mais
    • Nenhuma dependência com System.Web e um novo e leve HttpContext

ASP.NET vNext

No blog, Mike Wasson entra no detalhe sobre alguns itens. Logo no início ele fala da versão otimizada do vNext .Net Framework para núvem. Fala da unificação das abstrações do Web Api, Mvc e Web Pages. Cita os ganhos da versão cloud-optimized como menor consumo de memória e startup mais eficiente. Um ponto interessante que está ficando cada vez mais claro é que o framework poderá ser publicado junto com sua aplicação. Isso significa que facilmente você faria deploy side-by-side de aplicações com versões diferentes de frameworks. Isso é um ganho absurdo para a gestão de infra e gerência de configuração. Todo o fluxo de gestão de mudança é simplificado.

Ele cita também um ponto que me fez dar pulos de alegria nos últimos dias:

vNext is host agnostic. You can host your app in IIS, or self-host in a custom process. (Web API 2 and SignalR 2 already support self-hosting; ASP.NET vNext brings this same capability to MVC.)

Quem acompanha o Oragon Architecture, sabe que estou fazendo um servidor de aplicação self-hosted, e para a UI, fui obrigado a construir eu mesmo um micro Mvc para poder hospedar no meu processo sem depender do IIS. Já hospedo Web API e Signal R, sem problemas, mas MVC foi algo que não consegui resolver… bom… eles irão!!!

Outro ponto interessante é a flexibilidade e agora ficou claro que será flexível, a possibilidade de injetar seu IoC container de preferência, olhe no texto abaixo:

Dependency injection is built into the framework. Use your preferred IoC container to register dependencies.

Há algumas semanas tive de tomar a mesma decisão com o Oragon Architecture. Essa é uma decisão que torna a vida do programador muito mais fácil. Sob qualquer circunstância, você usa o container, que hoje é algo imprescindível, que mais lhe convier. Fiz alguns testes com o SimpleInjector e com o Ninject, o primeiro é o mais performático do mercado, o segundo é o mais usado pelo mercado. Na minha opinião: Não abandono o Spring.Net nem por um carro zero!!

vNext uses the Roslyn compiler to compile code dynamically. You will be able to edit a code file, refresh the browser, and see the changes without rebuilding the project.

O Roslyn é um projeto fantástico, suas aplicações são extremamente abrangentes. No podcast do tecnoretórica tanto o Victor Cavalcante quanto o Giovanni Bassi comentam, de dentro do TechEd esse lançamento e fazem comparativos impressionantes com Rubby e NodeJS.

Por último, eu considero esse o ponto mais importante do vNext.

vNext is open source and cross platform.

No blog do Scott Hanselman, depois eu vou falar com calma nos posts dele, temos uma versão do vNext rodando no Mac!!! É animal! A proposta rodar o vNext no Windows, Linux e Mac. Essa mudança abre possibilidades infinitas. No meu caso que estava construindo um application server, a maior dificuldade era escalar horizontalmente. A quantidade de recurso que um servidor windows precisava para si era razoável. Qualquer máquina nova já consome seus 2GB de Ram e 20Gb de disco, sem nada instalado nela, portanto escalar horizontalmente com o Windows não é tão barato quanto escalar com linux. Mas não abro mão do .Net, portanto esse é o melhor dos mundos!

Nesse mesmo podcast que citei acima, a galera se questionava sobre o comando K. Nesse post do Mike Wasson temos uma explicação do que seria esse K. K é o K Version Manager, ou KVM. Em diversos blogs é possível ver o KVM em ação e o Mike explica que o Visual Studio ainda não suporta o vNext, e por isso vários exemplos com o KVM.

Algo que ficou claro para mim, e vamos ver isso depois, é que no project.json definimos comandos, o comando WEB, chamado via “k web” aponta para a definição “web” que é uma entrada na sessão “commands” do arquivo project.json.

O novo modelo de projeto, também é algo bem interessante no HelloWorld vNext temos a ausência do csproj. Vemos o project.json e o start.cs que segundo o Mike respectivamente representam a lista de dependêncas de sua aplicação (project.json) e a classe de startup do seu projeto. Quem já trabalha com OWIN Self-Host conhece essa estrutura do StartUp.

Um ponto que me chama a atenção é que eles mantiveram as convenções, o nome da classe precisa ser startup e esta precisa ter um método configure, como mostro abaixo:

using Microsoft.AspNet.Builder;

public class Startup
{
    public void Configure(IBuilder app)
    {
        app.UseWelcomePage();
    }
}

Bom, eu esperava uma interface! Mas… uma hora eu me acostumo com isso!

Vale ficar atento aos exemplos dessa página, todos usam o namespace Microsoft.AspNet como base. É o que deve acontecer com o MVC 6, convergir para um pacote com esse nome.

using Microsoft.AspNet.Builder;
using Microsoft.AspNet.StaticFiles;
using Microsoft.AspNet.Routing;
using Microsoft.AspNet.Mvc;

using Microsoft.Framework.DependencyInjection;

Bom, a página tem muitos exemplos interessantes de como está ficando o vNext, vale conferir. O título do tópico tem o link direto para o post.

Tecnoretórica

Giovanni Bassi e Victor Cavalcante, MVP s Brazucas direto do TechEd falando sobre as novidades direto após a sessão do dia 12. Você não pode perder esse podcast. Dura cerca de 1 hora, e algumas das respostas para algumas dúvidas que eles citaram, já  estão aqui. De qualquer forma vale a pena escutar cada segundo!!!

Somasegar’s blog

Eu realmente nunca ouvi falar nesse nome antes do podcast do tópico acima, admito, mas o post dele é bem interessante. Somasegar é VP da divisão de Desenvolvimento da Microsoft, e tem muita coisa interessante nesse post dele para falar.

Com ele temos a dimensão do que está por vir, acompanhe:

.NET has been a bedrock of the Microsoft developer ecosystem ever since its initial release more than 12 years ago. The over 6 million professional developers using .NET have built some of the most important software and solutions powering businesses, apps and sites today, and the 1.8 billion installs of.NET across devices have created a key foundation for productive application development.

Today, I am thrilled to share with you some important updates on the .NET platform, including a wide array of important innovations around .NET as well as the creation of the .NET Foundation to foster further innovation across the .NET ecosystem.

Tradução

. NET tem sido uma pedra fundamental do ecossistema de desenvolvedores da Microsoft, desde seu lançamento mais de 12 anos atrás. Os mais de 6 milhões de desenvolvedores profissionais usando. NET construíram os mais importantes softwares e soluções que alimentam empresas, aplicativos e sites atuais e as 1,8 bilhão instalações do .NET através de dispositivos criaram uma base fundamental para o desenvolvimento de aplicações produtivas.

Hoje, eu estou muito feliz de compartilhar com vocês algumas atualizações importantes na NET., Incluindo uma grande variedade de inovações importantes ao redor. NET, bem como a criação da Fundação. NET para fomentar ainda mais a inovação através do ecossistema .Net

Somasegar aborda a reestruturação da área de desenvolvimento da Microsoft, falando do .Net Foundation que representa a abertura do código de boa parte da plataforma, e o incentivo para que a comunidade definitivamente seja ativa em relação aos projetos e produtos do segmento develop da Microsoft. É uma forma de estreitar o canal de comunicação. Já vimos no User Voice (ASP.NET, ASP.NET MVCASP.NET Web APIASP.NET Web Forms,  Visual Studio, Windows Phone) muita iteração por parte da comunidade, mas nunca de um ponto de vista tão colaborativo.

Em algumas sessões no channel 9 vemos a reestruturação do C# que teve seu compilador reescrito em C#, com o Roslyn. Vemos o .Net Foundation, o Microsoft .Net Native, que ficou esquecido em diversos blogs e comentários a respeito dos lançamentos.

De quebra o indiano ainda fala do Roslyn auxiliando o Xamarin Studio, para Mac, o que demonstra a interoperabilidade real, da plataforma .Net. O RyuJIT, que também é pouco falado por aqui. Bom, mas no que um novo JIT pode me influenciar? Já pensou em soluções como MongoDB, Radoop entre outros? Soluções que gerenciam uma infinidade de conteúdo em memória, com gigas ou até terabytes de memória. Pois é, a maioria das aplicações desenvolvidas sob a plataforma .Net trabalham melhor sob 32 bits, do que em 64 bits, em um mundo que já está quase todo convergindo para 64 bits. Em resumo, algumas limitações que encontramos em soluções de cache em memória, NoSQL em memória, e preocupações com escalabilidade de soluções que precisam desse tipo de endereçamento de memória tendem a morrer. Na verdade, habilitam a plataforma .Net a prover esse tipo de solução. O RyuJIT é um Just-In-Time Compiler x64 pra valer!

.NET Framework Blog

Bom aqui temos um resumo do dia 12 no TechEd. Já começando falando do Microsoft .Net Native, do RyuJIT e já falando do C# 6, made Roslyn. Ele cita o lançamento do Visual Studio 2013 Update 2, mostrando suas mudanças no link e falando um pouco sobre o desenvolvimento para Windows Phone 8.1.

Em diante o texto começa a ficar interessante e você não pode perder. É o texto mais completo que achei sobre o vNext. De cara ele compila as possibilidades das novas mudanças em um único parágrafo intraduzível!

TechEd is the first time we’re talking about .NET vNext, as the next major release of the .NET Framework. At Build and TechEd, we’ve shared many of the features and components that you can expect in the next release. You will be able to compile C# 6 and VB with the Roslyn compilers, host ASP.NET vNext apps on the server or cloud, compile your Windows Store apps with the .NET Native ahead of time compiler, and enjoy faster desktop and server apps with the Next Generation JIT.

Bom, a Microsoft está querendo brigar como sendo a melhor e mais rápida plataforma para desenvolvimento de aplicações do mercado, e está investindo muito para que esse sonho se torne verdade. Abrindo mão de estar somente no Windows, a Microsoft está cada vez mais ousada e cada vez mais eficiente!

Com a segmentação do mercado com o NodeJS, Rubby, Python e outras linguagens/plataformas eficientes, a Microsoft abandona a briga com o Java, para correr atras do prejuízo. Bom, brigar com o Java é relativamente fácil, mas brigar com NodeJS e Rubby é de explodir qualquer cabeça. Para isso mudanças foram necessárias, rever todo o stack de sua plataforma e otimizá-lo para ser mais eficiente e robusto. Felizmente a comunidade só tem a agradecer.

Entre a apresentação do fluxo simplificado que já víamos com self-host no OWIN, encontramos uma tabela que me fez escorrer uma lágrima, será que você também vai se comover?

The table below outlines the ASP.NET vNext scenarios we’ve built and where they are available.

ASP.NET vNext Feature On .NET vNext On .NET vNext (Cloud Optimized)
Cloud Ready * *
Modular Design * *
Dependency Injection * *
Consistent Tracing / Debugging * *
Faster Development (browser refresh) * *
Open Source * *
Full Side by Side (runtime and framework
deployed with application)
*
Faster startup, Lower memory / Higher throughput (best of class) *
Uses a smaller set of framework libraries *
Enabled on Mono, on Mac and Linux *

ASP.NET vNext will be open source and will be contributed to the .NET Foundation. This shouldn’t come as a big surprise since the ASP.NET Web stack is already open source. All of ASP.NET vNext will be delivered via NuGet, will be open source and will take contributions. Read ASP.NET vNext: the future of .NET on the Server to learn more.

Our announcement at TechEd is the first stop for .NET vNext and ASP.NET vNext. We’ll share much more in the months to come before we release the final versions. We’re looking forward to shipping pre-release versions in order to get your feedback.

Bom, Enabled on Mono, on Mac and Linux me fez escorrer uma lágrima hétero!

A dúvida que paira no ar é: O que estará presente nesse framework otimizado para cloud?

Nem tudo pode ser feito da mesma forma no Windows e no Linux. Se conseguimos hospedar HTTP, hospedar um Web Socket, então naturalmente temos algum suporte a TCP-IP, o que viabilizaria WCF hospedado no linux. Isso é interessante, mas e o resto? Manipulação de arquivos, acesso a disco, acesso à rede, transações distribuídas. Bom, ficam as perguntas que preciso de respostas. Mas já é algo bem empolgante.

SCOTT HANSELMAN

Por fim deixei o Scott Hanselman, que sem dúvida tem o material que eu mais leio hoje em dia. Ainda não assisti ao encontro dos Scotts no DEV-B385 “The Future of .NET on the Server’ no Channel 9, mas pretendo fazê-lo ainda nesse final de semana.

Bom, se você não sabe quem é o Hanselman, não sei nem porque cargas dágua você é meu leitor! 😀 Corra, vá lá dar uma olhada no perfil e no blog dele, urgente.

Lendo o post do Hanselman sobre o vNext, você ele brincando com 2 versões do vNext .Net Framework via NuGet e dois parágrafos que também emocionam:

ASP.NET vNext will let you deploy your own version of the .NET Framework on an app-by-app-basis. One app with new libraries can’t break an app next door with a different version. Different apps can even have their own cloud-optimized CLR of their own version. The CLR and cloud-optimized libraries are NuGet packages!

 

In this screenshot you can see build 418 and build 420 of the new framework (note how small they are) in my packages folder. These NuGet packages include the complete “Core CLR” and the cloud-optimized .NET Framework. You can deploy your own CLR and .NET Framework with your app as a NuGet.

Resumindo: No vNext você vai fazer deploy do seu próprio .Net Framework Aplicação-por-aplicação, uma nova dependência em uma aplicação não afeta as demais. A CLR e bibliotecas otimizadas para a nuvem são pacotes NuGet. Na imagem, ele mostra duas versões a 418 e a 420 que possuem mais ou menos 12MB. Cada pacote desses tem o Core do CLR e as bibliotecas otimizadas para a núvem.

Falando um pouquinho de self-hosting, ele diz:

I can run ASP.NET vNext apps within Visual Studio, of course, and within IIS, but I can also easily “self-host” them from the command line or within my own application. This alpha includes command line tools for running and managing ASP.NET vNext apps.

The “kvm” command allows me to control my environment. I run “kvm list” to see what versions of the ASP.NET vNext are available. I can switch between them on a per-environment basis

Não vou comentar agora, vou deixar para o final. Quero falar sobre as possibilidades do self hosting.

Em seguida ele mostra que no novo modelo de desenvolvimento, os assemblies simplesmente não existem. As aplicações são compiladas em memória. Essa é a facilidade de proposta pelo Roslyn e o RyuJIT. Assim, partes pequenas são modificadas e automaticamente recompiladas, assim o tempo de build cai muito pois somente um pedaço da sua aplicação é recompilado. Ele mostra uma pasta bin, contendo apenas 1 assemblie, o AspNet.Loader.dll. Segundo o pessoal do Tecnoretorica, era usado pelo projeto Helios, mas não o conheço, ainda!

A explicação para essa ausência vem nos seguintes parágrafos:

One of the great aspects of environments like node or rails is that they are “no compile.” Just change some code and hit refresh. With the next version of ASP.NET you get the power and throughput of the .NET runtime plus the “Roslyn” compiler-as-a-service for a “no-compile compile.” That means means during development time you can just change your C# classes and hit Refresh in the browser. It’s the power of .NET with the dynamism of a refresh-and-go development experience

NOTE: This isn’t ASP.NET Websites, or Razor View compilation – this is the whole thing, compiled in memory. You can use Visual Studio for development, or text editors like Sublime, or freakin’ Notepad. (Of course, if you want assemblies on disk, you can do that too.)

See my web app’s bin folder in the screenshot below? There’s no assemblies in there because the assemblies never exist on the disk. It’s actually faster and easier to have the compiler do all the work in memory. This way you don’t have to read source, write out dlls, then read the dlls in again. (That DLL is part of the magic that makes it all happen.)

O resumo do ASP.NET vNext é:

  • Otimizado para servidores e cloud
  • ASP.NET MVC and Web API serão unificados em um único modelo de desenvolvimento
  • Experiência do desenvolvimento sem compilação
  • Injeção de dependênca fora da caixa
  • Side by side – publicação de runtime e framework com sua aplicação
  • NuGet para tudo – até o próprio runtime
  • Tudo Open Source via the .NET Foundation e suas contribuições
  • ASP.NET vNext (e Rosyln) já rodam no Mono, tanto no Mac quanto no Linux. Enquanto o Mono não é um projeto Microsoft, vamos colaborar com sua equipe e mais do Mono será adicionado à matriz de testes, é nossa ambição que ele simplesmente funcione!

Resumo

Esses últimos anos foram muito importantes para a plataforma, mostrando que a Microsoft está investindo muito para se tornar a maior e melhor plataforma de desenvolvimento de aplicações em geral. Os esforços para tornar o .Net multiplataforma são muito bem vindos e abrem incríveis possibilidades para o mercado.

Em um mundo cada vez mais híbrido, a Microsoft se viu perdendo mercado e desenvolvedores. Uma hype de plataformas e linguagens novas abraçando muitos desenvolvedores e consequentemente grandes corporações. O Azure e sua abrangência demonstram que a Microsoft está se adaptando ao mercado, se adaptando aos desenvolvedores, e percebeu que estava andando, passos atrás dos interesses comuns.

Self Hosting, é uma demanda muito antiga e muito interessante, para soluções descentralizadas e altamente escaláveis. Com baixo custo de gerenciamento o que facilita em muito o trabalho dos DevOps. É sob essa ótica que o mercado vem pensando e trabalhando e a nova geração na Microsoft está alinhada com esses ideais.

Fico muito feliz por poder ver essas mudanças acontecendo e na velocidade com que vem acontecendo.

Vamos torcer para que as implementações sejam bem abrangentes!

Referências

TecnoRetorica – 15 – ASP.NET vNext (primeiras impressões) com Victor Cavalcante

Somasegar’s blog – The .NET Foundation and .NET Platform Innovation

 .NET Framework Blog – The Next Generation of .NET – ASP.NET vNext

.NET Web Development and Tools Blog – Introducing ASP.NET Project “Helios”

SCOTT HANSELMAN – Introducing ASP.NET vNext

ASP.NET – Getting Started with ASP.NET vNext

.NET Web Development and Tools Blog – ASP.NET vNext: the future of .NET on the Server

Não perca os vídeos

SignalR: Building Real-Time Applications with ASP.NET SignalR

INTRODUCING: The Future of .NET on the Server

DEEP DIVE: The Future of .NET on the Server

Agradecimentos

No mais obrigado pela atenção, sei que o texto é extremamente longo, mas vale a pena!

Espero que goste do texto, espero que compartilhe e que faça perguntas. Não sei quanto a você, mas eu estou muito excitado com essas novidades, elas geram um enorme impacto no desenvolvimento de soluções robustas!

Um grande abraço e até a próxima!

O Cloud Native .NET é meu principal projeto.

Onde empenho energia para ajudar, acompanhar, direcionar Desenvolvedores, Líderes Técnicos e jovens Arquitetos na jornada Cloud Native.

Conduzo entregando a maior e mais completa stack de tecnologias do mercado.

Ao trabalhar com desenvolvedores experientes, eu consigo usar seu aprendizado com .NET, banco de dados, e arquitetura para encurtar a jornada.

Ao restringir à desenvolvedores .NET eu consigo usar do contexto de tecnologias e problemas do seu dia-a-dia, coisas que você conhece hoje, como WCF, WebForms, IIS e MVC, por exemplo, para mostrar a comparação entre o que você conhece e o que está sendo apresentado.

É assim que construímos fundamentos sólidos, digerindo a complexidade com didática, tornando o complexo, simples.

É assim que conseguimos tornar uma jornada densa, em um pacote de ~4 meses.

Eu não acredito que um desenvolvedor possa entender uma tecnologia sem compreender seus fundamentos. Ele no máximo consegue ser produtivo, mas isso não faz desse desenvolvedor um bom tomador de decisões técnicas.

É preciso entender os fundamentos para conseguir tomar boas decisões.

0 comentários

Enviar um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.

Luiz Carlos Faria

Mensagem do Autor

Espero que goste desse post. Não deixe de comentar e falar o que achou.

Se acha que esse post pode ajudar alguém que você conheça, compartilhe!

 

Lives

Fique de olho nas lives

Fique de olho nas lives no meu canal do Youtube, no Canal .NET e nos Grupos do Facebook e Instagram.

Aceleradores

Existem diversas formas de viabilizar o suporte ao teu projeto. Seja com os treinamentos, consultoria, mentorias em grupo.