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

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

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

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

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

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

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

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

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

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

Hope это помогает.

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

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

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

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

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

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

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

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

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

Это, кажется, мнение Microsoft о вопросе:

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

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

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

Alin Constantin (MSFT)

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

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

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

Нет.

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