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


841

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

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


9
Файлы .suo воссоздаются автоматически. Отличный способ «обновить» ваши настройки по умолчанию, если что-то сломается.
CodingBarfield

3
Лучшие практики для проектов Subversion и Visual Studio - более общий вопрос на эту тему. Также принятый ответ содержит ссылку на официальную документацию MSDN, в которой подробно описывается, какие файлы / каталоги решений / проектов VS следует добавить в системы контроля версий, а какие части следует игнорировать.
Аттила Чипак

3
для * .suo, пожалуйста, смотрите здесь: msdn.microsoft.com/en-us/library/bb165909.aspx
smwikipedia

Ответы:


673

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


22
Будьте внимательны, файл suo хранит информацию о том, загружен / выгружен ли проект в рамках решения.
Кугель

5
Я считаю, что он хранит отладочную информацию в файле .user (по крайней мере, для инструментов данных SQL Server). Кроме того, когда вы меняете настройки на вкладке «Отладка», они не всегда сохраняются в .user сразу (закрытие решения, похоже, работает, немного раздражает ... или изменение другого параметра, хранящегося в файле .sqlproj).
jamiebarrow

87
Вы можете открыть файлы .user и .csproj в любом текстовом редакторе. Я только что протестировал копирование и вставку соответствующих параметров отладки из .user в .csproj, а затем удалил файл .user. Отладка продолжала работать, с удовольствием прочитав правильные настройки из их нового местоположения в файле .csproj. Это должно обеспечить способ фиксации настроек отладки без фиксации файла .user. Убедитесь, что вы поставили их в правильной конфигурации (отладка, выпуск и т. Д.). Работает на моей машине! =)
Крис Нильсен

139

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


19
Если вы работаете на нескольких разных машинах, стоит ли их добавлять?
thepocketwade

33
Я бы не стал, потому что это может быть хрупким к неожиданным системным различиям; например, если вы работаете с x64 на работе и x86 дома, то он может задушить «c: \ program files (x86)» и «c: \ program files». Я не знаю, но я бы не стал рисковать.
Стив Купер

2
Хотя они содержат специфичную для пользователя информацию, но информация о файлах, которые были добавлены с помощью опции (включить в проект), также находится в файле .csproj, который, как мне кажется, требует, чтобы другие пользователи вручную добавили все вновь добавленные ресурсы проекта. Если кто-нибудь знает обходной путь, пожалуйста, укажите здесь.
Цеппелин

69

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

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

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

Где и как устанавливается svn:ignoreсвойство?
Питер Мортенсен

@PeterMortensen, см. Этот вопрос: stackoverflow.com/questions/86049/…
JXG

Но есть случай (см. Этот ответ ) для добавления .user, так что тогда можно выбрать не игнорировать только .suo- или можно игнорировать .user, так что для их добавления требуется сознательное решение? Не думайте так, смысл в svn:ignoreтом, чтобы пометить вещи, в которых не требуется никакого осознанного решения.
PJTraill

49

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

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


4
Я также начинаю думать, что так и должно быть - зафиксируйте пользовательский файл, чтобы разработчики в команде использовали одинаковые параметры отладки. Если они меняют его на своей машине, все в порядке, если стандартным способом является версия в системе контроля версий.
jamiebarrow

1
Другие предлагали не делать этого, но я не уверен, какие могут быть опасности. Может быть, потому что файл репо с менее точными настройками унесет (лучше) локальную копию пользователя? (Наша команда использует Mercurial, BTW.)
Джон Кумбс

2
Microsoft не советует добавлять файл .user в систему контроля версий.
DavidRR

1
Вы можете переместить параметры отладки в .csproj, см. Этот комментарий
Timbo

26

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

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


2
Файл SDF, вероятно, является базой данных SQL Server Compact Edition .
Карл Дж

23

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

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

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


20

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

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

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

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

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


Также из MSDN: Файл опций решения пользователя (.Suo) . В первом предложении цель Microsoft совершенно ясна: «Файл пользовательских параметров решения (.suo) содержит параметры решения для каждого пользователя. Этот файл не должен быть зарегистрирован для контроля исходного кода».
DavidRR

19

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


12

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


У меня остался файл .sou, и это давало проблему с перезагрузкой пакетов. Удаление файла .sou устранило проблему. Спасибо.
Мерседес

11

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

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

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


9

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


8

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


7

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

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

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

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


7

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

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


5

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



4

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

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


only the .sln & .*proj should be registered- Вы не забыли много файлов здесь?
Wolf

@ Волк помимо очевидного
Поллукс

3

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


2

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

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


1

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

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

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

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

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


Символические ссылки также очень хорошо работают для этой цели.
sɐunıɔ ןɐ qɐp

1

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

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

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.