Есть ли альтернатива .NET для репозиториев артефактов Java, таких как Nexus или Artifactory? Где вы храните версии DLL?

Где хранить двоичные файлы, необходимые для автоматической сборки в Team System? Вы храните их вместе с кодом в SCM или где-то еще? Имеет ли большое количество двоичных файлов в SCM, что вызывает проблемы с производительностью с помощью источника?

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

Любые предложения приветствуются.

Ответ 1

Оба Nexus и Artifactory в настоящее время поддерживают хранилище для двоичных артефактов и зависимостей, используемых в разработке .net. Для сборки и интеграции TFS в Visual Studio с использованием пакетов NuGet вы можете просмотреть этот блог.

Ответ 2

Я всегда использовал svn: externals для этого в прошлом, как описано cringe. Но он медленно обновляется в локальной рабочей копии. Я начал проект с открытым исходным кодом с несколькими друзьями, чтобы попытаться решить эту проблему, которая все еще находится на очень ранней стадии, но если это проблема, которую вас интересует, вам может понадобиться следить за ней (или даже помочь с ним). Он называется Refix и размещен на CodePlex.

Ответ 3

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

Мне интересно: почему вы считаете это анти-шаблоном?

Ответ 4

Subversion, например, имеет svn: externals, который может использоваться для импорта содержимого другого каталога в ваши библиотеки. Внешний может быть привязан к конкретной ревизии. Для меня это лучший способ, и вы избегаете вложенных рабочих копий.

Ответ 5

(Я знаю, что это старый вопрос, но моя типично-основанная на Java команда делает немного работы .NET и задает одни и те же вопросы прямо сейчас, и вот что мы нашли.)

Если вы используете систему DVCS типа Git, то вы абсолютно правы, что могут возникнуть проблемы с производительностью, если вы проверите эти библиотеки в исходном элементе управления. В качестве отправной точки мы перешли несколько крупных проектов (2-5 ГБ) с проверенными двоичными файлами от Perforce до Git. Производительность импортированных репозиториев Git (с использованием Git 1,9 на жестких ящиках Windows с использованием SSD) была неприемлемо медленной для разработки. Мы модифицировали нашу сборку, чтобы вытащить большую часть этих зависимостей из частного экземпляра Nexus, и значительно более тонкие репозитории (50-200 МБ исходного кода), похоже, хорошо работают.

Если у вас уже есть экземпляр Nexus, доступный для вас, нет ничего, что помешало бы вам использовать его для хранения артефактов .NET - насколько это касается Nexus, артефакт - это всего лишь файл. Если вы заархивируете свои DLL файлы и файлы конфигурации, а еще что-то в одном файле, Nexus с удовольствием разместит это как артефакт с версией, и вы сможете загрузить/разархивировать его в нужное место, когда вам это нужно. (Я не использовал Artifactory, поэтому не могу комментировать, что он делает.)

Если вы хотите что-то, что специально интегрируется с VisualStudio (или MonoDevelop), то NuGet кажется теперь новым ответом.

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

Если у вас есть версия Pro Nexus, она заявляет, что она размещает файлы с артефактами .NET и разрешает доступ через NuGet, но у меня нет опыта использования он.