Решения и проекты
Которые Visual Studio использует для размещения и группировки кода, который вы пишете в интегрированной среде. Решения — это виртуальные контейнеры; они группируют и применяют свойства к одному (или нескольким) проектам. Проекты имеют и виртуальный, и физический характер. Помимо функционирования в качестве организационных единиц для вашего кода они также однозначно соответствуют результатам, получаемым на выходе компилятора. Иначе говоря, Visual Studio превращает проекты в откомпилированный код. Каждый проект приводит к созданию .NET-компонента (такого как файл с расширением dll или ехе).
В этой главе мы опишем роль решений и проектов в процессе разработки программного обеспечения. Мы увидим, как создавать решения и проекты, изучим…
С точки зрения программирования — все, что вы делаете внутри Visual Studio, происходит в контексте решения. Как мы уже упоминали, сами по себе решения не делают ничего, кроме того, что служат контейнерами высокого уровня для прочих элементов. Проекты — это самые очевидные элементы, которые можно поместить внутрь решений, но решения также могут содержать разнообразные файлы, которые необходимы для самого решения (такие как документы Readme и диаграммы проекта). Фактически в решение может быть добавлен файл любого типа. Однако решения не могут содержать другие решения. Кроме того, Visual Studio может открыть только одно решение единовременно. Если вам нужно работать над несколькими решениями…
Для разработки решения вы сначала создаете проект. Поскольку проекты в Visual Studi независимо от решения загружаться не могут, то создание проекта приведет к одновремен ному созданию и решения.
Примечание
В действительности существует все-таки способ создать пустое решение без однс временного создания проекта. Если вы развернете узел Other Project Types, которьп имеется в списке Project Types, то увидите вариант Visual Studio Solutions. В не* есть шаблон Blank Solution (Пустое решение). Такое пустое решение полезно в тог случае, когда вы создаете новое решение для уже существующих проектов; пусто< решение избавляет от беспокойства по поводу создания на жестком диске лишни ненужных проектов.
Откройте…
По умолчанию решение получает имя проекта. Здесь возможна путаница, поскольку теперь у вас есть два каталога/объекта с названием WindowsFormsApplicationl, Один относится к решению, другой — к проекту. Это не идеальный вариант физической организации вашего кода на диске. Рекомендуется во время создания проекта давать решению уникальное имя путем изменения названия по умолчанию, имеющегося в поле Solution Name (см. рис. 4.2).
Visual Studio хранит информацию о решении внутри двух отдельных файлов: файла определения решения и файла пользовательских опций решения. В предыдущем примере Visual Studio создала в указанном каталоге файл определения решения WindowsFormsApplicationl.sin и файл пользовательских опций решения WindowsFormsApplicationl.suo.
Файл определения решения отвечает за описание связей со всеми проектами решения и за хранение различных атрибутов уровня решения (которые можно настроить). Файл пользовательских опций решения хранит все настройки, которые вы (как пользователь Visual Studio) сделали в смысле способа отображения решения внутри интегрированной среды разработки (разворачивается ли решение, какие документы решения открыты в интегрированной среде). Кроме того, здесь хранятся также определенные настройки управления исходными…
После того как вы создали решение, вы уже имеете основное средство взаимодействия с базой ваших кодов. По существу, оно сводится к управлению способом сборки и развертывания составляющих решение проектов и файлов. Решения также предоставляют функциональные возможности, не имеющие отношения к проектам. Основным инструментом манипулирования решениями и проектами является Solution Explorer. Этот инструмент подробно обсуждается в главе 5. Здесь мы рассмотрим общие процедуры, используемые для управления решениями (при помощи меню в Visual Studio). Помните, что большая часть обсуждаемых здесь команд и действий может быть выполнена из Solution Explorer.
На практике содержимое, которое вы добавляете в решение, чаще всего имеет отношение к проектам. Но элементы можно добавлять и напрямую в решение. В собирательном смысле термин "элемент решения" относится к любому "непроектному" файлу, который включается в.решение. Поскольку мы знаем, что решения не могут компилироваться, то совершенно очевидно, что добавленные на уровне решения файлы не имеют практического значения (с точки зрения компиляции). Однако имеются различные причины, по которым вы можете добавлять в ваше решение элементы. Например, это удобный способ хранения документации, которая относится ко всему решению в целом. Поскольку вы можете добавить в решение файл любого типа, то это может быть…
Для помощи в организации различных файлов вашего решения вы можете использовать каталоги решения. Это виртуальные каталоги, которые полностью реализованы в Visual Studio. Создание каталога решения не приводит к созданию физического каталога файлов на диске; эти каталоги существуют исключительно для того, чтобы обеспечить еще один уровень группирования внутри решения. Каталоги решения могут быть вложенными и особенно полезны в больших решениях, которые содержат много различных проектов и разнообразных файлов. Например, вы можете сгруппировать все проекты ваших Web-сервисов в один каталог решения с именем Services, а элементы Windows Forms сгруппировать в каталог UI. Файлы, которые добавлены в виртуальный каталог, физически хранятся на диске…
Внутри интегрированной среды можно настроить несколько свойств уровня решения. Диалоговое окно Solution Property Pages дает вам непосредственный доступ к этим свойствам и позволяет:
□ настроить стартовый проект решения (этот проект будет запущен при старте отладчика);
□ управлять межпроектными зависимостями;
□ указать местоположение исходных файлов (для использования при отладке);
□ модифицировать конфигурации сборки решения.
Открывается это диалоговое окно через меню View | Property Pages или при помощи комбинации клавиш <Shift>+<F4>. В этом диалоговом окне категории страниц свойств представлены в виде дерева с левой стороны; разворачивание узла дерева показывает имеющиеся отдельные страницы свойств.
Указываем стартовый проект
На рис. 4.6 представлена страница свойств…
Если в решении есть проекты, которые зависят друг от друга, т. е. один проект зависит от типов другого проекта и использует их, то Visual Studio должна знать порядок сборки проектов. Для примера рассмотрим проект приложения Windows, который использует типы, предоставляемые проектом библиотеки классов. Если в последовательности сборки сначала не будет собрана библиотека классов, то процесс сборки закончится неудачно.
В большинстве случаев Visual Studio способна сама определить правильную последовательность сборки. Однако иногда вам может понадобиться вручную указать, что некий проект зависит от других проектов. Для предоставления такой информации используйте страницу свойств Project Dependencies (рис. 4.7). Выберите проект в раскрывающемся списке, а…