Как создать решение в visual studio

Решения в Visual Studio

В отличие от простейших программ, таких как «Hello World», большинство приложений состоит из нескольких исходных файлов. Это обстоятельство порождает массу проблем, в частности, как назвать файлы, где их разместить и можно ли их использовать повторно. В интегрированной среде разработки Visual Studio принята концепция решения (solution), состоящего из ряда проектов, которые в свою очередь состоят из ряда элементов, благодаря которой разработчики могут работать с исходными файлами. Интегрированная среда разработки имеет множество встроенных инструментов, позволяющих упростить этот процесс, обеспечив разработчикам доступ к большей части их приложений. Далее рассматриваются структура решений и проектов, доступные типы проектов и способы настройки их конфигурации.

Структура решения

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

Решение можно интерпретировать как контейнер связанных между собой проектов. Проекты внутри решения не обязательно должны быть написаны на одном и том же языке программирования или иметь одинаковый тип. Например, решение может содержать веб-приложение ASP.NET, написанное на языке Visual Basic, библиотеку на языке F# и WPF-приложение, написанное на языке C#. Решение позволяет пользователю открыть всё эти проекты в интегрированной среде разработки, а также управлять общими настройками для их создания и развертывания.

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

Для организации работы с исходным кодом и предотвращения его ассоциации с приложениями (за исключением веб-приложений, в которых существуют специальные папки, имеющие особое предназначение в данном контексте) используются папки (folders). Некоторые разработчики используют имена папок, соответствующие пространствам имен, которым принадлежат классы. Например, если класс Person находится в папке DataClasses в проекте FirstProject, то полностью квалифицированное имя класса может выглядеть как FirstProject.DataClasses.Person.

Папки решения (solution folders) — полезный способ организации проектов в большом решении. Они отображаются только в окне Solution Explorer — физически в файловой системе их не существует. Такие действия, как Build или Unload, можно легко выполнять над всеми проектами, включенными в папку решения. Для того чтобы разгрузить окно Solution Explorer, папки решения могут быть свернуты или скрыты.

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

Бытует распространенное заблуждение, что отдельный проект обязательно должен соответствовать отдельной .NET-сборке. Хотя в принципе это верно, довольно часто одну сборку могут представлять несколько проектов. Однако эта ситуация системой Visual Studio 2013 не поддерживается, поэтому мы будем считать, что один проект соответствует одной сборке.

Папка Miscellaneous Files — это специальная папка решения, которую можно использовать для того, чтобы следить за тем, какие еще файлы, не являющиеся частью какого-либо проекта в решении, были открыты в системе Visual Studio. По умолчанию папка Miscellaneous Files скрыта. Для того чтобы сделать ее видимой, следует выполнить команду Tools —> Options —> Environment —> Documents —> Show Miscellaneous Files.

Несмотря на то что формат файла решения, принятый в предыдущих версиях, не изменился, в системе Visual Studio 2010 открыть файл решения, созданный в версии Visual Studio 2013, невозможно.

Кроме информации о файлах, содержащихся в приложении, файлы решения и проектов могут содержать и другие записи, например, о том, как именно должен быть скомпилирован конкретный файл, об установках проекта, о ресурсах и многом другом. Система Visual Studio 2013 имеет немодальное диалоговое окно для редактирования свойств проекта, в то время как свойства решения по-прежнему открываются в отдельном окне. Как и следовало ожидать, свойствами проекта считаются те свойства, которые относятся только к данному проекту, например информация о сборке и связях, а свойства решения определяют общую конфигурацию для сборки приложений.

Формат файла решения

Система Visual Studio 2013 фактически создает для решения два файла, имеющих расширения .suo и .sln (solution file). Первый — это довольно неинтересный бинарный файл, который сложно редактировать. Он содержит информацию, специфичную для пользователя, например, какие файлы были открыты, когда решение закрывалось в последний раз и где находились контрольные точки. Этот файл скрыт, поэтому он не должен появляться в папке решения при использовании Windows Explorer, если не снять с него соответствующую метку.

Иногда файл .suo оказывается поврежденным, и это вызывает непредсказуемые последствия при сборке и редактировании приложений. Если при работе с конкретным решением система Visual Studio становится нестабильной, необходимо выйти из нее и удалить файл с расширением .suo. Он будет создан заново системой Visual Studio, когда решение будет открыто в следующий раз. Файл решения с расширением .sln содержит информацию о решении, например список проектов, конфигурации сборки и другие настройки, не специфичные для проекта. В отличие от многих файлов, используемых в системе Visual Studio 2013, файл решения не является XML-документом. Он хранит информацию в блоках, как показано в следующем примере:

Microsoft Visual Studio Solution File, Format Version 12.00 # Visual Studio 2013 VisualStudioVersion = 12.0.21005.1 MinimumVisualStudioVersion = 10.0.40219.1 Project("") = "GettingStarted", "GettingStarted\GettingStarted.csproj", "" EndProject Project("") = "Information Services", "Information Services\Information Services.csproj", "" EndProject Project("") = "Reference Library", "Reference Library\Reference Library.csproj", "" EndProject Global GlobalSection(SolutionConfigurationPlatforms) = preSolution Debug|Any CPU = Debug|Any CPU Release|Any CPU = Release|Any CPU EndGlobalSection GlobalSection(ProjectConfigurationPlatforms) = postSolution .Debug|Any CPU.ActiveCfg = Debug|Any CPU .Debug|Any CPU.Build.0 = Debug|Any CPU .Release|Any CPU.ActiveCfg = Release|Any CPU .Release|Any CPU.Build.0 = Release|Any CPU .Debug|Any CPU.ActiveCfg = Debug|Any CPU .Debug|Any CPU.Build.0 = Debug|Any CPU .Release|Any CPU.ActiveCfg = Release|Any CPU .Release|Any CPU.Build.0 = Release|Any CPU .Debug|Any CPU.ActiveCfg = Debug|Any CPU .Debug|Any CPU.Build.0 = Debug|Any CPU .Release|Any CPU.ActiveCfg = Release|Any CPU .Release|Any CPU.Build.0 = Release|Any CPU EndGlobalSection GlobalSection(SolutionProperties) = preSolution HideSolutionNode = FALSE EndGlobalSection EndGlobal

В этом примере решение состоит из трех проектов (GettingStarted, Information Services и Reference Library), а раздел Global содержит настройки, которые применяются к решению. Например, само решение будет видимым в окне Solution Explorer, потому что настройка HideSolutionNode установлена равной FALSE. Если изменить ее на TRUE, имя решения не будет отображаться в системе Visual Studio.

Если решение состоит из проектов, которые не нацелены на использование платформы .NET Framework версии 4.0, решение можно открыть в системе Visual Studio 2008, выполнив небольшое редактирование файла .sln. Необходимо просто заменить две первые строки файла приведенными ниже, и решение откроется без ошибок.

Microsoft Visual Studio Solution File, Format Version 10.00 # Visual Studio 2008

Свойства решения

Для того чтобы открыть диалоговое окно Properties, необходимо щелкнуть правой кнопкой мыши на узле Solution в окне Solution Explorer и выбрать команду Properties. Это диалоговое окно содержит два узла: Common properties и Configuration properties, как показано на рисунке ниже:

Более подробно узлы Common properties и Configuration properties описываются в следующих разделах.

Узел Common Properties

Определяя проект Startup Project для приложения, пользователь имеет три возможности, которые являются практически очевидными. Выбор Current Selection запускает проект, который в данный момент находится в фокусе окна Solution Explorer. Вариант Single Startup гарантирует, что каждый раз будет запускаться один и тот же проект. Эта установка задается по умолчанию, поскольку большинство приложений имеют только один стартовый проект. Последний вариант, Multiple Startup Projects, позволяет запускать несколько проектов в определенном порядке. Это может быть полезным при работе с приложением клиент/сервер в рамках одного решения, причем требуется, чтобы и клиент, и сервер выполнялись одновременно. При выполнении нескольких проектов важно контролировать порядок их запуска. Для управления порядком запуска проектов можно использовать навигационные кнопки, расположенные после списка проектов.

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

В разделе Debug Source Files можно создать список каталогов, в которых система Visual Studio может искать исходные файлы при отладке. Этот список задается по умолчанию и просматривается перед открытием диалогового окна Find Source. Кроме того, пользователь может перечислить исходные файлы, которые система Visual Studio не должна искать. Если щелкнуть на кнопке Cancel в момент, когда система предлагает найти конкретный исходный файл, то он будет добавлен в этот список.

Раздел Code Analysis Settings доступен только в версии Visual Studio Team Suite. Это позволяет выбирать набор правил статического анализа кода, которые будут применяться к конкретному проекту. Более подробно раздел Code Analysis обсуждается далее.

Узел Configuration Properties

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

Например, может быть создана новая конфигурация решения Test, состоящая из двух проектов: MyClassLibrary и MyClassLibraryTest. Когда пользователь создает свое приложение в конфигурации Test, он хочет, чтобы проект MyClassLibrary был собран в режиме Release, чтобы тестировать его в виде, максимально приближенном к окончательной версии. Однако, чтобы проверить тестируемый код, необходимо собрать тестовый проект в режиме Debug.

Когда пользователь собирает проект в режиме Release, он не хочет, чтобы решение Test было собрано или развернуто вместе с приложением. В данном случае в конфигурации решения Test можно указать, что пользователь хочет, чтобы проект MyClassLibrary был собран в режиме Release, а проект MyClassLibraryTest вообще не собирался.

Пользователь может легко переключаться между этими конфигурациями с помощью меню Configuration стандартной инструментальной панели. Однако, переключаться между платформами не так легко, потому что меню Platform нет ни в одной инструментальной панели. Для того чтобы сделать ее доступной, необходимо выбрать команду View —> Toolbars —> Customize. Затем элемент Solution Platforms из категории Build на закладке Command можно перетащить на инструментальную панель.

Следует отметить, что, выбрав узел Configuration Properties в диалоговом окне Solution Properties, как показано на рисунке ниже, можно получить доступ к раскрывающимся спискам Configuration и Platform. Раскрывающийся список Configuration содержит все доступные конфигурации решения: Debug и Release (заданные по умолчанию), Active и All Configurations. Аналогично в раскрывающемся списке Platform перечислены все доступные платформы. Как только пользователь получит доступ к этим раскрывающимся спискам, он может на этой же странице задать настройки для каждой конфигурации и/или платформы. Для того чтобы добавить новые конфигурации и/или платформы для решения, пользователь может также использовать кнопку Configuration Manager.

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

Возможности, доступные для создания новых платформенных конфигураций, ограничены типами доступных центральных процессоров: Itanium, x86 и x64. Новая платформенная конфигурация также может основываться на существующих платформенных конфигурациях, и существует возможность создания платформенной конфигурации для проекта.

В конфигурационном файле решения можно также задать тип центрального процессора, для которого оно собирается. Это особенно удобно, если нужно развернуть приложение для компьютеров с 64-битовой архитектурой. Установить настройки для всех этих решений можно непосредственно в контекстном меню, которое открывается после щелчка правой кнопкой мыши на узле Solution node в окне Solution Explorer. В то время как команда Set Startup Projects открывает окно конфигурации решения, команды Configuration Manager, Project Dependencies и Project Build Order открывают окно Configuration Manager and Project Dependencies. Команды Project Dependencies и Project Build Order отображаются в окне, только если решение состоит из нескольких проектов.

Команда Project Build Order открывает окно Project Dependencies и перечисляет порядок сборки, как показано на рисунке ниже:

Закладка Build Order демонстрирует порядок, в котором должны собираться проекты в соответствии с зависимостями между ними. Это может оказаться полезным, если пользователь поддерживает ссылки на бинарные сборки проектов, а не ссылки на проекты. Кроме того, эту возможность можно использовать для двойной проверки того, что проекты будут собраны в правильном порядке.

Как создать решение в visual studio

Скачай курс
в приложении

Перейти в приложение
Открыть мобильную версию сайта

© 2013 — 2023. Stepik

Наши условия использования и конфиденциальности

Public user contributions licensed under cc-wiki license with attribution required

Создание общего решения Visual Studio (.sln файл) из нескольких отдельных проектов: One Solution to Rule Them All

Для тестирования нашего C/C++ анализатора PVS-Studio мы часто проверяем различные проекты с открытым исходным кодом и публикуем отчёты о найденных в них ошибках. И, конечно, очевидно, что для этого нам интересны проекты с большими объёмами исходного кода (сотни тысяч строк), ведь в нескольких десятках файлов ничего особенно не потестировать. Уже несколько раз нам попадались большие наборы, состоящие из сотен небольших открытых проектов. Примером таких коллекций проектов могут служить, например, наборы тестовых примеров для различных SDK и Framework’ов. Нам такие коллекции проектов особенно интересно проверять для тестирования поддержки анализатором различных специфичных конструкций кода, подтипов Visual C++ проектов и т.п.

Но у такого типа проектов существует не очевидный на первый взгляд недостаток — отсутствие единого проектного файла – решения. Зачастую, каждый проект в таких наборах независим и имеет совой solution. Понятно, что проверка 4-5 сотен sln файлов — не самое увлекательное занятие, причём работать с полученными таким путём сотнями отчётов будет весьма затруднительно.

Логика подсказывает, что для всех проектных файлов можно создать и один независимый sln файл — One Solution to Rule Them All, объединяющий все требуемые проекты. Но оказалось, что такая простая задача является нетривиальной для Visual Studio, ведь диалог добавления проекта позволяет выбирать только один проект за раз! Так что, даже если вам очень повезёт, и все проекты будут лежать в одной директории, процесс их добавления всё равно окажется мучительным.

И тут же поверхностный поиск показал, что не мы одни столкнулись с подобной проблемой. Но что обычно предлагают в таком случае? Сгенерировать «вручную» новый solution, и, открыв его как текстовый файл, добавить необходимые строки для каждого проекта. Что же скрывает за собой подобный метод? Ведь помимо необходимости вычитывать из каждого проекта его идентификаторы и конфигурации, не дай бог возникнет конфликт между зависимостями или теми же GUID’ами у хотя бы 2-х проектов. Ведь тогда придётся вручную обходить весь такой solution, чтобы определить проблему! В итоге же писать такую программу, которая должна будет всё это учитывать, но скорее всего, понадобится лишь пару раз, становится весьма обременительно.

Но ведь вся эта функциональность уже присутствует в самой Visual Studio — этот как раз тот самый Add Existing Project. Если бы была только возможность автоматизировать вызов данной команды и получение списка требуемых файлов. Но такая возможность существует, приём она может быть описана всего 4 строками кода:

EnvDTE.DTE dte = Package.GetService(typeof(EnvDTE._DTE)) as EnvDTE.DTE; m_dte = (EnvDTE80.DTE2)dte; foreach (string file in Directory.GetFiles(ProjectRoot, "*.vcxproj", SearchOption.AllDirectories)) m_dte.Solution.AddFromFile(file, false);

Мы видим, что объект типа EnvDTE80.DTE2 позволяет программное добавить в текущее решение проект по имени файла. А ведь это как раз то, чего мы хотим! Причём метод AddFromFile также позволяет контролировать и добавляемые проекты, возвращая ссылку на каждый из них. А обертка этого кода в try. catch блок позволит отсечь все возможные конфликты между отдельными проектами.

Что же такое EnvDTE80.DTE2 и как его получить? Объект DTE (development environment) — это верхний объект API расширения среды Visual Studio, позволяющего автоматизировать работу с IDE и даже расширять возможности. Получить доступ к DTE можно несколькими разными способами, причём как из стороннего внешнего процесса, так и создав плагин-расширение (extension package) или подключаемый модуль для среды Visual Studio. А на нашем сайте есть цикл статей, посвящённый основам разработки подобных модулей расширения, в котором вы можете найти простые инструкции по созданию такого модуля прямо сейчас!

Разработка структуры решения моделирования

Область применения:Visual Studio Visual Studio для Mac Visual Studio Code

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

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

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

Сведения о том, какие версии Visual Studio поддерживают каждый инструмент и функцию моделирования, см. в статье «Поддержка версий» для средств архитектуры и моделирования.

Структура решения

В среднем или крупном проекте структура команды соответствует структуре приложения. Каждая команда использует решение Visual Studio.

Разделение приложения на слои

1. Структура решений должна основываться на структуре приложения, например веб-приложения, приложения службы или классического приложения. В руководстве по архитектуре приложений в руководстве по архитектуре приложений рассматриваются различные распространенные архитектуры.
2. Создайте решение Visual Studio, которое будет называться решением «Архитектура». Это решение будет использоваться для создания общей структуры системы. Оно будет содержать только модели без кода. Добавьте схему зависимостей в это решение. На схеме зависимостей нарисуйте архитектуру, выбранную для приложения. Например, на схеме могут отображаться следующие слои и зависимости между ними: «Презентация», «Бизнес-логика» и «Данные».
3. Создайте отдельное решение Visual Studio для каждого слоя на схеме зависимостей архитектуры. Эти решения будут использоваться для разработки кода слоев.
4. Создайте модели, представляющие конструкции слоев и концепции, которые являются общими для всех слоев. Разместите модели таким образом, чтобы все модели были видны из решения «Архитектура», а с каждого слоя были видны соответствующие модели. Эту задачу можно выполнить, используя любую из описанных ниже процедур. В первом варианте для каждого слоя создается отдельный проект моделирования; во втором варианте создается один проект моделирования, совместно используемый в слоях.

Использование отдельного проекта моделирования для каждого слоя

1. Создайте проект моделирования в каждом решении слоя. Эта модель будет содержать схемы, описывающие требования и дизайн этого слоя. Он также может содержать схемы зависимостей, показывающие вложенные слои. Теперь имеются модели для каждого слоя и модель для архитектуры приложения. Каждая модель содержится в своем собственном решении. Это позволяет членам команды одновременно работать над слоями.
2. В решение «Архитектура» добавьте проект моделирования для каждого решения слоя. Для этого откройте решение «Архитектура». В Обозреватель решений щелкните правой кнопкой мыши узел решения, наведите указатель мыши на добавление и выберите пункт «Существующий проект«. Перейдите в проект моделирования (MODELPROJ) в решении для одного слоя. Каждая модель теперь видна в двух решениях: в своем «домашнем» решении и в решении «Архитектура».
3. В проект моделирования каждого слоя добавьте схему зависимостей. Начните с копии схемы зависимостей архитектуры. Можно удалить части, которые не зависят от схемы зависимостей. Можно также добавить схемы зависимостей, представляющие подробную структуру этого слоя. Эти схемы используются для проверки кода, разрабатываемого в данном слое.
4. В решении «Архитектура» отредактируйте требования и модели структуры для всех слоев с помощью Visual Studio. В решении каждого слоя разработайте код для этого слоя в соответствии с моделью. Если вы планируете выполнять разработку без использования одного и того же компьютера для обновления модели, можно прочитать модель и разработать код, используя версии Visual Studio, в которых нельзя создавать модели. В этих версиях можно также создать код на основе модели. Этот метод гарантирует отсутствие взаимных помех, вызванных одновременным редактированием моделей слоев разными разработчиками. Однако использование отдельных моделей затрудняет ссылки на общие концепции. Каждая модель должна иметь собственную копию элементов, через которые она зависит от других слоев и архитектуры. Схема зависимостей в каждом слое должна быть синхронизирована с схемой зависимостей архитектуры. Сложно поддерживать синхронизацию при изменении таких элементов, хотя для этой цели можно разработать специальные средства.

Использование отдельного пакета для каждого слоя

1. В решение для каждого слоя добавьте проект моделирования «Архитектура». В Обозреватель решений щелкните правой кнопкой мыши узел решения, наведите указатель мыши на добавление и выберите пункт «Существующий проект«. Теперь один проект моделирования доступен из каждого решения: из проекта «Архитектура» и из проекта разработки для каждого слоя.
2. В общей модели создайте пакет для каждого слоя: в Обозреватель решений выберите проект моделирования. В Обозреватель модели UML щелкните правой кнопкой мыши корневой узел модели, наведите указатель на добавление и нажмите кнопку «Пакет«. Каждый пакет будет содержать схемы, описывающие требования и проектирование соответствующего слоя.
3. При необходимости добавьте локальные схемы зависимостей для внутренней структуры каждого слоя. Этот метод позволяет элементам структуры каждого слоя ссылаться напрямую на те слои и общую архитектуру, от которых они зависят. Хотя одновременная работа над различными пакетами может приводить к некоторым конфликтам, ими достаточно просто управлять, так как пакеты хранятся в отдельных файлах.

Создание шаблонов архитектуры

На практике вы не создаете все решения Visual Studio одновременно, но добавляете их в процессе выполнения проекта. Скорее всего, в будущих проектах вы также будете использовать ту же структуру решения. Для упрощения быстрого создания новых решений можно создать шаблон решения или проекта. Шаблон можно перенаправить в расширение интеграции Visual Studio Integration Extension (VSIX), упрощающее распространение и установку на другие компьютеры.

Например, если часто используются решения со слоями «Представление», «Бизнес» и «Данные», можно настроить шаблон, который будет создавать решения с такой структурой.

Создание шаблона решения

1. Скачайте и установите мастер экспорта шаблонов.
2. Создайте структуру решения, которую требуется использовать в качестве отправной точки для будущих проектов.
3. В меню Файл выберите команду Export Template as VSIX(Экспорт шаблона как VSIX). Откроется шаблон экспорта в виде мастера VSIX.
4. Следуя инструкциям в мастере, выберите проекты, которые требуется включить в шаблон, укажите имя и описание шаблона, а также укажите расположение выходных файлов.

Связанный контент