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

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?

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

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í .

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

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.

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.