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

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

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


person Ben Mills    schedule 16.09.2008    source источник
comment
Файлы .suo воссоздаются автоматически. Отличный способ «обновить» настройки до значений по умолчанию, если что-то сломается.   -  person CodingBarfield    schedule 27.09.2010
comment
Рекомендации для проектов Subversion и Visual Studio - это более общий вопрос по этой теме. Также принятый ответ на него содержит ссылку на официальную документацию MSDN, в которой подробно описано, какие файлы / каталоги решений VS / проекты должны быть добавлены в системы управления версиями, а какие части следует игнорировать.   -  person Attila Csipak    schedule 07.04.2014
comment
для * .suo см. здесь: msdn.microsoft.com/en-us /library/bb165909.aspx   -  person smwikipedia    schedule 05.03.2015
comment
Существует очень простой способ определить, следует ли включать конкретный файл в систему контроля версий. Удалите файл. Ваше приложение по-прежнему строится и выполняется так, как ожидалось? В таком случае файл не следует включать.   -  person JoelFan    schedule 27.10.2020


Ответы (22)


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

person Fabio Ceconello    schedule 16.09.2008
comment
Будьте осторожны, файл suo хранит информацию о том, загружен / выгружен проект в решении. - person Kugel; 13.10.2011
comment
Я считаю, что он хранит отладочную информацию в файле .user (по крайней мере, для SQL Server Data Tools). Кроме того, когда вы меняете настройки на вкладке «Отладка», это не всегда сохраняется для .user сразу (закрытие решения, кажется, работает, немного раздражает ... или изменение другого параметра, хранящегося в файле .sqlproj). - person jamiebarrow; 03.08.2012
comment
Вы можете открыть файлы .user и .csproj в любом текстовом редакторе. Я только что протестировал копирование соответствующих настроек отладки из .user в .csproj, а затем удаление файла .user. Отладка продолжала работать, с радостью считывая правильные настройки из их нового местоположения в файле .csproj. Это должно обеспечить способ фиксации настроек отладки без фиксации файла .user. Убедитесь, что вы поместили их в правильную конфигурацию (отладка, выпуск и т. Д.). Работает на моей машине! знак равно - person Chris Nielsen; 14.08.2012
comment
@ChrisNielsen отображаются ли вручную вставленные свойства в графическом интерфейсе Visual Studio? Кажется, у меня работает отладка, но это выглядит загадочно, поскольку значения полей не отображаются в Visual Studio. - person JamEnergy; 14.01.2021

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

person Steve Cooper    schedule 16.09.2008
comment
Если вы работаете один на нескольких разных машинах, стоит ли их добавлять? - person thepocketwade; 25.08.2009
comment
Я бы не стал, потому что он может быть уязвим к неожиданным системным различиям; например, если вы работаете на x64 на работе и на x86 дома, то это может заглушить c: \ program files (x86) и c: \ program files. Не знаю, но я бы не стал рисковать. - person Steve Cooper; 01.02.2011
comment
Хотя они содержат пользовательскую информацию, но информация о файлах, которые были недавно добавлены с помощью опции (включить в проект), я думаю, также находится в файле .csproj, что требует, чтобы другие пользователи вручную добавляли все недавно добавленные ресурсы проекта. Если кто-нибудь знает обходной путь, укажите здесь. - person zeppelin; 04.02.2015

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

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

  1. Так что другие разработчики не останутся без настроек одного разработчика.
  2. Поэтому, когда вы просматриваете статус или коммитите файлы, эти файлы не будут загромождать кодовую базу и скрывать новые файлы, которые вам нужно добавить.
person JXG    schedule 17.09.2008
comment
Где и как устанавливается свойство svn:ignore? - person Peter Mortensen; 21.04.2015
comment
@PeterMortensen, см. Этот вопрос: stackoverflow.com/questions/86049/ - person JXG; 26.04.2015
comment
Но есть случай (см. этот ответ) для добавления .user, поэтому можно выбрать не игнорировать только .suo - или можно было игнорировать .user, так что требуется сознательное решение добавить их? Не думайте, что суть svn:ignore в том, чтобы отмечать вещи, в которых не требуется сознательного решения. - person PJTraill; 27.05.2015

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

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

person Thomas    schedule 16.09.2008
comment
Я также начинаю думать, что это должно быть так - зафиксируйте пользовательский файл, чтобы разработчики в команде использовали одни и те же настройки отладки. Если они изменят его на своей собственной машине, все равно нормально, если стандартным способом является версия в системе управления версиями. - person jamiebarrow; 03.08.2012
comment
Другие предлагали этого не делать, но я не уверен, в чем может заключаться опасность. Может быть, потому что файл репо с менее точными настройками снесет (лучшую) локальную копию пользователя? (Наша команда использует Mercurial, кстати.) - person Jon Coombs; 23.09.2013
comment
Microsoft не рекомендует добавлять файл .user в систему управления версиями. - person DavidRR; 20.11.2015
comment
Вы можете переместить настройки отладки в .csproj, см. этот комментарий - person Tim Sparkles; 30.01.2018
comment
вы можете просто добавить копию стандартных пользовательских настроек с другим именем. - person QuantumDebris; 20.07.2021

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

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

person Stephen    schedule 04.07.2011
comment
Файл SDF, вероятно, является базой данных SQL Server Compact Edition. - person Carl G; 18.09.2012

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

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

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

person JRoppert    schedule 16.09.2008

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

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

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

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

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

person Scott W    schedule 16.09.2008
comment
Также из MSDN: Файл параметров пользователя решения (.Suo). Первое предложение проясняет намерения Microsoft: Файл пользовательских параметров решения (.suo) содержит индивидуальные параметры решения. Этот файл не следует возвращать в систему контроля исходного кода. - person DavidRR; 20.11.2015

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

person cori    schedule 16.09.2008

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

person Mike Becatti    schedule 16.09.2008
comment
У меня остался файл .sou, и это вызывало проблемы с перезагрузкой пакетов. Удаление файла .sou устранило проблему. Спасибо. - person mercedes; 27.09.2017

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

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

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

person Farax    schedule 19.05.2016

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

person ScaleOvenStove    schedule 16.09.2008

No.

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

person Pablo Carrasco Hernández    schedule 06.08.2019

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

person benefactual    schedule 16.09.2008

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

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

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

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

person ugasoft    schedule 16.09.2008

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

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

person massimogentilini    schedule 16.09.2008

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

person Nick    schedule 16.09.2008

При использовании Rational ClearCase ответ отрицательный. Только .sln &. * Proj должен быть зарегистрирован в элементе управления исходным кодом.

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

person titanae    schedule 16.09.2008
comment
only the .sln & .*proj should be registered - вы не забыли здесь много файлов? - person Wolf; 14.12.2016
comment
@Wolf помимо очевидного - person Polluks; 21.07.2017

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

person Amila    schedule 13.11.2018

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

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

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

* .DotSettings.User
* .onetoc2
* .suo
.vs
PrecompiledWeb
thumbs.db
obj
bin
отладка
* .user
* .vshost. *
* .tss
* .dbml.layout

person Stephen Kennedy    schedule 16.02.2019

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

Чтобы понять почему, полезно посмотреть, что на самом деле находится в этом файле. Я написал инструмент командной строки, который позволяет вам видеть содержимое .suo файла.

Установите его на свой компьютер через:

dotnet tool install -g suo

Он имеет две подкоманды, keys и view.

suo keys <path-to-suo-file>

Это будет выгружать ключ для каждого значения в файле. Например (в сокращенном виде):

nuget
ProjInfoEx
BookmarkState
DebuggerWatches
HiddenSlnFolders
ObjMgrContentsV8
UnloadedProjects
ClassViewContents
OutliningStateDir
ProjExplorerState
TaskListShortcuts
XmlPackageOptions
BackgroundLoadData
DebuggerExceptions
DebuggerFindSource
DebuggerFindSymbol
ILSpy-234190A6EE66
MRU Solution Files
UnloadedProjectsEx
ApplicationInsights
DebuggerBreakpoints
OutliningStateV1674
...

Как видите, многие функции IDE используют этот файл для хранения своего состояния.

Используйте команду view, чтобы увидеть значение данного ключа. Например:

$ suo view nuget --format=utf8 .suo
nuget

?{"WindowSettings":{"project:MyProject":{"SourceRepository":"nuget.org","ShowPreviewWindow":false,"ShowDeprecatedFrameworkWindow":true,"RemoveDependencies":false,"ForceRemove":false,"IncludePrerelease":false,"SelectedFilter":"UpdatesAvailable","DependencyBehavior":"Lowest","FileConflictAction":"PromptUser","OptionsExpanded":false,"SortPropertyName":"ProjectName","SortDirection":"Ascending"}}}

Дополнительная информация об этом инструменте: https://github.com/drewnoakes/suo.

person Drew Noakes    schedule 04.02.2021

Если вы установите зависимости исполняемого каталога в ProjectProperties> Отладка> Среда, пути сохраняются в файлах с расширением .user.

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

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

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

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

person adheen    schedule 26.07.2018
comment
Символические ссылки также очень хорошо подходят для этой цели. - person sɐunıɔןɐqɐp; 26.07.2018

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

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

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

person AntonK    schedule 29.04.2019