Разве вы не должны рассматривать папку bin как временную?

Question

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

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

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

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

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

Приветствия

- Ли

ОБНОВЛЕНИЕ: Оказывается, я не злюсь

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

В основном:

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

Answer 1

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

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

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

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

Answer 2

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

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

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

Answer 3

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

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

Answer 4

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