Solución de retargeting de .Net 4.0 a 4.5: ¿cómo retarget los paquetes NuGet?

205

He migrado una solución que actualmente apunta a .NET 4.0 en VS2010 a VS2012 y ahora me gustaría reorientarla a .Net 4.5

De lo que no estoy seguro es de los paquetes NuGet. Por ejemplo, EF5, que actualicé desde EF4 en VS2010, resulta ser EF 4.4 como puede ver aquí:

    <Reference Include="EntityFramework, Version=4.4.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, processorArchitecture=MSIL">
      <SpecificVersion>False</SpecificVersion>
      <HintPath>..\packages\EntityFramework.5.0.0\lib\net40\EntityFramework.dll</HintPath>
    </Reference>

También puedo ver lo siguiente en packages.config para el proyecto:

<?xml version="1.0" encoding="utf-8"?>
<packages>
  <package id="EntityFramework" version="5.0.0" targetFramework="net40" />
</packages>

Entonces mi pregunta es:

¿Cuál es la mejor práctica para reorientar todos los paquetes NuGet que actualmente están configurados para apuntar a .NET 4.0 para apuntar a .NET 4.5?

— Ivan Zlatev
fuente

stackoverflow.com/questions/6876732/…

— Ohad Schneider

266

NuGet 2.1 ofrece una función que hace que esto sea mucho más simple: simplemente hazlo update-package -reinstall -ignoreDependenciesdesde la consola del Administrador de paquetes.

NuGet 2.0 no maneja muy bien la reorientación de sus aplicaciones. Para cambiar los marcos de destino de sus paquetes, debe desinstalarlos y reinstalarlos (tomando nota de los paquetes que había instalado para poder reinstalar cada uno de ellos).

La razón por la que los paquetes deben desinstalarse y reinstalarse es:

Al instalar un paquete, determinamos el marco objetivo de su proyecto
Luego lo combinamos con el contenido del paquete, encontrando la carpeta \ lib \ apropiada (y la carpeta \ content \)
Se agregan referencias de ensamblaje con rutas de sugerencias que apuntan a la carpeta \ lib \ del paquete, con la subcarpeta derecha (\ lib \ net40, por ejemplo)
Los archivos de contenido se copian de la carpeta paquetes \ contenido \, con la subcarpeta derecha (\ content \ net40 por ejemplo)
Registramos el targetFramework utilizado para instalar el paquete dentro del archivo packages.config
Después de cambiar el marco de destino de su proyecto, las Rutas de sugerencias aún apuntan a net40
Cuando desinstala paquetes, verificamos el targetFramework que se grabó en packages.config para ver qué libs / contenido de framework de destino eliminar de su proyecto
Cuando reinstala el paquete, detectamos su marco de destino actualizado y hacemos referencia / copiamos las bibliotecas / contenidos correctos

— Jeff Handley
fuente

Utilizando VS 2012 con un proyecto ASP.NET MVC 4 y después de reorientar .NET Framework de 4.0 a 4.5, ejecuté update-package -reinstallen Package Manager Console. Todos los paquetes comenzaron a desinstalarse y actualizarse y, de repente, Windows 8 se reinició y cuando regresó le dijo "Su PC se encontró con un problema y se reinició. ¿Desea enviar información a Microsoft?" :( Asustando ... Por cierto, esta es la versión de NuGet que he instalado ahora 2.2.40116.9051: abrí

— Leniel Maccaferri

12

Las opciones de reinstalación nunca me han funcionado. Se elimina en el orden incorrecto y los errores en "no se puede eliminar X porque Y depende de ello" o, a veces, simplemente no se leen los paquetes. La última vez que lo probé, eliminó EntityFramework y luego nunca lo volvió a agregar.

— CodingWithSpike

44

update-package -reinstall no fue una solución para mí. También actualizó muchos paquetes, en lugar de dejarlos en las versiones que usamos y que probamos. Por ejemplo, Ninject se movió a v3, y eso es un cambio de versión de última hora.

— Steve Owen

13

Ni siquiera intente la actualización-página-reinstalar. Esto fue un desastre cuando se ejecutó en mi máquina local que tuve que evitar que el administrador de paquetes NuGet siguiera adelante. Eliminó mi versión jQuery 1.10 y la reemplazó con 1.4.4 por alguna razón. Solo hazlo manualmente y ahórrate la molestia.

— JustinMichaels

2

Estuve de acuerdo con el asunto del desastre, y eso es incluso dos años después de esta publicación. Encontró versiones inferiores de ciertos nugets y arruinó muchas referencias. Y eso fue después de casi dos horas de actualización (en una estación de trabajo de gama alta desde principios de 2014). 20 proyectos en la solución.

— Arve Systad

42

Para aquellos que tuvieron problemas con el update-package -reinstall <packagename>comando, considere ejecutarlo con -ignoreDependenciesflag, así:

update-package -reinstall <packagename> -ignoreDependencies

Este indicador dejará en paz las dependencias de su paquete, de lo contrario, podrían actualizarse incluso si el paquete que originalmente deseaba reinstalar aún mantiene su versión en el mismo.

Más información aquí .

— vpalmu
fuente

Gracias, eso realmente ahorra muchos problemas. Ver a Nuget tratando de reinstalar las aproximadamente 10 dependencias que EnterpriseLibrary tiende a crear, en más de 30 proyectos, se dirigía hacia un trabajo de un día. Esto lo reduce a minutos.

— David Keaveny

Como otros mencionaron, es muy probable que lo rompan todo.

— Gleno

9

Puede automatizar esto para toda la solución cambiándolo ligeramente cuando se ejecuta bajo la Consola del Administrador de paquetes:get-package | % { update-package $_.Id -reinstall -ProjectName $_.ProjectName -ignoreDependencies }

— Kaleb Pederson,

2

@KalebPederson En mi experiencia, el comando funciona en toda la solución?

1

@ BjörnAliGöransson - Perdón si no fui lo suficientemente claro. La respuesta proporciona una manera de actualizar un solo paquete en la solución. Mi script revisará todos los paquetes de NuGet en la solución y lo redirigirá a través de la solución. La respuesta es perfecta para un solo proyecto, pero el script que proporcioné puede ser mejor si tiene muchos paquetes que necesitan ser reorientados.

— Kaleb Pederson

22

Después de probar la respuesta aceptada sin éxito, me gustaría sugerir un comando menos arriesgado:

Update-Package <PackageName> -ProjectName <ProjectName> -Reinstall -IgnoreDependencies

Para más información: http://blog.nuget.org/20121231/a-quick-tutorial-on-update-package-command.html

— Bo Sunesen
fuente

1

De acuerdo con la documentación vinculada -reinstall, solo se instalará la misma versión, por lo que no ve ningún beneficio al usarla -safe. ¿Me estoy perdiendo de algo?

— Kaleb Pederson el

4

Al intentar reinstalar paquetes en toda la solución, encontré un error de dependencia (a pesar de usar el -ignoreDependenciesindicador), y todos los archivos packages.config para cada proyecto habían sido eliminados. En VS2013, parece que los paquetes.config no se vuelven a vaciar en el disco y se vuelven a agregar hasta que todas las dependencias / referencias actualizadas se vuelvan a unir al proyecto.

En mi caso, lo que funcionó fue actualizar cada proyecto uno por uno agregando el -ProjectName nombre del proyecto al update-packagecomando. En este caso los paquetes.config se actualizan a medida que se actualiza cada proyecto.

Puede que no sea práctico para soluciones muy grandes, pero parece un compromiso razonable seguir aprovechando la actualización automatizada para tantos proyectos como sea posible y aislar los problemáticos sin tener todos los paquetes.config en su solución eliminados en caso de falla.

— Craigologia
fuente

3

Me encontré con el mismo problema. UpdatePackage -Reinstalleliminó el paquete.config y las referencias de proyecto para algunos proyectos (específicamente los que tenían ensamblados falsos generados en ellos). Trabajamos alrededor de esto deshaciendo todos los cambios en el proyecto jodido y ejecutándolo:Update-Package -reinstall -ProjectName "PROJECTNAME" -IgnoreDependencies

— MSC

1

Con Visual Studio para Mac 2019, hacer clic con el botón derecho en la carpeta Paquetes muestra la opción 'Retarget' en el menú. Esto resolvió el problema de retarget para todos los paquetes en el proyecto que requerían retargeting. Parece que no había NuGet Package Manager en el menú Herramientas en Visual Studio para Mac (al menos en el mío), por lo que no pude iniciar Package Manager Console.

— Prabu Arumugam
fuente