Следует ли использовать .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),
• сборка сгенерированных файлов (например, с помощью сценария сборки) [Изменить:] - только если все необходимые сценарии сборки и инструменты доступны в системе контроля версий (для обеспечения подлинности сборок в истории cvs)

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

Да, это должно быть частью системы контроля версий. Когда вы когда-либо добавляете / удаляете проекты из своего приложения, .sln будет обновляться, и было бы хорошо, если бы он находился под контролем версий. Это позволит вам вытащить 2 версии кода вашего приложения и напрямую выполнить сборку (если это вообще необходимо).

Да, вы всегда хотите включать файл .sln, он включает ссылки на все проекты, которые есть в решении.

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

Если ваши файлы .sln созданы другим инструментом (например, CMake), то, вероятно, нецелесообразно помещать их в систему контроля версий.

Мы делаем это, потому что это все синхронизирует. Все необходимые проекты расположены вместе, и никому не нужно беспокоиться о пропаже одного. Наш сервер сборки (Ant Hill Pro) также использует sln для определения того, какие проекты нужно собрать для выпуска.

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

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

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

Мы храним файлы решений в системе контроля версий TFS. Но поскольку основное решение действительно велико, у большинства разработчиков есть личное решение, содержащее только то, что им нужно. Главный файл решения в основном используется сервером сборки.

.slns - единственное, с чем у нас не было проблем в tfs!