O objetivo deste artigo é apresentar algumas das mudanças envolvendo a implementação de projetos ASP.NET Core no Visual Studio 2017.
Introdução
Conforme conhecimento geral, o lançamento oficial do Visual Studio 2017 ocorreu em 7 de março, em um evento online de 2 dias promovido pela Microsoft. Ao longo deste dias, diversas apresentações e sessões de treinamento focaram as novidades da IDE.
E com a chegada de uma nova versão do Visual Studio, surgem inúmeras perguntas e dúvidas. No caso específico de aplicações Web, uma destas questões diz respeito a quais alterações ocorrerão no desenvolvimento com o ASP.NET Core. Ao longo deste artigo, serão abordadas algumas das novidades previstas ao se utilizar esta tecnologia no Visual Studio 2017.
Templates para a criação de novos projetos
O Visual Studio 2017 conta atualmente com templates do .NET Core para a criação de Console Applications, Class Libraries, projetos de testes baseados nos frameworks MS Test ou xUnit e Web Applications:
Ao se optar por uma aplicação Web, aparecerá uma segunda janela, com templates para a geração de um projeto Web API ou MVC:
Esta opção também permite selecionar a versão do ASP.NET Core com a qual o projeto será criado:
Mudanças na estrutura de um projeto ASP.NET Core
A alteração mais significativa (e até certo ponto, polêmica) envolvendo o ASP.NET Core foi o fato do uso do arquivo project.json ter sido descontinuado. A equipe responsável por esta tecnologia optou por manter o padrão baseado no MSBuild, com a volta de arquivos .csproj definindo configurações e dependências de um projeto.
Na próxima imagem é possível observar um projeto Web criado no Visual Studio Community 2017, já sem a presença do arquivo project.json:
As dependências de um projeto podem ser acessadas por meio do item Dependencies, com os diferentes elementos agrupados nas seções Bower (pacotes client-side), NuGet (bibliotecas .NET) e SDK (indicando o framework da aplicação):
E com ausência do arquivo project.json surge outra pergunta: como adicionar ou remover packages/bibliotecas do NuGet em uma aplicação?
Uma das alternativas consiste no processo tradicional via interface do NuGet, clicando para isto com o botão direito do mouse sobre o item Dependencies e selecionando a opção Manage NuGet Packages…:
Um outro caminho seria o Package Manager Console (opção disponível no menu Tools > NuGet Package Manager > Package Manager Console), com a digitação de comandos adicionando ou removendo pacotes de um projeto:
Um procedimento bastante similar à edição do project.json também está disponível, com a alteração das definições XML no arquivo .csproj da aplicação (contudo, o IntelliSense ainda não é suportado nestes casos). Uma dependência será representada pelo item PackageReference:
O utilitário de linha de comando dotnet (.NET Core Command-Line Interface) também poderá ser utilizado no gerenciamento de dependências. No exemplo a seguir, o Entity Framework Core 1.1 está sendo adicionado à aplicação MVC de exemplo, através da seguinte instrução (a execução deve acontecer a partir do diretório-raiz do projeto em questão):
dotnet add package Microsoft.EntityFrameworkCore -v 1.1.0
O resultado desta ação pode ser observado na próxima imagem:
Um pouco mais sobre o .NET Core Command-Line Interface (CLI)
O .NET Core Command-Line Interface engloba um conjunto de funcionalidades para a criação e gerenciamento de projetos baseados no .NET Core. Em sua versão mais recente (RC 4) já existe inclusive o suporte à criação de projetos compatíveis com o padrão MSBuild (extensão .csproj).
Ao executar a instrução dotnet new serão exibidas as diversas opções existentes para a criação de projetos .NET Core:
Para criar um novo projeto Web API, basta executar a seguinte linha de comando (a partir do diretório em que os arquivos deverão ser gerados):
dotnet new webapi
Aparecerá, então, como resultado:
Analisando o conteúdo, será possível notar a presença dos arquivos e diretórios que compõem a estrutura de um projeto Web API, incluindo o arquivo ExemploASPNETCoreAPI.csproj (e a ausência do project.json):
.NET Standard: convivendo com múltiplos runtimes
Novos desafios à evolução da plataforma .NET surgiram com o crescimento no uso de tecnologias como .NET Core e Xamarin, além da existência de um grande número de projetos baseados no .NET Full (soluções criadas com ASP.NET MVC, Web Forms, Windows Forms etc). Como conciliar a existência de múltiplos runtimes, sem que isto implique em diferentes versões de um mesmo tipo de biblioteca?
Levando em consideração tais fatores, a Microsoft deu início a uma nova iniciativa conhecida como .NET Standard, com o objetivo de uniformizar o ecossistema .NET.
Mas o que isto significa na prática? Agora há a possibilidade de implementação de APIs baseadas no .NET Standard, com o reaproveitamento dos mesmos recursos por mais de um runtime .NET. Graças a esta padronização, um mesmo conjunto de funcionalidades pode ser utilizado em uma aplicação .NET convencional, em um site ou API construídos com o ASP.NET Core, ou ainda, em um projeto Xamarim.
O Visual Studio 2017 já conta inclusive com um template para a criação de bibliotecas do .NET Standard:
Na próxima imagem está a estrutura de uma biblioteca .NET Standard, a qual não difere em muito de uma Class Library convencional:
Conclusão
Este artigo procurou trazer algumas das mudanças que envolvem o uso do .NET Core e do ASP.NET Core no Visual Studio 2017. Muitas novidades ainda estão por vir, sobretudo se considerarmos que as versões 2.0 do .NET Core e do .NET Standard têm seu lançamento previsto para os 4 últimos meses de 2017.
Referências
De 0 a 10, o quanto você recomendaria este artigo para um amigo?