Рішення для перенаправлення з .Net 4.0 на 4.5

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 \ папку)
Посилання на збірку додаються із підказками, які вказують на папку \ lib \ пакета, з правою підпапкою (наприклад, \ lib \ net40)
Файли вмісту копіюються з папки \ content \ у папку з правою підпапкою (наприклад, \ content \ net40)
Ми записуємо targetFramework, який використовується для встановлення пакета у файлі пакети.config
Після того, як ви зміните цільову рамку проекту, підказки все ще вказують на net40
Коли ви видаляєте пакети, ми перевіряємо targetFramework, який був записаний у пакети.config, щоб побачити, які вкладки / вміст цільової рамки потрібно видалити з вашого проекту
Після перевстановлення пакета ми виявляємо оновлений цільовий фреймворк і відсилаємо / копіюємо правильні конверти / вміст

— Джефф Хендлі
джерело

Використовуючи 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

Параметри -встановити ніколи не працювали для мене. Він або видаляє в неправильному порядку, і помилки на "не може видалити X, оскільки Y залежить від цього", або іноді просто не читає пакети. Востаннє я спробував це, він видалив EntityFramework і потім більше ніколи не додавав його.

— CodingWithSpike

4

update-package -reinstall не був рішенням для мене. Він також оновлював багато пакетів, а не залишав їх у версіях, які ми використовуємо та на яких було протестовано. Наприклад, Ninject переміщено до версії v3, і це невід'ємна зміна версії.

— Стів Оуен

13

Навіть не намагайтеся оновити сторінку оновлення. Ця річ була такою безладдям, коли він біг на мою локальну машину, що мені довелося перешкоджати менеджеру NuGet Package не йти далі. Він видалив мою версію jQuery 1.10 і чомусь замінив її 1.4.4. Просто зробіть це вручну і заощадите собі клопоту.

— JustinMichaels

2

Погодився на безлад, і це навіть два роки з цієї посади. Він знайшов нижчі версії певних нугетів і накрутив чимало посилань. І це було після майже двох годин оновлення (на високому робочому місці з початку 2014 року). 20 проектів у рішенні.

— Арве Систад

42

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

update-package -reinstall <packagename> -ignoreDependencies

Цей прапор залишить залежність вашого пакета в спокої, інакше він може бути оновлений, навіть якщо пакет, який ви спочатку хотіли перевстановити, все ще зберігає його версію в тій же самій.

Більше інформації тут .

— впалму
джерело

Дякую, що справді економить багато клопоту. Спостерігаючи за Nuget, що намагається перевстановити 10 або більше залежностей, які EnterpriseLibrary прагне створити, для проектів 30+, ішов до цілоденної роботи. Це зводить це до хвилин.

— David Keaveny

Як згадували інші, дуже ймовірно все зламати.

— Глено

9

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

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

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команди. У цьому випадку пакети.config оновлюються по мірі оновлення кожного проекту.

Можливо, це не є практичним для дуже великих рішень, але здається розумним компромісом все-таки скористатися автоматизованим оновленням для якомога більшої кількості проектів та виділити проблемні, не маючи кожного пакета .

— Крейгологія
джерело

3

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

— MSC

1

У Visual Studio для Mac 2019, клацнувши правою кнопкою миші папку Packages, у меню з’явиться опція «Retarget». Це вирішило проблему повторного націлювання для всіх пакетів проекту, які потребували повторного націлення. Схоже, у меню «Інструменти» в Visual Studio для Mac (щонайменше, у мене) не було менеджера пакунків NuGet, тому я не зміг запустити консоль Package Manager.

— Prabu Arumugam
джерело

Рішення для перенаправлення з .Net 4.0 на 4.5 - як змінити пакет NuGet?