Почему Visual Studio исключает папки BIN и OBJ при регистрации в Azure DevOps

Question

Я хочу знать, каков общий способ регистрации кода в DevOps Azure из Visual Studio или Git-Bash, который был закодирован в Visual Studio. Проблема, которая возникает, состоит в том, что папка bin содержит множество сторонних dll, которые хранятся в исходном коде до сборки проекта. Эти сторонние библиотеки необходимы для проектирования. Однако после регистрации в Azure DevOps бина и obj нет. Это происходит из-за файлов .gitignore и .gitattribute. Я удалил оба файла и проверил в папке bin на данный момент. Какова цель этих двух файлов. Может кто-нибудь, пожалуйста, предложите способ решить.

Answer 1

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

. Пожалуйста, помните, что идеальный / лучший способ использования библиотек третьей части - через NuGet Feed / Packages

Дляв некоторых случаях эти DLL не будут доступны на Nuget.org.В таком случае вы можете выполнить следующие шаги, чтобы добавить ссылки в ваш проект.

1. Создайте в своем проекте папку с именем lib

Добавить DLL в эту папку

Щелкните правой кнопкой мыши DLL-> Перейти к Properties, затем измените значения BuildAction на None и Copy to Output Directory на Do not copy для DLL

Наконец, добавьте ссылки из папки lib

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

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

Answer 2

Для накапливания: даже если вы хотите проверить свою папку bin (и, как уже упоминали другие, вы этого не делаете), не делайте этого, удаляя файлы .gitignore и .gitattributes.

.gitignore содержит список файлов, которые не должны быть добавлены в ваш репозиторий. Это файлы, которые не должны передаваться команде, такие как данные локальной конфигурации. Если вы зафиксируете данные SQLite в каталоге .vs, вы получите бесчисленные конфликты и не сможете извлечь их, потому что Visual Studio заблокирует этот файл.

.gitattributes содержит набор конфигураций, особенно для концов строк. Это должно существовать в репозитории, чтобы все разработчики могли договориться о настройке, иначе вы можете столкнуться с пробелами.

Если вы действительно должны (и не должны) регистрировать файлы в каталоге bin, восстановите .gitignore и .gitattributes. Затем явно перечислите их в .gitignore с шаблоном отрицания:

!bin/foo.dll

Но - как прокомментировали другие - это все еще плохая идея.

Answer 3

Файл

.gitignore определяет неотслеживаемые файлы. .gitattributes определяет атрибуты для каждого пути. Это конфигурационные файлы Git.

В Visual Studio папки bin и obj используются для хранения выходных данных, сгенерированных компиляторами (см. здесь ). Поскольку эти выходные файлы генерируются компиляторами, вы не хотите отслеживать их в системе контроля версий.

Если ваш проект должен ссылаться на некоторые сторонние dll, лучший способ - ссылаться на них как на пакеты Nuget, если для dll доступны пакеты Nuget. Если нет, вы можете поместить их в папку, отличную от bin или obj, чтобы их можно было отслеживать в Git. Вы не должны изменять .gitignore для отслеживания папок bin или obj.

Answer 4

Папка bin определенно не подходит для хранения сторонних библиотек. Сохраните их где-нибудь еще и скопируйте их в папку bin во время сборки или, если доступно, используйте пакеты NuGet. Это широко используемая стандартная процедура для исключения папок bin из проверки в систему контроля версий. Кроме того, если вы решите выполнить очистку своего решения, ваши папки bin будут очищены, а ваши сторонние dll исчезнут.

Еще один момент, поскольку после публикации вопроса с тегом azure-devops azure-devops предоставляет мощный конвейер для сборки и тестирования. Это означает, что вы можете проверить свой код, и размещенный сервер сборки (стандартный сценарий, IF , который вы настроили таким образом) вытащит ваш код из системы контроля версий и выполнит сборку, запустит несколько тестов и, если все будет ОК, заархивируйте свои двоичные файлы и поместите их туда, где вы можете загрузить их. Теперь, что происходит с вашими собственными dll в bin, которые вы зарегистрировали? Они будут перезаписаны, когда сервер создаст ваш код. Так зачем проверять их в первую очередь? Если сервер выполняет очистку (что он не обязательно сделает), то ваши dll сторонних производителей будут отсутствовать.

Answer 5

.gitignore предназначен для исключения вещей из системы контроля версий. Например, если у вас есть файл со строкой соединения с базой данных в папке разработки, вы не хотите, чтобы ваш пароль возвращался в систему контроля версий. Регистрация двоичных файлов в вашем хранилище - плохая практика. Вы должны использовать систему управления зависимостями (например, Nuget, Chocolately, Maven, npm и т. Д.), Чтобы указать свои зависимости и загрузить их. То, как вы делаете это сейчас, вы бы включили несколько копий в несколько проектов и не смогли бы управлять ими в одном месте. Правильное управление зависимостями, вероятно, является причиной того, что версии .gitignore по умолчанию исключают определенные папки. Вы также хотите восстановить все содержимое папки obj. Если у вас есть старые копии, отметки времени становятся странными Чистая сборка каждый раз означает запуск с новой копии без каких-либо скомпилированных артефактов.