Решения Visual Studio содержат два типа скрытых пользовательских файлов. Одним из них является .suoфайл решения, который является двоичным файлом. Другой .userфайл проекта, который является текстовым файлом. Какие именно данные содержат эти файлы?
Мне также было интересно, следует ли мне добавлять эти файлы в систему контроля версий (в моем случае это Subversion). Если я не добавлю эти файлы и другой разработчик проверит решение, Visual Studio автоматически создаст новые пользовательские файлы?
visual-studio
version-control
Бен Миллс
источник
источник
Ответы:
Эти файлы содержат конфигурации пользовательских настроек, которые в целом относятся к вашей машине, поэтому лучше не помещать их в SCM. Кроме того, VS будет изменять его почти каждый раз, когда вы его выполняете, поэтому SCM всегда будет помечать его как «измененный». Я тоже не включаю, я в проекте, использующем VS в течение 2 лет, и у меня не было проблем с этим. Единственное небольшое неудобство заключается в том, что параметры отладки (путь выполнения, цель развертывания и т. Д.) Хранятся в одном из этих файлов (не знаю, какие именно), поэтому, если у вас есть стандарт для них, вы не сможете ' опубликуйте «через SCM для других разработчиков, чтобы вся среда разработки была готова к использованию».
источник
Вам не нужно добавлять их - они содержат настройки для каждого пользователя, и другие разработчики не захотят вашу копию.
источник
Другие объяснили , почему имея
*.suoи*.userфайлы в системе управления версиями не является хорошей идеей.Я хотел бы предложить вам добавить эти шаблоны в
svn:ignoreсвойство по двум причинам:источник
svn:ignoreсвойство?.user, так что тогда можно выбрать не игнорировать только.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?
источник
Нет, вам не следует добавлять их в систему контроля версий, поскольку, как вы сказали, они зависят от пользователя.
Файл .user содержит пользовательские параметры для проекта (в то время как SUO - для решения) и расширяет имя файла проекта (например, что угодно .csproj.user содержит пользовательские настройки для проекта everything.csproj).
источник
Похоже, это мнение Microsoft по этому вопросу:
Добавление (и редактирование) файлов .suo в систему контроля версий.
источник
По умолчанию Microsoft Visual SourceSafe не включает эти файлы в элемент управления исходным кодом, поскольку они являются файлами пользовательских настроек. Я бы следовал этой модели, если вы используете SVN в качестве источника контроля.
источник
Visual Studio автоматически создаст их. Я не рекомендую помещать их в систему контроля версий. Было много раз, когда файл SOU локального разработчика вызывал хаотичное поведение VS на этом блоке разработчиков. Удаление файла и последующее его восстановление VS всегда исправляли проблемы.
источник
На сайте MSDN четко указано, что
Так что я бы сказал, что довольно безопасно игнорировать эти файлы при проверке содержимого в вашем контроле исходного кода.
источник
Я бы не стал. Все, что может измениться для каждого «пользователя», обычно не подходит для контроля версий. Каталоги .suo, .user, obj / bin
источник
Эти файлы являются пользовательскими параметрами, которые не должны зависеть от самого решения. Visual Studio будет создавать новые по мере необходимости, поэтому их не нужно регистрировать в системе контроля версий. Действительно, вероятно, было бы лучше этого не делать, поскольку это позволяет отдельным разработчикам настраивать свою среду так, как они считают нужным.
источник
Вы не можете управлять исходными файлами .user, потому что это зависит от пользователя. Он содержит имя удаленной машины и другие зависящие от пользователя вещи. Это файл, связанный с vcproj.
Файл .suo является файлом, связанным с sln, и содержит «пользовательские параметры решения» (стартовый проект (ы), положение окон (что закреплено и где, что перемещается) и т. Д.)
Это двоичный файл, и я не знаю, содержит ли он что-то «связанное с пользователем».
В нашей компании мы не берем эти файлы под контроль источников.
источник
Они содержат конкретные параметры проекта, которые обычно назначаются одному разработчику (например, стартовый проект и стартовая страница, которые запускаются при отладке приложения).
Так что лучше не добавлять их в систему управления версиями, а VS создавать их заново, чтобы у каждого разработчика были нужные настройки.
источник
.user - это пользовательские настройки, и я думаю .suo - это пользовательские настройки решения. Вы не хотите, чтобы эти файлы находились под контролем исходного кода; они будут воссозданы для каждого пользователя.
источник
Нет.
источник
Используя Rational ClearCase, ответ - нет. Только .sln &. * Proj должен быть зарегистрирован в контроле исходного кода.
Я не могу отвечать за других поставщиков. Если я правильно помню, эти файлы являются "пользовательскими" настройками вашей среды.
источник
only the .sln & .*proj should be registered- Вы не забыли много файлов здесь?Не добавляйте эти файлы в систему управления версиями. Эти файлы автоматически генерируются с информацией, специфичной для рабочей станции, если они включены в систему контроля версий, что вызовет проблемы на других рабочих станциях.
источник
Нет, они не должны быть привязаны к управлению исходным кодом, поскольку являются локальными настройками разработчика / компьютера.
GitHub поддерживает список предлагаемых типов файлов, которые пользователи Visual Studio должны игнорировать, по адресу https://github.com/github/gitignore/blob/master/VisualStudio.gitignore.
Для SVN у меня есть следующий
global-ignoreнабор свойств:источник
Если вы установите свои исполняемые зависимости dir в ProjectProperties> Debugging> Environment , пути будут храниться в файлах .user.
Предположим, я установил эту строку в вышеупомянутом поле: «PATH = C: \ xyz \ bin». Вот как она будет храниться в файле «.user»:
<LocalDebuggerEnvironment>PATH=C:\xyz\bin$(LocalDebuggerEnvironment)</LocalDebuggerEnvironment>Это очень помогло нам во время работы в OpenCV. Мы могли бы использовать разные версии OpenCV для разных проектов. Еще одним преимуществом является то, что было очень легко настроить наши проекты на новой машине. Нам просто нужно было скопировать соответствующие каталоги зависимостей. Поэтому для некоторых проектов я предпочитаю добавлять '.user' в систему контроля версий.
Хотя это полностью зависит от проектов. Вы можете принять звонок в зависимости от ваших потребностей.
источник
Как объясняется в других ответах, оба
.suoи.userих не следует добавлять в систему контроля.suoверсий , поскольку они зависят от пользователя / компьютера (кстати, для новейших версий VS был перемещен в выделенный временный каталог.vs, который следует полностью исключить из системы контроля версий ).Однако если вашему приложению требуется некоторая настройка среды для отладки в VS (такие настройки обычно хранятся в
.userфайле), может быть удобно подготовить образец файла (назвав его так.user.SAMPLE) и добавить его в систему контроля версий для ссылок.Вместо жестко запрограммированного абсолютного пути в таком файле имеет смысл использовать относительные или полагаться на переменные среды, поэтому образец может быть достаточно универсальным, чтобы его можно было легко использовать другими.
источник