it-swarm.com.ru

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

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

 exclude

3
Salman

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

4
ojblass

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

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

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

4
Chun Liu

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

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

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

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

!bin/foo.dll

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

3
Edward Thomson

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

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

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

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

 enter image description here

  1. Добавьте DLL в эту папку

 enter image description here

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

 enter image description here

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

 enter image description here

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

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

2
Jayendran

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

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

1
DanDan