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

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

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

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

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

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

Ваше здоровье,

-- Ли

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

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

В основном :

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

.net c# compiler-construction building
person Lee Englestone    schedule 12.10.2009    source источник
comment
Я чувствую то же самое и всегда помещаю свои библиотеки DLL прямо в папку проекта. Visual Studio использует корень проекта в качестве пути обновления, поэтому, если я обновлю свои библиотеки DLL, ссылки не нарушатся.   -  person John Gietzen    schedule 12.10.2009

Ответы (4)


arrow_upward
19
arrow_downward

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

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

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

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

person Groo    schedule 12.10.2009
comment
+1 за «папки bin и obj всегда должны быть полностью исключены». - person csharptest.net; 12.10.2009

arrow_upward
16
arrow_downward

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

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

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

person JaredPar    schedule 12.10.2009

arrow_upward
5
arrow_downward

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

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

person Jack Ryan    schedule 12.10.2009

arrow_upward
4
arrow_downward

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

person Tom    schedule 12.10.2009