Да, не всё так радужно, как показалось.
Согласно MSDN, в параметр Private Path можно указывать не одну папку, а несколько.
Правда, не уверен, что всё это будет корректно собираться, буду пробовать.
Надо признаться, вы меня сильно задели, указав на неполное решение задачи.
Долго думал, обращался к первоисточникам, и хотел бы доформулировать свою мысль насчёт разных папок для библиотек пакета.
1. Согласно известной книге Рихтера, глава 2, для каждой сборки в конфигурационном файле приложения можно указать относительный PrivatePath, где CLR будет искать файлы, относящиеся к данной сборке:
2. Прописать данную настройку в .config файле можно с помощью PowerShell скрипта, идущего вместе с package.
3. При сборке пакета можно запаковать библиотеки именно в указанную Private Path.
Соответственно, во время сборки солюшена с разными версиями пакета зависимости будут храниться в отдельных папках, и друг друга не перетрут.
Единственная пока проблема — не смог найти поддержку работы с Private Path в документации NuGet. Спросил в их блоге, посмотрим, что ответят. Если будет работать, обновлю статью.
А насколько часто лично вам приходилось встречаться с тем, что в рамках одного solution встречались проекты, работающие с разными версиями одной и той же библиотеки?
Пожалуйста.
В документации к NuGetter есть пример создания пакета из двух решений с разными версиями .NET Framework.
Там библиотеки рассовываются в разные папки в одном пакете.
Соответственно, можно запаковать и старую, и новую версии.
При том, что проекты собираются не только локально.
Я не настраивал билды проектов, кроме «общей» библиотеки, так что опыт не очень большой — но никаких особых действий для включения поддержки NuGet на TFS-сервере не производилось.
Библиотека собралась со всеми пакетными зависимостями.
И не попадают в общий bin при результирующей сборке?
Здесь наврал, извините. В рамках одного solution — одна версия пакета.
… и это тоже не из коробки.
Да, подразумевается, что на машине разработчика стоит NuGet-расширение — работа с Azure намекает на необходимость данного условия.
Именно. Нарушение обратной совместимости в полный рост.
Да, выбор сделан не в пользу поддержки старых версий — по примеру Azure SDK.
Что, в общем-то, означает, что nuget-пакеты не решают проблемы реальной работы с разными версиями одной зависимости. Проверено на практике.
Спасибо за пищу для размышлений. У нас ситуация пока проще, чем вы описали.
Может быть, есть что-либо почитать на эту тему?
Вот прямо из коробки? Без каких-либо дополнительных настроек, особенно на TFS?
Не очень понятно, при чём тут TFS — или вы имеете ввиду VS на машине разработчика?
Там, конечно, должен стоять расширение NuGet, для корректной работы с пакетами.
… а что будет, если разные проекты в солюшне используют разные версии пакета?
Так как в разных проектах прописаны разные NuGet-targets, проекты и получат разные пакеты (у нас сейчас в solution есть около 10 версий, всё корректно собирается).
А что будет, если разные версии пакета смотрят на разные версии зависимостей?
Всё зависит от того, на какой пакет настроен ваш проект, и включено ли у вас обновление пакетов при сборке — если да, то при обновлении библиотек могут возникнуть ошибки сборки, да.
Ну вообще нет. Компилятор про nuget ничего не знает.
Согласен, неверно сформулировал. Я имел ввиду, что при сборке проекта NuGet-расширение исследует файл *.targets на предмет всех нужных пакетов, и если какие-то не получены, и включена их подгрузка — оно их загружает/обновляет, после чего сборка проекта идёт дальше.
У вас есть ваш собственный проект, он смотрит на, скажем, Entity Framework 4. У вас есть подключенный nuget-package, который смотрит на Entity Framework 5. Что получится?
Для решения таких случаев можно, например, в PowerShell скрипт добавить код прописывания bindingRedirect, например:
Данный код из web.config взят с реального проекта. Такой bindingRedirect прописывается пакетами Azure SDK. Разумеется, данный подход так же может породить ошибки компиляции, так как в новой EntityFramework может не быть какого-то либо функционала из прошлых версий.
Что будет без подобного редиректа — не проверял, но, видимо, будет следующее:
Код проекта, пытающийся вызвать функционал из пакета, завязанный на Entity Framework, породит ошибку компиляции.
1. Подключаем пакет через NuGet-менеджер — обращаемся к своему NuGet-репозиторию, получаем последнюю версию проекта во время сборки.
2. Через NuGet-менеджер можно запросить конкретную версию пакета, и производить сборку именно через него.
3. В пакет закладывается не только наша библиотека, но и все её зависимости (те же азуровские библиотеки).
4. Библиотеки при получении через NuGet во время сборки корректно находятся компилятором.
Собственно, после подключения к своему NuGet-фиду проблемы были решены (по крайней мере, у нас).
Пожалуйста, уточните ваш последний вопрос — я его не очень понял.
Не согласен по современникам. Лермонтов открыто восхищался Пушкиным, а Гоголь, всё-таки, начал писать, уже зная о Пушкине.
Далее, по степени известности Жуковский и Баратынский уступали (и сейчас уступают) Пушкину.
Так что не могу разделить ваше недоумение по поводу Пушкина.
Я сказал только то, что Пушкин в своих произведениях осуществил переход от одного стиля к другому (У него тоже есть торжественные стихи, но не все).
На тот момент бомонд, в котором вращался Пушкин, говорил больше на французском, нежели на русском, разве не так?
И именно благодаря стихам Пушкина этот самый бомонд увидел прелесть и в родном языке.
Всё выше указанное — лишь моё мнение, основанное на школьных знаниях литературы и истории, специальных исследований я не читал, так что поправьте, если где-то ошибся.
И к этому мнению добавляется стойкое отвращение к его произведениям, как и ко всему, что «хорошо по определению». А про его труд как историка вообще никто не заикался в школе.
Переход от од (Ломоносов, Державин и другие пафосные литераторы) к простому слогу и более обыденным словам (Евгений Онегин, например) осуществил именно А.С.
Согласно MSDN, в параметр Private Path можно указывать не одну папку, а несколько.
Правда, не уверен, что всё это будет корректно собираться, буду пробовать.
Долго думал, обращался к первоисточникам, и хотел бы доформулировать свою мысль насчёт разных папок для библиотек пакета.
1. Согласно известной книге Рихтера, глава 2, для каждой сборки в конфигурационном файле приложения можно указать относительный PrivatePath, где CLR будет искать файлы, относящиеся к данной сборке:
2. Прописать данную настройку в .config файле можно с помощью PowerShell скрипта, идущего вместе с package.
3. При сборке пакета можно запаковать библиотеки именно в указанную Private Path.
Соответственно, во время сборки солюшена с разными версиями пакета зависимости будут храниться в отдельных папках, и друг друга не перетрут.
Единственная пока проблема — не смог найти поддержку работы с Private Path в документации NuGet. Спросил в их блоге, посмотрим, что ответят. Если будет работать, обновлю статью.
В документации к NuGetter есть пример создания пакета из двух решений с разными версиями .NET Framework.
Там библиотеки рассовываются в разные папки в одном пакете.
Соответственно, можно запаковать и старую, и новую версии.
Я не настраивал билды проектов, кроме «общей» библиотеки, так что опыт не очень большой — но никаких особых действий для включения поддержки NuGet на TFS-сервере не производилось.
Библиотека собралась со всеми пакетными зависимостями.
И не попадают в общий bin при результирующей сборке?
Здесь наврал, извините. В рамках одного solution — одна версия пакета.
… и это тоже не из коробки.
Да, подразумевается, что на машине разработчика стоит NuGet-расширение — работа с Azure намекает на необходимость данного условия.
Именно. Нарушение обратной совместимости в полный рост.
Да, выбор сделан не в пользу поддержки старых версий — по примеру Azure SDK.
Что, в общем-то, означает, что nuget-пакеты не решают проблемы реальной работы с разными версиями одной зависимости. Проверено на практике.
Спасибо за пищу для размышлений. У нас ситуация пока проще, чем вы описали.
Может быть, есть что-либо почитать на эту тему?
Не очень понятно, при чём тут TFS — или вы имеете ввиду VS на машине разработчика?
Там, конечно, должен стоять расширение NuGet, для корректной работы с пакетами.
Так как в разных проектах прописаны разные NuGet-targets, проекты и получат разные пакеты (у нас сейчас в solution есть около 10 версий, всё корректно собирается).
Всё зависит от того, на какой пакет настроен ваш проект, и включено ли у вас обновление пакетов при сборке — если да, то при обновлении библиотек могут возникнуть ошибки сборки, да.
Согласен, неверно сформулировал. Я имел ввиду, что при сборке проекта NuGet-расширение исследует файл *.targets на предмет всех нужных пакетов, и если какие-то не получены, и включена их подгрузка — оно их загружает/обновляет, после чего сборка проекта идёт дальше.
Для решения таких случаев можно, например, в PowerShell скрипт добавить код прописывания
bindingRedirect, например:Данный код из web.config взят с реального проекта. Такой
bindingRedirectпрописывается пакетами Azure SDK. Разумеется, данный подход так же может породить ошибки компиляции, так как в новой EntityFramework может не быть какого-то либо функционала из прошлых версий.Что будет без подобного редиректа — не проверял, но, видимо, будет следующее:
Код проекта, пытающийся вызвать функционал из пакета, завязанный на Entity Framework, породит ошибку компиляции.
2. Через NuGet-менеджер можно запросить конкретную версию пакета, и производить сборку именно через него.
3. В пакет закладывается не только наша библиотека, но и все её зависимости (те же азуровские библиотеки).
4. Библиотеки при получении через NuGet во время сборки корректно находятся компилятором.
Собственно, после подключения к своему NuGet-фиду проблемы были решены (по крайней мере, у нас).
Пожалуйста, уточните ваш последний вопрос — я его не очень понял.
Долго думал, что же такое эр гэ.
Вы бы хоть PR писали, что бы понятно было, что английские буквы в середине русского текста.
А так — удачи с продолжением проекта.
удачи с открытием.
Далее, по степени известности Жуковский и Баратынский уступали (и сейчас уступают) Пушкину.
Так что не могу разделить ваше недоумение по поводу Пушкина.
На тот момент бомонд, в котором вращался Пушкин, говорил больше на французском, нежели на русском, разве не так?
И именно благодаря стихам Пушкина этот самый бомонд увидел прелесть и в родном языке.
Всё выше указанное — лишь моё мнение, основанное на школьных знаниях литературы и истории, специальных исследований я не читал, так что поправьте, если где-то ошибся.