La guía paso a paso o código que hallarás en este artículo es la solución más eficiente y válida que hallamos a tu duda o dilema.
Solución:
Después de muchas horas de buscar y examinar las publicaciones de problemas de NuGet y filtrar el ruido de .net core, ¡tengo una solución!
De acuerdo con algunos problemas de NuGet y msbuild msbuild planteados, al restaurar con NuGet (o msbuild /restore) en la cuenta del sistema local en Windows Server 2012, no se puede acceder a la carpeta que usa NuGet o es una carpeta diferente debido a 32 bits frente a 64 bits proceso que se está ejecutando para que no pueda descargar nugets a esa carpeta de caché local.
Esta carpeta que msbuild quiere buscar en tiempo de compilación parece ser C:Windowssystem32configsystemprofile.nugetpackages.
La solución para nosotros fue configurar la carpeta de caché del paquete NuGet usando la variable de entorno de todo el sistema NUGET_PAQUETES a una carpeta diferente y accesible, como C:NugetPackageCache, por ejemplo
NUGET_PACKAGES=C:NugetPackageCache
También puede configurar esto por proyecto de Jenkins configurando el Entorno de compilación->Inyectar variables de entorno en el proceso de compilación->Propiedades Contenido a:
NUGET_PACKAGES=C:/NugetPackageCache
Otra solución potencial de acuerdo con esta publicación de problemas de NuGet es establecer la variable de entorno en la carpeta en la que msbuild está buscando los nugets, es decir
NUGET_PACKAGES=C:Windowssystem32configsystemprofile.nugetpackages
Nota: Las variables de entorno tienen prioridad con NuGet. No parece que hayan actualizado los documentos de NuGet todavía para mencionar la precedencia.
Nota: Para inyectar/establecer las variables de entorno, estamos usando el complemento EnvInject Jenkins que se ve así:
Tuvimos una situación muy similar pero ligeramente diferente en un proyecto de .NET Framework, recientemente convertido a 4.7.2 y para usar packages.config, basado en servidores Jenkins basados en Windows donde el servicio se ejecuta como sistema local. En nuestro caso, encontramos que nuget restore era simplemente no mirando nuestro feed MyGet privado y, en consecuencia, no estaba instalando nuestros propios paquetes desde esa fuente, lo que falló en la compilación. No aparecía en la lista de “fuentes usadas” después de una nuget restore dominio.
Inspirado por la respuesta de mips aquí (y los problemas de NuGet vinculados desde allí), descubrí que el problema era que, a pesar de enumerar C:Windowssystem32configsystemprofileAppDataRoamingNuGetNuGet.config como fuente de configuración (que de hecho fue donde se configuró nuestro feed MyGet), de hecho estaba usando C:WindowsSysWOW64configsystemprofileAppDataRoamingNuGetNuGet.config en cambio. Pude resolver el problema copiando el archivo NuGet.config de la ubicación system32 a la ubicación SysWOW64.
No hubo necesidad de configurar e inyectar una variable de entorno NUGET_PACKAGES.
Comentarios y valoraciones
Te invitamos a añadir valor a nuestra información cooperando tu veteranía en las ilustraciones.