Следует ли использовать .sln в системе контроля версий?


100

Рекомендуется ли зафиксировать файл .sln в системе управления версиями? Когда это уместно или неуместно?

Обновление В ответах было сказано несколько хороших моментов. Спасибо за ответы!


21
Я считаю, что это файл .SUO, который НЕ нужно фиксировать.
apandit

Просто для записи, я считаю, что списки задач (если вы их используете) хранятся в файле .SUO ... Поэтому, хотя вы можете не захотеть передавать их в систему управления версиями, вы можете не захотеть `` просто удалить '' их как посторонний хлам.
Бенджол

Ответы:


68

Я думаю, что из других ответов ясно, что файлы решений полезны и должны быть зафиксированы, даже если они не используются для официальных сборок. Их удобно иметь для всех, кто использует такие функции Visual Studio, как «Перейти к определению / объявлению».

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

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

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

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

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

ipch/
*.sdf
*.opensdf

2
У меня также есть правило игнорирования результатов модульного тестирования. Некоторые люди могут проверить их, но мне не нравится беспорядок,
Мэтью Уитед,

9
+1 - Я лично также не фиксирую ничего, что будет построено, например bin / и obj /
Стивен Эверс,

Я фиксирую только файлы .sln, содержащие более 1 проекта
Джастин

2
вот моя subversion Global ignore patter: * .vsmdi * .suo * / [Bb] в [Bb] в * / obj obj TestResults *. [Uu] ser * Thumbs.db * Web.Publish.xml * WebApplication.Publish. xml * Web.log
Мерритт

Вот общий файл .gitignore, который включает временные файлы, результаты сборки и файлы, созданные популярными надстройками Visual Studio.
Лорен Ван Слоун

58

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


3
Определенно .sln имеет ссылки на файлы .prj (проекты)
dplante

20

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

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


13

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


8

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

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

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


Похоже, это может быть ответом на один из моих давно оставшихся без ответа вопросов ( stackoverflow.com/questions/1490728/… ), есть ли шанс получить копию этого плагина?
Benjol

@Benjol: Извините, это внутренний инструмент. В дополнение к перечисленным выше функциям он также интегрируется с рядом других внутренних систем, поэтому он очень специфичен для того, как мы работаем. Если вам нужна только часть решения / проекта, это не так сложно реализовать.
Брайан Расмуссен,

Хорошо, только одно: в вашем «большом решении» есть ссылки на проекты или файлы? И если разработчик добавляет новую ссылку на файл / проект, выполняет ли плагин соответствующее преобразование перед регистрацией? И как вы справляетесь с зависимостями, которые разработчик не выбрал для проверки?
Benjol

8

Да, вам следует сделать следующее:

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

Вы не должны совершать следующие действия:

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

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


1
Я не согласен с «любым автоматически созданным файлом».
Mehrdad Afshari

@Mehrdad, как вы думаете, файлы Intelisense тоже должны быть зафиксированы?
Эдисон Густаво Мюнц

1
@ Эдисон: Нет. Я имею в виду, например, автоматически сгенерированные исходные файлы, такие как контекст данных LINQ to SQL.
Mehrdad Afshari,

2
Разве файлы Formname.Designer.cs не считаются автоматически созданными?
jasonh

1
Я имел в виду файлы, созданные во время сборки. Я часто нахожу это - кто-то фиксирует файл, который создается автоматически, а затем SVN сообщает об изменении только потому, что был изменен какой-то комментарий.
Groo

5

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


4

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


4

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

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


2

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


2

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


1

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


1

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


1

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


0

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


1
Забавно ... SLN были единственными файлами, которые мне приходилось исправлять ... но проблемы были вызваны тем, что разработчики не были осторожны с слияниями.
Мэтью Уайтд
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.