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

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

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

16.09.2008 13:40:42
Файлы .suo воссоздаются автоматически. Отличный способ «обновить» ваши настройки по умолчанию, если что-то сломается.
CodingBarfield 27.09.2010 09:19:21
Лучшие практики для проектов Subversion и Visual Studio - более общий вопрос на эту тему. Также принятый ответ содержит ссылку на официальную документацию MSDN, в которой подробно описывается, какие файлы / каталоги решений / проектов VS следует добавить в системы контроля версий, а какие части следует игнорировать.
Attila Csipak 6.04.2014 21:22:05
для * .suo, пожалуйста, смотрите здесь: msdn.microsoft.com/en-us/library/bb165909.aspx
smwikipedia 5.03.2015 05:54:15
21 ОТВЕТ
РЕШЕНИЕ

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

669
1.10.2014 18:27:04
Будьте внимательны, в файле suo хранится информация о том, загружен / выгружен ли проект в рамках решения.
Kugel 13.10.2011 09:21:15
Я считаю, что он хранит отладочную информацию в файле .user (по крайней мере, для инструментов данных SQL Server). Кроме того, когда вы меняете настройки на вкладке «Отладка», они не всегда сохраняются в .user сразу (закрытие решения, похоже, работает, немного раздражает ... или изменение другого параметра, хранящегося в файле .sqlproj).
jamiebarrow 3.08.2012 08:57:40
Вы можете открыть файлы .user и .csproj в любом текстовом редакторе. Я только что протестировал копирование, вставив соответствующие параметры отладки из .user в .csproj, а затем удалил файл .user. Отладка продолжала работать, с удовольствием прочитав правильные настройки из их нового местоположения в файле .csproj. Это должно обеспечить способ фиксации настроек отладки без фиксации файла .user. Убедитесь, что вы поставили их в правильной конфигурации (отладка, выпуск и т. Д.). Работает на моей машине! =)
Chris Nielsen 14.08.2012 16:18:40

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

139
16.09.2008 13:42:39
Если вы работаете на нескольких разных машинах, стоит ли их добавлять?
thepocketwade 24.08.2009 21:32:57
Я бы не стал, потому что это может быть хрупким к неожиданным системным различиям; например, если вы работаете с x64 на работе и x86 дома, то она может подавиться над «c: \ program files (x86)» и «c: \ program files». Я не знаю, но я бы не стал рисковать.
Steve Cooper 1.02.2011 16:19:34
Хотя они содержат специфичную для пользователя информацию, но информация о файлах, которые были добавлены с помощью опции (включить в проект), также находится в файле .csproj, который, как мне кажется, требует, чтобы другие пользователи вручную добавили все вновь добавленные ресурсы проекта. Если кто-нибудь знает обходной путь, пожалуйста, укажите здесь.
zeppelin 3.02.2015 22:20:35

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

12
16.09.2008 13:42:45
У меня остался файл .sou, и это давало проблему с перезагрузкой пакетов. Удаление файла .sou устранило проблему. Спасибо.
mercedes 26.09.2017 23:10:19

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

19
16.09.2008 13:43:13

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

5
16.09.2008 13:43:31

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

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

4
27.10.2018 14:25:05
only the .sln & .*proj should be registered- Вы не забыли много файлов здесь?
Wolf 14.12.2016 12:51:14
@ Волк помимо очевидного
Polluks 21.07.2017 09:30:37

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

8
16.09.2008 13:44:07

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

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

7
14.12.2016 12:49:14

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

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

49
27.12.2013 16:40:48
Я также начинаю думать, что так и должно быть - зафиксируйте файл пользователя, чтобы разработчики в команде использовали одинаковые параметры отладки. Если они меняют его на своей машине, все в порядке, если стандартным способом является версия в системе контроля версий.
jamiebarrow 3.08.2012 08:59:18
Другие предлагали не делать этого, но я не уверен, какие могут быть опасности. Может быть, потому что файл репо с менее точными настройками унесет (лучше) локальную копию пользователя? (Наша команда использует Mercurial, BTW.)
Jon Coombs 22.09.2013 23:52:37
Microsoft не советует добавлять файл .user в систему контроля версий.
DavidRR 20.11.2015 14:19:58
Вы можете переместить параметры отладки в .csproj, см. Этот комментарий
Timbo 30.01.2018 02:05:38

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

9
16.09.2008 13:52:17

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

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

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

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

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

20
27.10.2018 14:26:12
Также из MSDN: Файл пользовательских параметров решения (.Suo) . Первое предложение проясняет намерение Microsoft: «Файл пользовательских параметров решения (.suo) содержит параметры решения для каждого пользователя. Этот файл не должен быть зарегистрирован для контроля исходного кода».
DavidRR 20.11.2015 14:11:14

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

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

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

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

7
21.04.2015 09:43:09

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

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

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

23
16.09.2008 13:55:38

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

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

  1. Таким образом, другие разработчики не получат настройки одного разработчика.
  2. Поэтому, когда вы просматриваете статус или фиксируете файлы, эти файлы не будут загромождать базу кода и затенять новые файлы, которые вам нужно добавить.
69
14.12.2016 12:39:08
Где и как устанавливается svn:ignoreсвойство?
Peter Mortensen 21.04.2015 09:44:11
@PeterMortensen, см. Этот вопрос: stackoverflow.com/questions/86049/…
JXG 26.04.2015 12:11:18
Но есть случай (см. Этот ответ ) для добавления .user, так что тогда можно выбрать не игнорировать только .suo- или можно игнорировать .user, так что для их добавления требуется сознательное решение? Не думайте так, смысл в svn:ignoreтом, чтобы отмечать вещи, в которых не требуется никакого осознанного решения.
PJTraill 27.05.2015 16:21:43

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

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

26
23.05.2017 12:34:45
Файл SDF, вероятно, является базой данных SQL Server Compact Edition .
Carl G 17.09.2012 23:03:54

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

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

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

11
19.05.2016 02:30:34

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

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

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

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

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

1
26.07.2018 07:29:54
Символьные ссылки также очень хорошо работают для этой цели.
sɐunıɔןɐqɐp 26.07.2018 08:02:55

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

3
13.11.2018 05:04:33

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

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

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

* .DotSettings.User
* .onetoc2
* .suo
.vs
Предварительно скомпилированныйWeb
thumbs.db
obj
bin
debug
* .user
* .vshost. *
* .Tss
* .dbml.layout

2
16.02.2019 18:17:28

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

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

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

1
29.04.2019 09:38:43

Нет.

Я просто хотел по-настоящему краткий ответ, и не было никакого.

4
6.08.2019 01:00:44