Как запустить файл в visual studio 2019

Отображение файлов с помощью команды «Открыть файл»

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

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

Когда пользователь щелкает команду «Открыть файл» в меню «Файл» и выбирает файл в диалоговом окне «Открыть файл«, происходит следующий процесс:

1. Используя запущенную таблицу документов, интегрированная среда разработки определяет, открыт ли файл в проекте.
2. Если файл открыт, интегрированная среда разработки возвращает окно.
3. Если файл не открыт, интегрированная среда разработки вызывает IsDocumentInProject запрос к каждому проекту, чтобы определить, какой проект может открыть файл.

Примечание. В реализации проекта укажите значение приоритета IsDocumentInProject, указывающее уровень, на котором открывается файл. Значения приоритета предоставляются в VSDOCUMENTPRIORITY перечислении.

• Проект, который отвечает с наивысшим приоритетом ( DP_Intrinsic ) открывает файл. Если несколько проектов отвечают с этим приоритетом, первый проект для ответа открывает файл.
• Если ни один проект не отвечает с наивысшим приоритетом ( DP_Intrinsic ), но все проекты отвечают с одинаковым, низким приоритетом, активный проект открывает файл. Если проект не активен, первый проект для ответа открывает файл.
• Если проект не утверждает владение файлом ( DP_Unsupported ), проект «Прочие файлы» открывает файл. Если создается экземпляр проекта «Прочие файлы», проект всегда отвечает со значением DP_CanAddAsExternal . Это значение указывает, что проект может открыть файл. Этот проект используется для размещения открытых файлов, которые не находятся в другом проекте. Список элементов в этом проекте не сохраняется; этот проект отображается в Обозреватель решений только в том случае, если он используется для открытия файла. Если проект «Другие файлы» не указывает, что он может открыть файл, экземпляр проекта не был создан. В этом случае интегрированная среда разработки создает экземпляр проекта «Прочие файлы» и сообщает проекту открыть файл.

См. также

• Отображение файлов с помощью команды Open With
• Открытие и сохранение элементов проекта
• Практическое руководство. Открытие редакторов для конкретных проектов
• Практическое руководство. Открытие стандартных редакторов

Краткое руководство. Создание первого приложения Vue.js с помощью Visual Studio

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

В рамках этого краткого (на 5–10 минут) знакомства с возможностями интегрированной среды разработки (IDE) Visual Studio вы создадите и запустите простое веб-приложение Vue.js.

Начиная с Visual Studio 2022, можно также создать проект Vue с помощью рекомендуемого типа проекта на основе ИНТЕРФЕЙСА командной строки. Сведения в этой статье относятся только к типу проектов Node.js (расширение файла NJSPROJ).

Необходимые компоненты

• У вас должна быть установлена среда Visual Studio и должна иметься рабочая нагрузка «Разработка Node.js». Установите Visual Studio 2019 бесплатно со страницы скачиваемых материалов Visual Studio, если еще не сделали этого. Если вам нужно установить рабочую нагрузку, но вы уже используете Visual Studio, выберите пункт Средства>Получить средства и компоненты. , после чего запустится Visual Studio Installer. Выберите рабочую нагрузку Разработка Node.js, а затем элемент Изменить.
• У вас должна быть установлена среда выполнения Node.js. Если он не установлен, мы рекомендуем установить версию LTS с веб-сайта Node.js для обеспечения лучшей совместимости с внешними платформами и библиотеками. Node.js построен для 32-разрядных и 64-разрядных архитектур. Средства Node.js в Visual Studio, включенные в рабочую нагрузку Node.js, поддерживают обе версии. Однако требуется только одна, поскольку программа установки Node.js поддерживает только одну установку за раз. Как правило, Visual Studio автоматически обнаруживает установленную среду выполнения Node.js. Если установленная среда выполнения не обнаружена, вы можете настроить проект так, чтобы он ссылался на установленную среду выполнения, на странице свойств (после создания проекта щелкните его узел правой кнопкой мыши, выберите пункт Свойства и укажите путь Node.exe). Можно использовать глобальную установку Node.js или указать путь к локальному интерпретатору в каждом из проектов Node.js.

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

Сначала вы создадите проект веб-приложения Vue.js.

1. Если у вас не установлена среда выполнения Node.js, установите версию LTS с веб-сайта Node.js. Дополнительные сведения см. в разделе Необходимые условия.
2. Откройте Visual Studio.
3. Создание проекта Нажмите клавишу ESC, чтобы закрыть окно запуска. Нажмите CTRL + Q, чтобы открыть поле поиска, введите Basic Vue.js и выберите Простое веб-приложение Vue.js (JavaScript или TypeScript). В появившемся диалоговом окне введите имя basic-vuejs, а затем выберите команду Создать. Если шаблон проекта Простое веб-приложение Vue.js отсутствует, нужно добавить рабочую нагрузку Разработка Node.js. Подробные инструкции см. в разделе с предварительными требованиями. Visual Studio создаст новый проект. Новый проект откроется в обозревателе решений (в правой области).
4. Отслеживайте установку пакетов npm, необходимых для приложения, в окне вывода (нижняя панель).
5. В обозревателе решений откройте узел npm и проверьте установку всех необходимых пакетов npm. Если каких-либо пакетов не хватает (имеется значок с восклицательным знаком), можно щелкнуть правой кнопкой мыши узел npm и выбрать пункт Установить недостающие пакеты npm.

Изучение интегрированной среды разработки

1. Посмотрите на обозреватель решений в правой области.
   • Полужирным шрифтом выделен ваш проект, имя которого вы указали в окне Новый проект. На диске этот проект представлен файлом NJSPROJ в папке проекта.
   • Сверху представлено решение, имя которого по умолчанию совпадает с именем проекта. Решение, представленное на диске файлом SLN, является контейнером для одного или нескольких связанных проектов.
   • В узле npm представлены все установленные пакеты npm. Вы можете щелкнуть узел npm правой кнопкой мыши, чтобы найти и установить пакеты npm с помощью диалогового окна.
2. Чтобы установить пакеты npm или выполнить команды Node.js из командной строки, щелкните узел проекта правой кнопкой мыши и выберите пункт Открыть командную строку здесь.

Добавление VUE-файла в проект

1. В обозревателе решений щелкните правой кнопкой мыши любую папку, например src/components, а затем выберите Добавить>Новый элемент. Если вы не видите все шаблоны элементов, выберите «Показать все шаблоны» и выберите шаблон элемента.
2. Выберите Отдельный VUE-файл JavaScript или Отдельный VUE-файл TypeScript и нажмите кнопку Добавить. Среда Visual Studio добавит новый файл в проект.

Сборка проекта

1. Затем выберите Сборка>Собрать решение для сборки проекта.
2. Просмотрите результаты сборки в окне вывода и выберите Сборка в списке Показать выходные данные из.

В шаблоне проекта JavaScript Vue.js (и более ранних версиях шаблона TypeScript) используйте скрипт build npm, настроив событие после сборки. Если вы хотите изменить этот параметр, откройте файл проекта (.njsproj) в проводнике Windows и найдите следующую строку кода:

npm run build 

Выполнение приложения

1. Чтобы запустить приложение, нажмите клавиши CTRL+F5 (или выберите Отладка > Запуск без отладки). В консоли появится сообщение Запуск Development Server. Затем приложение откроется в браузере. Если сведения о работающем приложении не отображаются, обновите страницу.
2. Закройте веб-браузер.

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

MSBuild

Microsoft Build Engine представляет собой платформу для сборки приложений. Компонент MSBuild обеспечивает для файла проекта схему XML, определяющую способы, используемые платформой сборки для обработки и сборки приложений. Visual Studio использует MSBuild, но MSBuild не зависит от Visual Studio. Вызвав msbuild.exe или dotnet build в файле проекта или решения, вы можете оркестрировать и создавать продукты в средах, где Visual Studio не установлен.

Visual Studio использует MSBuild для загрузки и сборки управляемых проектов. Файлы проектов в Visual Studio (с расширением CSPROJ, VBPROJ, VCXPROJ) содержат код XML MSBuild, который выполняется при создании проекта с помощью интегрированной среды разработки. Проекты Visual Studio импортируют все необходимые параметры и процессы сборки для выполнения стандартной работы по разработке, но их можно расширять и изменять в Visual Studio или в редакторе XML.

Чтобы установить MSBuild в системе Windows, которая не имеет Visual Studio, перейдите в раздел «Средства сборки для Visual Studio » на странице загрузки. Установка MSBuild с помощью этого метода предоставляет MSBuild.exe.

Для .NET Core и .NET 5 или более поздней версии другой способ получения эквивалента MSBuild заключается в установке пакета SDK для .NET. Команда dotnet build сборки .NET доступна с помощью пакета SDK для .NET в macOS, Windows или Linux. Команда dotnet build сборки .NET — это тонкая оболочка по версии MSBuild.exe .NET Core. С помощью интерфейса командной строки .NET Core (CLI), использующего MSBuild, можно создавать проекты, предназначенные для .NET Core и .NET 5 и более поздних версий.

Начиная с Visual Studio 2022, при выполнении сборки в Visual Studio используется 64-разрядная версия MSBuild.

Сведения об MSBuild для C++ см. в разделе MSBuild (C++).

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

• Среда Visual Studio не установлена.
• Вам требуется 64-разрядная версия MSBuild, но вы используете Visual Studio 2019 или более ранней версии. Эта версия MSBuild обычно не нужна, но она позволяет MSBuild обращаться к большему объему памяти.
• Сборку требуется выполнять в нескольких процессах. Однако можно использовать интегрированную среду разработки, чтобы добиться того же результата для проектов на C++ и C#.
• Требуется изменить систему сборки. Например, может потребоваться выполнить следующие действия:
  • предварительная обработка файлов перед их компиляцией;
  • копирование выходных данных сборки в другое место;
  • создание сжатых файлов из выходных данных сборки;
  • пост-обработка. Например, может потребоваться присвоить сборке другой номер версии.

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

  С помощью Azure Pipelines можно автоматически компилировать, тестировать и развертывать приложение. Система сборки может автоматически запускать сборку, когда разработчики возвращают код (например, как часть стратегии непрерывной интеграции) или по расписанию (например, выполнять ежедневную ночную тестовую сборку). Azure Pipelines компилирует код с использованием MSBuild. Дополнительные сведения см. в описании Azure Pipelines.

  Вводное руководство по MSBuild в Windows см. в пошаговом руководстве по использованию MSBuild.

  Использование MSBuild в командной строке

  Чтобы запустить MSBuild из командной строки, передайте файл проекта в MSBuild.exe при использовании соответствующих параметров командной строки. Параметры командной строки позволяют задавать свойства, выполнять определенные целевые объекты и задавать другие параметры, управляющие процессом построения. Например, используя следующий синтаксис командной строки, можно создать файл MyProj.proj со свойством Configuration , для которого задается значение Debug .

  MSBuild.exe MyProj.proj -property:Configuration=Debug 

  Дополнительные сведения о параметрах командной строки MSBuild см. в статье Справочник по командной строке MSBuild.

  Перед загрузкой проекта определите, можно ли доверять коду.

  Для .NET Core и .NET 5 или более поздней версии обычно используется dotnet build для вызова MSBuild. См . dotnet build. Если вы устанавливаете только пакет SDK для .NET, а не Visual Studio или средства сборки Visual Studio, вы используете MSBuild только через dotnet build .

  В командной dotnet build —help строке перечислены параметры командной строки, относящиеся к dotnet build не всем параметрам MSBuild.exe, но вы по-прежнему можете использовать все параметры командной строки, перечисленные в справочнике командной строки MSBuild. Параметры, которые не обрабатываются dotnet build , передаются в MSBuild.

  Файл проекта

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

  Система сборки Visual Studio хранит логику для конкретного проекта в самом файле проекта и использует импортированные XML-файлы MSBuild с такими расширениями, как .props и .targets для определения стандартной логики сборки. Файлы определяют свойства MSBuild и .targets файлы определяют целевые .props объекты MSBuild. Эти импорты иногда отображаются в файле проекта Visual Studio, но в более новых проектах, таких как .NET Core, .NET 5 и .NET 6, импорт в файле проекта не отображается; Вместо этого вы увидите ссылку на пакет SDK, который выглядит следующим образом:

  Это так называемые проекты в стиле SDK. При ссылке на пакет SDK, например пакет SDK для .NET, импорты .props и .target файлы неявно указываются пакетом SDK.

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

  Свойства

  Свойства представляют пары ключ-значение, с помощью которых выполняется настройка построения. Для объявления свойства создается элемент с таким же именем как у свойства, который является дочерним по отношению к элементу PropertyGroup. Например, в следующем коде создается свойство BuildDir со значением Build .

   Build  

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

  DefaultValue 

  Для обращения к свойствам в файле проекта используется синтаксис $(). Например, к свойствам из предыдущих примеров можно обращаться с помощью конструкций $(BuildDir) и $(Configuration) .

  Дополнительные сведения о свойствах см. в разделе Свойства MSBuild.

  Товаров

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

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

  Для обращения к типам элементов в файле проекта используется синтаксис @(). Например, ссылка на тип элементов в этом примере выглядела бы следующим образом: @(Compile) .

  В MSBuild имена элементов и атрибутов задаются с учетом регистра. А имена свойств, элементов (item) и метаданных — нет. В следующем примере создается тип элементов Compile , comPile или любого другого варианта написания, и типу элементов присваивается значение «one.cs;two.cs».

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

  Задачи

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

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

  MSBuild включает стандартные задачи, которые можно изменять в соответствии с требованиями. Примеры: Copy — копирование файлов, MakeDir — создание каталогов, Csc — компиляция файлов исходного кода Visual C#. Список доступных задач и сведения об их использовании см. в справочнике по задачам.

  Задача выполняется в файле проекта MSBuild путем создания элемента с таким же именем как у задачи в виде дочернего элемента по отношению к элементу Target. Задачи, как правило, принимают параметры, которые передаются как атрибуты элемента. В качестве параметров можно использовать свойства и элементы MSBuild. Например, с помощью следующего кода вызывается задача MakeDir и ей передается значение свойства BuildDir , объявленного в предыдущем примере.

  Дополнительные сведения о задачах см. в разделе Задачи.

  Цели

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

  Целевые объекты объявляются в файле проекта с помощью элемента Target. Например, с помощью следующего кода создается целевой объект с именем Compile , который затем вызывает задачу Csc со списком элементов, объявленным в предыдущем примере.

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

  Журналы сборки

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

  Использование MSBuild в Visual Studio

  Visual Studio использует формат файла проекта MSBuild для хранения данных сборки об управляемых объектах. Параметры проекта, добавленные или измененные с помощью интерфейса Visual Studio, отражаются в файле .*proj, который создается для каждого проекта. Для построения управляемых проектов в Visual Studio используется размещенный экземпляр MSBuild. Это означает, что выполнить построение управляемого проекта можно в Visual Studio или в командной строке (даже при отсутствии Visual Studio), и результаты будут одинаковыми.

  Руководство по использованию MSBuild в Visual Studio см. в разделе Пошаговое руководство. Использование MSBuild.

  Настройка для различных версий

  С помощью Visual Studio можно скомпилировать приложение для запуска в любой из нескольких версий платформа .NET Framework или .NET Core, включая .NET 5 и более поздних версий. Например, можно скомпилировать приложение для запуска на платформа .NET Framework 4 на 32-разрядной платформе, и вы можете скомпилировать то же приложение для запуска на платформа .NET Framework 4.8 на 64-разрядной платформе. Возможность компиляции для нескольких платформ называется настройкой для различных версий.

  Ниже приведены несколько преимуществ настройки для различных версий:

  • Вы можете разрабатывать приложения, ориентированные на более ранние версии .NET Framework, например версии 3.5 и 4.7.2.
  • Можно ориентироваться на профиль платформы, который представляет собой предопределенное подмножество целевой платформы.
  • После появления пакета обновления для текущей версии .NET Framework можно выбрать его в качестве целевой платформы.
  • Поддержка различных платформ гарантирует, что приложение использует только те функциональные возможности, которые доступны в целевой версии .NET Framework и платформы.

  Дополнительные сведения см. в разделе Настройка для различных версий.

  Настройка сборки

  MSBuild поддерживает широкий спектр пользовательских сценариев сборки. Большинство встроенных функций можно переопределить или расширить. Дополнительные сведения см. в статье Настройка сборки и

  Доступ к MSBuild программным способом

  Если вы разрабатываете средство сборки, может потребоваться вызвать MSBuild программным способом из приложения .NET. С помощью API MSBuild можно управлять всеми аспектами сложной системы сборки. MSBuild предоставляет пакет NuGet с полным API (пространство имен Microsoft.Build), который можно использовать из приложения .NET для этих целей. См. раздел «Использование API MSBuild».

  MSBuild — это открытый код

  MSBuild — это проект с открытым исходным кодом, который принимает вклад пользователей, как и остальная часть экосистемы .NET. Репозиторий, содержащий источник MSBuild, доступен в репозитории GitHub: MSBuild GitHub.

  См. также

  Заголовок	Description
  Пошаговое руководство. Создание файла проекта MSBuild с нуля	Содержит описание способов пошагового создания основного файла проекта путем использования только текстового редактора.
  Пошаговое руководство. Использование MSBuild	Содержит вводную информацию о стандартных блоках MSBuild и описание способов записи, управления и отладки проектов MSBuild без выхода из интегрированной среды разработки Visual Studio.
  Основные понятия MSBuild	Содержит информацию о четырех стандартных блоках MSBuild: свойствах, элементах, целевых объектах и задачах.
  Товаров	Содержит описание общих понятий, относящихся к формату файлов MSBuild, и способов взаимодействия фрагментов.
  Свойства MSBuild	Содержит вводную информацию о свойствах и коллекциях свойств. Свойства представляют собой пары ключ-значение, с помощью которых выполняется настройка сборок.
  Целевые объекты	Содержит объяснение группировки задач в определенном порядке и вызова разделов процесса построения из командной строки.
  Задачи	Описывает процесс создания блока исполняемого кода, с помощью которого MSBuild выполняет атомарные операции построения.
  Условия	Рассматривает использование атрибута Condition в элементе MSBuild.
  Пакетная обработка	Описывает, как MSBuild классифицирует списки элементов по метаданным для выполнения в задачах и целевых объектах.
  Настройка для различных версий	Показывает, как использовать несколько версий .NET и (или) нескольких платформ.
  Получение журналов сборки	Описание возможностей записи в журнал событий, сообщений и ошибок сборки.
  Как MSBuild выполняет сборку проектов	Описывает внутренний процесс сборки, используемый в MSBuild.
  Создание настраиваемой задачи для создания кода	Инструкции по созданию настраиваемой задачи и пример кода.
  Использование MSBuild для создания клиента REST API	Инструкции по расширению сборки для работы с созданием клиента REST API и пример кода.
  Дополнительные ресурсы	Содержит список ресурсов сообщества и службы поддержки с дополнительной информацией о MSBuild.

  Ссылка

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

  Отладка приложений в локальном контейнере Docker

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

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

  В этой статье рассказывается, как запускать приложение в локальном контейнере Docker с помощью Visual Studio, вносить изменения и обновлять браузер для их отображения. В ней также показано, как устанавливать точки останова для отладки контейнерных приложений. Поддерживаются такие типы проектов: веб-приложение, консольное приложение и функция Azure для платформ .NET Framework и .NET Core. Примеры в этой статье — это проект веб-приложения ASP.NET Core и проект консольного приложения .NET Framework.

  Если у вас уже есть проект поддерживаемого типа, Visual Studio может создать Dockerfile и настроить проект для запуска в контейнере. Ознакомьтесь со статьей Средства для контейнеров в Visual Studio.

  Необходимые компоненты

  Для отладки приложений в локальном контейнере Docker необходимо установить следующие средства:

  • Visual Studio 2019 с установленной рабочей нагрузкой «Веб-разработка».
  • Visual Studio 2022 с установленной рабочей нагрузкой «Веб-разработка».

  Для запуска контейнеров Docker локально требуется локальный клиент Docker. Вы можете использовать Docker Desktop. Для этого требуется Windows 10 или более поздней версии.

  Создание веб-приложения.

  Пропустите этот раздел, если у вас есть проект и вы добавили поддержку Docker, как описано в обзоре.

  

  1. В начальном окне Visual Studio выберите Создать проект.
  2. Выберите пункт Веб-приложение ASP.NET Core и нажмите кнопку Далее.
  3. Введите имя нового приложения (или оставьте имя по умолчанию), укажите расположение на диске и нажмите кнопку ОК.
  4. Выберите версию .NET, которую нужно использовать в качестве целевой. Если вы не знаете, какую версию выбрать, выберите выпуск LTS (долгосрочная поддержка).
  5. Решите, требуется ли вам поддержка SSL, установив или сняв флажок Настроить для HTTPS.
  6. Установите флажок Включить поддержку Docker.
  7. Выберите тип контейнера (Windows или Linux) и нажмите кнопку Создать.

  

  1. В начальном окне Visual Studio выберите Создать проект.
  2. Выберите пункт Веб-приложение ASP.NET Core и нажмите кнопку Далее.
  3. Введите имя нового приложения (или оставьте имя по умолчанию), укажите расположение на диске и нажмите кнопку ОК.
  4. Выберите версию .NET, которую нужно использовать в качестве целевой. Если вы не знаете, какую версию выбрать, выберите выпуск LTS (долгосрочная поддержка).
  5. Решите, требуется ли вам поддержка SSL, установив или сняв флажок Настроить для HTTPS.
  6. Установите флажок Enable Docker (Включить Docker).
  7. В текстовом поле Docker OS (ОС Docker) выберите тип контейнера (Windows или Linux) и нажмите кнопку Создать.

  Изменение страниц Razor и обновление

  Для быстрого изменения страниц Razor можно запустить приложение в контейнере. Затем продолжайте вносить изменения, просматривая их так же, как в IIS Express.

  1. Убедитесь, что Docker настроен для применения типа контейнера (Linux или Windows), который вы используете. На панели задач щелкните правой кнопкой мыши значок Docker и выберите пункт Switch to Linux containers (Переключиться на контейнеры Linux) или Switch to Windows containers (Переключиться на контейнеры Windows) в зависимости от ситуации.
  2. (Только для .NET Core 3 и более поздних версий.) Изменение кода и обновление работающего сайта, описанные в этом разделе, не включены в шаблонах по умолчанию в .NET Core 3.0 и более поздних версий. Чтобы включить их, установить пакет NuGet Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation. В Startup.cs добавьте вызов метода расширения IMvcBuilder.AddRazorRuntimeCompilation в код в методе ConfigureServices . Этот параметр должен быть включен только в режиме отладки, поэтому код должен выглядеть следующим образом:

  public IWebHostEnvironment Env < get; set; >public void ConfigureServices(IServiceCollection services) < IMvcBuilder builder = services.AddRazorPages(); #if DEBUG if (Env.IsDevelopment()) < builder.AddRazorRuntimeCompilation(); >#endif // code omitted for brevity > 

  Измените метод Startup следующим образом.

  public Startup(IConfiguration configuration, IWebHostEnvironment webHostEnvironment)

  Hello from a Docker container!
   

  Now listening on: http://*:80 Application started. Press Ctrl+C to shut down. 

  Отладка с использованием точек останова

  Изменения часто требуют дальнейшей проверки. Для этого можно использовать функции отладки Visual Studio.

  1. В Visual Studio откройте файл Index.cshtml.cs.
  2. Замените содержимое метода OnGet следующим кодом:

   ViewData["Message"] = "Your application description page from within a container"; 

  

  

  Создание консольного приложения .NET Framework

  Этот раздел содержит сведения о том, как выполнять отладку для проекта консольного приложения .NET Framework в локальном контейнере Docker, вначале описывая, как обеспечить поддержку Docker в проекте. Важно понимать, что проекты разных типов имеют разные уровни поддержки Docker. Существуют даже различные уровни поддержки Docker для проектов консольного приложения .NET Core (включая .NET 5 и более поздних версий) и для проектов консольного приложения .NET Framework.

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

  Следующая процедура демонстрирует, как добавить поддержку оркестрации в проект консольного приложения .NET Framework, что впоследствии обеспечивает поддержку Docker и позволяет отлаживать проект в локальном контейнере Docker.

  1. Создайте проект консольного приложения .NET Framework.
  2. В обозревателе решений щелкните правой кнопкой мыши узел проекта и выберите Добавить>Container Orchestration Support (Поддержка оркестрации контейнеров). В появившемся диалоговом окне выберите Docker Compose. Файл Dockerfile будет добавлен в проект, а проект Docker Compose со вспомогательными файлами будет добавлен в решение.

  Отладка с использованием точек останова

  1. В обозревателе решений откройте файл Program.cs.
  2. Замените содержимое метода Main следующим кодом:

   System.Console.WriteLine("Hello, world!"); 

  

  Проверка подлинности в службах Azure с помощью прокси-сервера маркера

  При использовании служб Azure из контейнера можно использовать DefaultAzureCredential (с включенным VisualStudioCredential) для проверки подлинности со службами Azure с учетной записью Microsoft Entra без дополнительной конфигурации в контейнере. Чтобы включить эту функцию, см. инструкции по настройке средств контейнеров Visual Studio. Кроме того, необходимо настроить проверку подлинности Azure в Visual Studio, выполнив инструкции по проверке подлинности Visual Studio в Azure. Поддержка VisualStudioCredential в контейнере доступна в Visual Studio версии 17.6 и более поздних версиях.

  Функции Azure

  Если вы выполняете отладку интегрированного проекта Функции Azure и используете прокси-сервер маркера в контейнере для обработки проверки подлинности в службах Azure, необходимо скопировать среду выполнения .NET в контейнер для запуска прокси-сервера маркера. Если вы выполняете отладку изолированного проекта Функции Azure, он уже имеет среду выполнения .NET, поэтому для этого дополнительного шага нет необходимости.

  Чтобы обеспечить доступность среды выполнения .NET для прокси-сервера маркера, добавьте или измените debug слой в Dockerfile, который копирует среду выполнения .NET в образ контейнера. Для контейнеров Linux можно добавить следующий код в Dockerfile:

  # This layer is to support debugging, VS's Token Proxy requires the runtime to be installed in the container FROM mcr.microsoft.com/dotnet/runtime:8.0 AS runtime FROM base as debug COPY --from=runtime /usr/share/dotnet /usr/share/dotnet RUN ln -s /usr/share/dotnet/dotnet /usr/bin/dotnet 

  Кроме того, в проекте Visual Studio необходимо внести некоторые изменения, чтобы указать этот уровень, используемый при отладке в быстром режиме. Описание быстрого режима см. в разделе «Настройка контейнеров Docker» в Visual Studio. Для сценариев одного контейнера (не Docker Compose) задайте для свойства DockerfileFastModeStage debug MSBuild значение, чтобы использовать этот уровень для отладки. Для Docker Compose измените следующее docker-compose.vs.debug.yml :

  # Set the stage to debug to use an image with the .NET runtime in it services: functionappintegrated: build: target: debug 

  Пример кода проверки подлинности с Функции Azure, включая интегрированные и изолированные сценарии, см. в разделе VisualStudioCredentialExample.

  Повторное использование контейнеров

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

  Если вы вручную изменили контейнер и хотите выполнить перезапуск с чистым образом контейнера, выберите команду Сборка>Очистить, а затем выполните сборку как обычную.

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

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

  Устранить неполадки

  Следующие шаги

  Дополнительные сведения об использовании Docker с Visual Studio, Windows и Azure

  • Дополнительные сведения о разработке контейнеров с помощью Visual Studio.
  • Сведения о сборке и развертывании контейнера Docker см. в статье Интеграция Docker для Azure Pipelines.
  • Указатель статей, посвященных Windows Server и Nano Server, см. на странице Контейнеры в документации Windows.
  • Ознакомьтесь с общими сведениями о Службе Azure Kubernetes и документацией по Службе Azure Kubernetes.
  Читать:

  Как посмотреть настройки монитора на windows 10