Лучшие практики для хранения сборок? - PullRequest
3 голосов
/ 23 февраля 2010

Я ищу руководство по хранению сборок. Вот так выглядит наше исходное дерево на данный момент:

ProjectName
Ствол
| -------- src (исходный код)
| -------- lib (сборки, необходимые для каждого проекта, например NUnit framework, svn external)
| -------- инструменты (инструменты, необходимые для каждого проекта, например, исполняемый файл NUnit, внешний svn)
| -------- ThirdPartyAssemblies (специфичные для проекта сборки, например, log4net)

Мы переместили некоторый код в собственную библиотеку, которая называется Utils.dll.

Теперь мне интересно, куда поместить эту библиотеку (буквально хорошее название для папки), а также другие библиотеки, которые мы напишем в будущем.

ThirdPartyAssemblies не похоже на правильное место (так как оно не от третьей стороны), как и lib, поскольку сборки нужны не каждому проекту, который мы создаем.

Ответы [ 2 ]

4 голосов
/ 23 февраля 2010

Ну, вы, безусловно, могли бы создать каталог «FirstPartyAssemblies», если вам нужно - но вам определенно нужно «хранить» эти сборки в первую очередь? Они приходят из другого решения? Можете ли вы не просто использовать несколько проектов в одном и том же решении и позволить VS извлекать сборки соответствующим образом? Конечно, вам не обязательно иметь все проекты в одной иерархии источников.

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

0 голосов
/ 23 февраля 2010

Я бы не всегда включал проект в решение, если только вы не хотите использовать подход с открытым исходным кодом. Это может стать грязным. Я всегда использую название компании. Нравится [CompanyName] Utils. Таким образом, вы можете дополнительно разбить его, если вам нужно. Например, [CompanyName] [Domain] Utils или что-то еще.

...