Solução de redirecionamento de .Net 4.0 para 4.5 - como redirecionar os pacotes NuGet?

205

Migrei uma solução que está direcionada para o .NET 4.0 no VS2010 para o VS2012 e agora gostaria de redirecioná-la para .Net 4.5

O que não tenho certeza são os pacotes NuGet. Por exemplo, o EF5, que atualizei do EF4 no VS2010, na verdade é o EF 4.4, como você pode ver aqui:

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

Também posso ver o seguinte em packages.config para o projeto:

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

Então, minha pergunta é:

Qual é a melhor prática para redirecionar todos os pacotes NuGet atualmente definidos para direcionar o .NET 4.0 para o .NET 4.5?

— Ivan Zlatev
fonte

stackoverflow.com/questions/6876732/…

— Ohad Schneider

266

O NuGet 2.1 oferece um recurso que torna isso muito mais simples: basta fazê update-package -reinstall -ignoreDependencies-lo no Package Manager Console.

O NuGet 2.0 não trata de redirecionar seus aplicativos muito bem. Para alterar as estruturas de destino dos seus pacotes, você deve desinstalar e reinstalar os pacotes (anotando os pacotes que você instalou para poder reinstalar cada um deles).

O motivo pelo qual os pacotes devem ser desinstalados e reinstalados é:

Ao instalar um pacote, determinamos a estrutura de destino do seu projeto
Em seguida, combinamos isso com o conteúdo do pacote, localizando a pasta \ lib \ apropriada (e a pasta \ content \)
As referências de montagem são adicionadas com os caminhos de dica que apontam para a pasta \ lib \ do pacote, com a subpasta correta (\ lib \ net40, por exemplo)
Os arquivos de conteúdo são copiados da pasta packages \ content \, com a subpasta correta (\ content \ net40, por exemplo)
Registramos o targetFramework usado para instalar o pacote no arquivo packages.config
Depois de alterar a estrutura de destino do seu projeto, os Caminhos da dica ainda apontam para net40
Quando você desinstala os pacotes, verificamos o targetFramework que foi registrado em packages.config para ver quais bibliotecas / conteúdo da estrutura de destino remover do seu projeto
Quando você reinstala o pacote, detectamos sua estrutura de destino atualizada e fazemos referência / copiamos as libs / conteúdo corretos

— Jeff Handley
fonte

Usando o VS 2012 com um projeto ASP.NET MVC 4 e depois de redirecionar o .NET Framework de 4.0 para 4.5, executei update-package -reinstallno Package Manager Console. Todos os pacotes começaram a ser desinstalados e atualizados e, de repente, o Windows 8 foi reiniciado e, quando voltou, ele disse: "Seu PC encontrou um problema e foi reiniciado. Deseja enviar informações à Microsoft?" :( Assustador ... Aliás, esta é a versão do NuGet que instalei no momento: 2.2.40116.9051Abriu um problema aqui: nuget.codeplex.com/workitem/3049

— Leniel Maccaferri -

12

as opções de reinstalação nunca funcionaram para mim. Ele é removido na ordem errada e os erros em "não é possível remover o X porque Y depende dele" ou às vezes simplesmente não lê os pacotes. A última vez que tentei, ele removeu o EntityFramework e nunca o adicionou novamente.

— precisa saber é o seguinte

4

update-package -reinstall não foi uma solução para mim. Também atualizou muitos pacotes, em vez de deixá-los nas versões que usamos e testamos. Por exemplo, o Ninject foi movido para a v3, e essa é uma mudança na versão.

— Steve Owen

13

Nem tente a reinstalação da página de atualização. Essa coisa estava tão bagunçada quando funcionou na minha máquina local que eu tive que parar o Gerenciador de Pacotes NuGet de continuar. Ele removeu minha versão do jQuery 1.10 e a substituiu pela 1.4.4 por algum motivo. Basta fazê-lo manualmente e poupar o trabalho.

— 23813 JustinMichaels #

2

Concordo com a bagunça, e isso é até dois anos depois deste post. Encontrou versões inferiores de certas pepitas e estragou muitas referências. E isso ocorreu depois de quase duas horas de atualização (em uma estação de trabalho de ponta do início de 2014). 20 projetos na solução.

— Arve Systad 23/09/14

42

Para aqueles que tiveram problemas com o update-package -reinstall <packagename>comando, considere executá-lo com -ignoreDependenciessinalizador, assim:

update-package -reinstall <packagename> -ignoreDependencies

Esse sinalizador deixará as dependências do pacote em paz, caso contrário, elas poderão ser atualizadas, mesmo que o pacote que você queria reinstalar ainda mantenha sua versão na mesma.

Mais informações aqui .

— vpalmu
fonte

Obrigado, isso realmente economiza muitos problemas. Observar Nuget tentando reinstalar as 10 dependências que a EnterpriseLibrary tende a criar, em mais de 30 projetos, estava caminhando para um trabalho de um dia. Isso reduz a minutos.

— David Keaveny

Como outros mencionaram, é muito provável que quebre tudo.

— Gleno

9

Você pode automatizar esse para toda a solução, alterando-o apenas ligeiramente quando rodando sob o console de Gerenciador de Pacotes:get-package | % { update-package $_.Id -reinstall -ProjectName $_.ProjectName -ignoreDependencies }

— Kaleb Pederson

2

@KalebPederson Na minha experiência, o comando funciona em toda a solução?

1

@ BjörnAliGöransson - Desculpe se eu não estava suficientemente claro. A resposta fornece uma maneira de atualizar um único pacote na solução. Meu script percorre todos os pacotes NuGet da solução e os redireciona novamente para a solução. A resposta é perfeita para um único projeto, mas o script que forneci pode ser melhor se você tiver muitos pacotes que precisam ser redirecionados.

— Kaleb Pederson

22

Depois de tentar a resposta aceita sem êxito, gostaria de sugerir um comando menos arriscado:

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

Para mais informações: http://blog.nuget.org/20121231/a-quick-tutorial-on-update-package-command.html

— Bo Sunesen
fonte

1

De acordo com a documentação vinculada -reinstall, instalará apenas a mesma versão, portanto, não há nenhum benefício em usar -safe. Estou esquecendo de algo?

— Kaleb Pederson

4

Enquanto tentava reinstalar os pacotes em toda a solução, encontrei um erro de dependência (apesar de usar o -ignoreDependenciessinalizador) e todos os arquivos packages.config para cada projeto foram excluídos. No VS2013, parece que o packages.config não é liberado novamente no disco e adicionado novamente até que todas as dependências / referências atualizadas sejam reconectadas ao projeto.

No meu caso o que funcionou foi o de atualizar cada projeto de um-em-um-tempo, adicionando a -ProjectName projectname ao update-packagecomando. Nesse caso, o packages.config é atualizado à medida que cada projeto é atualizado.

Pode não ser prático para soluções muito grandes, mas parece um compromisso razoável ainda aproveitar a atualização automatizada para o maior número possível de projetos e isolar os problemáticos sem que todos os packages.config da sua solução sejam excluídos por falha.

— Craigology
fonte

3

Eu tive o mesmo problema. UpdatePackage -Reinstallexcluiu as referências package.config e project para alguns projetos (especificamente aqueles que tiveram assemblies falsos gerados neles). Fizemos uma solução para isso, desfazendo todas as alterações no projeto e executando asneira:Update-Package -reinstall -ProjectName "PROJECTNAME" -IgnoreDependencies

— MSC

1

Com o Visual Studio para Mac 2019, clicar com o botão direito do mouse na pasta Pacotes mostra a opção 'Retarget' no menu. Isso resolveu o problema de redirecionamento para todos os pacotes no projeto que exigiam redirecionamento. Parece que não havia o Gerenciador de Pacotes NuGet no menu Ferramentas do Visual Studio para Mac (pelo menos no meu), então não pude iniciar o Console do Gerenciador de Pacotes.

— Prabu Arumugam
fonte