Решение по ретаргетингу от .Net 4.0 до 4.5 - как перенастроить пакеты NuGet?

205

Я перенес решение, которое в настоящее время нацелено на .NET 4.0 в VS2010, на VS2012, и теперь я бы хотел переназначить его на .Net 4.5.

В чем я не уверен, так это в пакетах NuGet. Например, EF5, который я обновил с EF4 в VS2010, на самом деле оказывается EF 4.4, как вы можете видеть здесь:

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

Я также вижу следующее в пакетах.config для проекта:

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

Итак, мой вопрос:

Какова лучшая практика для переориентации всех пакетов NuGet, которые в настоящее время настроены на целевой .NET 4.0, на целевой .NET 4.5?

— Иван Златев
источник

stackoverflow.com/questions/6876732/…

— Охад Шнайдер

266

NuGet 2.1 предлагает функцию, которая делает это намного проще: просто сделайтеupdate-package -reinstall -ignoreDependencies из консоли диспетчера пакетов.

NuGet 2.0 не очень хорошо справляется с переориентацией ваших приложений. Чтобы изменить целевые рамки ваших пакетов, вы должны удалить и переустановить пакеты (принимая во внимание установленные вами пакеты, чтобы вы могли переустановить каждый из них).

Причина, по которой пакеты должны быть удалены и переустановлены:

При установке пакета мы определяем целевую структуру вашего проекта
Затем мы сопоставляем это с содержимым пакета, находя соответствующую папку \ lib \ (и \ content \ folder)
Ссылки на сборки добавляются путями подсказок, которые указывают на папку \ lib \ пакета, с правой подпапкой (например, \ lib \ net40)
Файлы содержимого копируются из папки packages \ content \, с правой подпапкой (например, \ content \ net40)
Мы записываем targetFramework, использованный для установки пакета, в файле packages.config
После изменения целевой структуры вашего проекта пути подсказок все еще указывают на net40
Когда вы удаляете пакеты, мы проверяем targetFramework, который был записан в packages.config, чтобы увидеть, какие libs / content целевой платформы удалить из вашего проекта.
Когда вы переустанавливаете пакет, мы обнаруживаем ваш обновленный целевой фреймворк и ссылаемся / копируем нужные библиотеки / контент

— Джефф Хэндли
источник

Используя VS 2012 с проектом ASP.NET MVC 4 и после переназначения .NET Framework с 4.0 на 4.5, я запустил update-package -reinstallв консоли диспетчера пакетов. Все пакеты начали удаляться и обновляться, и внезапно Windows 8 перезагружался, и когда он вернулся, он сказал: «Ваш компьютер столкнулся с проблемой и перезапустился. Хотите отправить информацию в Microsoft?» :( Пугая ... Кстати, это версия NuGet, которую я установил прямо сейчас: 2.2.40116.9051открыл проблему здесь: nuget.codeplex.com/workitem/3049

— Лениэль Маккаферри

12

Опции -reinstall никогда не работали для меня. Он либо удаляет в неправильном порядке, а ошибки «не могут удалить X, потому что Y зависит от него», или иногда просто не читает пакеты. В прошлый раз, когда я попробовал это, он удалил EntityFramework, а затем никогда не добавлял его снова.

— CodingWithSpike

4

update-package -reinstall не был решением для меня. Он также обновил множество пакетов, вместо того, чтобы оставить их в версиях, которые мы используем и проверяли. Например, Ninject был перенесен на v3, и это смена версии.

— Стив Оуэн,

13

Даже не пытайтесь обновить страницу обновления. Эта вещь была настолько беспорядочной, когда она работала на моей локальной машине, и мне пришлось помешать менеджеру пакетов NuGet пойти дальше. Он удалил мою версию jQuery 1.10 и почему-то заменил ее на 1.4.4. Просто сделайте это вручную и избавьте себя от хлопот.

— Джастин Майклс

2

Согласился на беспорядок, и это даже через два года с этого поста. Он нашел более низкие версии некоторых нюансов и облажался много ссылок. И это было после почти двух часов обновления (на рабочей станции высокого уровня с начала 2014 года). 20 проектов в решении.

— Арве Систад

42

Для тех, у кого были проблемы с update-package -reinstall <packagename>командой, попробуйте запустить ее с -ignoreDependenciesфлагом, например так:

update-package -reinstall <packagename> -ignoreDependencies

Этот флаг оставит зависимости вашего пакета в покое, в противном случае они могут быть обновлены, даже если пакет, который вы первоначально хотели переустановить, все еще сохраняет свою версию в прежнем состоянии.

Больше информации здесь .

— vpalmu
источник

Спасибо, это действительно избавляет от многих проблем. Наблюдая за тем, как Nuget пытается переустановить 10 или около того зависимостей, которые EnterpriseLibrary стремится создать для более чем 30 проектов, направлялся к работе на целый день. Это сводит это к минутам.

— Дэвид Кивини

Как уже упоминалось, очень вероятно, что все сломается.

— Глено

9

Вы можете автоматизировать это для всего решения, слегка изменив его при работе в консоли диспетчера пакетов:get-package | % { update-package $_.Id -reinstall -ProjectName $_.ProjectName -ignoreDependencies }

— Kaleb Pederson

2

@KalebPederson По моему опыту, команда работает широкое решение?

1

@ BjörnAliGöransson - Извините, если я не достаточно ясно. Ответ предоставляет способ обновить один пакет в рамках решения. Мой сценарий будет проходить через каждый пакет NuGet в решении и перенаправлять его по всему решению. Ответ идеально подходит для одного проекта, но предоставленный мною сценарий может быть лучше, если у вас много пакетов, на которые нужно перенаправить.

— Калеб Педерсон

22

После неудачной попытки принять принятый ответ я хотел бы предложить менее рискованную команду:

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

Для получения дополнительной информации: http://blog.nuget.org/20121231/a-quick-tutorial-on-update-package-command.html

— Бо Сунесен
источник

1

Согласно связанной документации -reinstallбудет установлена только одна и та же версия, поэтому не вижу никакой пользы от использования -safe. Я что-то упускаю?

— Калеб Педерсон

4

При попытке переустановить пакетное решение в целом, я столкнулся с ошибкой зависимости (несмотря на использование -ignoreDependenciesфлага), и все файлы packages.config для каждого проекта были удалены. В VS2013, кажется , что packages.config не сбрасываться на диск и добавили повторно , пока все модернизированная зависимость / ссылка повторно прикреплено к проекту.

В моем случае то, что работало, состояло в том, чтобы обновить каждый проект по одному, добавив имя -ProjectName проекта к update-packageкоманде. В этом случае packages.config обновляется при обновлении каждого проекта.

Может быть непрактичным для очень больших решений, но кажется разумным компромиссом по-прежнему использовать автоматическое обновление для максимально возможного числа проектов и изолировать проблемные, не удаляя при этом все пакеты package.config в вашем решении.

— Craigology
источник

3

Я столкнулся с той же проблемой. UpdatePackage -Reinstallудалил файл package.config и ссылки на проекты для нескольких проектов (особенно тех, в которых были созданы поддельные сборки). Мы работали над этим, отменив все изменения в испорченном проекте и запустив:Update-Package -reinstall -ProjectName "PROJECTNAME" -IgnoreDependencies

— MSC

1

В Visual Studio для Mac 2019 при щелчке правой кнопкой мыши по папке «Пакеты» в меню отображается пункт «Ретаргетинг». Это решило проблему ретаргетинга для всех пакетов в проекте, которые требовали ретаргетинга. Похоже, в меню «Инструменты» в Visual Studio для Mac не было диспетчера пакетов NuGet (по крайней мере, у меня), поэтому я не смог запустить консоль диспетчера пакетов.

— Прабу Арумугам
источник