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

Question

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

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

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

Answer 1

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

Answer 2

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

Answer 3

(я знаю, что это старый вопрос, но моя обычно основанная на 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 , но у меня нет опыта ее использования.

Answer 4

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

Answer 5

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

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