Fala galera, belezura?

Hoje é praticamente impossível falar do novo ASP.NET 5 (o famoso vNext) sem falar do DNX. Mas o que de fato é o DNX? Para que serve? Como utilizar corretamente? Vamos entender um pouco mais sobre ele neste post.

DNX (.NET Execution Environment)

Uma das estratégias atuais da Microsoft para o o ASP.NET é que ele seja cloud-ready/friendly, ou seja, que ele esteja pronto para ser executado na nuvem, seja ela o Azure, Amazon ou qualquer outra estrutura de nuvem que as empresas utilizem. Para isso foi necessário tornar não apenas o ASP.NET algo cross-platform, mas também o próprio .NET e é aqui que entra o DNX.

DNX, ou .NET Execution Environment, é o runtime do .NET ao mesmo tempo em que é o próprio SDK. É o ambiente de execução de nossos projetos ASP.NET, tendo nele tudo que é necessário para executar uma aplicação. O interessante aqui é que o DNX não está limitado apenas ao ASP.NET, sendo possível executar outros tipos de aplicações .NET com ele.

O DNX, como era de se esperar, é Open Source e roda tanto em Windows, Mac (OSX) e Linux =)

DNX e Cross-Platform

Com o DNX é possível que uma aplicação ASP.NET seja desenvolvida em uma plataforma Windows e seja executada em produção no Azure utilizando Docker em uma máquina Linux, bastando apenas que a mesma versão do DNX esteja disponível. É interessante ressaltar também que o DNX faz uso do novo formato de arquivos de projeto (project.json), garantindo que de fato seja possível desenvolver e trabalhar com .NET fora do ambiente Windows, onde o Visual Studio não está presente para fornecer todo tooling de suporte ao projeto. É um mundo de possibilidades novas.

Projetos com DNX

Uma das críticas que eu sempre tive aos projetos .NET era o fato de o Visual Studio não conseguir compreender que todos os arquivos dentro do meu diretório de projeto faziam parte daquele projeto. Era preciso que eu manualmente adicionasse os arquivos aos projeto, algo que ele fazia de uma forma completamente obscura e sinistra. Enquanto em projetos Ruby/Rails, Python ou Node eu simplesmente tinha tudo dentro de um diretório como fazendo parte do meu “projeto” eu precisava confiar no Visual Studio para as magias ocultas.

Com o DNX isso tudo também mudou. Para o DNX um projeto é um tudo que existe dentro de um diretório que contenha um arquivo project.json. Sério, isso é muito $%@! bacana! Qualquer editor de textos pode trabalhar com um arquivo Json (Sublime, Atom, VS Code, Notepad, Vim, Brackets, etc, etc) e isso novamente corrobora com a estratégia multi-plataforma da ferramenta: você está livre para trabalhar no sistema que quiser utilizando a ferramenta que quiser.

Um arquivo project.json pode ser tão simples quanto isso para uma aplicação ASP.NET:

{
  "compilationOptions": {
    "emitEntryPoint": true
  },

  "dependencies": {
    "Microsoft.AspNet.Mvc.Core": "6.0.0-rc1-final",
    "Microsoft.AspNet.Server.Kestrel": "1.0.0-rc1-final",
  },

  "commands": {
    "web": "Microsoft.AspNet.Server.Kestrel",
  },

  "frameworks": {
    "dnx451": { },
    "dnxcore50": { }
  }
}

Incrível se comparado aos web.config da vida não?!

DNX e Commands

Uma coisa que vamos perceber em diversos projetos e ferramentas é que o DNX consegue executar comandos dentro/com a nossa aplicação. Estes comandos são definidos dentro do nosso project.json.

Basicamente um comando é um nome que aponta para um entry point em alguma library/projeto. E com isso é possível executarmos isso via DNX, no contexto do nosso projeto passando parâmetros.

Um exemplo abaixo:

"commands": {
  "web": "Microsoft.AspNet.Server.Kestrel",
  "gen": "Microsoft.Framework.CodeGeneration",
  "ef": "EntityFramework.Commands"
}

Esta chave commands no nosso project.json define três comandos. O primeiro deles web é o comando que inicia nossa aplicação e a executa, colocando-a disponível em uma porta acessível via HTTP. O segundo comando, gen aponta para Microsoft.Framework.CodeGeneration e permite trabalhar com scaffolding 😉 Já o terceiro comando, ef oferece tooling para trabalhar com Entity Framework e nos dá acesso a migrations e coisas do tipo.

Tudo isso pode ser executado via console com comandos como:

dnx web

ou

dnx ef migrations add <nome da nova migration>

ou

dnx gen controller --name MeuController --dbcontext MeuDbContext --model MeuModel

Além disso você pode criar entry points dentro do seu projeto para executar tarefas que sejam pertinentes, por exemplo em um projeto que estou trabalhando temos um entry point para criar dados de testes no banco de dados e usamos algo como:

dnx seed dev

Onde seed é o nome que demos ao nosso comando no project.json e dev é um parâmetro que passamos para o comando 😉

Para entender um pouco melhor o que é isso podemos dar uma olhada nos comandos que o Entity Framework nos oferece, veja aqui no github deles.

Application Host

De forma geral o DNX é quem executa nossa aplicação, faz todo o trabalho de parse do project.json, resolve dependências, etc. Até o presente momento (pois algo pode mudar até a versão final agora no começo de 2016) é quem fornece para nossas aplicações alguns serviços (através de DI) para que as mesmas façam uso.

E como já foi mencionado anteriormente é possível ter diferentes versões do DNX lado-a-lado em uma máquina sem que uma interfira com a outra utilizando o DNVM para gerenciar isso.

Conclusão

Até o presente momento o DNX é não apenas um comando para executar outros comandos, mas é o próprio ambientes de execução de projetos .NET. “dentro dele” que nossas aplicações irão rodar e é “por causa dele” que poderemos executar nossas aplicações em ambientes Linux ou Windows na nuvem, enquanto desenvolvemos as mesmas utilizando OSX 😉

Mais informações podem ser encontradas na documentação oficial do DNX, ou no github do projeto DNX.

Dúvidas ou comentários abaixo,
Abraços galera!

tags

.NETASP.NET 5dnxproject.json

Vinicius Quaiato