Após experimentar um formato de projeto baseado em JSON, a Microsoft voltou ao MSBuild como a base dos arquivos de projeto C# e VB. Junto dessa decisão veio a promessa de implementar muitas das funcionalidades do project.json que agradaram ao público. Hoje nós iremos falar de uma dessas funcionalidades, a integração com o NuGet.
Tradicionalmente o NuGet é um acessório. Enquanto o compilador poderia disparar o download de pacotes NuGet, ele não entendia o processo. Após o download de um pacote, ele precisava ser instalado no projeto. Isso incluía atualizar as referências do projeto, copiar arquivos, executar scripts PowerShell. Isso era frágil e desenvolvedores ás vezes tinham que manualmente limpar os arquivos do projeto antes de reinstalar pacotes.
Com a nova funcionalidade PackageReference do MSBuild, muitos desses problemas irão embora. Ao invés de referenciar os assemblies individualmente, os desenvolvedores podem agora referenciar apenas o próprio pacote no projeto.
As referências são transitivas. Isso significa que você só precisa referenciar o pacote, você não precisa referenciar de maneira explícita cada pacote que tal pacote requer. De acordo com o comunicado, isso pode resultar em uma melhora de até 5x na performance da instalação e atualização de pacotes. Em um exemplo, um processo de 10 minutos foi reduzido para 30 ms.
A pasta packages na pasta da solução também foi eliminada. Dependências são referenciadas diretamente do cache do usuário. Se você está se perguntando por quê não fizeram isso antes, considere que o NuGet era visto como um mero acessório. Já que o compilador não entendia os pacotes NuGet, ele requeria que o caminho dos pacotes fossem especificados no arquivo de projeto. Já que cada usuário poderia colocar seu cache em um caminho diferente, utilizá-lo não era uma opção. Sendo assim a pasta packages na pasta da solução foi criada, garantindo que os caminhos relativos dos pacotes no projeto fossem iguais para todos desenvolvedores.
Versionamento
O suporte ao versionamento de referências de pacotes NuGet melhorou consideravelmente. Agora você pode utilizar faixas e curingas ao especificar qual versão de um dado pacote você deseja utilizar. Faixas utilizam uma sintaxe comum:
- Versão x.y ou anterior: x.y]
- Versão x.y ou posterior: [x.y
- Versão anterior à x.y: x.y)
- Versão posterior à x.y: (x.y
Por exemplo, se você deseja pelo menos a versão 1.4.2 mas não a 1.5, você pode escrever “[1.4.2, 1.5)”. Se você deseja qualquer versão da família 1.4, você pode especificar “1.4.*”.
Arquivos de conteúdo podem ser controlados utilizando as tags IncludeAssets e ExcludeAssets. Elas são utilizadas para modificar quais tipos de recursos (analisadores, arquivos de conteúdo, etc.) serão incluídos no processo de build. Você pode até mesmo marcá-los como privados, significando que eles são utilizados apenas para desenvolvimento e não devem aparecer para as bibliotecas subsequentes.
Criando pacotes NuGet com MSBuild
Enquanto era possível executar o NuGet para criar pacotes do MSBuild via o comando Exec, isso não funciona bem em um ambiente de integração contínua. Então, como parte desse versão, o próprio MSBuild pode empacotar os projetos. Irá funcionar até mesmo com projetos que tem vários frameworks diferentes especificados como TargetFrameworks.
Por falar nisso, você pode sentir a necessidade de referenciar diferentes pacotes dependendo da plataforma. Com PackageReference, você pode incluir uma expressão condicional para indicar quando a referência é aplicável.
Problemas de compatibilidade com versões anteriores
A falta de algumas antigas funcionalidades do NuGet como pastas content, transformações XDT, e os scripts PowerShell install.ps1/uninstall.ps1 é uma grande preocupação.
Nesse momento essas funcionalidades estão disponíveis para projetos .NET Core e .NET Standard. Outros tipos de projetos poderão utilizá-las caso o VS 2017 Update 1 Preview esteja instalado.