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

Question

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

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

Answer 1

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

Answer 2

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

Answer 3

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

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

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

Answer 4

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

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

Answer 5

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

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

Answer 6

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

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

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

Answer 7

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

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

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

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

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

Answer 8

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

Answer 9

Нет.

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

Answer 10

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

Answer 11

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

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

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

Answer 12

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

Answer 13

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

Answer 14

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

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

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

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

Answer 15

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

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

Answer 16

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

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

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

      dotnet tool install -g suo

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

      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

Answer 17

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

Answer 18

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

Answer 19

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

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

Answer 20

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

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

Answer 21

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

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

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

Answer 22

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

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

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

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

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