Должен ли .sln быть привязан к источнику контроля?

Ответ 1

Я думаю, что из других ответов ясно, что файлы решений полезны и должны быть выполнены, даже если они не используются для официальных сборок. Они удобны для тех, кто использует функции Visual Studio, такие как Go To Definition/Declaration.

По умолчанию они не содержат абсолютных путей или других артефактов, специфичных для машины. (К сожалению, некоторые надстройки не поддерживают это свойство должным образом, например, AMD CodeAnalyst.) Если вы стараетесь использовать относительные пути в файлах проектов (как С++, так и С#), они будут независимы от машины тоже.

Вероятно, более полезный вопрос: какие файлы вы должны исключить? Здесь содержимое моего файла .gitignore для моих проектов VS 2008:

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

(Последняя запись предназначена только для профайлера AMD CodeAnalyst.)

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

ipch/
*.sdf
*.opensdf

Ответ 2

Да - я считаю, что это всегда уместно. Пользовательские настройки находятся в других файлах.

Ответ 3

Да, вы должны это сделать. Файл решения содержит только информацию об общей структуре вашего решения. Эта информация является глобальной для решения и, вероятно, является общей для всех разработчиков в вашем проекте.

Он не содержит никаких пользовательских настроек.

Ответ 4

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

Ответ 5

Да, вещи, которые вы должны зафиксировать:

• solution (*.sln),
• файлы проекта,
• все исходные файлы,
• конфигурационные файлы приложений
• строить скрипты

Вы должны не совершать:

• файлы параметров решения (.suo),
• сгенерировать сгенерированные файлы (например, с помощью сборки script) [Изменить:] - только если все необходимые скрипты и инструменты сборки доступны под управлением версии (чтобы гарантировать, что сборки аутентичны в истории cvs)

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

Ответ 6

Я вообще согласен, что файлы решений должны быть проверены, однако, в компании, в которой я работаю, мы сделали что-то другое. У нас есть довольно большой репозиторий, и разработчики время от времени работают над разными частями системы. Чтобы поддерживать то, как мы работаем, у нас будет либо один большой файл решения, либо несколько меньше. У обоих из них есть несколько недостатков и требуется ручная работа над частью разработчиков. Чтобы этого избежать, мы создали плагин, который обрабатывает все это.

Плагин позволяет каждому разработчику проверять подмножество исходного дерева, чтобы работать, просто выбрав соответствующие проекты из репозитория. Затем плагин генерирует файл решения и изменяет файлы проекта "на лету" для данного решения. Он также обрабатывает ссылки. Другими словами, все разработчики должны сделать это, чтобы выбрать соответствующие проекты, а затем создать или изменить необходимые файлы. Это также позволяет нам настраивать различные настройки для обеспечения стандартов компании.

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

Ответ 7

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

Ответ 8

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

Ответ 9

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

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

Ответ 10

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

Ответ 11

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

Ответ 12

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

Ответ 13

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

Ответ 14

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

Ответ 15

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

Ответ 16

1) Создайте новый проект в VS
2) Щелкните правой кнопкой мыши по решению в обозревателе решений, выберите "Добавить в исходное управление"

Добавлен ли sln в исходный элемент управления? Это ваш ответ.