.NET e ASP.NET vNext – Prepare-se para o futuro

Olá galera!

Já faz um bom tempo que não escrevo, espero que esse mal hábito acabe logo (rsss…).

Hoje quero aproveitar e falar de um assunto bem legal, e que todo programador adora.

Novidade!

Todo programador adora novidade, tanto é que se ele pudesse reescreveria o sistema a cada vez que uma manutenção fosse solicitada. Diga se não é verdade? (kkk), quem não adora um green field?

Pois bem, falando em novidade, uma que achei bastante interessante foi o anuncio da nova versão do ASP.NET (tá, já faz um bom tempo – mas ainda não está muito difundido na comunidade), a chamada ASP.NET vNext. Já faz algum tempo que o ASP.NET estava disponível como código aberto no CodePlex com o projeto AspNetWebStack, só que agora é pra valer, veja:

• Primeiro – O projeto foi migrado totalmente para o GitHub;
• Segundo – Está totalmente liberto do pipeline do IIS, ou seja, não depende mais do monstruoso System.Web.dll;
• Terceiro – É totalmente multiplataforma, e o time do Mono está envolvido.

Uma outra coisa que gostei muito foi o formato do arquivo de projeto, que agora passa a ser JSON.

Comecei a usar o brinquedinho e posso dizer que promete muito, e neste post pretendo mostrar como você pode preparar seu ambiente para também brincar com o novo .NET e ASP.NET vNext.

Mas primeiro…

Eu estou acostumado com o desenvolvimento hard core do tipo linha de comando e texto puro e simples, e confesso que uma coisa que me deixa bastante chateado é de criar uma Solution no Visual Studio e ela vir com trocentas dependências, que muitas vezes não são nem usadas, entre algumas outras coisas, como ter que referenciar cada arquivo na definição do projeto, sem contar que é difícil ler o arquivo de projeto e edit-alo manualmente. Quem é hard core está acostumado com o princípio de: “só adicione a dependência quando realmente precisar”. Quando você desenvolve para uma única plataforma não tem preocupações, mas quando você precisa manter um projeto para várias plataformas, perceberá logo que editar arquivos de projeto fora das ferramentas visuais será necessário. Se você der uma olhada nos fontes dos projetos do ASP.NET no GitHub (no MVC por exemplo) perceberá que cada um deles tem um arquivo build.bat e build.sh, respectivamente responsáveis por construir o projeto no Windows e Unix likes. Quando você desenvolve para uma única plataforma, dificilmente precisará disso, mas em projetos muitiplataforma isso faz parte do dia a dia. Ou seja, nada de usar o Visual Studio para construir a solução final, quem já usa Integração Contínua também já está acostumado a isso.

Já a algum tempo tive que me render ao .NET, C# e Visual Studio, por sua robustez incontestável. Realmente é uma ótima arquitetura para o desenvolvimento de software. E agora o ASP.NET vNext me encantou mais ainda principalmente por isso. Ele está agora, mais do que nunca, com cara de ferramenta para o desenvolvimento multiplataforma.

Eu fiz alguns testes a um tempo atras com o MonoDevelop (monodevelop.com) e Xamarin Studio (xamarin.com/studio), objetivando uma alternativa para o desenvolvimento multiplataforma porque a pesar de o .NET, C# e ASP.NET já serem uma realidade para o desenvolvimento no mundo Unix like (Linux, FreeBSD, Mac OS, etc), as ferramentas de produção ainda deixavam muito a desejar, principalmente porque estavam sempre uma versão atras, ou seja, sempre que saia a nova versão do ASP.NET, era necessário aguardar o port ser finalizado para começar a usar nos Unix likes. Por esse motivo acabei abandonando minhas esperiências temporariamente.

Hoje, com esse anúncio, confesso que fiquei novamente motivado a voltar ao trabalho.

Não que antes não era possível desenvolver ASP.NET em outras ferramentas como o Notepad++, SublimeText, ou o mais novo queridinho Atom, era sim, mas que dava trabalho dava. Agora, já está sendo até encorajado, vejam esse post do Scott Hanselman (Introducing ASP.NET vNext), e isso é possível principalmente por causa de dois novos componentes incluídos no ecossistema .NET, o KVM (K Version Manager) e o KRE (K Runtime), com eles podemos gerenciar nossas versões do .NET disponíveis na máquina de forma fácil, e isso quer dizer que nós podemos ter várias versões funcionando em paralelo, e podemos testar as aplicações nas várias versões com um simples clique, ou melhor dizendo, com um simples comando (kkk).

Além de:

• O Framework também ficou mais enxuto, e é possível por exemplo, distribuir todo o framework junto com sua aplicação adicionando poucos MB;
• Mais performance no compilador com o uso do Roslyn;
• O próprio .NET Framework tem uma série de novidades, veja;
• Etc., etc., etc…

E pra que não fique só em palavras, veja como você pode também se deliciar com as novidades do ASP.NET vNext.

Agora sim! Preparando o ambiente

Nesse exemplo prático vamos:

1. Instalar o KVM (nosso gerenciador de versões do .NET)

A primeira coisa que precisamos é do gerenciador de versões do .NET disponível para que possamos instalar as ferramentas necessárias (runtime e compiladores) que usaremos no desenvolvimento de nossos projetos. Para isso não usaremos o Visual Studio como exemplo (ele também está cheio de novidades, veja) para que possamos focar em como a nova arquitetura do .NET está disposta.

Antes de mais nada, crie um diretório específico para conter os arquivos necessários, de forma que você possa entender melhor o que foi feito. Eu vou criar o diretório C:\AspNet_vNext, você pode ficar à vontade pra criar o seu onde escolher.

mkdir C:\AspNet_vNext
cd C:\AspNet_vNext

A instalação em si do KVM se resume nos seguintes passos:

Clonar o projeto Home do GitHub

git clone http://github.com/aspnet/Home.git

Isso é bem rápido, uma vez que esse projeto só tem o instalador do KVM, além de algums exemplos de código para iniciar. Confira o diretório clonado.

Executar o script de setup

Mas antes, execute o prompt de comando como administrador:

Executando o prompt de comando com privilégios de administrador

E digite o seguinte comando:

cd Home
kvm setup

Agora você já tem um comando “kvm” disponível na sua linha de comando principal para ser executado de qualquer diretório.

1. Instalar a última versão KRE (.NET Runtime) disponível

Já temos o gerenciador de versões, mas ainda não temos uma versão do runtime do .NET em si (pelo menos não no novo modelo).

Então:

kvm install latest

Somente com isso você já tem a última versão do Runtime .NET Framework disponível para brincar. E só para conferir você pode listar as suas versões disponíveis com o seguinte comando:

kvm list

Verá algo como:

Active Version Runtime Architecture Location
------ ------- ------- ------------ --------
 * 1.0.0-alpha3-10202 svr50 x86 C:\Users\YOU\.kre\...

1. Criar um projeto Hello World do tipo console usando a nova estrutura

Agora vamos ver se é verdade!

Crie um subdiretório para o projeto de exemplo:

mkdir C:\AspNet_vNext\Sample

Dentro desse diretório teremos somente dois arquivos. O programa de console que imprime “Hello World!” na tela (Program.cs), e o projeto (project.json):

Arquivos do projeto ASP.NET vNext Sample no editor Atom

 

Observação

Enquanto o AspNet vNext ainda não for liberado, e como os pacotes NuGet estão hospedados no repositório “myget.org” e não no padrão “nuget.org”, você precisará incluir um arquivo de configuração do NuGet informando o novo repositório no seu projeto, para que o comando “kpm restore” possa funcionar adequadamente.

Abaixo, o código de cada arquivo.

	<?xml version="1.0" encoding="utf-8"?>
	<configuration>
	<packageSources>
	<clear />
	<add key="AspNetVNext" value="https://www.myget.org/F/aspnetvnext/&quot; />
	<add key="NuGet.org" value="https://nuget.org/api/v2/&quot; />
	</packageSources>
	</configuration>

view raw

NuGet.config

hosted with ❤ by GitHub

	using System;
	public class Program
	{
	public static void Main()
	{
	Console.WriteLine("Hello World!");
	}
	}

view raw

Program.cs

hosted with ❤ by GitHub

	{
	"dependencies": {
	"System.Console": "4.0.0.0"
	},
	"configurations": {
	"net45": {},
	"k10": {}
	}
	}

view raw

project.json

hosted with ❤ by GitHub

PS: Esse é o mesmo código de exemplo disponibilizado pelo projeto AspNet/Home/Samples.

1. Compilar e executar nosso projeto

E para testar basta:

cd C:\AspNet_vNext\Sample
kpm restore
k run

Com isso nós baixamos as dependências com “kpm restore” e rodamos o aplicativo com “k run”. Uma curiosidade é que os pacotes baixados via NuGet não são mais armazenados no subdiretório “packages” dentro do diretório do projeto, e sim em um subdiretório “packages” no diretório do usuário “C:\Users\YOU\.kpm\packages”, isso é legal porque os pacotes são compartilhados entre seus vários projetos e não mais só na solução, e ficam em cache, melhorando as próximas restaurações.

Por fim, você deve ver a mensagem “Hello World” impressa no seu console, e isso é o resultado da execução de nosso programinha.

Conclusão

É claro que não fizemos realmente um projeto “ASP.NET”, mas sim um simples Hello World em console app, mas o que importa é que você já tem o ambiente do .NET vNext pronto para trabalhar, nos próximos posts vamos explorá-lo melhor e continuar com nossas descobertas sobre essa novidade.

Esteja pronto para o futuro, não fique acomodado com o conhecimento que você já tem.

Vídeo

Abaixo segue um vídeo que fiz pra demonstrar melhor a parte prática onde preparamos o ambiente:

Referências

• Site oficial do ASP.NET vNext
• Ponto de partida do projeto no GitHub
• The Future of .NET on the Server: ASP.NET vNext content and videos from TechEd 2014
• Introducing ASP.NET vNext
• The Next Generation of .NET – ASP.NET vNext
• Getting Started with ASP.NET MVC 6
• The Next Generation of .NET