Разве вы не относитесь к папке bin как к переходной ситуации?

Я всегда учил себя и других думать о том, что папка bin является временной.

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

Я видел, как люди падали, когда они клали dll прямо в папку bin и ссылались на них там. Поэтому я стараюсь избегать этого и помещать все необходимые DLL файлы в папку под названием Refs и добавлять ссылки на DLL файлы там. Во время компиляции они все равно будут скопированы в папку bin.

Я сошел с ума? Это слишком осторожно? здравый смысл?

Какова наилучшая практика в этом сценарии?

Приветствия,

- Ли

ОБНОВЛЕНИЕ: Оказывается, я не сумасшедший

Приветствия парней, которых вы набрали в некоторых моментах, я забыл упомянуть.

В основном:

Не проверять папку bin в исходном элементе управления

Ответ 1

Правильно, вы не хотите разместить ссылочные DLL в папке bin. Если вы используете управление версиями, всегда должны быть полностью исключены папки bin и obj.

Все ссылочные dll должны быть включены в систему управления версиями, желательно в отдельный подкаталог в рамках вашего проекта trunk, чтобы каждый имел все необходимые источники и ссылки для каждой чистой перестройки. bin папка легко воссоздается с нуля.

Что-то, что, по моему мнению, большинство людей будет ожидать при проверке вашего источника.

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

Ответ 2

Нет, это имеет смысл и является практикой, которую я сам реализую в личных проектах. Все, что находится под папкой bin, должно рассматриваться как свойство среды msbuild/Visual Studio.

В то время как оба они очень заботятся о том, чтобы удалить только те из них, о которых они знают, возможно, что пользователь не может полностью понять, что такое вывод сборки и скопировать результат сборки, и, следовательно, удалить его во время операции "Чистый", Также возможно, чтобы другие инструменты были более агрессивными при очистке DLL. Я сам склоняюсь к тому, чтобы время от времени нажимать каталог bin, если я думаю, что процесс сборки ищет устаревшие данные.

Кроме того, наличие ссылки ref дает вам одно место для обновления ссылок на коллекцию проектов в рамках решения. Для меня это очень естественная конструкция.

Ответ 3

Я думаю, что папка bin является временной, это место для полного рабочего скомпилированного приложения.

Мы размещаем любые внешние сборки в каталоге Assemblies. Многие другие используют каталог lib. Это отделяет идею того, что необходимо для компиляции приложения из самого скомпилированного приложения.

Ответ 4

Я понятия не имею, сумасшедший ты, но мы следовали тем же самым практикам на последнем месте, где работали, и я перенес их на свою работу. Папки /bin и/obj находятся вне контроля версий, и я никогда не прикасаюсь к ним. В основном они не существуют, насколько я заинтересован во время разработки. Все включенные DLL файлы находятся в другой папке и ссылаются на них.