Разве Вы не должны рассматривать папку мусорного ведра, как являющуюся переходным?
NAnt был вокруг дольше и является значительно более сформировавшимся продуктом и также IMO, легче использовать. Существует большое общественное ноу-хау там для наслаждения, и это является также межплатформенным, должны Вы интересоваться созданием приложений, которые могут работать под Моно, а также.NET и Silverlight. Из поля это делает намного больше, чем MSBuild. Ах да, и можно назвать MSBuild от NAnt (хорошо, от NAntContrib) :-)
На отрицательной стороне, NAnt и его дочернем проекте, NAntContrib, действительно кажется, застоялись, при этом новое обновление в конце 2007.
основные преимущества, которые я вижу MSBuild, состоят в том, что он поставлется с Платформой.NET, таким образом, это - то меньше продукта для установки; и существует продолжение более активной разработки (хотя в местах для достижения уровня более старого NAnt).
Лично, я нахожу его синтаксис немного более трудным взять, но затем я уверен, что длительное воздействие ti сделало бы вещи легче.
Заключение? Если Вы работаете с существующими сценариями NAnt, палкой с ними, это не стоит стычки портирования. Если Вы запускаете новый проект, и Вы чувствуете себя предприимчивыми, то даете MSBuild движение.
4 ответа
Верно, вы не хотите помещать ссылочные dll в папку bin . Если вы используете систему управления версиями, папки bin и obj всегда должны быть полностью исключены.
Все библиотеки, на которые есть ссылки, должны быть включены в систему управления версиями, желательно в отдельном подкаталоге в trunk вашего проекта, чтобы все имели все необходимые источники и ссылки для каждого чистого восстановления. Папка bin должна быть легко воссоздана с нуля.
Я думаю, что большинство людей ожидают при проверке вашего источника.
Мы также включаем _READ_ME .txt файл в корне проекта, содержащий дополнительную информацию об инструментах и материалах, необходимых для пакетной сборки проекта ( nant ,
Нет, это имеет смысл, и я сам применяю эту практику в личных проектах. Все, что находится в папке bin, следует рассматривать как свойство среды msbuild / Visual Studio.
Хотя они оба очень стараются удалить только те выходные данные, о которых они знают, пользователь может не полностью понять, что является результатом сборки, и скопировать результат сборки и, следовательно, удалить его во время операции в стиле «Очистить». . Также возможно, что другие инструменты будут более агрессивно очищать библиотеки DLL. Я сам время от времени пытаюсь уничтожить каталог bin, если думаю, что процесс сборки смотрит на устаревшие данные.
Кроме того, расположение ссылки дает вам единое место для обновления ссылок для коллекции проектов в рамках решения. Для меня это ' очень естественная конструкция.
Я считаю, что папка bin временна, это место, куда может перейти полностью работающее скомпилированное приложение.
Мы помещаем любые внешние сборки в каталог под названием Assemblies. Многие другие используют каталог под названием lib. Это отделяет идею того, что необходимо для компиляции приложения, от самого скомпилированного приложения.
Понятия не имею, сумасшедший ли вы, но мы следовали тем же методам на последнем месте, где я работал, и я перенес их в свою работу. Папки / bin и / obj находятся вне контроля версий, и я никогда не касаюсь этого. Насколько я понимаю, они практически не существуют во время разработки. Все включенные библиотеки DLL находятся в другой папке, и на них есть ссылки.