.sln должен посвятить себя управлению исходным кодом?
Если вы имеете дело с JSON, следует отметить, что, строго говоря, строки JSON должны заключаться в двойные кавычки. Конечно, многие библиотеки также поддерживают одинарные кавычки, но у меня были большие проблемы в одном из моих проектов, прежде чем я понял, что одиночные кавычки строки на самом деле не соответствуют стандартам JSON.
15 ответов
Я думаю Из других ответов ясно, что файлы решений полезны и должны быть зафиксированы, даже если они не используются для официальных сборок. Их удобно иметь для всех, кто использует такие функции Visual Studio, как «Перейти к определению / объявлению»
. По умолчанию они не содержат абсолютных путей или каких-либо других артефактов, зависящих от машины. (К сожалению, некоторые инструменты надстройки не поддерживают это свойство должным образом, например AMD CodeAnalyst.) Если вы осторожно используете относительные пути в файлах проекта (как C ++, так и C #), они не будут зависеть от машины. тоже.
Возможно, более полезный вопрос: какие файлы следует исключить? Вот содержание моего. gitignore для моих проектов VS 2008:
*.suo
*.user
*.ncb
Debug/
Release/
CodeAnalyst/
(Последняя запись предназначена только для профилировщика AMD CodeAnalyst.)
Для VS 2010 вы также должны исключить следующее:
ipch/
*.sdf
*.opensdf
1) Создайте новый проект в VS
2) Щелкните правой кнопкой мыши решение в обозревателе решений, выберите «Добавить в систему управления версиями»
. Добавлен sln в систему управления версиями? Это ваш ответ.
.slns - единственное, с чем у нас не было проблем в tfs!
Мы храним файлы решений или файлы решений в системе контроля версий TFS. Но поскольку основное решение действительно велико, у большинства разработчиков есть личное решение, содержащее только то, что им нужно. Главный файл решения в основном используется сервером сборки.
Мы так делаем, потому что он все синхронизирует. Все необходимые проекты расположены вместе, и никому не нужно беспокоиться о пропаже одного. Наш сервер сборки (Ant Hill Pro) также использует sln для определения того, какие проекты нужно собрать для выпуска.
Да, вы должны зафиксировать следующее:
- решение (* .sln),
- файлы проекта,
- все исходные файлы,
Единственный случай, когда вы даже не захотите хранить его в системе управления версиями, - это если у вас есть большое решение со многими проектами, находящимися в системе управления версиями, и вы хотите создать небольшое решение с некоторые проекты из основного решения для некоторых частных переходных требований.
Да, он должен быть частью системы управления версиями. Когда вы когда-либо добавляете / удаляете проекты из своего приложения, .sln будет обновляться, и было бы хорошо, если бы он находился под контролем версий. Это позволит вам извлечь код вашего приложения на две версии назад и напрямую выполнить сборку (если это вообще необходимо).
Да - все, что используется для создания вашего продукта, должно находиться в системе контроля версий.
Вы обязательно должны его получить. Помимо причин, упомянутых другими людьми, необходимо сделать возможной сборку всего проекта за один шаг.
Да, вам следует это сделать. Файл решения содержит только информацию об общей структуре вашего решения. Эта информация является глобальной для решения и, вероятно, является общей для всех разработчиков вашего проекта.
Он не содержит никаких пользовательских настроек.
Да, я думаю, это всегда уместно. Пользовательские настройки находятся в других файлах.
Я в целом согласен с тем, что файлы решений должны быть возвращены, однако в компании, в которой я работаю, мы сделали кое-что другое. У нас довольно большой репозиторий, и разработчики время от времени работают над разными частями системы. Для поддержки нашей работы у нас будет либо один большой файл решения, либо несколько меньших. Оба они имеют несколько недостатков и требуют ручной работы со стороны разработчиков. Чтобы этого избежать, мы создали плагин, который этим всем занимается.
Подключаемый модуль позволял каждому разработчику проверять подмножество исходного дерева для работы, просто выбирая соответствующие проекты из репозитория. Затем плагин создает файл решения и на лету изменяет файлы проекта для данного решения. Он также обрабатывает ссылки. Другими словами, все, что нужно сделать разработчику, - это выбрать подходящие проекты, после чего необходимые файлы будут сгенерированы / изменены. Это также позволяет нам настраивать различные другие параметры в соответствии со стандартами компании.
Кроме того, мы используем подключаемый модуль для поддержки различных политик регистрации, которые обычно не позволяют пользователям отправлять ошибочный / несовместимый код в репозиторий.
Да, вы всегда хотите включить файл .sln, он включает ссылки на все проекты, которые есть в решении.
Обычно мы помещаем все наши файлы решений в каталог решений. Таким образом мы немного отделяем решение от кода, и мне будет проще выбрать проект, над которым мне нужно работать.