Как открыть свойства проекта visual studio

Свойства проекта: раздел Application в Visual Studio

Для того чтобы открыть свойства проекта, нужно щелкнуть правой кнопкой мыши на узле Project в окне Solution Explorer и выбрать команду Properties либо дважды щелкнуть на узле My Project (или Properties, если проект создается на языке C#), расположенном под узлом Project. В отличие от свойств решения свойства проекта отображаются не в модальном окне, а на дополнительной закладке, расположенной рядом с исходными файлами. Это сделано отчасти для того, чтобы было легче перемещаться между файлами программы и свойствами проекта, а отчасти для того, чтобы можно было одновременно открыть свойства нескольких проектов.

На рисунке ниже показаны настройки проекта, имеющего тип C# WPF. В этом разделе можно пройти по всем вертикальным закладкам редактора проекта как для проектов на языке Visual Basic, так и для проектов на языке C#.

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

Закладка Application, показанная на рисунке выше, позволяет разработчику вводить информацию о сборке, которая будет создана в ходе компиляции проекта. К этой информации относятся такие атрибуты, как тип вывода (т.е. Windows или Console Application, Class Library, Windows Service или Web Control Library), пиктограмма приложения и запускаемый объект. Закладка Application для приложений C# предоставляет также возможность выбрать целевую версию платформы .NET Framework.

Информация о сборке

Атрибуты, которые ранее задавались вручную в файле AssemblyInfo, содержащемся в проекте, теперь можно задать также с помощью кнопки Assembly Information. Это важная информация, поскольку она отображается в момент инсталляции приложения и при просмотре свойств файла в окне Windows Explorer. На рисунке ниже, слева, показана информация о сборке для простого приложения, а справа — свойства скомпилированного выполняемого файла, которые можно открыть в проводнике Windows:

Каждый из наборов свойств в диалоговом окне Assembly Information представляется атрибутом, который применяется ко всей сборке. Это значит, что из кода можно послать запрос к сборке и извлечь эту информацию. При работе с языком Visual Basic простой способ извлечения этой информации обеспечивает пространство имен My.Application.Info, а в языке C# — класс System.Reflection.Assembly.

Настройки User Account Control

Система Visual Studio 2013 поддерживает разработку приложений, работающих с компонентом User Account Control (UAC) под управлением операционных систем Windows Vista и выше. Этот процесс включает в себя генерирование манифестного файла сборки, представляющего собой XML-файл, уведомляющий операционную систему о запросах приложения на получение административных привилегий при запуске приложения. Для генерации учетной записи пользователя и добавления манифестного файла сборки в приложение пользователя используется кнопка View Windows Settings на закладке Application. В следующем коде продемонстрирован манифестный файл, сгенерированный по умолчанию системой Visual Studio.

Если значение запрошенного уровня исполнения, заданное по умолчанию, было изменено с asInvoker на requireAdministrator, то система Windows при запуске приложения выдаст приглашение UAC. Если запросы UAC допускаются и приложение, требующее прав администратора, запущено в режиме Debug, то система Visual Studio 2013 также выведет приглашение на повторный запуск с правами администратора. На рисунке ниже показано приглашение, свидетельствующее о том, что система Windows позволяет перезапустить среду Visual Studio с правами администратора:

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

Настройки программных компонентов Application Framework (только для языка Visual Basic)

В проектах типа Visual Basic Windows Forms можно задавать дополнительные настройки, поскольку они используют набор программных компонентов Application Framework, предназначенный исключительно для языка Visual Basic. Это позволяет расширить стандартную событийную модель и обеспечить ряд событий, происходящих с приложением, а также настройки, управляющие поведением этого приложения. Для того чтобы получить доступ к набору программных компонентов Application Framework, необходимо установить флажок Enable Application Framework. Имеются три флажка, управляющих поведением набора компонентов Application Framework:

Enable XP Visual Styles

Визуальные стили XP представляют собой свойство, которое значительно улучшает внешний вид и впечатление от приложения, выполняемого под управлением операционной системы Windows XP или систем Windows более поздних версий, поскольку они сглаживают углы используемых кнопок и элементов управления, динамически изменяющих цвет при прохождении над ними курсора мыши. В приложениях на языке Visual Basic стили XP доступны по умолчанию и могут быть отключены с помощью диалогового окна Project Settings. Кроме того, ими можно управлять из кода с помощью метода EnableVisual Styles в классе Application.

Make Single Instance Application

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

Save My.Settings on Shutdown

Выбрав команду Selecting the Save My.Settings on Shutdown, пользователь гарантирует, что любые изменения, внесенные в пользовательских настройках, будут сохранены до завершения выполнения приложения.

Раздел настройки программных компонентов Application Framework также позволяет выбрать режим аутентификации для приложения. По умолчанию он настроен на операционную систему Windows и текущего зарегистрированного пользователя. Выбрав команду Application-defined, пользователь может использовать свой собственный модуль аутентификации. Он может также идентифицировать форму, которую следует использовать в качестве заставки при первом запуске приложения, и задать поведение приложения по завершении его работы.

Настройки приложения C#: определение, пример

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

Что такое настройки приложения?

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

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

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

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

Создание настроек приложения

Настройки приложения можно настроить вручную в файле app.config. Однако гораздо проще выполнить эту настройку с помощью свойств проекта Visual Studio. Чтобы просмотреть параметры приложения, щелкните правой кнопкой мыши имя проекта в Обозревателе решений и выберите пункт Свойства в появившемся контекстном меню. В названиях разделов слева от окна свойств выберите Настройки.

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

Параметры приложения Visual Studio

Visual Studio позволяет создавать по одному параметру приложения на строку. Для каждой настройки требуется указать четыре значения:

• Имя. Столбец Имя используется для присвоения параметру уникального имени. Это имя станет именем свойства, которое будет использоваться для доступа к значению параметра.
• Тип. Все настройки приложения строго типизированы. Этот столбец используется для указания типа свойства настройки.
• Область. Доступны два параметра области, позволяющие указать, хотите ли вы создать настройку для всего приложения или для конкретного пользователя.
• Значение. Последний столбец используется для указания значения по умолчанию для параметра.

Примечание: После компиляции приложения файл app.config будет переименован в соответствии с именем сборки; в этом случае AppSettings.exe.config. Вы сможете отредактировать этот текстовый файл, чтобы изменить настройки без перекомпиляции.

Чтение настроек приложения

Создание файла настроек приложения по умолчанию добавляет новое пространство имен с именем «Свойства» в пространство имен проекта по умолчанию. Внутри нового пространства имен находится класс, предоставляющий доступ к новым свойствам. Чтобы продемонстрировать, вернитесь в редактор кода для класса, содержащего основной метод программы. Чтобы упростить доступ к новому пространству имен, добавьте следующую директиву using в начало кода:

Теперь мы можем вывести содержимое параметра приложения, обратившись к свойству класса, созданного Visual Studio. Чтобы вывести текст на консоль, добавьте следующий код в метод Main:

Запустите программу, чтобы увидеть значение параметра приложения, выведенное на консоль. Вы также можете попробовать выполнить скомпилированный исполняемый файл и изменить значение в файле AppSettings.exe.config. Это покажет, что значение можно изменить без перекомпиляции.

Создание пользовательских yастроек

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

Значения для всего приложения не могут быть изменены во время выполнения. Однако пользовательские настройки могут быть изменены во время выполнения для отдельного пользователя. Чтобы изменить набор тестов на пользовательский, вернитесь к свойствам проекта и измените значение области для параметра на «Пользователь». Теперь код будет скомпилирован, но изменения в настройках будут существовать только до тех пор, пока приложение не прекратит выполнение. Для сохранения пользовательских настроек между сеансами необходимо использовать метод Сохранения. Чтобы попробовать это, добавьте следующую строку в конец основного метода:

Попробуйте выполнить скомпилированную исполняемую версию программы несколько раз, каждый раз вводя новую строку для параметра. Вы должны увидеть, что введенное значение сохраняется между запусками программного обеспечения. Однако, если вы просмотрите файл AppSettings.exe.config в папке исполняемого файла, вы увидите, что настройки не изменяются. Этот файл продолжает содержать значения по умолчанию для каждого настраиваемого элемента, гарантируя, что новые пользователи программы не унаследуют изменения, внесенные другими пользователями. Пользовательские значения хранятся в новом файле в папке пользователя. Точный путь к папке определяется операционной системой.

Сброс пользовательских настроек

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

Автор этого материала — я — Пахолков Юрий. Я оказываю услуги по написанию программ на языках Java, C++, C# (а также консультирую по ним) и созданию сайтов. Работаю с сайтами на CMS OpenCart, WordPress, ModX и самописными. Кроме этого, работаю напрямую с JavaScript, PHP, CSS, HTML — то есть могу доработать ваш сайт или помочь с веб-программированием. Пишите сюда.

заметки, си шарп, настройки, Visual Studio, .NET

Настраиваем удобную сборку проектов в Visual Studio

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

В качестве примера попробуем сделать так чтобы в Студию можно было добавлять flatbuffer schema, а Студия автоматически вызывала flatc в тех случаях когда это нужно (и не вызывала — когда изменений не было) и позволяла задавать настройки напрямую через File Properties

Оглавление

ЗАМЕЧАНИЕ: все приведенные в статье примеры проверялись в VS 2017. В рамках моего понимания они должны работать и в более ранних версиях студии начиная по крайней мере с VS 2012, но обещать я этого не могу.

Level 1: лезем внутрь .vcxproj файлов

Давайте взглянем внутрь типичного .vcxproj автоматически сгенеренного Visual Studio.

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

Поговорим о .props файлах

Для этого обратим пока внимание на то что взятый нами файл — это обычный XML-документ и его можно логически разделить на две части, в первой из которых перечисляются настройки проекта, а во второй — входящие в него файлы. Давайте эти половинки разделим физически. Для этого нам понадобится уже встречающийся в коде тэг Import который является аналогом сишного #include и позволяет включить один файл в другой. Скопируем наш .vcxproj в какой-нибудь другой файл и уберем из него все объявления относящиеся к файлам входящим в проект, а из .vcxproj-а в свою очередь наоборот уберем все кроме объявлений относящихся к файлам собственно входящим в проект. Получившийся у нас файл с настройками проекта но без файлов в Visual Studio принято называть Property Sheets и сохранять с расширением .props. В свою очередь в .vcxproj мы поставим соответствующий Import

Его можно упростить еще больше, убрав лишние XML-элементы. К примеру свойство «PrecompiledHeader» объявляется сейчас 4 раза для разных вариантов конфигурации (release / debug) и платформы (win32 / x64) но каждый раз это объявление одно и то же. Кроме того у нас здесь используется несколько разных ItemGroup тогда как в реальности вполне достаточно одного элемента. В результате приходим к компактному и понятному .vcxproj который просто перечисляет 1) входящие в проект файлы, 2) то чем является каждый из них (плюс настройки специфичные для конкретных отдельных файлов) и 3) содержит в себе ссылку на хранящиеся отдельно настройки проекта.

Перезагружаем проект в студии, проверяем сборку — все работает.

Но зачем вообще разделять .vcxproj и .props?

Поскольку в сборке ничего не поменялось, то на первый взгляд может показаться что мы поменяли шило на мыло, сделав бессмысленный «рефакторинг» файла в который нам до этого собственно и не было никакой нужды заглядывать. Однако допустим на минутку что в наш solution входит более одного проекта. Тогда, как несложно заметить, несколько разных .vcxproj-файлов от разных проектов могут использовать один и тот же .props файл с настройками. Мы отделили правила сборки используемые в solution от исходного кода и можем теперь менять настройки сборки для всех однотипных проектов в одном месте. В подавляющем большинстве случаев подобная унификация сборки — это хорошая идея. К примеру добавляя в solution новый проект мы в одно действие тривиально перенесем в него подобным образом все настройки из уже существующих в solution проектов.

Но что если нам все же нужны разные настройки для разных проектов? В этом случае мы можем просто создать несколько разных .props-файлов для разных типов проектов. Поскольку .props-файлы могут совершенно аналогичным образом Import-ить другие .props-файлы, то довольно легко и естественно можно выстроить «иерархию» из нескольких .props-файлов, от файлов описывающих общие настройки для всех проектов в solution до узкоспециализированных версий задающих специальные правила для всего одного-двух проектов в solution. В MSBuild действует правило что если одна и та же настройка объявляется во входном файле дважды (скажем вначале импортится в base.props а затем объявляется повторно в derived.props который import-ит в своем начале base.props) то более позднее объявление перекрывает более раннее. Это позволяет легко и удобно задавать произвольные иерархии настроек просто перекрывая в каждом .props файле все необходимые для данного .props-а настройки не заботясь о том что они могли быть где-то уже объявлены ранее. В числе прочего где-нибудь в .props-ах разумно импортировать стандартные настройки окружения Студии которые для C++-проекта будут выгледеть вот так:

Отмечу что на практике весьма удобно класть собственные .props файлы в ту же папку что и .sln файл

Делаем настройку проекта читабельнее

Теперь когда нам больше не требуется возиться с каждым проектом по отдельности мы можем уделить больше внимания настройке процесса сборки. И для начала я рекомендую дать с помощью .props-файлов вменяемые имена большинству интересных объектов в файловой системе относящихся к solution. Для этого нам следует создать тэг PropertyGroup с пометкой UserMacros:

Тогда в настройках проектов вместо конструкций вида «..\..\..\ThirdParty\protobuf\src\protoc.exe» мы сможем написать просто «$(ProtoBufRoot)\protoc.exe». Помимо большей читабельности это делает код намного мобильнее — мы можем свободно перемещать .vcxproj не боясь что у него слетят настройки и можем перемещать (или обновлять) Protobuf изменив всего одну строчку в одном из .props файлов.

При последовательном объявлении нескольких PropertyGroups их содержимое будет объединено — перезапишутся только макросы имена которых совпадают с ранее объявлявшимися. Это позволяет легко дополнять объявления во вложенных .props файлах не боясь потерять макросы уже объявленные ранее.

Делаем удобным подключение сторонних библиотек

Обычный процесс включения зависимости от thirdparty-библиотеки в Visual Studio частенько выглядит примерно вот так:

Процесс соответствующей настройки включает в себя редактирование сразу нескольких параметров находящихся на разных вкладках настроек проекта и потому довольно зануден. Вдобавок его обычно приходится проделывать по нескольку раз для каждой отдельно взятой конфигурации в проекте, так что нередко в результате подобных манипуляций оказывается что проект в Release-сборке собирается, а в Debug-сборке — нет. Так что это неудобный и ненадежный подход. Но как Вы наверное уже догадываетесь, те же самые настройки можно «упаковать» в props-файл. К примеру для библиотеки ZeroMQ подобный файл может выглядеть примерно так:

Обратите внимание что если мы просто определим тэг типа AdditionalLibraryDirectories в props-файле, то он перекроет все более ранние определения. Поэтому здесь используется чуть более сложная конструкция в которой тэг завершается последовательностью символов ;%(AdditionalLibraryDirectories) образующих ссылку тэга самого на себя. В семантике MSBuild этот макрос раскрывается в предыдущее значение тэга, так что подобная конструкция дописывает параметры в начало строки хранящейся в парамере AdditionalLibraryDirectories.

Для подключения ZeroMQ теперь достаточно просто импортировать данный .props файл.

И на этом манипуляции с проектом заканчиваются — MSBuild автоматически подключит необходимые заголовочные файлы и библиотеки и в Release и в Debug сборках. Таким образом потратив немного времени на написание zeromq.props мы получаем возможность надежно и безошибочно подключать ZeroMQ к любому проекту всего в одну строчку. Создатели Студии даже предусмотрели для этого специальный GUI который называется Property Manager, так что любители мышки могут проделать ту же операцию в несколько кликов.

Правда как и остальные инструменты Студии этот GUI вместо читабельного однострочника добавит в код .vcxproj что-то вроде

Так что я предпочитаю добавлять ссылки на сторонние библиотеки в .vcxproj файлы вручную.

Аналогично тому что уже обсуждалось ранее, работа с ThirdParty-компонентами через .props файлы позволяет так же легко в дальнейшем обновлять используемые библиотеки. Достаточно отредактировать единственный файл zeromq.props — и сборка всего solution синхронно переключится на новую версию. К примеру в наших проектах сборка проекта через этот механизм увязана с менеджером зависимостей Conan который собирает необходимый набор thirdparty-библиотек по манифесту зависимостей и автоматически генерирует соответствующие .props-файлы.

Project Templates — автоматизируем создание проектов

Править вручную .vcxproj-файлы созданные Студией конечно довольно скучно (хотя при наличии навыка и недолго). Поэтому в Студии предусмотрена удобная возможность по созданию собственных шаблонов для новых проектов, которые позволяют провести ручную работу по настройке .vcxproj лишь один раз, после чего повторно использовать ее одним кликом в любом новом проекте. В простейшем случае для этого даже не надо ничего править вручную — достаточно открыть проект который нужно превратить в шаблон и выбрать в меню Project \ Export Template. В открывшемся диалоговом окне можно задать несколько тривиальных параметров вроде имени для шаблона или строки которая будет показываться в его описании, а так же выбрать, будет ли вновь созданный шаблон сразу добавлен в диалоговое окно «New Project». Созданный таким способом шаблон создает копию использованного для его создания проекта (включая все файлы входящие в проект), заменяя в нем только имя проекта и его GUID. В довольно большом проценте случаев этого более чем достаточно.

При более детальном рассмотрении сгенерированного Студией шаблона можно легко убедиться в том что это просто zip архив в котором лежат все файлы использованные в шаблоне и один дополнительный конфигурационный файл с расширением .vstemplate. В этом файле хранится список метаданных проекта (вроде использованной иконки или строки с описанием) и список файлов которые необходимо создать при создании нового проекта. Например,

Обратите внимание на параметр ReplaceParameters=«true». В данном случае он применяется только к vcxproj-файлу который выглядит следующим образом:

На месте GUID и RootNamespace как видите стоят не конкретные значения, а «заглушки» $guid1$ и $safeprojectname$. При использовании шаблона, Студия проходит по файлам помеченным ReplaceParamters=«true», ищет в них заглушки вида $name$ и заменяет их на вычисляемые значения по специальному словарю. По умолчанию Студия поддерживает не очень много параметров, но при написании Visual Studio Extensions (о чем мы поговорим чуть позже) туда нетрудно добавить сколько угодно своих собственные параметров вычисляемых (или вводимых пользователем) при запуске диалога по созданию нового проекта из шаблона. Как можно увидеть в файле .vstemplate, тот же словарь может использоваться и для формирования имени файла что позволяет, в частности, сформировать шаблону уникальные имена .vcxproj-файлов для разных проектов. При задании ReplaceParameters=false файл указанный в шаблоне будет просто скопирован без дополнительной обработки.

Полученный ZIP-архив с шаблоном можно добавить в список шаблонов известных Студии одним из нескольких способов. Проще всего просто скопировать этот файл в папку %USERPROFILE%\Documents\Visual Studio XX\Templates\ProjectTemplates. Стоит заметить, что несмотря на то что в этой папке Вы найдете множество разных подпапок совпадающих по названиям с папками в окне создания нового проекта, по факту шаблон следует положить просто в корневую папку поскольку положение шаблона в дереве новых проектов определяется Студией из тэгов ProjectType и ProjectSubType в .vstemplate-файле. Этот способ удобнее всего подходит для создания «персональных» шаблонов уникальных только для Вас и если Вы выберете в диалоге Export Template галочку «Automatically import template into Visual Studio» то Студия именно это и сделает, поместив созданный при экспорте zip-архив в эту папку с шаблонами. Однако делиться такими шаблонами с коллегами путем их ручного копирования конечно не очень удобно. Поэтому давайте познакомимся с чуть более продвинутым вариантом — создадим Visual Studio Extension (.vsix)

Для создания VSIX нам понадобится установить опциональный компонент Студии который так и называется — средства для разработки Visual Studio Extensions:

После этого в разделе Visual C# \ Extensibility появится вариант «VSIX project». Обратите внимание, что несмотря на свое расположение (C#), он используется для создания любых расширений, в том числе и наборов шаблонов проектов на C++.

В созданном VSIX проекте можно делать массу самых разных вещей — к примеру, создать свое собственное диалоговое окно которое будет использоваться для настройки создаваемых по шаблону проектов. Но это отдельная огромная тема для обсуждения которую я не буду в этой статье затрагивать. Для создания же шаблонов в VSIX все устроено предельно просто: создаем пустой VSIX проект, открываем файл .vsixmanifest и прямо в GUI задаем все данные для проекта. Вписываем метаданные (название расширения, описание, лицензия) на вкладке Metadata. Обратите внимание на расположенное в правом верхнем углу поле «Version» — его желательно указать правильно, поскольку Студия впоследствии использует именно его для определения того какая версия расширения установлена на компьютере. Затем идем на вкладку Assets и выбираем «Add new Asset», с Type: Microsoft.VisualStudio.ProjectTemplate, Source: File on filesystem, Path: (имя к zip-архиву с шаблоном). Нажимаем OK, повторяем процесс пока не добавим в VSIX все желаемые шаблоны.

После этого остается выбрать Configuration: Release и скомандовать Build Solution. Код писать не требуется, править конфигурационные файлы вручную — тоже. На выходе получается переносимый файл с расширением .vsix, который является, по сути, инсталлятором для созданного нами расширения. Созданный файл будет «запускаться» на любом компьютере с установленной Студией, показывать диалог с описанием расширения и лицензией и предлагать установить его содержимое. Разрешив установку — получаем добавление наших шаблонов в диалоговое окно «Создать новый проект»

Подобный подход позволяет легко унифицировать работу большого количества человек над проектом. Для установки и использования шаблонов от пользователя не требуется никакой квалификации кроме пары кликов мышкой. Установленное расширение можно посмотреть (и удалить) в диалоге Tools \ Extensions and Updates

Level 2: настраиваем кастомную компиляцию

ОК, на этом этапе мы разобрались как организованы vcxproj и props файлы и научились их организовывать. Давайте теперь предположим что мы хотим добавить в наш проект парочку .proto схем для сериализации объектов на основе замечательной библиотеки Google Protocol Buffers. Напомню основную идею этой библиотеки: Вы пишите описание объекта («схему») на специальном платформонезависимом мета-языке (.proto-файл) которая компилируется специальным компилятором (protoc.exe) в набор .cpp / .cs / .py / .java / etc. файлов которые реализуют сериализацию / десериализацию объектов по этой схеме в нужном языке программирования и которые Вы можете использовать в своём проекте. Таким образом при компиляции проекта нам нужно первым делом позвать protoc который создаст для нас набор .cpp файлов которые мы в дальнейшем будем использовать.

Традиционный подход

Классическая реализация «в лоб» прямолинейна и состоит в том чтобы просто добавить вызов protoc в pre-build step для проекта которому нужны .proto-файлы. Примерно вот так:

• Требуется явно указывать список обрабатываемых файлов в команде
• При изменении этих файлов билд НЕ будет пересобран автоматически
• При изменении ДРУГИХ файлов в проекте которые Студия распознает как исходные коды, напротив, без нужды будет выполнен pre-build step
• Сгенерированные файлы не входят по умолчанию в сборку проекта
• Если мы включим сгенерированные файлы в проект вручную, то проект будет выдавать ошибку когда мы его будем открывать в первый раз (поскольку файлы еще не сгенерированы первой сборкой).

Знакомимся с MSBuild targets

С точки зрения MSBuild, сборка любого проекта состоит из последовательности сборки сущностей которые называются build targets, сокращенно targets. К примеру сборка проекта может включать в себя выполнение таргета Clean который удалит оставшиеся от предыдущих билдов временные файлы, затем выполнение таргета Compile который скомпилирует проект, затем таргета Link и наконец таргета Deploy. Все эти таргеты вместе с правилами по их сборке не фиксированы заранее а определяются в самом .vcxproj файле. Если Вы знакомы с nix-овой утилитой make и Вам на ум в этот момент приходит слово «makefile», то Вы совершенно правы: .vcxproj является XML-вариацией на тему makefile.

Но стоп-стоп-стоп скажет тут сбитый с толку читатель. Как это так? Мы просмотрели до этого .vcxproj в простом проекте и там не было ни target-ов ни какого-либо сходства с классическим makefile. О каких target-ах тогда может идти речь? Оказывается что они просто «спрятаны» вот в этой строчке включающей в .vcxproj набор стандартных target-ов для сборки C++ — кода.

«Стандартный» билд-план предлагаемый Студией довольно обширен и предлагает большой набор правил для компиляции C++-кода и «стандартных» таргетов типа Build, Clean и Rebuild к которым умеет «цепляться» Студия. Этот набор часто известен под собирательным названием toolset и заменяя в импорте toolset можно заставить Студию компилировать один и тот же проект с помощью другой версии Студии или, к примеру, интеловским компилятором или Clang. Кроме того при желании от стандартного toolset-а можно вообще отказаться и написать свой собственный toolset с нуля. Но мы будем рассматривать в этой статье более простой вариант в котором мы ничего не будем заменять, а лишь дополним стандартные правила необходимыми нам дополнениями.

• Список входов (inputs)
• Список выходов (outputs)
• Зависимости от других targets (dependencies)
• Настройки target-а
• Последовательность фактических шагов выполняемых target-ом (tasks)

то мы добавляем (Include) файл protobuf_tests.cpp в список входов (inputs) данного таргета, а когда пишем

то присваем значение «Use» настройке ClCompile.PrecompiledHeader которую target затем превратит в флаг /Yu переданный компилятору cl.exe.

Попробуем создать target для сборки .proto файлов

Добавление нового target-а реализуется с помощью тэга target:

Традиционно target-ы выносят в подключаемый файл с расширением .targets. Не то чтобы это было строго необходимо (и vcxproj и targets и props файлы внутри являются равнозначным XML-ем), но это стандартная схема именования и мы будем ее придерживаться. Чтобы в коде .vcxproj файла теперь можно было писать что-то вроде

созданный нами target необходимо добавить в список AvailableItemName

Нам также понадобится описать что же конкретно мы хотим сделать с нашими входными файлами и что должно получиться на выходе. Для этого в MSBuild используется сущность которая называется «task». Таска — это какое-то простое действие которое нужно сделать в ходе сборки проекта. К примеру «создать директорию», «скомпилировать файл», «запустить команду», «скопировать что-то». В нашем случае мы воспользуемся таской Exec чтобы запустить protoc.exe и таской Message чтобы отобразить этот шаг в логе компиляции. Укажем так же что запуск данного target-а следует провести сразу после стандартного таргета PrepareForBuild. В результате у нас получится примерно вот такой файлик protobuf.targets

Мы использовали здесь довольно нетривиальный оператор «%» (batching operator) который означает «для каждого элемента из списка» и автоматически добавляемые метаданные. Идея тут в следующем: когда мы записываем код вида

то мы этой записью добавляем в список с названием «ProtobufSchema» дочерний элемент «test.proto» у которого есть дочерний элемент (метадата) AdditionalData содержащая строку «Test». Если мы напишем «ProtobufSchema.AdditionalData» то мы получим доступ к записи «Test». При этом помимо явно объявленных нами метаданных AdditionalData, хитрый MSBuild ради нашего удобства автоматически добавляет к записи еще добрый десяток полезных часто используемых дочерних элементов описанных вот здесь из числа которых мы использовали Identity (исходная строка), Filename (имя файла без расширения) и FullPath (полный путь к файлу). Запись же со знаком % заставляет MSBuild применить описанную нами операцию к каждому элементу из списка — т.е. к каждому .proto файлу по отдельности.

в protobuf.props, переписываем наши proto-файлы в .vcxproj-е на тэг ProtobufSchema

и проверяем сборку

1>—— Rebuild All started: Project: protobuf_test, Configuration: Debug x64 ——
1>Compiling schema test.proto
1>Compiling schema test2.proto
1>pch.cpp
1>protobuf_test.cpp
1>protobuf_test.vcxproj -> S:\Temp\msbuild\protobuf_msbuild_integration\x64\Debug\protobuf_test.exe
========== Rebuild All: 1 succeeded, 0 failed, 0 skipped ==========

Ура! Заработало! Правда наши .proto файлы теперь стали не видны в проекте. Лезем в .vcxproj.filters и вписываем там по аналогии

Перезагружаем проект — файлы снова видны.

Доводим наш модельный пример до ума

Впрочем на самом деле я немного схитрил. Если не создать вручную перед началом билда папку generated, то билд на самом деле падает

1>. \protobuf_test\protobuf.targets(13,6): error MSB3073: The command «. \ThirdParty\protobuf\bin\protoc.exe —cpp_out=.\generated test.proto» exited with code 1.

Чтобы это исправить добавим вспомогательный target который создаст необходимую папку

С помощью свойства DependsOnTargets мы указываем что перед тем как запускать любую из задач GenerateProtobuf следует запустить PrepareToGenerateProtobuf, а запись @(ProtobufSchema) ссылается на список ProtobufSchema целиком, как единую сущность используемую как вход для этой задачи, так что запущена она будет лишь один раз.

Перезапускам сборку — работает! Давайте попробуем сделать теперь еще раз Rebuild, чтобы уж на этот раз точно во всем убедиться

1>—— Rebuild All started: Project: protobuf_test, Configuration: Debug x64 ——
1>pch.cpp
1>protobuf_test.cpp
1>protobuf_test.vcxproj -> S:\Temp\msbuild\protobuf_msbuild_integration\x64\Debug\protobuf_test.exe
========== Rebuild All: 1 succeeded, 0 failed, 0 skipped ==========

Эм, а куда же пропали наши новые таски? Небольшая отладка — и мы видим что таски на самом деле запускаются MSBuild, но не выполняются поскольку в указанной нами выходной папке уже есть сгенерированные файлы. Проще говоря в Rebuild у нас не работает Clean для .\generated файлов. Исправим это, добавив еще один таргет

Проверяем — работает. Clean очищает созданные нами файлы, Rebuild пересоздает их заново, повторный вызов Build не запускает без нужды пересборку еще раз.

========== Build: 0 succeeded, 0 failed, 1 up-to-date, 0 skipped ==========

Вносим правку в один из C++ файлов, пробуем сделать Build еще раз

1>—— Build started: Project: protobuf_test, Configuration: Debug x64 ——
1>protobuf_test.cpp
1>protobuf_test.vcxproj -> S:\Temp\msbuild\protobuf_msbuild_integration\x64\Debug\protobuf_test.exe
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

.proto-файл не менялся, поэтому protoc не перезапускался, все ожидаемо. Пробуем теперь изменить .proto файл.

========== Build: 0 succeeded, 0 failed, 1 up-to-date, 0 skipped ==========

Интересно что если запустить сборку MSBuild через командную строку вручную, а не через UI из Студии то такой проблемы не будет — MSBuild корректно пересоберет необходимые .pp.cc файлы. Если мы поменяем какой-нибудь .cpp то запустившийся в студии MSBuild пересоберет не только его, но и .props файл который мы меняли раньше

1>—— Build started: Project: protobuf_test, Configuration: Debug x64 ——
1>Compiling schema test.proto
1>protobuf_test.cpp
1>protobuf_test.vcxproj -> S:\Temp\msbuild\protobuf_msbuild_integration\x64\Debug\protobuf_test.exe
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

U2DCheck и tlog файлы

Оказывается что создатели Visual Studio посчитали что вызывать MSBuild на каждый чих слишком накладно и… реализовали собственную «быструю проверку» на то нужно ли собирать проект или нет. Она называется U2DCheck и если по ее мнению проект не менялся, то Студия просто не станет запускать MSBuild для этого проекта. Обычно U2DCheck работает настолько «тихо» что про ее существование мало кто догадывается но в реестре можно включить полезный флажок который заставит U2DCheck выводить более подробные отчеты.

В своей работе U2DCheck опирается на специальные .tlog файлы. Их легко можно найти в intermediate-output папке (имя_проекта).tlog и чтобы U2DCheck корректно реагировал на изменения в исходных файлах нам надо сделать в этой папке запись в один из read tlog — файлов, а чтобы U2DCheck корректно реагировал на удаление выходных файлов — запись в одном из write tlog — файлов.

Чертыхнувшись, возвращаемся к соответствующей правке нашего target-а

Проверяем — работает: правка .props файла триггерит необходимый ребилд, сборка в отсутствие правки показывает что проект up-to-date. В данном примере для простоты я не стал писать write tlog отслеживающий удаление созданных при компиляции файлов, но он добавляется в target аналогичным образом.

Начиная с Visual Studio 2017 update 15.8 в MSBuild была добавлена новая стандартная таска GetOutOfDateItems которая автоматизирует эту черную магию, но поскольку это произошло совсем недавно то практически все кастомные .target-ы продолжают работать с .tlog файлами вручную.

При желании можно так же полностью отключить U2DCheck для любого проекта добавив одну строчку в поле ProjectCapability

Однако в этом случае Студия будет гонять MSBuild для этого проекта и всех зависящих от него при каждой сборке и да, U2DCheck добавляли не просто так — это работает не так быстро как мне хотелось бы.

Финализуем наш кастомный .target

Получившийся у нас результат вполне работоспособен, но его есть еще куда совершенствовать. К примеру в MSBuild существует режим «выборочной сборки» когда в командной строке указывается что требуется собрать не весь проект в целом, а лишь отдельные конкретно выбранные в нем файлы. Поддержка этого режима требует чтобы таргет проверял содержимое списка @(SelectedFiles).

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

Наконец мы все еще не реализовали обещанную в самом начале задумку — автоматическое включение сгенерированных файлов в проект. Мы уже можем #include-ить сгенерированные protobuf-ом заголовочные файлы зная что они будут автоматически созданы до того как дело дойдет до компиляции, но с линковщиком этот номер не проходит :). Поэтому просто дописываем сгенерированные файлы в список ClCompile.

Общие настройки здесь были вынесены в PropertyGroup, а списки входных и выходных файлов заполняет новый target ComputeProtobufInput. Попутно (чтобы продемонстрировать работу со списками выходных файлов) была добавлена генерация кода из схемы для интеграции с python. Запускаем и проверяем что все работает правильно

А что насчет CustomBuildStep?

Надо сказать что разработчики из Майкрософт вполне здраво оценивали что все вышеописанное, хм, несколько нетривиально и плохо задокументировано и попытались облегчить жизнь программистов введя специальный таргет CustomBuildStep. В рамках этой концепции мы должны были бы в настройках файла отметить что наши .props файлы относятся к типу Custom Build Step

Затем следовало бы указать необходимые шаги по сборке во вкладке Custom Build Step

В .vcxproj-е это выглядит примерно вот так

Эта конструкция работает за счет того что введенные таким образом данные подставляются в недрах Microsoft.CppCommon.targets в специальный таргет CustomBuildStep который делает, в общем-то, все то же самое что я описал выше. Но работает все через GUI и не надо задумываться о реализации clean и tlog-ах :). При желании этот механизм вполне можно использовать, но я бы не рекомендовал этого делать в силу следующих соображений:

• CustomBuildStep может быть только один на весь проект
  • Соответственно так обработать можно лишь 1 тип файлов на весь проект
  • Включать такой step в .props файл используемый для подключения ThirdParty библиотеки нецелесообразно, т.к. разные библиотеки могут его перекрывать друг у друга

  Правильное копирование файлов

  Очень часто встречающейся разновидностью build target является копирование каких-нибудь файлов из одного места в другое. Например копирование файлов ресурсов в папку с собранным проектом или копирование thirdparty DLL к собранному бинарнику. И очень часто эту операцию реализуют «в лоб» через запуск консольной утилиты xcopy в Post-Build Targets. К примеру,

  

  Так делать не надо по тем же самым причинам по которым не надо пытаться запихивать в Post-build steps другие build targets. Вместо этого мы можем напрямую указать Студии что ей необходимо скопировать тот или иной файл. К примеру если файл напрямую входит в проект, то ему достаточно указать ItemType=Copy

  

  После нажатия кнопки apply появится дополнительная вкладка на которой можно настроить куда и как следует копировать выбранный файл. В коде .vcxproj-файла это будет выглядеть примерно так:

  Всё заработает «из коробки», включая правильную поддержку tlog-файлов. Внутри это реализовано по все тому же принципу «специальной стандартной таски для копирования файлов» что и Custom Build Step которую я критиковал буквально в предыдущем разделе, но поскольку копирование файлов — довольно тривиальная операция и мы не переопределяем саму операцию (копирование) а лишь меняем список входных и выходных файлов для нее то работает это неплохо.

  Замечу что при формировании списков файлов CopyFilesToFolder можно использовать wildcards. К примеру

  Добавление файлов в список CopyFileToFolders — пожалуй самый простой способ реализовать копирование при сборке проекта, в том числе в .props-файлах подключающих thirdparty-библиотеки. Однако если хочется получить больше контроля над происходящим, то еще одним вариантом является добавление в свои build target специализированной таски Copy. К примеру

  R сожалению таска Copy не поддерживает wildcards и не заполняет .tlog файлы. При желании это можно реализовать вручную,

  Однако работа с стандартным CopyFileToFolders обычно будет намного проще.

  Level 3: интегрируемся с GUI от Visual Studio

  Все то чем мы до сих пор занимались со стороны может показаться довольно унылой попыткой реализовать в не слишком подходящем для этого инструменте функциональность нормального make. Ручная правка XML-файлов, неочевидные конструкции для решения простых задач, костыльные tlog-файлы… Однако у билд-системы Студии есть и плюсы — к примеру после первоначальной настройки она обеспечивает получившимуся билд-плану неплохой графический интерфейс. Для его реализации используется тэг PropertyPageSchema о котором мы сейчас и поговорим.

  Вытаскиваем настройки из недр .vcxproj в Configuration Properties

  Давайте попробуем сделать так чтобы мы могли бы редактировать свойство $(ProtobufOutputFolder) из «причесанной реализации protobuf.targets» не вручную в файле, а с комфортом прямо из IDE. Для этого нам потребуется написать специальный XAML-файл с описанием настроек. Открываем текстовый редактор и создаем файл с названием, к примеру, custom_settings.xml

  Помимо собственно тэга StringProperty который указывает Студии на существование настройки «ProtobufOutputFolder» с типом String и Subtype=Folder и объясняет то как ее следует показывать в GUI, данный XML-ник указывает что хранить эту информацию следует в project file. Помимо ProjectFile можно использовать еще UserFile — тогда данные будут записаны в отдельный файлик .vcxproj.user который по задумке создателей Студии предназначается для приватных (не сохраняемых в VCS) настроек. Подключаем описанную нами схему к проекту, дописав в наш protobuf.targets тэг PropertyPageSchema

  Для того чтобы наши правки вступили в силу перезапускаем Студию, загружаем наш проект, открываем project properties и видим…

  

  Да! Появилась наша страничка с нашей настройкой и ее значение по умолчанию было верно прочитано Студией. Пробуем ее изменить, сохраняем проект, смотрим .vcxproj…

  Как можно видеть по традиционному условию Condition, по умолчанию настройки ассоциированы с конкретной конфигурацией билда. Но при желании это можно перекрыть с помощью установки флага DataSource HasConfigurationCondition=«false». Правда в 2017 студии присутствует баг из-за которого настройки проекта могут не показываться если среди них нет хотя бы одной настройки ассоциированной с какой-то конфигурацией. К счастью эта настройка может быть невидимой.

  <?xml version=»1.0″ encoding=»utf-8″?>
  <Rule.DataSource>
  />
  </Rule.DataSource>
  <StringProperty Name=»ProtobufOutputFolder»
  DisplayName=»Protobuf Output Directory»
  Description=»Directory where Protobuf generated files are created.»
  Subtype=»folder»>
  <StringProperty.DataSource>
  />
  </StringProperty.DataSource>

  Настроек можно добавлять сколько угодно. Возможные типы включают BoolProperty, StringProperty (с опциональными подтипами «folder» и «file»), StringListProperty, IntProperty, EnumProperty и DynamicEnumProperty причем последний может заполняться на лету из любого списка доступного в .vcxproj. Подробнее об этом можно почитать здесь. Можно так же группировать настройки в разделы. Попробуем к примеру добавить еще одну настройку типа Bool

  

  Редактируем настройку, сохраняем проект — все работает как ожидалось

  Объясняем Студии про новые типы файлов

  До сих пор чтобы добавить в проект protobuf-файл нам необходимо было вручную прописывать в .vcxproj что это . Это легко исправить дописав к упомянутому выше .xml три тэга

  Перезапускаем студию, смотрим свойства у наших .proto файлов

  

  Как легко видеть файлы теперь верно распознаются как «Google Protobuf Schema». К сожалению соответствующий пункт не добавляется автоматически в диалог «Add new item», но если мы добавим в проект уже существующий .proto-файл (контекстное меню проекта \ Add \ Existing item… ) то он распознается и добавится правильно. Кроме того наш новый «тип файлов» можно будет выбрать в выпадающем списке Item type:

  

  Ассоциируем настройки с индивидуальными файлами

  Помимо настроек «для проекта в целом» совершенно аналогичным образом можно сделать «настройки для отдельного файла». Достаточно указать в тэге DataSource аттрибут ItemType.

  

  Сохраняем, смотрим содержимое .vcxproj

  Все работает как ожидалось.

  Level 4: расширяем функциональность MSBuild

  У меня никогда не возникало необходимости залезать в процесс сборки настолько глубоко, но раз уж статья так и так получилась немаленькой, то коротенько упомяну о последней возможности для кастомизации: расширение самого MSBuild. Помимо довольно обширной коллекции «стандартных» тасков, в MSBuild таски можно «импортировать» из разных источников с помощью тэга UsingTask. К примеру мы можем написать свое расширение для MSBuild, скомпилировать его в DLL-библиотеку и импортировать как-то вот так:

  Именно так реализовано большинство «стандартных» тасков предоставляемых Студией. Но таскать с собою кастомную DLL для сборки по очевидным причинам частенько неудобно. Поэтому в тэге UsingTask поддерживается штука которая называется TaskFactory. TaskFactory можно считать «компилятором для task-ов» — мы передаем ей на вход некий исходный «мета-код», а она по нему генерирует реализующий его объект типа Task. К примеру с помощью CodeTaskFactory можно воткнуть код написанной на C# таски прямо внутрь .props-файла.

  Если кто-то подобной функциональностью пользовался — отпишитесь об интересных use-case в комментариях.

  На этом всё. Надеюсь что мне удалось показать как при настройке MSBuild работу с крупным проектом в Visual Studio можно сделать простой и удобной. Если Вы соберетесь внедрять у себя что-то из описанного выше, то дам небольшой совет: для отладки .props, .targets и .vcxproj удобно выставить MSBuild «отладочный» уровень логгирования в котором он весьма подробно пошагово расписывает свои действия с входными и выходными файлами

  

  Спасибо всем кто дочитал до конца, надеюсь что получилось интересно :).

  Делитесь своими рецептами для msbuild в комментариях — я постараюсь обновлять пост чтобы он служил исчерпывающим гайдом по конфигурированию solution в Студии.

  Знакомство с Visual Studio

  Исходя из того, что мы узнали при знакомстве с платформой .NET, для того, чтобы написать и выполнить приложение, написанное на языке C# нам понадобится одна из реализаций .NET, в состав которой будет входить CLR (общеязыковая среды выполнения), а также JIT-компилятор и текстовый редактор для написания кода программы.

  В большинстве случаев разработчики используют интегрированные среды разработки — IDE (от англ. Integrated Development Environment). IDE значительно облегчает процесс разработки и содержит в себе все необходимые инструменты — от редактора кода с подсветкой синтаксиса до средств отладки, рефакторинга и профилирования приложений. Одной из наиболее популярных IDE для языка C# является Visual Studio.

  Где скачать и сколько стоит Visual Studio?

  Visual Studio — это полнофункциональная интегрированная среда разработки (IDE) для написания, отладки, тестирования и развертывания кода на различных языках, в том числе и на C#.

  Скачать Visual Studio можно с сайта https://visualstudio.microsoft.com/ru/.

  При этом, для работы вам доступно три редакции IDE:

  

  1. Community
  2. Professional
  3. Enterprise

  Редакция Community предоставляется абсолютно бесплатно. При этом, на сайте Microsoft относительно этой редакции сказано дословно следующее:

  

  Кому не хочется читать текст с картинки — ниже скопированный текст с сайта Microsoft

  Соответственно, я скачал Visual Studio Community 2019 с которой и начну свой путь из Delphi в C# (и обратно, если потребуется).

  Знакомство с Visual Studio

  Создание нового проекта

  При запуске Visual Studio Вы увидите следующее окно, в котором Вам предложат выбрать необходимое действие для дальнейшей работы — создать проект, клонировать репозиторий т.д.

  

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

  Допустим, нам необходимо создать новый проект «Hello, world» (не будем оригинальными). Для этого выбираем последний пункт списка справа «Создание проекта»

  

  Перед вами откроется новое окно создания проекта, которое по умолчанию выглядит вот так:

  

  Слева в списке отображаются последние использованные шаблоны проектов, а справа — все доступные шаблоны, в зависимости от того, какую конфигурацию Visual Studio вы выбрали при установке.

  Для того, чтобы быстро находить необходимый вам шаблон проекта, доступны фильтры по языку программирования, платформе и типам проектов:

  

  Например, чтобы создать проект консольного приложения на C# можно выбрать следующие значения фильтров:

  • Язык программирования: C#
  • Платформа: Windows
  • Тип проекта: Консоль

  В результате, вы увидите в списке шаблонов всего два шаблона проектов:

  

  • Консольное приложение (.NET Core) для Windows, Linux и Mac OS
  • Консольное приложение (.NET Framework) для Windows

  Выберем второй пункт (тот который .NET Framework) и нажмем кнопку «Далее».

  На втором шаге нас попросят ввести:

  • Имя проекта
  • Расположение проекта
  • Имя решения
  • и выбрать платформу

  

  После того, как вы зададите название проекта, его расположение и название решения, то у вас на жестком диске будут созданы следующие директории:

  1. Директория, путь к которой Вы указали для расположения проекта (например, C:\Sources)
  2. Поддиректория с именем решения, например, если вы назвали решение «FirstSteps», то будет создана директория C:\Sources\FirstSteps
  3. Поддиректория с именем вашего проекта. Например, если вы назвали проект HelloWorld, то путь к файлам проекта будет C:\Sources\FirstSteps\HelloWorld

  О том, какие файлы располагаются по умолчанию в директории с проектом, мы поговорим позже, когда познакомимся с устройством Visual Studio, а пока перейдем к дальнейшему изучению IDE.

  Основные окна в Visual Studio

  После того, как мы создали первый проект консольного приложения для Windows, перед нами откроется основное окно Visual Studio с примерно таким содержимым:

  

  В целом, для тех, кто работал в RAD Sudio, внешний вид окна Visual Studio не должен вызвать никаких проблем, хотя здесь есть и свои значительные отличия. Итак, что у нас есть:

  справа располагается «Панель элементов»:

  

  Для консольного приложения эта панель пустая и не содержит ничего, кроме подсказки:

  

  Далее идёт привычное нам окно исходного кода с вкладками под каждый модуль проекта. Так как у нас один модуль, то и вкладка пока у нас в окне кода одна:

  В правой части окна IDE расположены следующие окна:

  Обозреватель решений

  

  Здесь мы можем увидеть, какие проекты входят в то или иное решение, посмотреть свойства проекта, модули, входящие в состав проекта и т.д. Например, если, находясь в окне «Обозреватель решений», раскрыть вкладку «Properties» и выбрать в списке файл AssemblyInfo.cs, то в окне кода появится содержимое файла:

  

  Файл содержит комментарии на русском языке, поэтому разобраться с его содержимым можно относительно просто. Однако, если Вам необходимо посмотреть и изменить свойства проекта в более удобном виде, то можно выбрать в «Обозревателе решений» вкладку «Properties», нажать на ней правой кнопкой мыши и выбрать пункт «Открыть». В результате, откроется вкладка с настройками вашего первого проекта, сгруппированные по секциям «Приложение», «Сборка» и т.д.:

  

  Здесь же, в «Обозревателе решений» достаточно удобно, на мой взгляд, реализована навигация по модулям проекта. Так, например, если мы раскроем вкладку с названием единственного нашего модули «Program.cs», то увидим какие классы содержит модуль, а также методы классов:

  

  Соответственно, если выбрать в списке, например, метод Main, то этот метод будет выделен в окне с исходным кодом проекта.

  Team Explorer

  

  Здесь вы можете создать подключение, например, к репозиторию Git или GitHub. С содержимым этого окна и работой с репозиториями мы поговорим позднее.

  Представление классов

  

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

  Свойства

  

  Окно расположено в нижней левой части экрана и, как и следует из названия, предназначено для отображения свойств элементов. Ну а, так как свойства имеют не только компоненты, но и файлы, то выбрав, например, файл в «Обозревателе решений», можно увидеть его свойства (что, собственно, и показано на рисунке выше).

  Средства диагностики

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

  

  В принципе, для первого знакомства с основными окнами Visual Studio информации достаточно. Теперь попробуем создать наше первое приложение.

  Первое приложение в Visual Studio

  Итак, если вы заплутали в окнах IDE, то, выберите «Обозреватель решений» и в этом окне щелкните мышкой по файлу Program.cs, чтобы в рабочей области появился исходный код нашей программы:

  Напишем следующий код для метода Main:

  Теперь нажмите F5 и увидите, что на экране появилось и быстро исчезло окно консоли Windows, что ожидаемо — программа выполнила необходимые действия и закрылась. Чтобы окно консоли не закрывалось, допишем код нашей программы следующим образом:

  Теперь снова нажмите F5 и увидите приветствие от нашего первого приложения на C#, а IDE перейдет в режим отладки в котором «Средства диагностики» будут показывать используемые нашим приложением ресурсы:

  

  Чтобы приложение закрылось достаточно нажать любую клавишу на клавиатуре.

  При написании кода нашей программы вы, возможно, заметили, что справа в окне исходного кода периодически появляется вот такой значок:

  

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

  Судя по подсказке, можно спокойно удалить неиспользуемые директивы using. Выбираем во всплывающем окне ссылку «Показать возможные решения» и Visual Studio покажет, что можно безопасно удалить:

  

  Применяем предложенное решение и IDE сама удалит лишний строки из модуля и наша программа станет выглядеть вот так:

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