Home

##Introdução ao ASP.NET vNext

Na próxima versão do ASP.NET nós estamos trabalhando com vários times da Microsoft para criar um novo web stack de componentes leves, combináveis e modernos para o novo cenário de aplicações web e nuvem.

Este novo web stack consistirá de:

• Um .NET Framework menor, que será composto em pacotes que poderão ser baixados sob demanda
• Um framework web unificado criado sobre um pequeno core
• Simples regras de empacotamento/versionamento/manutenção
• Funcionamento side-by-side, de tal forma que duas aplicações rodando diferentes versões do CLR podem rodar lado a lado no mesmo servidor sem conflito entre si.

#Runtime

##O que é o KRuntime?

O KRuntime é um SDK que contém todos os binários necessários para compilação e execução da aplicação. Ele pode ser instalado na pasta bin da sua aplicação ou pode ser instalado de forma compartilhada com outra aplicação no mesmo servidor.

O KRuntime contém vários comandos, como o k.cmd que habilita você fazer k build, o carregador (loader) padrão e outras partes que são necessárias para compilar sua aplicação. Você pode ver mais da estrutura e componentes do KRuntime aqui.

##Definindo um projeto

Projetos no novo web stack são um pouco diferente do que você está acostumado. Quando trabalhar neste novo framework a definição principal do projeto acontece no arquivo project.json. Este arquivo é feito para que humanos possam ler e contêm toda informação requerida pelo runtime para rodar sua aplicação. Isto inclui o metadado sobre seu projeto como o nome, a versão, etc. Como também a lista de dependências, comandos que podem ser executados, e algumas outras informações. Ele funciona como um nuspec e packages.config.

Ele não inclui qualquer coisa de ferramenta, como configurações do VS, configurações específicas do usuário, etc. No futuro, haverá a experiência de primeira classe do Visual Studio que você tem hoje, com algumas novas funcionalidades. Mas as configurações e informações exigidas por essas ferramentas serão armazenados em um arquivo de projeto, semelhante aos csproj que temos hoje, e não nos arquivos project.json. Não deve haver duplicação entre os dois arquivos, e o project.json deve ser relevante e específico para sua aplicação. Mas, por enquanto, só temos o runtime e linha de comando para usar.

Se um diretório tem um arquivo chamado project.json nele, então o runtime assumirá que esse diretório contém código fonte que pode ser compilado e executado. Algumas das informações no project.json são trabalhadas por convenção, o nome do diretório sendo o nome da sua aplicação, por exemplo. Então, o mínimo necessário para obter código fonte compilado pelo runtime é uma pasta com um arquivo project.json válido, o que significa um arquivo com chaves vazias. Claro que, na prática, a sua aplicação não será capaz de fazer muita coisa sem algumas dependências.

##Dependências

Dependencias são definidas usando somente o nome e versão:

"dependencies": {
  "Microsoft.AspNet.ConfigurationModel": "0.1-alpha-*",
  "SomeProject": ""
}

Existe uma cadeia de carregamento que o runtime usa para determinar o que precisa para carregar ao resolver uma dependência. Por exemplo, um dos carregadores vai olhar para um pacote NuGet com o nome dado, outro vai olhar para um projeto que pode compilar (outra pasta com um project.json), e outra vai encontrar assemblies no disco.

Um dos objetivos desse esforço foi para fazer do pacote NuGet a principal unidade de referência, espera-se que todas as dependências acabar tanto como pacotes NuGet ou referências do projeto.

Um dos cenários que permite isso é a capacidade de depender de um pacote NuGet, e depois clonar a fonte em seu projeto e usar código fonte sem mudar nada em seu projeto. Isto reduz significativamente o atrito de depuração e correção de uma biblioteca que você tem o fonte.

##Core CLR

Parte desse esforço é um reduzido `.NET Framework otimizado para o servidor e nuvem. O que isto significa na prática é que você vai depender do core CLR, um pequeno CLR capaz de rodar lado a lado, bem como uma série de pacotes NuGet com bibliotecas que você deseja usar. Por exemplo, nenhuma das APIs XML fazem parte do core CLR. Para usá-los, você pode adicionar uma dependência a um dos pacotes XML que tem a funcionalidade que você precisa.

Nós ainda estamos trabalhando nesta experiência. Queremos proporcionar o máximo de pay-for-play que podemos, o que lhe permite escolher quais partes do framework que você precisa usar e nada mais. Mas há também um desejo de não tornar difícil de encontrar o que eu preciso usar. Estamos planejando uma camada de meta pacotes que deverá agrupar pacotes comumente usados para tornar mais fácil de depender de um pedaço de uma funcionalidade.

Build vs Run

Nós mencionamos algumas vezes que as dependências podem ser um diretório de código fonte que o runtime pode compilar. Isto é feito com Roslyn. Se uma execução precisa de uma carga de um projeto, então ele é capaz de usar o Roslyn para compilar o projeto e carregar o assembly gerado. Um aspecto importante desta compilação é que nunca escreve um assembly para o disco, e quando você faz o build em vez de rodar tudo o que você está fazendo é gravando a mesma coisa para o disco. portanto, não há diferença entre build e executar, além da saída de um assembly para o disco.

#Frameworks

##MVC

Construído em cima dos recursos do runtime descritas acima é uma nova e unificada web stack. Estamos fundindo MVC, Web API e Web Pages em um framework que inclui:

• Um sistema de roteamento, um sistema de model binding, uma pipeline de filtro, etc.
• Uma transição suave de Web Pages para MVC
• Retorno de HTML como views ou dados

##SignalR

ASP.NET vNext inclui suporte para web em tempo real através da nova versão do ASP.NET SignalR.

#Dados

Para Dados estamos construindo uma versão mais leve do EF que pode ser usado em uma ampla variedade de plataformas. Este esforço não é sobre a re-implementação de toda a pilha de EF; a pilha atual contém um monte de APIs e recursos que não são especialmente úteis e/ou quase nunca são usados. A versão mais leve será simplificada, de modo que ela não contenha estes recursos. Alguns exemplos desta simplificação incluem apenas ter a API DbContext (sem a API ObjectContext) e apoiar um conjunto reduzido de padrões de mapeamento. Você pode ler mais sobre os planos para a EF [aqui] (https://entityframework.codeplex.com/wikipage?title=Entity% 20Framework% 20Everywhere)