Solución:
Ambos nuget restore y dotnet restore son más o menos iguales: realizan una operación de restauración de NuGet.
La unica diferencia: dotnet restore es un envoltorio de conveniencia para invocar dotnet msbuild /t:Restore que invoca una restauración integrada en MSBuild. Esto solo funciona en distribuciones de MSBuild que incluyen NuGet, como Visual Studio 2017 (Visual Studio completo, herramientas de compilación) o Mono 5.2+ (=> msbuild /t:Restore) y el SDK de .NET Core que proporciona este comando de conveniencia.
Por el momento, hay dos formas de utilizar los paquetes NuGet en proyectos (tres en realidad, pero ignoremos project.json en UWP por el momento):
-
packages.config: La forma “clásica” de hacer referencia a los paquetes NuGet. Esto supone que NuGet es una herramienta independiente y MSBuild no sabe nada sobre NuGet. Un cliente de NuGet comonuget.exeo las herramientas integradas de Visual Studio ven elpackages.configy descarga los paquetes a los que se hace referencia en una carpeta local durante la restauración. La instalación de un paquete modifica el proyecto para hacer referencia a activos fuera de esta carpeta local. Entonces una restauración para unpackages.configproyecto solo descarga los archivos. -
PackageReference: El proyecto contiene elementos de MSBuild que hacen referencia a un paquete NuGet. diferente apackages.config, solo se enumeran las dependencias directas y el archivo del proyecto no hace referencia directamente a ningún activo (archivos DLL, archivos de contenido) de los paquetes. En la restauración, NuGet calcula el gráfico de dependencia mediante la evaluación de las dependencias directas y transitivas, se asegura de que todos los paquetes se descarguen en la caché de paquetes global del usuario (no local de la solución, por lo que solo se descarga una vez) y escribe un archivo de activos en elobjcarpeta que contiene una lista de todos los paquetes y activos que usa el proyecto, así como destinos de MSBuild adicionales si algún paquete contiene lógica de compilación que debe agregarse a un proyecto. Por lo tanto, una restauración de NuGet puede descargar paquetes si aún no están en la caché global y crear este archivo de activos. Además de las referencias de paquetes, el proyecto también puede hacer referencia a herramientas CLI, que son paquetes NuGet que contienen comandos adicionales que estarán disponibles para eldotneten el directorio del proyecto.
La restauración integrada en msbuild solo funciona para PackageReference proyectos de tipo (.NET Standard, .NET Core de forma predeterminada, pero es opcional para cualquier proyecto .NET) y no para packages.config proyectos. Si usa una nueva versión de nuget.exe(por ejemplo, 4.3.0), puede restaurar ambos tipos de proyectos.
Su error acerca de los tipos que faltan es un poco más interesante: los “ensamblados de referencia” (bibliotecas que se pasan como entrada al compilador) no están instalados en el sistema sino que vienen a través de paquetes NuGet. Mientras los paquetes NuGet falten en la caché de paquetes global o en el obj/project.assets.json El archivo no ha sido generado por una operación de restauración, tipos fundamentales como System.Objectno estará disponible para el compilador.
Tuve problemas similares con un proyecto de .NET Core 2 que se compilaría bien en mi estación de trabajo, tanto dentro de Visual Studio 2017 como solo con MSBuild, pero no se compiló en TeamCity. El mensaje de error fue:
C:Program Filesdotnetsdk2.1.4SdksMicrosoft.NET.SdkbuildMicrosoft.PackageDependencyResolution.targets(327, 5):
Assets file 'D:TeamCitybuildAgentwork596486b1d4e7a8e7SourceIntegrationsSomeAPIobjproject.assets.json' not found.
Run a NuGet package restore to generate this file.
En mi configuración de compilación, ya tenía un paso de instalación de NuGet antes del paso de compilación:
- NuGetversion: 3.4.4
- Modo de restauración: instalar
Resultó que tuve que usar:
- Versión de NuGet: 4.0.0 o superior
- Modo de restauración: Restaurar (requiere NuGet 2.7+)