Вопрос по nuget, c#, visual-studio-2013, nuget-package, visual-studio – Безболезненное локальное развитие, а также ссылки на пакеты NuGet

36

Я пытаюсь публиковать и использовать версионные пакеты библиотек классов NuGet, избегая при этом головной боли при локальной разработке. Вот пример макета решения Visual Studio:

| Libraries
  | LibraryA
  | LibraryB
  | LibraryC
| Applications
  | ApplicationD
  | ApplicationE

Это единое решение, содержащее как общие библиотеки классов, так и несколько приложений. В настоящее время ссылки на библиотеки классов приложениями являются локальными ссылками в решении.

Я хотел бы опубликовать библиотеки (A, B, C) в виде версионных пакетов NuGet, на которые затем ссылаются приложения по мере необходимости (D, E). Это позволяет изменению общей библиотеки быть независимым от обновления развернутого приложения. Без этого изменение одной библиотеки может привести к изменению двоичных файлов в дюжине или более приложений, которые технически необходимо будет протестировать. Это нежелательно, и версия с NuGet исправляет это.

Тем не менее, позвольте мне сказать, что я хочу обновить содержимое LibraryA и ApplicationD одновременно. Чтобы сделать это после того, как мы переключимся на NuGet, мне придется внести изменения в LibraryA, зафиксировать их, дождаться создания пакета, сказать ApplicationD обновить ссылку на LibraryA, а затем протестировать или разработать в ApplicationD. Это гораздо сложнее, чем просто работать с обоими одновременно, используя локальные ссылки в решении.

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

РЕДАКТИРОВАТЬ: Чтобы уточнить предпосылку, этот вопрос предполагает следующее:

Архитектура (решение и организация проекта) не может быть существенно реорганизованаОбщие библиотеки будут меняться с нетривиальной частотойИзменение общей библиотеки не может принудительно обновить любое приложениеПриложения могут ссылаться на разные версии общих библиотек
@ Андрей Да! Возможность ссылаться на конкретные версии - вот почему я использую NuGet для решения этой проблемы. jmsb
@Euphoric Есть ли у вас какие-либо рекомендации, как я могу обновить разделяемую библиотеку A, которая может использоваться 50 отдельными приложениями, без необходимости навязывать новую версию для всех 50 приложений и запускать много регрессионного тестирования? Упомянутая вами стабильность - это хороший идеал, к которому нужно стремиться, но не пригодный для этого варианта использования. Я открыт для других подходов / инструментов, конечно. jmsb
Я думаю, что проблема в том, что у вас есть библиотека, которая не стабильна и зависит от 50 других. Лучший способ - это перестроить архитектуру, чтобы повысить стабильность, а затем создать отдельное решение с его собственными требованиями, запросами на изменение и планом развития. И если у вас действительно есть 50 приложений, которые зависят от него, то это не будет таким большим усилием. Euphoric
«Допустим, я хочу обновлять содержимое LibraryA и ApplicationD одновременно». Если это вызывает озабоченность, я настоятельно рекомендую не использовать пакеты NuGet. Сборки должны быть превращены в пакеты NuGet, когда они достаточно стабильны, чтобы редко изменяться и когда процесс их изменения отделен от остальной системы. Euphoric

Ваш Ответ

3   ответа
9

что это 2-летний пост, но только что нашел его, столкнувшись с той же ситуацией. Также нашел это для VS2015, я нахожусь в процессе тестирования, ING. Я вернусь и исправлю свой ответ соответственно.

https://marketplace.visualstudio.com/items?itemName=RicoSuter.NuGetReferenceSwitcherforVisualStudio2015

Этот плагин не работает, даже тот, что для VS2017 Jeremy F.
В части вопросов и ответов. «Зачем мне ссылаться на пакет NuGet проекта, который уже находится в моем решении? Разве это не простая ссылка на проект, не требующая NuGet? В некоторых случаях это может быть правильным сценарием, но гораздо более реалистичным Сценарий - это когда код для пакета NuGet находится в другом решении, и поэтому вы будете ссылаться на него как на пакет NuGet. И этот инструмент ничего не помогает, не так ли? " Это так верно: / ahmet
Мы смогли использовать этот модуль для наших целей. Он создает файл сопоставления для каждого csproj (MyProj.nugetreferenceswitcher), который по существу перечисляет различные ссылки с их сопоставлением проекта / nuget. Это позволяет легко переключаться назад и вперед, но занимает несколько секунд / минут. JayR
Я хочу выразить это не раз :) ironic
18

можно вручную редактировать файлы .csproj, чтобы установить условные ссылки, добавивCondition приписать соответствующие ссылки.

РЕДАКТИРОВАТЬ Я переместил эти условия в ItemGroups, так как, похоже, именно так работает мой упомянутый производственный код, и было упомянуто о возможной проблеме в VS 2013.

<ItemGroup Condition="'$(Configuration)' == 'Debug Local'">
    <!-- Library A reference as generated by VS for an in-solution reference, children unmodified -->
    <ProjectReference>...
</ItemGroup>

<ItemGroup Condition="'$(Configuration)' == 'Debug NuGet'">
    <!-- Library A reference as generated by NuGet, child nodes unmodified --> 
    <Reference Include="LibraryA">...
</ItemGroup>

Это позволило бы вам иметь в проектах D & E конфигурации «Debug NuGet» и «Debug Local», которые по-разному ссылаются на библиотеки. Если затем у вас есть несколько файлов решений, сопоставление их конфигураций с соответствующими конфигурациями в проектах, конечный пользователь никогда не увидит больше, чем «Отладка» и «Выпуск» для большинства операций, так как это конфигурации конфигурации, и он будет только необходимо открыть полное решение для редактирования проектов A, B и C.

Теперь, что касается извлечения проектов A, B и C, вы можете настроить их в папке, помеченной как подрепортаж (при условии, что вы используете SCM, который поддерживает это, например, Git). Большинству пользователей никогда не потребуется извлекать подпункты, так как они не имеют доступа к проектам ABC, а вместо этого получают данные из NuGet.

В плане обслуживания я могу гарантировать, что VS не будет редактировать условные ссылки и будет уважать их во время компиляции. Я прошел как VS 2010, так и 2013 (РЕДАКТИРОВАТЬПрофессиональная версия, хотя я и сделал то же самое с Express) с теми же условными ссылочными проектами в работе. Имейте в виду, что в VS ссылки могут быть независимыми от версии, что делает NuGet единственным местом, где нужно поддерживать версию, и это можно сделать, как и любой другой пакет NuGet. Хотя я надеюсь, я НЕ проверял, будет ли NuGet бороться с условными ссылками.

РЕДАКТИРОВАТЬ Также целесообразно отметить, что условные ссылки могут вызывать предупреждения об отсутствующих библиотеках DLL, но фактически не мешают компиляции или запуску.

У @Andrew также есть предупреждение о неприятностях, должно было быть упомянуто так - еще одно входящее обновление. David
Это возможный прорыв на стороне NuGet, но легкий на VS. Я включу эту информацию в свой ответ. David
Спасибо, эти условные ссылки полезно знать. Однако после того, как я преобразую существующие ссылки, все будущие ссылки на библиотеки необходимо будет настроить вручную с использованием того же двойного подхода, верно? Я обеспокоен тем, что это будет трудно поддерживать. jmsb
Я знаю, только что сделал нечто подобное в VS2013, что, по крайней мере, для<Reference> элементы, IDE не обрабатывает несколько ссылок на одну и ту же библиотеку изящно, даже когда активна только одна ссылкаCondition атрибутов. Я не знаю, есть ли у обоих<ProjectReference> и<Reference> представляет ту же проблему. Если это так, это можно предотвратить, создав свойства, специфичные для конфигурации, и используя значения свойств в теге вместо создания нескольких тегов. Andrew
2

действительно нет способа получить лучшее из обоих миров. Внутренне в моей компании мы несколько смягчили это с помощью быстрого процесса сборки / развертывания, который снимает большую часть бремени с постоянной ссылкой на пакет NuGet. По сути, все наши приложения используют разные версии одной и той же библиотеки, размещенной в локальном репозитории NuGet. Поскольку мы используем наше собственное программное обеспечение для сборки, развертывания и размещения пакетов, это позволяет довольно быстро обновить библиотеку, а затем обновить ее пакет NuGet в другом решении. По сути, самый быстрый рабочий процесс, который мы нашли, это:

Внести изменения в библиотекуАвтоматически создавать и развертывать версию библиотеки с увеличением на 1 для внутреннего фида NuGetОбновление пакета NuGet в потребительском приложении

Весь процесс от регистрации до обновления потребляющего проекта занимает около 3 минут. В репозитории NuGet также есть сервер символов / исходных текстов, который очень помогает при отладке.

Вы используете для этого 1.2.3-pre <Build> или считаете, что проще всего придерживаться 1.2. <build> и быть менее строгим в отношении всего этого? steve
Мы никогда не используем предварительную версию, в прошлом у нас возникали проблемы. Однако для обработки аналогичного случая альтернативой может быть продвижение пакета из канала разработки в поток производства или что-то в этом роде. John Rasch

Похожие вопросы