Visual studio удалить конфигурацию

Обновлено: 04.07.2024

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

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

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

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

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

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

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

Папка 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-документом. Он хранит информацию в блоках, как показано в следующем примере:

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

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

Для того чтобы открыть диалоговое окно 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 демонстрирует порядок, в котором должны собираться проекты в соответствии с зависимостями между ними. Это может оказаться полезным, если пользователь поддерживает ссылки на бинарные сборки проектов, а не ссылки на проекты. Кроме того, эту возможность можно использовать для двойной проверки того, что проекты будут собраны в правильном порядке.

Итак, я попытался повторить всю процедуру. После удаления всех строк, в которых упоминается «Dev_WithSource» из файла sln, конфигурации проекта «Dev_WithSource» все еще отображаются в диспетчере конфигураций. Я просмотрел все файлы csproj и sln в своем решении. Ни один из них не содержит текста «Dev_WithSource».

После всего этого я попытался разработать надстройку. Я могу получить фантомные конфигурации с помощью project.ConfigurationManager.ConfigurationRowNames, но я также не могу их удалить. Я что-то пропустил? Эти конфигурации хранятся в каких-то других файлах, а не в csproj / sln?

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

Я знаю, что это старая ветка, но для меня это был ответ:

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

В появившемся диалоговом окне отметьте каждую нежелательную конфигурацию и выберите «Удалить».

Предположим, вы хотите удалить конфигурацию «Release» из всего решения и проектов. Итак, сначала вы переходите в Tools -> Диспетчер пакетов Nuget -> Диспетчер пакетов Консоль . На этой консоли используйте следующую команду, чтобы удалить сборку из всех проектов в решении:

Затем вы удалите его, как объяснил Майк Гримм .

Щелкните правой кнопкой мыши-> Выгрузите проект с конфигурациями, которые вы хотите удалить.
Щелкните правой кнопкой мыши-> Редактировать файл проекта xml напрямую.
Удалите группы свойств, содержащие условия, содержащие названия платформ / конфигураций, которые вы хотите удалить.
Сохраните и снова загрузите проект. Нежелательные конфигурации должны исчезнуть.
Если конфигурация кажется настроенной правильно, но OutPutPath по-прежнему «не установлен», попробуйте переместить его тег propertygroup вверх в xml.

Доступ к диспетчеру конфигурации можно получить одним из двух способов:

Из меню вверху: Build > Configuration Manager.
В раскрывающемся списке ваших конфигураций на главной панели инструментов выберите Configuration Manager.

В диалоговом окне диспетчера конфигурации в разделе Active solution configuration: выберите <Edit. > из раскрывающегося списка.

Откроется диалоговое окно со всеми конфигурациями вашего решения. Здесь вы можете выбрать и нажать кнопку Remove .

Я знаю, что немного опоздал, но вот полное решение. Чтобы полностью удалить конфигурацию из решения и свойства проекта, откройте файл .sln в любой среде IDE как обычный текст и удалите всю информацию о конфигурации. ПРИМЕЧАНИЕ. Не удаляйте значения GUID и конфигурации отладки / выпуска. Затем откройте файл .vcxproj в формате XML и удалите всю информацию о конфигурации. Сюда входят основные свойства для него, Platform Toolset и связанные элементы свойств на языке XML. ПРИМЕЧАНИЕ. Обязательно удалите закрывающие теги. когда вы вернетесь в визуальную студию, нажмите «Заменить все», и все готово.

В Visual Studio для MAC -

Дважды щелкните Решение> Конфигурации> Общие.
Щелкните «ConfigToRemove» в списке, затем «Удалить» (убедитесь, что вы отметили «Удалить также Конфигурации» в элементах решения), затем «Да».
Щелкните ОК, чтобы сохранить изменения.
Теперь щелкните правой кнопкой мыши «Решение» и «Инструменты»> «Изменить файл».
Перейдите в «GlobalSection (SolutionConfigurationPlatforms) = preSolution» и удалите все конфигурации, которые вам больше не нужны, в противном случае они все равно будут отображаться в сопоставлениях конфигурации, даже если в проекте нет сопоставлений!
Сохраните и готово.

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

Вам необходимо удалить конфигурацию из решения И из проекта. Из диспетчера конфигураций:

Итак, я попытался повторить всю процедуру. После удаления всех строк, упоминающих "Dev_WithSource" из файла sln, конфигурации проекта "Dev_WithSource" все еще отображаются в configuration manager. Я искал все файлы csproj и sln в своем решении. Ни один из них не содержит текста "Dev_WithSource".

После всего этого я попробовал разработать надстройку. Я могу получить фантомные конфигурации с помощью project.ConfigurationManager.ConfigurationRowNames, но также не могу их удалить. Я что-то упустил? Хранятся ли эти конфигурации в каких-то других файлах, а не в csproj/sln?

У меня есть решение Visual Studio 2010 C++ с двумя проектами: исполняемым файлом и библиотекой. Я успешно могу удалить конфигурации проекта из Configuration Manager для одного из проектов (исполняемый файл), но не для другого (библиотека). Оба проекта ранее были частью решения vs2008, которое с.

Доступ к менеджеру конфигурации можно получить одним из двух способов:

Из меню вверху: Build > Configuration Manager.
В раскрывающемся списке ваших конфигураций на главной панели инструментов выберите Configuration Manager.

В диалоговом окне Configuration manager в разделе Active solution configuration: выберите <Edit. > из раскрывающегося списка.

Откроется диалоговое окно, в котором будут показаны все конфигурации для вашего решения. Здесь вы можете выбрать и нажать кнопку Remove .

Щелкните правой кнопкой мыши->Выгрузите проект с конфигурациями, которые вы хотите удалить.
Щелкните правой кнопкой мыши->Непосредственно редактировать файл проекта xml.
Удалите группы свойств, содержащие условия, содержащие имена платформ/конфигураций, которые вы хотите удалить.
Сохраните и снова загрузите проект. Нежелательные конфигурации должны быть удалены.
Если конфигурация кажется настроенной правильно, но OutPutPath все еще "не настроена", попробуйте переместить ее тег propertygroup в xml.

Предположим, вы хотите удалить конфигурацию "Release" из всего решения и проектов. Итак, сначала вы переходите к Инструментам -> Nuget Диспетчер пакетов -> Консоль диспетчера пакетов . Из этой консоли используйте следующую команду, чтобы удалить сборку из всех проектов в решении :

Затем вы удаляете его с помощью решения, как объяснил Майк Гримм .

У меня есть проект Windows Mobile / Pocket PC в Visual Studio 2008 SP1. Я попытался удалить старую конфигурацию сборки ReleaseCN3 из решения с помощью Диспетчера конфигурации. Я запускаю Configuration Manager, нажимаю Edit, затем выделяю конфигурацию ReleaseCN3 и нажимаю Remove. Конфигурация будет.

Я знаю, что это старая тема, но это был ответ для меня:

В Диспетчере конфигураций выберите "Edit. " в столбце "Configuration" для каждого проекта (не через раскрывающийся список с именем Конфигурация активного решения), у которого есть конфигурации, которые вы хотите удалить.

В появившемся диалоговом окне отметьте каждую нежелательную конфигурацию и выберите "Remove".

Я решил эту проблему с помощью утилиты, которая анализирует файлы csproj и вставляет необходимые блоки propertygroup в файлы csproj. Старые конфигурации проекта все еще появляются в диспетчере конфигураций, но я отказался от попыток удалить их.

Вам нужно удалить конфигурацию из решения AND проекта. Из диспетчера конфигурации:

Конфигурация активного решения > правка > удалить
Контексты проекта > конфигурация > правка > удалить

В Visual Studio за MAC -

Похожие вопросы:

Как удалить тип проекта из Visual Studio? Я создал один и установил его с файлом VSIX, но я хочу изменить его, и новый файл VSIX говорит, что я не могу установить новый, потому что старый.

Я видел, что это очень распространенная вещь-использовать макрос Visual Studio под названием $(Configuration) для построения путей к файлам. Например, если вы создадите новый проект Visual C++ в.

Как удалить конфигурации проекта в пакетной сборке? Я создал новую конфигурацию Test и использовал опцию пакетной сборки Visual Studio для создания различных конфигурационных пар конфигурация /.

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

Я хочу создать проекты C++ с Visual Studio (2005/8/10), которые имеют больше конфигураций, отличных от стандартных Debug и Release. Например, я мог бы дополнительно сгенерировать Debug DLL и Release.

Не удается создать папку внутри общего проекта в Visual Studio 2017. На месте контекстного меню я вижу только новый фильтр Возможно ли вообще - создать папку в этом типе проекта ? Обновление 1: -.

Возможно ли в проекте установщика условно выполнить Пользовательское действие, основанное на конфигурации сборки проекта (например, отладка, выпуск и т. д.)? Также включать / исключать файлы на.

Любой проект в 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 предоставляет удобные и гибкие механизмы настройки свойств конфигураций проектов, что позволяет программистам выполнять компиляцию и сборку своих проектов с актуальным набором настроек.

Читайте также: