Variable not found: ¡Hasta la vista, project.json! ¡Hola de nuevo, .csproj!

Probablemente muchos recordaréis que cuando comenzaron a verse las primeras previews de ASP.NET Core, por entonces aún llamado ASP.NET vNext, una de las novedades más sorprendentes que pudimos descubrir fue la aparición de un nuevo archivo de proyecto, llamado project.json, que sustituiría al vetusto .csproj (o vbproj).

La comunidad se entusiasmó bastante con la idea porque el nuevo archivo de proyecto era bastante más simple y liviano que el tradicional .csproj, daría menos problemas con los sistemas de control de código fuente, era fácil de leer y de editar sin necesidad de disponer de Visual Studio o un IDE completo, y por tanto era muy portable entre plataformas. Y encima usaba el formato JSON, que sin duda resultaba mucho más cool que XML. ¿Qué más podíamos pedir?

Antes de continuar, permitidme un inciso: aunque conceptualmente todo lo que vamos a contar es cierto en este momento (enero/2017) y probablemente seguirá siéndolo, el tooling aún está en desarrollo y, por tanto, algunos detalles todavía podrían cambiar.

Este nuevo archivo acompañó a las distintas previews y release candidates de .NET Core y sus frameworks, así como a sus sucesivas versiones oficiales 1.0 y 1.1 RTM, y durante algún tiempo hemos podido disfrutarlo en nuestros proyectos .NET Core. Sin embargo, esos lanzamientos siempre fueron acompañados de un tooling aún en preview; es decir, aunque los frameworks se distribuían con la calidad y funcionalidades esperadas en una versión final, las herramientas para crear aplicaciones con ellos (IDE, CLI) eran preliminares y, por tanto, sujetas a modificaciones que de hecho habían sido planificadas tiempo atrás.

Básicamente el problema era que el ámbito de utilización de .NET Core había crecido y era mucho más ambicioso que lo que se pretendía en un primer momento, y el nuevo objetivo era conseguir que el código .NET Core pudiera ser compartido entre los distintos sabores de aplicaciones .NET (WinForms, WPF, UWP, Xamarin, etc.). Project.json estaba bien para los sistemas web y bibliotecas para los que había sido diseñado inicialmente, pero se quedaba corto ante los nuevos escenarios.

Como comentaba Scott Hunter, del equipo de ASP.NET:

"Teníamos dos opciones. Una era mover todos los proyectos .NET a project.json, lo que requeriría cambiar las herramientas de todos los tipos de proyectos en Visual Studio, Xamarin e incluso afectaría a herramientas de terceros como Unity. Tendríamos que haber extendido project.json para soportar los escenarios de build requeridos por cada uno de esos proyectos, y proporcionar una ruta de migración para todos ellos. Otra opción era construir puentes de forma que proyectos .csproj pudieran referenciar proyectos .xproj y viceversa en Visual Studio y Xamarin Studio, con todas las complejidades que esto traería consigo."

Pero la otra opción era más simple y es la que tomaron finalmente: dar marcha atrás y hacer que los proyectos basados en .NET Core volvieran a utilizar los archivos de proyecto .csproj, pero aprovechando para actualizar este formato con ventajas que aportaba el project.json, como permitir la operación a través de .NET CLI, el multi-targeting, la posibilidad de generar paquetes Nuget, o simplemente permitir patrones y rutas a la hora de indicar los archivos pertenecientes a un proyecto en lugar de tener que hacerlo de forma individual.

Todo esto está muy bien, pero, ¿puedo ver un ejemplo?

La materialización a estos cambios llegó hace apenas un par de meses, cuando se anunció la disponibilidad de .NET Core Tools MSBuild “alpha” (o .NET Core Tools Preview 3), un conjunto de herramientas que ya implementan el cambio a archivos de proyecto .csproj y la construcción basada en MSBuild (que, por cierto, también es open source y se está trabajando para que sea multiplataforma desde hace tiempo). En estos momentos ya existe una versión posterior, la preview 4.

Tras instalar la actualización del tooling, observad que la creación de un proyecto .NET Core utilizando el CLI es exactamente igual que antes, pero en el resultado puede apreciarse que ya no aparece el difunto project.json, y sí un bonito .csproj:

C:\MyProjects>md test

C:\MyProjects>cd test

C:\MyProjects\test>dotnet new
Created new C# project in C:\MyProjects\test.

C:\MyProjects\test>dir
 El volumen de la unidad C no tiene etiqueta.
 El número de serie del volumen es: AA8B-7BC7

 Directorio de C:\MyProjects\test

22/01/2017  13:18    <DIR>          .
22/01/2017  13:18    <DIR>          ..
07/12/2016  21:49               133 Program.cs
07/12/2016  21:49               422 test.csproj
               2 archivos            555 bytes
               2 dirs  26.682.449.920 bytes libres

C:\MyProjects\test>

Y, como era de esperar, podemos restaurar los paquetes Nuget y ejecutarlo como de costumbre:

C:\MyProjects\test>dotnet restore
  Restoring packages for C:\MyProjects\test\test.csproj...
  Writing lock file to disk. Path: C:\MyProjects\test\obj\project.assets.json
  Restore completed in 1991,6245ms for C:\MyProjects\test\test.csproj.

  NuGet Config files used:
      C:\Users\josem\AppData\Roaming\NuGet\NuGet.Config

  Feeds used:
      https://api.nuget.org/v3/index.json
      https://www.myget.org/F/aspnetvnext/api/v3/index.json

C:\MyProjects\test>dotnet run
Hello World!

C:\MyProjects\test>

Para que os hagáis una idea, el contenido del archivo .csproj que hemos creado anteriormente es el siguiente. No es la limpieza de nuestro querido project.json, pero bueno, tampoco está nada mal ;). Observad especialmente el uso de patrones para especificar los archivos incluidos en el proyecto:

<Project Sdk="Microsoft.NET.Sdk" ToolsVersion="15.0">

<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp1.0</TargetFramework>
</PropertyGroup>

<ItemGroup>
<Compile Include="**\*.cs" />
<EmbeddedResource Include="**\*.resx" />
</ItemGroup>

<ItemGroup>
<PackageReference Include="Microsoft.NETCore.App" Version="1.0.1" />
</ItemGroup>

</Project>

Si hacéis la prueba de crear una aplicación de consola "tradicional" que únicamente muestre por pantalla un mensaje "Hello World!" veréis que el archivo .csproj clásico es bastante más denso que éste, donde podemos identificar claramente las secciones que comprende e incluso podríamos atrevernos a modificar desde un editor cualquiera. Efectivamente, son algunas de las ventajas del project.json, pero sobre el .csproj :)

Una vez aparezcan las versiones definitivas de las herramientas, previsiblemente para primavera de este año, este será el enfoque utilizado a la hora de crear nuevos proyectos tanto desde las órdenes de línea de comando como desde entornos de desarrollo como Visual Studio. Project.json, por tanto, tiene los días contados.

¿Y en qué nos afectará esto a los desarrolladores? Pues tranquilos, porque en esta ocasión no salpicará demasiado. El paso a esta nueva estructura de proyectos será transparente en muchos de los casos, o existirán herramientas específicas para facilitar la migración. También, dado que existe un gran paralelismo entre las estructuras de proyecto project.json y .csproj, prácticamente podríamos traducir de uno a otro sin demasiado esfuerzo.

Veremos todo esto en próximos posts ;)

Más información:

• Changes to Project.json
• .NET Core Roadmap
• Announcing .NET Core Tools MSBuild “alpha”
• Uso de MSBuild para compilar proyectos .NET Core
• Referencia del comando "dotnet migrate"