Стоит ли добавлять файлы Visual Studio .suo и .user в систему контроля версий?

Решения Visual Studio содержат два типа скрытых пользовательских файлов. Одним из них является .suoфайл решения, который является двоичным файлом. Другой .userфайл проекта, который является текстовым файлом. Какие именно данные содержат эти файлы?

Мне также было интересно, следует ли мне добавлять эти файлы в систему контроля версий (в моем случае это Subversion). Если я не добавлю эти файлы и другой разработчик проверит решение, Visual Studio автоматически создаст новые пользовательские файлы?

Эти файлы содержат конфигурации пользовательских настроек, которые в целом относятся к вашей машине, поэтому лучше не помещать их в SCM. Кроме того, VS будет изменять его почти каждый раз, когда вы его выполняете, поэтому SCM всегда будет помечать его как «измененный». Я тоже не включаю, я в проекте, использующем VS в течение 2 лет, и у меня не было проблем с этим. Единственное небольшое неудобство заключается в том, что параметры отладки (путь выполнения, цель развертывания и т. Д.) Хранятся в одном из этих файлов (не знаю, какие именно), поэтому, если у вас есть стандарт для них, вы не сможете ' опубликуйте «через SCM для других разработчиков, чтобы вся среда разработки была готова к использованию».

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

Другие объяснили , почему имея *.suoи *.userфайлы в системе управления версиями не является хорошей идеей.

Я хотел бы предложить вам добавить эти шаблоны в svn:ignoreсвойство по двум причинам:

1. Таким образом, другие разработчики не получат настройки одного разработчика.
2. Поэтому, когда вы просматриваете статус или фиксируете файлы, эти файлы не будут загромождать базу кода и затенять новые файлы, которые вам нужно добавить.

Мы не фиксируем двоичный файл (* .suo), но мы фиксируем файл .user. Файл .user содержит, например, параметры запуска для отладки проекта. Вы можете найти параметры запуска в свойствах проекта на вкладке «Отладка». Мы использовали NUnit в некоторых проектах и ​​настроили nunit-gui.exe в качестве опции запуска для проекта. Без файла .user каждый член команды должен был бы настроить его отдельно.

Надеюсь это поможет.

Так как я нашел этот вопрос / ответ через Google в 2011 году, я решил взять секунду и добавить ссылку для файлов * .SDF, созданных Visual Studio 2010, в список файлов, которые, вероятно, не следует добавлять в систему контроля версий ( IDE создаст их заново). Поскольку я не был уверен, что файл * .sdf может иметь законное применение в других местах, я проигнорировал только конкретный файл [projectname] .sdf из SVN.

Почему мастер преобразования Visual Studio 2010 создает массивный файл базы данных SDF?

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

SUO (Опции пользователя решения). Записывает все параметры, которые вы можете связать с вашим решением, чтобы каждый раз, когда вы открываете его, оно включало сделанные вами настройки.

Файл .user содержит пользовательские параметры для проекта (в то время как SUO - для решения) и расширяет имя файла проекта (например, что угодно .csproj.user содержит пользовательские настройки для проекта everything.csproj).

Похоже, это мнение Microsoft по этому вопросу:

Добавление (и редактирование) файлов .suo в систему контроля версий.

Я не знаю, почему ваш проект хранит DebuggingWorkingDirectory в файле suo. Если это пользовательская настройка, вы должны сохранить ее в имени файла * .proj.user. Если этот параметр доступен всем пользователям, работающим над проектом, вам следует сохранить его в самом файле проекта.

Даже не думайте добавлять файл suo в систему управления версиями! Файл SUO (soluton user options) должен содержать пользовательские настройки и не должен использоваться совместно пользователями, работающими над тем же решением. Если вы добавляете файл suo в базу данных scc, я не знаю, какие другие вещи в IDE вы нарушите, но с точки зрения контроля исходного кода вы нарушите интеграцию scc веб-проектов, использовался плагин Lan vs Internet. другими пользователями для доступа к VSS, и вы можете даже заставить scc полностью сломаться (путь к базе данных VSS, сохраненный в файле suo, который может быть действительным для вас, может быть недействительным для другого пользователя).

Алин Константин (MSFT)

По умолчанию Microsoft Visual SourceSafe не включает эти файлы в элемент управления исходным кодом, поскольку они являются файлами пользовательских настроек. Я бы следовал этой модели, если вы используете SVN в качестве источника контроля.

Visual Studio автоматически создаст их. Я не рекомендую помещать их в систему контроля версий. Было много раз, когда файл SOU локального разработчика вызывал хаотичное поведение VS на этом блоке разработчиков. Удаление файла и последующее его восстановление VS всегда исправляли проблемы.

На сайте MSDN четко указано, что

Файл пользовательских параметров решения (.suo) содержит параметры решения для каждого пользователя. Этот файл не должен быть зарегистрирован для контроля исходного кода .

Так что я бы сказал, что довольно безопасно игнорировать эти файлы при проверке содержимого в вашем контроле исходного кода.

Я бы не стал. Все, что может измениться для каждого «пользователя», обычно не подходит для контроля версий. Каталоги .suo, .user, obj / bin

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

Вы не можете управлять исходными файлами .user, потому что это зависит от пользователя. Он содержит имя удаленной машины и другие зависящие от пользователя вещи. Это файл, связанный с vcproj.

Файл .suo является файлом, связанным с sln, и содержит «пользовательские параметры решения» (стартовый проект (ы), положение окон (что закреплено и где, что перемещается) и т. Д.)

Это двоичный файл, и я не знаю, содержит ли он что-то «связанное с пользователем».

В нашей компании мы не берем эти файлы под контроль источников.

Они содержат конкретные параметры проекта, которые обычно назначаются одному разработчику (например, стартовый проект и стартовая страница, которые запускаются при отладке приложения).

Так что лучше не добавлять их в систему управления версиями, а VS создавать их заново, чтобы у каждого разработчика были нужные настройки.

.user - это пользовательские настройки, и я думаю .suo - это пользовательские настройки решения. Вы не хотите, чтобы эти файлы находились под контролем исходного кода; они будут воссозданы для каждого пользователя.

Нет.

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

Используя Rational ClearCase, ответ - нет. Только .sln &. * Proj должен быть зарегистрирован в контроле исходного кода.

Я не могу отвечать за других поставщиков. Если я правильно помню, эти файлы являются "пользовательскими" настройками вашей среды.

Не добавляйте эти файлы в систему управления версиями. Эти файлы автоматически генерируются с информацией, специфичной для рабочей станции, если они включены в систему контроля версий, что вызовет проблемы на других рабочих станциях.

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

GitHub поддерживает список предлагаемых типов файлов, которые пользователи Visual Studio должны игнорировать, по адресу https://github.com/github/gitignore/blob/master/VisualStudio.gitignore.

Для SVN у меня есть следующий global-ignoreнабор свойств:

* .DotSettings.User
* .onetoc2
* .suo
.vs
PrecompiledWeb
thumbs.db
OBJ
бин
отладки
* .user
* .vshost. *
* .Tss
* .dbml.layout

Если вы установите свои исполняемые зависимости dir в ProjectProperties> Debugging> Environment , пути будут храниться в файлах .user.

Предположим, я установил эту строку в вышеупомянутом поле: «PATH = C: \ xyz \ bin». Вот как она будет храниться в файле «.user»:

<LocalDebuggerEnvironment>PATH=C:\xyz\bin$(LocalDebuggerEnvironment)</LocalDebuggerEnvironment>

Это очень помогло нам во время работы в OpenCV. Мы могли бы использовать разные версии OpenCV для разных проектов. Еще одним преимуществом является то, что было очень легко настроить наши проекты на новой машине. Нам просто нужно было скопировать соответствующие каталоги зависимостей. Поэтому для некоторых проектов я предпочитаю добавлять '.user' в систему контроля версий.

Хотя это полностью зависит от проектов. Вы можете принять звонок в зависимости от ваших потребностей.

Как объясняется в других ответах, оба .suoи .userих не следует добавлять в систему контроля .suoверсий , поскольку они зависят от пользователя / компьютера (кстати, для новейших версий VS был перемещен в выделенный временный каталог .vs, который следует полностью исключить из системы контроля версий ).

Однако если вашему приложению требуется некоторая настройка среды для отладки в VS (такие настройки обычно хранятся в .userфайле), может быть удобно подготовить образец файла (назвав его так .user.SAMPLE) и добавить его в систему контроля версий для ссылок.

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