Блог

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

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

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

Причины, по которым вам может понадобиться несколько проектов в одном решении:

• Разные проекты могут иметь разные зависимости (либо зависимости от других проектов в вашем решении, либо, как правило, зависимости от сторонних библиотек DLL).
• Разные проекты могут быть разных типов — консольное приложение, dll, веб-сервис и т.д.
• Разные проекты могут иметь разные этапы до / после сборки
• Некоторые из ваших проектов могут даже не быть реализованы на C #. У вас может быть c , VB.net , и т.д., проекты также в том же решении.
• Различные проекты могут быть компонентами, которые повторно используются различными другими командами.
• много других причин

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

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

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

Есть несколько причин иметь несколько проектов. Вот несколько:

1. Возможность повторного использования кода. Возможно, вы разработали какой-то код, который хотите упаковать в библиотеку и использовать в других программах в будущем.
2. Простота. Иногда при создании сложного приложения вам захочется создавать архитектуру по частям, чтобы приложение было легче отлаживать в целом.
3. Конфликтующие языки. Предполагается, что ваше приложение написано на C #, но вы хотите использовать некоторый код, который содержится в VB.NET библиотека. Поскольку проект не может смешивать C # и VB.NET код, ваше решение состоит в том, чтобы создавать разные проекты в одном и том же решении.

Цитата из какой-то выдержки из MSDN

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

Решения содержат элементы, которые вам нужны для создания вашего приложения. Решение включает в себя один или несколько проектов, а также файлы и метаданные, которые помогают определить решение в целом. Visual Studio автоматически генерирует решение при создании нового проекта. Visual Studio хранит определение решения в двух файлах: .sln и .suo. В файле определения решения (.sln) хранятся метаданные, которые определяют ваше решение, в том числе:

• Проекты, связанные с решением.
• Элементы, которые не связаны с конкретным проектом.
• Конфигурации сборки, которые определяют, какие конфигурации проекта применять в каждом типе сборки.

Метаданные, сохраненные в файле .suo при создании решения и настройке его свойств, используются для настройки IDE всякий раз, когда решение активно. Например, обозреватель решений отображает папку «Разные файлы» для решения, если вы включите эту опцию, и инструменты, подходящие для типов проектов, включенных в решение, становятся доступными из панели инструментов.

Когда вы дважды щелкните файл .sln (решение), он откроет это решение в Visual Studio.

Решение позволяет вам группировать проекты вместе в одном, erm, решении.

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

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

Какой метод вы ранее использовали для организации своих проектов?

Вот конкретный пример:

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

но зачем мне когда-либо хотеть иметь группу проектов в одном файле?

Потому что вы не программист-любитель, который просто учится программировать и писать приложения, подобные hello world.

В моем основном проекте около 40 проектов, принадлежащих одному приложению. Оболочка, несколько расширений powershell, несколько программ, несколько установщиков. Они принадлежат друг другу и собираются вместе — это одно решение.

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

MSBuild создает проекты в соответствии с инструкциями в решении, что еще?