Чи має бути .sln зобов'язаний контролювати джерело?

Чи є найкращою практикою введення файлу .sln для управління джерелом? Коли це доцільно чи недоцільно робити?

Оновлення У відповідях було зроблено кілька хороших моментів. Дякуємо за відповіді!

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

За замовчуванням вони не містять абсолютних шляхів або будь-яких інших артефактів, специфічних для машини. (На жаль, деякі додаткові інструменти не підтримують належним чином цю властивість, наприклад, AMD CodeAnalyst.) Якщо ви обережно використовувати відносні шляхи у файлах проекту (як C ++, так і C #), вони будуть незалежними від машини. теж.

Напевно, більш корисне питання: які файли слід виключити? Ось вміст мого файлу .gitignore для моїх проектів VS 2008:

*.suo
*.user
*.ncb
Debug/
Release/
CodeAnalyst/

(Останній запис призначений саме для профілера AMD CodeAnalyst.)

Для VS 2010 також слід виключити наступне:

ipch/
*.sdf
*.opensdf

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

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

Він не містить певних налаштувань для користувача.

Ви обов'язково повинні це мати. Окрім причин, про які згадували інші, потрібно зробити один крок побудови всіх проектів.

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

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

Крім того, ми використовуємо плагін для підтримки різних політик реєстрації, що, як правило, не дозволяє користувачам надсилати у сховище несправний / невідповідний код.

Так, ви повинні скористатися:

• розчин (* .sln),
• файли проекту,
• всі вихідні файли,
• файли конфігурації програми
• будувати сценарії

Що ви не повинні робити:

• файли параметрів користувача (.suo),
• створювати генеровані файли (наприклад, використовуючи сценарій збірки) [Редагувати:] - лише якщо всі необхідні сценарії та інструменти для збирання доступні під контролем версій (щоб переконатися, що збірки є автентичними в історії резюме)

Щодо інших автоматично генерованих файлів, є окрема тема .

Так, це повинно бути частиною контролю джерела. Коли ви коли-небудь додаєте / видаляєте проекти зі своєї програми, .sln буде оновлюватися, і було б добре мати його під контролем джерела. Це дозволить вам витягнути назад версії 2 програми та безпосередньо скласти збірку (якщо вона взагалі потрібна).

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

Якщо ваші .sln файли генеруються іншим інструментом (наприклад, CMake), то, ймовірно, недоцільно їх розміщувати у контролі джерела.

Так, ви завжди хочете включити .sln файл, він містить посилання на всі проекти, які є в рішенні.

Ми робимо це тому, що це синхронізує все. Усі необхідні проекти розміщені разом, і ніхто не повинен турбуватися про відсутність. Наш сервер побудови (Ant Hill Pro) також використовує sln, щоб визначити, які проекти потрібно створити для випуску.

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

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

Так - все, що використовується для створення вашого продукту, має контролюватися джерелами.

Ми зберігаємо або вирішуємо файли в TFS Version Control. Але оскільки основне рішення дійсно велике, більшість розробників мають персональне рішення, що містить лише те, що їм потрібно. Основний файл рішення в основному використовується сервером збірки.

.slns - це єдине, з чим у нас не було проблем у tfs!