visual-studio - revirtiendo - visual studio la configuracion de nuget no es valida

No se puede actualizar automáticamente un paquete NuGet a la última versión durante la compilación

Question

Tenemos dos soluciones .NET separadas:

• Ejecutar una compilación para la primera solución produce nuestro producto final: un grupo de DLL. Estos archivos DLL se entregan a nuestros clientes a través de un paquete NuGet.
• La segunda solución sirve como una solución de prueba de producto: el paquete NuGet está instalado, y está construido y ejecutado, por lo que hace uso de nuestro producto exactamente de la misma manera que lo harían nuestros clientes.

El desafío aquí es que debería haber una manera en que nuestro último paquete NuGet se instale automáticamente en la solución de prueba del producto, preferiblemente durante la construcción de esta solución de prueba del producto.

Basado en las ideas de una pregunta similar , llegué tan lejos con la configuración de la solución de prueba de producto:

• Primero habilité NuGet Package Restore. Esto me permite deshacerme por completo del directorio "packages" de VCS ya que NuGet descargará automáticamente el paquete con la versión definida en el archivo packages.config antes de la compilación.
• Luego agregué el siguiente evento de preconstrucción en Visual Studio: $(SolutionDir).nuget/nuget update -prerelease $(ProjectDir)packages.config . Esto me permite incorporar la última versión de nuestro paquete NuGet durante la compilación.

Actualmente uso el escenario anterior para ejecutar compilaciones locales usando Visual Studio y compilaciones desatendidas usando TeamCity. La solución parece funcionar para ambos escenarios a primera vista, pero en realidad no produce el resultado esperado : cuando se construye la solución de prueba de producto, en el directorio bin no obtengo la última versión de los DLL, solo el la última versión 1.

El problema es que aunque el comando nuget update actualiza todo como se esperaba, incluidos los packages.config y el archivo .csproj , la .csproj no recoge su nuevo contenido , por lo tanto, como supongo, la configuración HintPath del .csproj El archivo aún refleja un estado "anterior a la compilación", por lo tanto, los archivos DLL antiguos se copian en el directorio bin . Supongo que el archivo .csproj se procesa solo una vez: antes de que se desencadene el evento de precompilación, y los cambios realizados por el evento de preconstrucción se ignoran hasta la próxima compilación.

Consideré las siguientes soluciones:

• Al parecer, la preconstrucción no es lo suficientemente "pre". Si había un punto aún más temprano que podría insertar el comando nuget update , mi solución anterior probablemente funcionaría.
• Leí que podía anular HintPath-s en el archivo .csproj definiendo un ReferencePath. Pero dudo que pueda encontrar fácilmente el camino correcto o podría establecerlo lo suficientemente temprano para que la compilación lo capte.
• Como solución alternativa pude ejecutar las compilaciones dos veces: duplicar el paso de compilación para la solución de prueba de producto en TeamCity y siempre pude construir la solución dos veces localmente en Visual Studio.

¿Alguien ha descubierto cómo actualizar automáticamente un paquete NuGet a la última versión durante la compilación?

Answer 1

Creo que poner la actualización automática al paso previo a la compilación no es estilo NuGet. Puede comprender que necesita esta operación cada vez que lo hace. Sobre todo porque puede aumentar el tiempo de construcción. Por ejemplo, cuando usa TDD y, con frecuencia, reconstruye proyectos y ejecuta pruebas, espera que se haga de forma rápida. Además, puede actualizar paquetes inesperados y romper algo, después de eso puede pasar mucho tiempo para encontrar el problema.
Sugiero actualizar como el paso separado. En TeamCity puede usar el paso de compilación del NuGet installer . Para realizar la actualización simplemente marque dos casillas de verificación en el área inferior de la configuración de pasos:

Además, si desea mantener el resultado de la actualización después de una compilación exitosa y una prueba de aprobación, puede agregar un paso de compilación posterior que confirme estos cambios en VCS (utilizando cmd o PowerShell, por ejemplo).
Cuando trabajas localmente, creo que es mejor ejecutar los paquetes de actualización una vez antes de comenzar a trabajar con el proyecto. Puede usar la Package Manager Console de Package Manager Console para esto, con el comando Update-Package -IncludePrerelease .

Answer 2

Echa un vistazo a una publicación de blog que acabo de hacer con respecto a este proceso. En lugar de configurar cosas en el servidor, lo hice aumentando el archivo Nuget.Targets que se implementó con la opción Restauración de paquetes de Nuget. La belleza de este enfoque es que se ejecuta localmente Y en el servidor (para que pueda ver los posibles efectos secundarios antes de romper la construcción)

Detalles detallados aquí: http://netitude.bc3tech.net/2014/11/28/auto-update-your-nuget-packages-at-build-time/

Answer 3

La solución de MSBuild que descubrí es anular la propiedad BuildDependsOn . Por lo tanto, creé un UpdateNugetPackages.target que se ve así:

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="14.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <BuildDependsOn>
      UpdateNugetPackages;
      $(BuildDependsOn);
    </BuildDependsOn>
    <UpdateCommand>"$(SolutionDir)pathToYourNugetExe.exe" update "$(SolutionDir)NameOfYourSolution.sln"</UpdateCommand>
  </PropertyGroup>
  <Target Name="UpdateNugetPackages">
    <Exec Command="$(UpdateCommand)"></Exec>
  </Target>
</Project>

UpdateCommand define dónde y con qué argumentos se llama a nuget.exe . Siéntase libre de adoptar esto para sus propias necesidades.

A continuación, se hace referencia a este objetivo en su archivo .csproj . Tan sencillo como eso:

<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
 ...
    <Import Project="$(MSBuildToolsPath)/Microsoft.CSharp.targets" />
    <!-- After the initial decleration of the BuildDependsOn-Property. -->        
    <Import Project="UpdateNugetPackages.target" Condition="Exists(''UpdateNugetPackages.target'')" />

Tenga en cuenta que importa el orden de importación. UpdateNugetPackages.targets importar su archivo de destino ( UpdateNugetPackages.targets ), con anulaciones (o BuildDependsOn decorar) la propiedad BuildDependsOn , después del archivo de destino Microsoft.Common.targets que lo define. De lo contrario, la propiedad se redefinirá y eliminará los cambios, ya que la definición inicial en Microsoft.Common.targets no incluye ningún valor existente en BuildDependsOn . Microsoft.Common.targets es importado por Microsoft.CSharp.targets para un proyecto de C #. Por lo tanto, su importación debe ir después de la importación de Microsoft.CSharp.targets .