Решения Visual Studio содержат два типа скрытых пользовательских файлов. Одним из них является файл решения .suo, который является двоичным файлом. Другим является файл проекта .user, который является текстовым файлом. Какие данные содержатся в этих файлах?
Мне также интересно, следует ли добавлять эти файлы в исходный код (Subversion в моем случае). Если я не добавлю эти файлы, а другой разработчик проверяет решение, Visual Studio автоматически создаст новые пользовательские файлы?
Эти файлы содержат конфигурации предпочтений пользователей, которые в целом относятся к вашей машине, поэтому лучше не помещать их в SCM. Кроме того, VS изменит его почти каждый раз, когда вы его запустите, поэтому он всегда будет отмечен SCM как "измененный". Я тоже не включаю, я участвую в проекте с использованием VS в течение 2 лет и не имел никаких проблем с этим. Единственное незначительное раздражение заключается в том, что параметры отладки (путь выполнения, цель развертывания и т.д.) Хранятся в одном из этих файлов (не знаю, что), поэтому, если у вас есть стандарт для них, вы не сможете " опубликовать 'через SCM для других разработчиков, чтобы вся среда разработки была готова к использованию.
Вам не нужно добавлять их - они содержат настройки для каждого пользователя, а другим разработчикам не нужна ваша копия.
Другие объяснили, почему отсутствие файлов *.suo и *.user под контролем источника не является хорошей идеей.
Я хотел бы предложить добавить эти шаблоны в свойство svn:ignore по двум причинам:
Мы не фиксируем двоичный файл (*.suo), но мы фиксируем файл .user. Файл .user содержит, например, начальные параметры для отладки проекта. Параметры запуска в свойствах проекта можно найти на вкладке "Отладка". Мы использовали NUnit в некоторых проектах и настроили nunit-gui.exe в качестве стартового варианта для проекта. Без файла .user каждый член команды должен будет настроить его отдельно.
Надеюсь, что это поможет.
Поскольку я нашел этот вопрос/ответ через Google в 2011 году, мне показалось, что я возьму секунду и добавлю ссылку на *.SDF файлы, созданные Visual Studio 2010, в список файлов, которые, вероятно, не следует добавлять в (IDE будет их воссоздавать). Поскольку я не был уверен, что файл *.sdf может иметь законное использование в другом месте, я только проигнорировал конкретный файл [projectname].sdf из SVN.
Почему мастер преобразования Visual Studio 2010 создает массивный файл базы данных SDF?
Нет, вы не должны добавлять их в исходное управление, поскольку, как вы сказали, они специфичны для пользователя.
SUO (параметры пользователя решения): записи все варианты, которые вы могли бы связать с вашим решением так, чтобы каждый раз, когда вы его открываете, он включает настройки, которые вы сделал.
Файл .user содержит параметры пользователя для проекта (в то время как SUO для решения) и расширяет имя файла проекта (например, anything.csproj.user содержит пользовательские настройки для проекта anything.csproj).
По умолчанию Microsoft Visual SourceSafe не включает эти файлы в исходный элемент управления, потому что они являются файлами настроек для конкретного пользователя. Я буду следовать этой модели, если вы используете SVN в качестве источника управления.
Похоже, это мнение Microsoft по этому вопросу:
Добавление (и редактирование) файлов .suo в систему контроля версий.
Я не знаю, почему ваш проект хранит DebuggingWorkingDirectory в файле suo. Если это пользовательская настройка, вы должны сохранить ее в имени файла *.proj.user. Если этот параметр доступен всем пользователям, работающим над проектом, вам следует сохранить его в самом файле проекта.
Даже не думайте добавлять файл suo в систему управления версиями! Файл SUO (soluton user options) должен содержать пользовательские настройки и не должен использоваться совместно пользователями, работающими над тем же решением. Если вы добавляете файл suo в базу данных scc, я не знаю, какие другие вещи в IDE вы нарушите, но с точки зрения контроля версий вы нарушите интеграцию scc веб-проектов, использовался плагин Lan vs Internet. другими пользователями для доступа к VSS, и вы можете даже заставить scc полностью сломаться (путь к базе данных VSS, сохраненный в файле suo, который может быть действительным для вас, может быть недействительным для другого пользователя).
Алин Константин (MSFT)
Visual Studio автоматически создаст их. Я не рекомендую вводить их в исходный контроль. Было много раз, когда локальный SOU файл разработчика вызывал ошибку VS в этой области разработчиков. Удалив файл, а затем разрешив его воссоздание, он всегда исправлял проблемы.
Я бы не стал. Все, что может измениться для каждого пользователя, обычно не подходит для контроля источника..suo,.user, obj/bin каталоги
Эти файлы являются пользовательскими параметрами, которые не зависят от самого решения. Visual Studio при необходимости создаст новые, поэтому их не нужно проверять в исходном управлении. В самом деле, вероятно, было бы лучше не делать этого, поскольку это позволяет отдельным разработчикам настраивать свою среду по своему усмотрению.
Они содержат конкретные настройки проекта, которые обычно назначаются одному разработчику (например, стартовый проект и стартовая страница запускаются при отладке вашего приложения).
Поэтому лучше не добавлять их в контроль версий, оставляя VS воссоздавать их, чтобы каждый разработчик мог иметь нужные настройки.
Вы не можете использовать исходные файлы .user, потому что этот пользователь определен. Он содержит имя удаленной машины и другие зависящие от пользователя вещи. Это связанный с vcproj файл.
Файл .suo является связанным с sln файлом и содержит "параметры пользователя решения" (проекты запуска, положение окна (что закреплено и где, что плавающее) и т.д.)
Это двоичный файл, и я не знаю, содержит ли он что-то "связанное с пользователем".
В нашей компании мы не берем эти файлы под контролем источника.
Лучшие практики для проектов Subversion и Visual Studio - более общий вопрос об этой точной теме.
Также в принятом ответе на него содержится ссылка на официальную документацию MSDN, в которой подробно описываются, какие файлы/каталоги VS-решений/проектов VS должны быть добавлены в исходное управление систем и какие части следует игнорировать.
.user - это пользовательские настройки, и я думаю, что .suo - это параметры пользователя решения. Вы не хотите, чтобы эти файлы находились под контролем источника; они будут воссозданы для каждого пользователя.
Используя Rational ClearCase, ответ - нет. Только .sln &. * Proj должен быть зарегистрирован в контроле исходного кода.
Я не могу отвечать за других поставщиков. Если я правильно помню, эти файлы являются "пользовательскими" настройками вашей среды.
Не добавляйте эти файлы в систему контроля версий. Эти файлы автоматически генерируются с информацией, специфичной для рабочей станции, если они включены в систему контроля версий, что вызовет проблемы на других рабочих станциях.
Если вы установите свои исполняемые зависимости dir в ProjectProperties> Debugging> Environment, пути будут храниться в файлах ".user".
Предположим, я установил эту строку в вышеупомянутом поле: "PATH = C:\xyz\bin". Вот как она будет храниться в файле ".user":
<LocalDebuggerEnvironment>PATH=C:\xyz\bin$(LocalDebuggerEnvironment)</LocalDebuggerEnvironment>
Это очень помогло нам во время работы в OpenCV. Мы могли бы использовать разные версии OpenCV для разных проектов. Еще одним преимуществом является то, что было очень легко настроить наши проекты на новой машине. Нам просто нужно было скопировать соответствующие каталоги зависимостей. Поэтому для некоторых проектов я предпочитаю добавлять '.user' в систему контроля версий.
Хотя это полностью зависит от проектов. Вы можете принять звонок в зависимости от ваших потребностей.
Нет, они не должны быть привязаны к управлению исходным кодом, поскольку являются локальными настройками разработчика/компьютера.
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
Как объясняется в других ответах, и .suo и .user не должны добавляться в систему управления версиями, поскольку они зависят от пользователя/компьютера (кстати, .suo для новейших версий VS был перемещен в выделенный временный каталог .vs, который должен быть держаться вне системы контроля полностью).
Однако если вашему приложению требуется некоторая настройка среды для отладки в VS (такие настройки обычно хранятся в файле .user), может быть удобно подготовить образец файла (назвав его как .user.SAMPLE) и добавить его в систему контроля .user.SAMPLE для Рекомендации.
Вместо жестко запрограммированного абсолютного пути в таком файле имеет смысл использовать относительные или полагаться на переменные среды, поэтому образец может быть достаточно универсальным, чтобы его можно было легко использовать другими.