Visual studio настройка конфигурации
Любой проект в Visual Studio 2010 включает несколько самостоятельных конфигураций для компиляции разных версий программы. Конфигурацией называется набор параметром компилятора, компоновщика и библиотекаря, используемый при построении проекта. По умолчанию, при создании проекта, среда Visual Studio 2010 автоматически включает в него две конфигурации: Debug (отладочная) и Release (финальная). Как следует из их названий, отладочная конфигурация используется в процессе написания программы, ее тестовых запусков для обнаружения и исправления ошибок; в то время как финальная конфигурация используется для построения конечной версии продукта, передаваемого заказчику для промышленного использования.
При создании проекта настройки отладочной ( Debug ) и финальной ( Release ) конфигураций устанавливаются в значения по умолчанию. С этими настройками выполняются следующие действия:
- Debug (отладочная) конфигурация проекта компилируется с включением полной символьной отладочной информации и выключенной оптимизацией. Оптимизация кода затрудняет процесс отладки, так как усложняет или даже полностью изменяет отношение между строками исходного кода программы и сгенерированными машинными инструкциями. Такая отладочная информация используется отладчиком Visual Studio 2010 для отображения значений переменных, определения текущей выполняемой строки программы, отображения стека вызовов и так далее, то есть для поддержки стандартных действий, выполняемых при отладке программы.
- Release (финальная) конфигурация проекта не содержит никакой отладочной информации и подвергается полной оптимизации. Без отладочной информации процесс отладки программы очень затруднен. Однако, при необходимости, отладочная информация может быть создана и для финальной версии программы и записана в отдельный файл с расширением .pdb. Файлы отладочной информации .pdb могут оказаться очень полезными, если позднее возникнет необходимость в отладке финальной версии программы, например, при обнаружении критических ошибок в процессе ее эксплуатации на компьютерах заказчика. Файлы .pdb обычно заказчику не передаются, а сохраняются у разработчиков.
Переключение между конфигурациями можно осуществлять из панели инструментов или при помощи окна Configuration Manager ( менеджер конфигураций).
Для быстрого переключения конфигурации, используемой для компиляции проекта, используется стандартная панель инструментов (рис. 24.1).
Рис. 24.1. Переключение конфигураций из панели инструментов
Программист может в любой момент изменить настройки конфигурации проекта или, при необходимости, создать новую конфигурацию. Эти действия выполняются в окне свойств проекта. Настройки свойств проекта применяются к текущей выбранной конфигурации. Можно указать одну из созданных конфигураций проекта, или выбрать All configurations, в этом случае настройки будут применены ко всем конфигурациям одновременно. Рассмотрим основные отличия в настройках проекта для отладочной и финальной конфигураций. На рис. 24.2 изображено окно свойств проекта со страницей настроек оптимизации ( Optimization ) для отладочной конфигурации проекта. Видно, что для отладочной конфигурации оптимизация генерируемого машинного кода выключена (Disabled).
Для финальной версии проекта по умолчанию включена оптимизация по скорости выполнения программы (Optimize Speed ). На рис. 24.3 показана страница с выбранными настройками финальной конфигурации.
Кроме того, можно также выбрать следующие параметры оптимизации – генерировать максимально компактный код ( Minimize Size ) и полная оптимизация ( Full Optimization ), которая включает максимальные настройки оптимизации. На рис. 24.4 показан список свойств закладки Optimization .
На странице свойств генерации кода ( Code Generation ) можно указать версию стандартной библиотеки языка C, которая будет использована при компиляции и компоновке проекта – настройка Runtime Library . Для отладочной конфигурации по умолчанию используется настройка Multithreaded Debug DLL (многопоточная отладочная версия стандартной библиотеки, размещенной в динамически загружаемом модуле DLL ). Эта версия библиотеки содержит отладочную информацию. Она также поддерживает дополнительные проверки времени выполнения, что позволяет, с одной стороны выполнять функции стандартной библиотеки под управлением отладчика, а с другой стороны – обнаруживать на раннем этапе трудно обнаруживаемые проблемы, такие как выход за границы массивов, неправильную работу с динамически распределяемой памятью и некоторые другие. Из-за наличия этих дополнительных проверок отладочная версия библиотеки выполняется медленнее финальной.
Для финальной версии проекта по умолчанию используется настройка Multithreaded DLL (финальная версия стандартной библиотеки без отладочной информации, размещенной в динамически загружаемом модуле DLL ). Важным моментом является то, что для запуска финальной версии программы при компиляции ее с такими настройками, модуль DLL стандартной библиотеки должен присутствовать в системе. Он устанавливается либо при установки Visual Studio 2010, либо при помощи отдельного инсталляционного пакета Microsoft Visual C++ 2010 Redistributable Package ( x86 ). Если же библиотека DLL в системе не установлена, то скомпилированная программа не будет запущена.
Для исключения зависимости от отдельной DLL стандартной библиотеки значение настройки Runtime Library нужно установить в Multithreaded (многопоточная версия стандартной библиотеки). В этом случае весь необходимый функционал будет включен непосредственно в результирующий .exe файл , который может быть запущен и исполнен независимо от того, были ли установлены файлы DLL стандартной библиотеки или нет.
На рис. 24.5 показана страница свойств закладки Code Generation для отладочной конфигурации.
На рис. 24.6 показана страница свойств закладки Code Generation для финальной конфигурации.
Отладочная и финальная версия программы компилируются также с различными символами препроцессора . Для отладочной версии объявляется символ препроцессора _DEBUG , а для финальной версии – символ NDEBUG . Это позволяет использовать директивы препроцессора для условной компиляции программы, включая или исключая некоторую функциональность в отладочную или финальную версию программы. Обычно это используется для включения дополнительных проверок и отладочного вывода в отладочную версию программы. Для финальной версии такие проверки и вывод не нужны, поэтому они в нее не включаются. Например, в следующем фрагменте программы значение переменной res будет выведено на экран только в отладочной версии:
На рис. 24.7 представлена страница свойств Preprocessor для отладочной конфигурации. На рис. 24.8 представлена страница свойств Preprocessor для финальной конфигурации.
В отладочной и финальной версиях также различаются форматы отладочной информации ( Debug Information Format ), генерируемой компилятором и сохраняемой в .pdb файле.
Для отладочной версии используется Program Database for Edit and Continue , позволяющая отлаживать и даже изменять программу, если сработала точка останова . При возобновлении выполнения программы, внесенные изменения будут автоматически применены, и выполнение продолжится уже с внесенными изменениями. Эта возможность позволяет сократить время, необходимое на остановку и перекомпиляцию программы при нахождении и исправлении ошибок. В тоже время такая настройка несовместима с настройками оптимизации, поэтому может быть использована только в отладочной версии. На рис. 24.9 показана страница свойств General для отладочной конфигурации.
В финальной версии используется настройка Program Database . Она включает генерацию .pdb файла, который может быть использован при необходимости поиска ошибок в финальной версии продукта. Эта настройка никак не влияет на оптимизацию генерируемого кода, поэтому она может быть использована для финальной версии.
На рис. 24.10 показана страница свойств General для финальной конфигурации.
На странице свойств Debugging ( отладка ) узла Linker настройка Generate Debug Info (генерировать отладочную информацию) управляет генерацией отладочной информации. Настройка Generate Program Database File (создавать файл с отладочной информаций для программы) задает имя результирующего .pdb файла с отладочной информацией.
На рис. 24.11 показана страница свойств Debugging узла Linker для отладочной версии.
MS Visual Studio 2010 предоставляет удобные и гибкие механизмы настройки свойств конфигураций проектов, что позволяет программистам выполнять компиляцию и сборку своих проектов с актуальным набором настроек.
Конфигурации сборок требуются для создания проектов с разными параметрами. Например, Debug и Release — это конфигурации, и при их создании используются разные параметры компилятора. Одна конфигурация является активной и отображается на панели команд в верхней части интегрированной среды разработки.
Этот раздел относится к Visual Studio в Windows. Информацию о Visual Studio для Mac см. в статье Конфигурации сборки в Visual Studio для Mac.
Параметры "Конфигурация" и "Платформа" позволяют определить, где будут храниться выходные файлы сборки. Как правило, когда в Visual Studio выполняется сборка проекта, выходные данные помещаются во вложенную папку проекта с именем активной конфигурации (например, bin/debug/x86). Но это можно изменить.
Вы можете создавать свои конфигурации сборки на уровне решения и проекта. Конфигурация решения определяет, какие проекты включаются в сборку, когда эта конфигурация активна. В сборку будут включены только проекты, указанные в активной конфигурации решения. Если в Configuration Manager выбрано несколько целевых платформ, будут построены все проекты, которые применяются к этой платформе. Конфигурация проекта определяет, какие параметры сборки и компилятора используются при сборке проекта.
Чтобы создать, выбрать, изменить или удалить конфигурацию, можно использовать Configuration Manager. Чтобы открыть его, выберите в строке меню Сборка > Configuration Manager или просто введите Configuration в поле поиска. Можно также использовать список Конфигурации решения на панели инструментов Стандартные, чтобы выбрать конфигурацию или открыть Configuration Manager.
Если вы не можете найти параметры конфигурации решения на панели инструментов и не можете получить доступ к Configuration Manager, можно применить параметры развертывания Visual Basic. Дополнительные сведения см. в разделе Практическое руководство. Управление конфигурациями с применением параметров разработчика Visual Basic.
По умолчанию конфигурации Debug и Release включены в проекты, которые создаются с использованием шаблонов Visual Studio. Конфигурация Debug поддерживает отладку приложения, а конфигурация Release создает версию приложения, которое можно развернуть. Дополнительные сведения см. в разделе Практическое руководство. Настройка конфигураций отладки и выпуска. Можно также создать пользовательские конфигурации решений и проектов. Дополнительные сведения см. в разделе Практическое руководство. создавать и изменять конфигурации.
Конфигурации решения
Конфигурация решения указывает, как следует создавать и развертывать проекты в решении. Чтобы изменить конфигурацию решения или определить новую конфигурацию в Configuration Manager, в меню Активная конфигурация решения щелкните Изменить или Создать.
Каждая запись в поле Контексты проекта в конфигурации решений представляет проект в решении. Для каждой комбинации Активная конфигурация решения и Активная платформа решения можно задать способ использования каждого проекта. (Дополнительные сведения о платформах решений см. в разделе Общие сведения о сборках платформ.)
При определении новой конфигурации решения и установке флажка Создать новые конфигурации проектовVisual Studio автоматически назначает новую конфигурацию всем проектам. Аналогичным образом, при определении новой платформы решения и установке флажка Создать новые платформы проектовVisual Studio автоматически назначает новую платформу всем проектам. Кроме того, если вы добавите проект, предназначенный для новой платформы, Visual Studio добавит эту платформу в список платформ решений и назначит ее всем проектам. Вы по-прежнему можете изменять параметры для каждого проекта.
Активная конфигурация решения также предоставляет контекст для IDE. Например, если вы работаете над проектом и конфигурация указывает, что он будет создан для мобильного устройства, на панели инструментов отобразятся только элементы, которые можно использовать в проекте мобильного устройства.
Конфигурации проекта
Параметры сборки и компилятора, используемых при сборке проекта определяют конфигурация и целевая платформа. В проекте могут быть разные параметры для каждой комбинации конфигурации и платформы. Чтобы изменить свойства проекта, откройте контекстное меню проекта в обозревателе решений и щелкните Свойства. В верхней части вкладки Сборка конструктора проектов выберите активную конфигурацию, чтобы изменить параметры сборки.
Сборка нескольких конфигураций
При построении решения с помощью команды Сборка > Собрать решение, Visual Studio выполняет сборку только активной конфигурации. Все проекты, указанные в этой конфигурации решения, будут построены, и единственной конфигурацией проекта будет только одна из них, указанная в активной конфигурации решения и активной платформе решения, которая отображается на панели инструментов в Visual Studio. Например, Отладка и x86. Другие определенные конфигурации и платформы не создаются.
Если требуется создать несколько конфигураций и платформ в одном действии, можно использовать параметр Сборка > Пакетная сборка в Visual Studio. Для получения доступа к этой функции, нажмите Ctrl+Q, чтобы открыть поле поиска, и введите Batch build . Пакетная сборка доступна не для всех типов проектов. См. практическое руководство по сборке с использованием нескольких конфигураций.
Назначение конфигураций проектов Visual Studio
Если вы определяете конфигурацию нового решения и не копируете параметры из существующего, Visual Studio использует следующие критерии для назначения конфигурации проектов по умолчанию. Критерии оцениваются в следующем порядке.
Если проект имеет имя конфигурации ( <configuration name> <platform name> ), которое точно совпадает с именем новой конфигурации решения, назначается эта конфигурация. В именах конфигураций не учитывается регистр.
Если проект имеет имя конфигурации, в котором часть имени конфигурации совпадает с новой конфигурацией решения, назначается эта конфигурация (независимо от того, совпадает ли часть имени платформы или нет).
Если совпадений все равно нет, назначается первая конфигурация, указанная в проекте.
Назначение конфигураций решений Visual Studio
При создании конфигурации проекта (в Configuration Manager путем выбора пункта Создать в раскрывающемся меню столбца Конфигурация для этого проекта) и установке флажка Создать новые конфигурации решений Visual Studio ищет конфигурацию решения с таким же именем, чтобы создать проект на каждой поддерживаемой платформе. В некоторых случаях Visual Studio переименовывает существующие конфигурации решения или определяет новые.
Visual Studio использует следующие критерии для назначения конфигураций решения.
Если конфигурация проекта не указывает платформу или указывает только одну платформу, будет найдена или добавлена конфигурация решения, имя которой совпадает с именем новой конфигурации проекта. Имя по умолчанию конфигурации решения не включает имя платформы; оно имеет формат <project configuration name> .
Если проект поддерживает несколько платформ, для каждой поддерживаемой платформы будет найдена или добавлена конфигурация решения. Имя каждой конфигурации решения включает как имя конфигурации проекта, так и имя платформы, и имеет формат <project configuration name> <platform name> .
Проекты Visual Studio имеют отдельные конфигурации выпуска и отладки для вашей программы. Производится построение отладочной версии для отладки и версии выпуска для окончательного выпуска программы.
Отладочная конфигурация программы компилируется с полной символической отладочной информацией и без оптимизации. Оптимизация усложняет отладку, поскольку усложняется связь между исходным кодом и сгенерированными инструкциями.
Конфигурация выпуска для программы полностью оптимизируется и не содержит символической отладочной информации. Для управляемого кода и кода C++ отладочная информация может быть создана в виде PDB-файлов в зависимости от используемых параметров компилятора. Создание PDB-файлов может оказаться полезным, если позднее возникнет необходимость в отладке версии выпуска.
Дополнительные сведения о конфигурациях сборки см. в статье Общие сведения о конфигурациях сборки.
Изменение конфигурации сборки
Для изменения конфигурации сборки сделайте следующее.
На панели инструментов выберите либо Отладка, либо Выпуск из списка Конфигурации решения.
Можно выбрать создание файлов символов (PDB) и отладочные данные, которые необходимо включить. Для большинства типов проектов компилятор создает файлы символов по умолчанию для отладочных и окончательных сборок, в то время как другие параметры по умолчанию отличаются по типу проекта и версии Visual Studio.
Отладчик загружает PDB-файл для исполняемого файла, только если он точно соответствует PDB-файлу, который был создан при сборке исполняемого файла (то есть это должен быть либо оригинальный PDB-файл, либо его копия). Дополнительные сведения см. в статье Почему Visual Studio требует, чтобы файлы символов отладчика точно соответствовали двоичным файлам, с которыми они были собраны?
Каждый тип проекта может иметь свой способ установки этих параметров.
Выберите проект в Обозревателе решений.
Выберите значок Свойства (или нажмите клавишу ALT+ВВОД).
В боковой области выберите Сборка (или Компилировать в Visual Basic).
В списке Конфигурация выберите Отладка или Выпуск.
В списке Сведения об отладке (или Создать сведения об отладке в Visual Basic) выберите Полные, Только для PDB или Переносимые.
Компилятор создает файлы символов в той же папке, что и исполняемый файл или основной выходной файл.
Создание файлов символов для проекта C++
Выберите проект в Обозревателе решений.
Выберите значок Свойства (или нажмите клавишу ALT+ВВОД).
В списке Конфигурация выберите Отладка или Выпуск.
В боковой области выберите Компоновщик > Отладка, а затем выберите параметры в разделе Создать сведения об отладке.
Дополнительные сведения о параметрах проекта для конфигурации отладки C++ см. в разделе Параметры проекта для конфигурации отладки C++.
Настройте параметры для раздела Создание файлов базы данных программы.
В большинстве проектов C++ значением по умолчанию является $(OutDir)$(TargetName).pdb , которое создает PDB-файлы в выходной папке.
Компилятор создает файлы символов в той же папке, что и исполняемый файл или основной выходной файл.
При создании нового проекта в Visual Studio по умолчанию вы получаете две конфигурации сборки: Debug и Release. И для большинства мелких проектов этого вполне достаточно. Но с ростом проекта может возникнуть потребность добавить дополнительные конфигурации. И хорошо, если нужно добавить одну-две новые конфигурации, а если их добрый десяток? А если при этом в солюшене находится штук 20 проектов, для каждого из которых эти конфигурации нужно настроить? В данном случае управлять параметрами сборки и модифицировать их становится достаточно сложно.
В этом посте будет рассмотрен способ, с помощью которого вы сможете немного упростить себе жизнь, существенно сократив описание конфигураций сборок.
Откройте csproj-файл одного из ваших проектов, вы найдёте в нём строчки такого вида:
Первая проблема, которая стоит перед нами, состоит в том, что эти строчки дублируются (или практически дублируются) во всех проектах. К счастью, csproj-файлы поддерживают импорт конфигураций, так что создадим в корне солюшена файл Configurations.targets следующего содержания:
После этого вы сможете заменить соответствующие строчки в исходном csproj-файле на
Отлично, теперь дублирование описаний конфигураций ушло, можно сосредоточиться на редактировании единственного файла. Можно заметить, что в Debug и Release конфигурациях некоторые строчки всё ещё дублируются. Предполагается, что разработчик захочет настроить все эти параметры индивидуально для каждой конфигурации. Если такой потребности нет, то можно вынести дублирующиеся строчки в общую PropertyGroup :
Можно ли ещё что-нибудь улучшить? Давайте подумаем. Глаз сразу цепляется за OutputPath , который можно «вычислить» из названия конфигурации. При наличии двух конфигураций можно оставить для каждой индивидуальную настройку, но вот если конфигураций будет очень много, то здорово было бы сделать так, чтобы OutputPath выводился из названия конфигурации. Тут нам на помощь приходит переменная $(Configuration) , с помощью которой это самое название можно узнать:
Замечательно, дублирование ушло. От чего ещё можно избавиться? Как правило, выставляемые свойства зависят только от конфигурации, изменение платформы ни на что не влияет. Давайте уберём лишнее условие:
Теперь добавим новых конфигураций. Положим, мы хотим ввести в наше приложение Demo-режим, в котором будут доступны не все функции. Demo-режим также может потребоваться отладить, поэтому разумно создать конфигурации DebugDemo и ReleaseDemo . А ещё, к примеру, мы хотим ввести режим сборки, при котором от пользователя будет требоваться лицензия. Demo-версию также может понадобится лицензировать, так что мы имеем ещё 4 конфигурации: DebugLicense , ReleaseLicense , DebugDemoLicense , ReleaseDemoLicense (данная ситуация приведена только для примера, в вашем проекте может быть всё иначе). Demo и License будут добавлять новые переменные в DefineConstatns . Казалось бы, для 8 конфигураций нужно сделать 8 отдельных PropertyGroup , но что-то внутри сознания сразу начинает протестовать. К счастью, в Condition можно разместить более сложное условие, нежели простое сравнение. В данном примере будем искать заданную подстроку в названии конфигурации:
Выглядит вполне неплохо. Но только образовалась проблема: Visual Studio теперь «не видит» список доступных конфигураций. Эту проблему можно решить, добавив пустых PropertyGroup c таким же Condition , как были вначале. При этом можно добавлять не все возможные конфигурации, а только те, которые вы реально будете использовать при работе. Например, мы не хотим отлаживать Demo и License конфигурации, тогда можно написать так:
Если у вас есть врождённая ненависть к дублированию чего угодно, то в получившийся файл можно также вынести дополнительные свойства, которые дублируются во всех проектах. Например так:
Теперь точно всё дублирование ушло, а настраивать конфигурации стало легко и просто. Хочется отметить, что совершенно не обязательно данный подход подойдёт именно вам, многие проекты отлично пишутся и без правки конфигураций. А иногда каждую конфигурацию для каждого проекта и каждой платформы приходится настраивать вручную — в этом случае не особо получится сэкономить на удалении дублирования. Но если всё-таки возникла проблема с настройкой большого количества конфигураций для большого количество проектов, то, возможно, этот способ вам пригодится. Также будет полезно почитать справочные сведения о сборке в MSDN:
Читайте также: