Чи слід додати файли Visual Studio .suo та .user до керування джерелом?

Рішення Visual Studio містять два типи прихованих файлів користувача. Один - .suoфайл рішення, який є двійковим файлом. Інший - .userфайл проекту, який є текстовим файлом. Які саме дані містять ці файли?

Мені також було цікаво, чи варто додати ці файли до управління джерелом (в моєму випадку Subversion). Якщо я не додаю ці файли, а інший розробник перевірить рішення, чи Visual Studio автоматично створить нові файли користувачів?

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

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

Інші пояснили, чому мати файли *.suoта *.userфайли під контролем джерела - це не дуже гарна ідея.

Я хочу запропонувати вам додати ці шаблони до svn:ignoreвласності з 2 причин:

1. Тому інші розробники не закінчуються налаштуваннями одного розробника.
2. Таким чином, коли ви переглядаєте статус або вводите файли, ці файли не захаращують базу коду та не затьмарюють нові файли, які потрібно додати.

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

Сподіваюсь, це допомагає.

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

Чому майстер перетворення Visual Studio 2010 створює масивний файл бази даних SDF?

Ні, не слід додавати їх до керування джерелами, оскільки - як ви вже сказали - вони залежать від користувачів.

SUO (Параметри користувача рішення): записує всі параметри, які можна пов’язати зі своїм рішенням, щоб кожен раз, коли ви відкриваєте його, він включав налаштування, які ви зробили.

Файл .user містить параметри користувача для проекту (в той час як SUO призначений для рішення) і розширює ім'я файлу проекту (наприклад, Everything.csproj.user містить налаштування користувача для проекту what.csproj).

Схоже, це думка Microsoft щодо цього:

Додавання (та редагування) файлів .suo до керування джерелом

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

Не думайте навіть додавати файл suo до керування джерелом!Файл SUO (параметри користувальницьких програм Soluton) повинен містити специфічні для користувача налаштування, і він не повинен ділитися серед користувачів, які працюють над тим самим рішенням. Якщо ви додаєте файл suo в базу даних scc, я не знаю, які інші речі в IDE ви зламаєте, але з точки зору контролю джерела ви порушите інтеграцію SCC веб-проектів, використовувався плагін Lan vs Internet різними користувачами для доступу до VSS, і ви навіть можете змусити scc повністю розірватися (шлях VSS до бази даних, збережений у файлі suo, який може бути дійсним для вас, може бути недійсним для іншого користувача).

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

За замовчуванням Visual SourceSafe Майкрософт не включає ці файли в джерело керування, оскільки це файли налаштувань. Я б дотримувався цієї моделі, якщо ви використовуєте SVN як керування джерелом.

Visual Studio автоматично створить їх. Я не рекомендую ставити їх у контроль джерел. Неодноразово файли SOU місцевого розробника змушували VS поводитись нестандартно у вікні цього розробника. Видалення файлу та надання можливості відновлення VS завжди вирішує проблеми.

На веб-сайті MSDN чітко зазначено, що

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

Тому я б сказав, що цілком безпечно ігнорувати ці файли під час перевірки матеріалів до вашого джерела управління.

Я б не став. Все, що могло змінитись на кожного користувача, зазвичай не є хорошим у контролі джерела. .suo, .user, obj / bin каталоги

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

Ви не можете керувати джерелами файлів .user, оскільки це специфічно для користувача. Він містить назву віддаленої машини та інших речей, що залежать від користувача. Це файл, пов'язаний з vcproj.

Файл .suo - це файл, пов’язаний з sln, і він містить "параметри користувача рішення" (проект запуску, положення вікна (що докинуто і де, що плаває) тощо)

Це двійковий файл, і я не знаю, чи містить він щось "пов'язане з користувачем".

У нашій компанії ми не беремо ці файли під контроль джерела.

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

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

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

Ні.

Я просто хотів справжньої короткої відповіді, а такої не було.

Використовуючи Rational ClearCase, відповідь - ні. Тільки .sln &. * Proj повинен бути зареєстрований у контролі вихідного коду.

Я не можу відповідати за інших постачальників. Якщо я пам'ятаю правильно, ці файли - це "користувацькі" параметри, ваше оточення.

Не додайте жодного з цих файлів до контролю версій. Ці файли автоматично генеруються за допомогою конкретної інформації про робочу станцію, якщо вона зареєстрована у контролі версій, що спричинить проблеми на інших робочих станціях.

Ні, вони не повинні зобов’язуватися керувати джерелами, оскільки вони є локальними налаштуваннями для розробника / машини.

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

Якщо ви встановите свої виконувані залежності від dir в ProjectProperties> Debugging> Environment , шляхи зберігаються у файлах '.user'.

Припустимо, я встановив цей рядок у вищезгаданому полі: "PATH = C: \ xyz \ bin" Ось як він зберігатиметься у файлі ".user":

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

Це нам дуже допомогло під час роботи в OpenCV. Ми могли використовувати різні версії OpenCV для різних проектів. Ще одна перевага полягає в тому, що налаштувати наші проекти на новій машині було дуже просто. Нам просто довелося скопіювати відповідні режими залежності. Тому для деяких проектів я вважаю за краще додавати ".user" до керування джерелами.

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

Як пояснено в інших відповідях, і те, .suoі інше .userне слід додавати до керування джерелами, оскільки вони є специфічними .suoдля користувача / машини (BTW для новіших версій VS було переміщено у спеціальний тимчасовий каталог .vs, який слід повністю уникати від контролю джерела).

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

Замість жорстко закодованого абсолютного шляху в такому файлі є сенс використовувати відносні або покладатися на змінні середовища, тому вибірка може бути достатньо загальною, щоб легко повторно користуватися іншими.