Как настроить проекты Visual Studio 2013 для создания пакетов nuget с несколькими версиями .Net?

102
10

У нас есть несколько разных команд, создающих приложения С# с Visual Studio. Когда мы хотим делиться библиотеками между командами, мы создаем пакеты nuget для библиотек и добавляем их в локальный фид nuget.


Процесс, который мы используем для упаковки наших библиотек, очень прост: мы создаем .nuspec для библиотеки, а затем запускаем nuget в проекте .csproj для создания пакета.


В результате создается пакет, специфичный для .Net-версии (4.0, 4.5, 4.5.1), выбранной для проекта .csproj для проекта. Мы довольно много стандартизировали на 4.5, чтобы справиться с этим.


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


Итак, мой вопрос: есть ли простой/стандартный способ настройки проекта библиотеки в Visual Studio, чтобы он создавал пакет Nuget, совместимый с кросс-версией?

спросил(а) 2021-01-19T19:02:03+03:00 9 месяцев назад
1
Решение
79

Если вам действительно нужно поддерживать разные версии фреймворков, сначала вам придется создавать разные конфигурации для каждой версии фреймворка (в ваших файлах .csproj), используя диспетчер конфигурации. Подобно стандартным конфигурациям "Debug" и "Release", или "x86_Debug" и т.д. Вы можете добавлять конфигурации самостоятельно, как Release_Fw_40, Release_Fw_45, Release_Fw_451.


При упаковке с помощью Nuget вы можете использовать параметр


   -Prop Configuration=Release_Fw_40

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

Обратите внимание, что это потребует дополнительных усилий для тех, кто поддерживает библиотеку, для управления этими многочисленными конфигурациями. Должно быть очевидно, что даже если вы предоставили версию своей версии "Fw 4.5.1", вы можете использовать только функции Fw 4.0 в исходном коде, если хотите поддерживать конфигурацию Fw 4.0. Поэтому убедитесь, что вы пытаетесь на самом деле стоить хлопот.


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



Я не уверен, что вы подразумевали под этим предложением, может быть, я рассказываю вам только то, что вы уже знали. Но "перемещение файлов по разным папкам" и "вызов пакета nuget на более низком уровне" - это вещи, которые могут быть очень легко написаны сценарием. Для таких задач вы можете использовать простые сценарии оболочки Windows или скрипты Powershell, независимо от того, что вы предпочитаете.

ответил(а) 2021-01-19T19:02:03+03:00 9 месяцев назад
79

Не прямой ответ на ваш вопрос, я знаю это, но...


Зачем настраивать несколько версий фреймворка?


Когда NuGet устанавливает пакет с несколькими версиями сборки, он пытается сопоставить имя структуры сборки с целевой рамки проекта. Если совпадение не найдено, NuGet копирует сборку, которая для самой высокой версии, которая меньше или равна целевую структуру проекта.



Соответствие версии сборки целевой инфраструктуре проекта

Мы сделали то, что наш самый низкий общий знаменатель, как для наших библиотек, так и для нашей организации. В нашем случае у нас есть несколько старых приложений, все еще работающих на платформе 3.5, поэтому любые пакеты NuGet, которые у нас есть, которые должны быть доступны для всех/всех проектов, также нацелены на структуру 3.5. Тем не менее, у нас также есть несколько библиотек, которые нужны только некоторым новым приложениям, этим целевым 4.5 (как для проектов, так и для библиотек). Это позволяет нам использовать более новые функции.


Если мы окажемся в ситуации, когда более старое приложение должно ссылаться на пакет, который должен ссылаться на новейшую версию для работы, мы кусаем пулю и обновляем проект. Однако для наших библиотек/пакетов мы всегда нацелены на самую старую версию. В принципе, разделение - это то, где мы хотим/должны использовать Async/Await.


TL; DR: не нацеливаться на несколько фреймворков. Задайте самый низкий общий знаменатель. Это дает мотивацию для обновления приложений, отстающих на 3,5 или 4. (Или, не дай Бог, 2.0...)

ответил(а) 2021-01-19T19:02:03+03:00 9 месяцев назад
Ваш ответ
Введите минимум 50 символов
Чтобы , пожалуйста,
Выберите тему жалобы:

Другая проблема