Должен ли я добавить Visual Studio.СУО и.файлы пользователю управлять источником?
=================================================================================

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

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

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



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



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

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

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


мы не фиксируем двоичный файл (*.СУО), но мы совершаем .пользовательский файл. Этот.файл пользователя содержит, например, параметры запуска для отладки проекта. Параметры запуска можно найти в свойствах проекта на вкладке "отладка". Мы использовали NUnit в некоторых проектах и настроили NUnit-gui.exe в качестве опции запуска для проекта. Без него .пользовательский файл, каждый член команды должен был бы настроить его отдельно.

надеюсь, что это помогает.



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

*[Почему мастер преобразования Visual Studio 2010 создает массивный файл базы данных SDF?](https://stackoverflow.com/q/4237660/759749)*



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

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

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



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



Это, по-видимому, мнение Microsoft по этому вопросу:
[http://social.msdn.microsoft.com/forums/en-US/vssourcecontrol/thread/dee90d75-d825-4c76-a30f-016eab15ef7f](https://social.msdn.microsoft.com/forums/en-US/vssourcecontrol/thread/dee90d75-d825-4c76-a30f-016eab15ef7f)

> 
> Я не знаю, почему ваш проект хранит DebuggingWorkingDirectory в
>  файл suo. Если это пользовательский параметр, вы должны рассмотреть
>  хранить это в *.proj.имя пользователя. Если этот параметр является общим
>  между всеми пользователями, работающими над проектом, вы должны рассмотреть сохраняющий
>  это в самом файле проекта.
> 
> 
> **даже не думайте о добавлении файла suo в систему управления версиями!** СУО
>  (параметры пользователя soluton) файл должен содержать пользовательские параметры
>  параметры и не должны совместно использоваться пользователями, работающими над одним и тем же
>  решение. Если вы добавляете файл suo в базу данных scc, я не
>  знаете, что еще в IDE вы сломаете, но из системы управления версиями
>  точка зрения вы нарушите интеграцию веб-проектов scc, Lan vs
>  Интернет-плагин, используемый различными пользователями для доступа VSS, и вы можете
>  даже заставьте scc полностью сломаться (путь к базе данных VSS, хранящийся в
>  файл suo, который может быть действительным для вас, может быть недействительным для другого пользователя).
> 
> 
> Алин Константин (MSFT)
> 
> 
> 



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



на  [веб-сайт MSDN](https://msdn.microsoft.com/en-us/library/bb165909.aspx), в нем четко указано, что 

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

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



Я бы не стал. Все, что может измениться на "пользователя", обычно не очень хорошо в системе управления версиями. .СУО .каталоги пользователя, obj / bin



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



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

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

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

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



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

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



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



используя Rational ClearCase ответ-нет, только the .ФСЛ. & * proj должен быть зарегистрирован в управлении исходным кодом, я не могу ответить за других поставщиков. Если я правильно помню, эти файлы являются "пользовательскими" конкретными параметрами, вашей средой.



Если вы установите исполняемые зависимости dir в **ProjectProperties>Отладка>Окружающая Среда**, пути хранятся в '.файлы пользователя. 

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

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

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

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