Как запустить компиляцию в visual studio

Программная компиляция кода с помощью компилятора C#

В этой статье описывается компиляция кода из текстового источника с помощью компилятора C#.

Исходная версия продукта: Visual Studio, платформа .NET Framework
Исходный номер базы знаний: 304655

Аннотация

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

Требования

Visual Studio
Компилятор языка Visual C#

Компиляция кода с помощью компилятора C#

Платформа .NET Framework предоставляет интерфейс выполнения компилятора ICodeCompiler . Класс CSharpCodeProvider реализует этот интерфейс и предоставляет доступ к экземплярам генератора кода C# и компилятора кода. Следующий пример кода создает экземпляр CSharpCodeProvider и использует его для получения ссылки на ICodeCompiler интерфейс.

CSharpCodeProvider codeProvider = new CSharpCodeProvider(); ICodeCompiler icc = codeProvider.CreateCompiler();

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

System.CodeDom.Compiler.CompilerParameters parameters = new CompilerParameters(); parameters.GenerateExecutable = true; parameters.OutputAssembly = Output; CompilerResults results = icc.CompileAssemblyFromSource(parameters,SourceString);

Приведенный выше код использует CompilerParameters объект , чтобы сообщить компилятору, что вы хотите создать исполняемый файл (в отличие от БИБЛИОТЕКи DLL) и что вы хотите вывести результируемую сборку на диск. CompileAssemblyFromSource Вызов — это место, где компилируется сборка. Этот метод принимает объект параметров и исходный код, который является строкой. После компиляции кода можно проверить наличие ошибок компиляции. Используйте возвращаемое значение из CompileAssemblyFromSource , которое является CompilerResults объектом . Этот объект содержит коллекцию ошибок, которая содержит все ошибки, возникшие во время компиляции.

if (results.Errors.Count > 0) < foreach(CompilerError CompErr in results.Errors) < textBox2.Text = textBox2.Text + "Line number " + CompErr.Line + ", Error Number: " + CompErr.ErrorNumber + ", '" + CompErr.ErrorText + ";" + Environment.NewLine + Environment.NewLine; >>

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

Пошаговый пример процедуры

Создайте новое приложение .NET для .NET для Visual C# для Windows. Форма Form1 создается по умолчанию.
Добавьте элемент управления Button в Form1, а затем измените его свойство Text на Build.
Добавьте еще один элемент управления Button в Form1, а затем измените его свойство Text на Run.
Добавьте два элемента управления TextBox в Form1, задайте для свойства Multiline для обоих элементов управления значение True, а затем размер этих элементов управления, чтобы можно было вставить несколько строк текста в каждый элемент управления.
В редакторе кода откройте исходный файл Form1.cs .
Form1 Вставьте в класс следующий обработчик нажатия кнопки.

private void button1_Click(object sender, System.EventArgs e) < CSharpCodeProvider codeProvider = new CSharpCodeProvider(); ICodeCompiler icc = codeProvider.CreateCompiler(); string Output = "Out.exe"; Button ButtonObject = (Button)sender; textBox2.Text = ""; System.CodeDom.Compiler.CompilerParameters parameters = new CompilerParameters(); //Make sure we generate an EXE, not a DLL parameters.GenerateExecutable = true; parameters.OutputAssembly = Output; CompilerResults results = icc.CompileAssemblyFromSource(parameters, textBox1.Text); if (results.Errors.Count >0) < textBox2.ForeColor = Color.Red; foreach (CompilerError CompErr in results.Errors) < textBox2.Text = textBox2.Text + "Line number " + CompErr.Line + ", Error Number: " + CompErr.ErrorNumber + ", '" + CompErr.ErrorText + ";" + Environment.NewLine + Environment.NewLine; >> else < //Successful Compile textBox2.ForeColor = Color.Blue; textBox2.Text = "Success!"; //If we clicked run then launch our EXE if (ButtonObject.Text == "Run") Process.Start(Output); >>

В начале файла добавьте следующие using операторы:

using System.CodeDom.Compiler; using System.Diagnostics; using Microsoft.CSharp;

public Form1()

Примечание. Возникает ошибка компилятора.

using System; namespace HelloWorld < /// /// Summary description for Class1. ///
 class HelloWorldClass < static void Main(string[] args) < Console.WriteLine("Hello World!"); Console.ReadLine(); >> >

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

Ссылки

Класс CSharpCodeProvider
Интерфейс ICodeCompiler

Обратная связь

Были ли сведения на этой странице полезными?

Указание событий сборки (Visual Basic)

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

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

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

Visual Basic Express не поддерживает запись событий сборки. Она поддерживается только в полных версиях Visual Studio.

Указание событий перед сборкой и после нее

Чтобы указать событие сборки

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

Примечание. Добавьте оператор call перед всеми командами после сборки, запускающими BAT-файлы. Например, call C:\MyFile.bat или call C:\MyFile.bat call C:\MyFile2.bat .

Примечание. Если событие перед сборкой или после сборки завершается ошибкой, можно прервать сборку, задав завершение действия события с кодом, отличным от нуля (0), что означает успешное выполнение действия.

Пример: как изменить данные манифеста с помощью события после сборки

В следующей процедуре демонстрируется, как задать минимальную версию операционной системы в манифесте приложения с помощью команды EXE, вызываемой из события после сборки (файл exe.manifest в каталоге проекта). Минимальная версия операционной системы — число из четырех частей, например 4.10.0.0. Чтобы это сделать, команда изменит раздел манифеста:

Чтобы создать команду EXE для изменения манифеста приложения

Создайте консольное приложение для команды. В меню Файл выберите команду Создать, а затем — Проект.
В диалоговом окне Новый проект в узле Visual Basic выберите Приложение Windows, а затем шаблон Консольное приложение. Присвойте проекту имя ChangeOSVersionVB .
В Module1.vb добавьте следующую строку для других операторов Imports в верхней части файла:

Imports System.Xml

Sub Main() Dim applicationManifestPath As String applicationManifestPath = My.Application.CommandLineArgs(0) Console.WriteLine("Application Manifest Path: " & applicationManifestPath.ToString) 'Get version name Dim osVersion As Version If My.Application.CommandLineArgs.Count >= 2 Then osVersion = New Version(My.Application.CommandLineArgs(1).ToString) Else Throw New ArgumentException("OS Version not specified.") End If Console.WriteLine("Desired OS Version: " & osVersion.ToString()) Dim document As XmlDocument Dim namespaceManager As XmlNamespaceManager namespaceManager = New XmlNamespaceManager(New NameTable()) With namespaceManager .AddNamespace("asmv1", "urn:schemas-microsoft-com:asm.v1") .AddNamespace("asmv2", "urn:schemas-microsoft-com:asm.v2") End With document = New XmlDocument() document.Load(applicationManifestPath) Dim baseXPath As String baseXPath = "/asmv1:assembly/asmv2:dependency/asmv2:dependentOS/asmv2:osVersionInfo/asmv2:os" 'Change minimum required OS Version. Dim node As XmlNode node = document.SelectSingleNode(baseXPath, namespaceManager) node.Attributes("majorVersion").Value = osVersion.Major.ToString() node.Attributes("minorVersion").Value = osVersion.Minor.ToString() node.Attributes("buildNumber").Value = osVersion.Build.ToString() node.Attributes("servicePackMajor").Value = osVersion.Revision.ToString() document.Save(applicationManifestPath) End Sub

Чтобы вызвать событие после сборки для изменения манифеста приложения

Создайте приложение Windows для проекта, который должен быть опубликован. В меню Файл выберите команду Создать, а затем — Проект.
В диалоговом окне Новый проект в узле Visual Basic выберите Рабочий стол Windows, а затем шаблон Приложение Windows Forms. Присвойте проекту имя VBWinApp .
Выберите проект в обозревателе решений, а затем в меню Проект щелкните пункт Свойства.
В конструкторе проектов перейдите на страницу Публикация и для параметра Расположение публикации задайте значение C:\TEMP.
Опубликуйте проект, щелкнув Опубликовать сейчас. Будет выполнена сборка файла манифеста, и он будет помещен в каталог C:\TEMP\VBWinApp_1_0_0_0\VBWinApp.exe.manifest. Чтобы просмотреть манифест, щелкните правой кнопкой мыши файл и выберите пункт Открыть с помощью, затем выберите Выбрать программу из списка и щелкните Блокнот. Найдите в файле элемент . Например, версия может быть следующей:

См. также

Страница «Компиляция» в конструкторе проектов (Visual Basic)
Сведения о странице публикации в конструкторе проектов
Сведения о диалоговых окнах «Командная строка события перед сборкой» и «Командная строка события после сборки»
Практическое руководство. Назначение событий сборки (C#)

Настройка контейнеров Docker в Visual Studio

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

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

Предположим, вы хотите внести изменения в Dockerfile и увидеть результаты отладки и рабочих контейнеров. В этом случае можно добавить команды в Dockerfile, чтобы изменить первый этап (обычно base ). См. раздел Изменение образа контейнера для среды отладки и рабочей среды. Но если вы хотите внести изменения только для среды отладки, но не рабочей среды, вам следует создать еще один этап и использовать параметр сборки DockerfileFastModeStage , чтобы указать Visual Studio использовать этот этап для отладочных сборок. См. раздел Изменение образа контейнера только для среды отладки.

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

Многоэтапная сборка

Когда в Visual Studio выполняется сборка проекта, который не использует контейнеры Docker, на локальном компьютере вызывается MSBuild и создаются выходные файлы в папке (обычно bin ), вложенной в локальную папку решения. Однако для контейнерного проекта в процессе сборки учитываются инструкции из файла Dockerfile. Сборка с помощью Dockerfile в Visual Studio делится на несколько этапов. При этом применяется функция многоэтапной сборки Docker.

Функция многоэтапной сборки повышает эффективность сборки контейнеров и позволяет уменьшить их размер, так как они содержат только тот код, который требуется приложению во время выполнения. Многоэтапная сборка применяется для проектов .NET Core, но не для проектов .NET Framework.

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

FROM mcr.microsoft.com/dotnet/aspnet:3.1-buster-slim AS base WORKDIR /app EXPOSE 80 EXPOSE 443

Сначала в Dockerfile используется образ ASP.NET из реестра контейнеров Майкрософт (mcr.microsoft.com) для создания промежуточного образа base , для которого открываются порты 80 и 443, и определения рабочей папки /app .

Следующий этап — build . Выглядит он так:

FROM mcr.microsoft.com/dotnet/sdk:3.1-buster-slim AS build WORKDIR /src COPY ["WebApplication43/WebApplication43.csproj", "WebApplication43/"] RUN dotnet restore "WebApplication43/WebApplication43.csproj" COPY . . WORKDIR "/src/WebApplication43" RUN dotnet build "WebApplication43.csproj" -c Release -o /app/build

Как вы видите, на этапе build вместо продолжения работы с образом base берется другой исходный образ из реестра ( sdk , а не aspnet ). Образ sdk содержит все средства сборки и поэтому гораздо больше, чем образ aspnet, который содержит только компоненты времени выполнения. Причина использования отдельного образа становится очевидной, если посмотреть на остальную часть файла Dockerfile:

FROM build AS publish RUN dotnet publish "WebApplication43.csproj" -c Release -o /app/publish FROM base AS final WORKDIR /app COPY --from=publish /app/publish . ENTRYPOINT ["dotnet", "WebApplication43.dll"]

Последний этап снова начинается с образа base и включает в себя команду COPY —from=publish , которая копирует опубликованные выходные данные в итоговый образ. Это позволяет значительно уменьшить итоговый образ, так как в него не нужно включать все средства сборки, которые имелись в образе sdk .

Сборка из командной строки

Если нужно выполнить сборку вне Visual Studio, можно использовать docker build или MSBuild для построения из командной строки.

docker build

Для сборки контейнерного решения из командной строки обычно можно использовать команду docker build для каждого проекта в решении. Укажите аргумент build context. build context для Dockerfile — это папка на локальном компьютере, которая служит рабочей папкой для создания образа. Например, из нее копируются файлы в контейнер. Для проектов .NET Core используйте папку, содержащую файл решения (SLN). При использовании относительного пути этот аргумент обычно имеет значение «..» для Dockerfile в папке проекта и файла решения в родительской папке. Для проектов .NET Framework контекст сборки — это папка проекта, а не решения.

docker build -f Dockerfile ..

MSBuild

Dockerfiles, созданные Visual Studio для проектов платформа .NET Framework (и для проектов .NET Core, созданных с использованием версий Visual Studio до Visual Studio 2017 с обновлением 4), не являются многоэтапными файлами Dockerfile. Действия, описанные в этих файлах Dockerfile, не компилируют код. Вместо этого, когда среда Visual Studio выполняет сборку с помощью Dockerfile для .NET Framework, она сначала компилирует проект с помощью MSBuild. Если компиляция завершилась успешно, Visual Studio выполняет сборку Dockerfile. При этом выходные данные сборки из MSBuild просто копируются в полученный образ Docker. Так как инструкции по компиляции кода не включаются в Dockerfile, выполнять сборку файлов Dockerfile для .NET Framework с помощью команды docker build из командной строки невозможно. Для сборки таких проектов следует использовать MSBuild.

Чтобы создать образ для одного проекта контейнера Docker, можно использовать MSBuild с параметром /t:ContainerBuild команды. Эта команда сообщает MSBuild создать целевой объект ContainerBuild , а не целевой объект Build по умолчанию. Например:

MSBuild MyProject.csproj /t:ContainerBuild /p:Configuration=Release

При сборке решения из интегрированной среды разработки Visual Studio отображаются выходные данные, аналогичные тому, что отображается в окне вывода . Всегда используйте /p:Configuration=Release , так как при применении оптимизации многоэтапной сборки в Visual Studio результаты сборки в конфигурации отладки могут отличаться от ожидаемых. См. раздел Отладка.

Если вы используете проект Docker Compose, используйте эту команду для создания образов:

msbuild /p:SolutionPath=.sln /p:Configuration=Release docker-compose.dcproj

Прогрев проекта

Под прогревом проекта понимается последовательность действий, которая выполняется при выборе профиля Docker для проекта (то есть при загрузке проекта или добавлении поддержки Docker) с целью оптимизировать его производительность при последующих запусках (F5 или CTRL+F5). Это поведение можно настроить в разделе «Средства > параметров>контейнера». Ниже описываются задачи, которые выполняются в фоновом режиме:

Проверка установки и запуска Docker Desktop.
Проверка того, что для Docker Desktop и проекта задана одна и та же операционная система.
Извлечение образа на первом этапе файла Dockerfile (этап base в большинстве файлов Dockerfile).
Создание файла Dockerfile и запуск контейнера.

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

Сопоставление томов

Чтобы реализовать отладку в контейнерах, Visual Studio использует сопоставление томов для сопоставления отладчика и папок NuGet с хост-компьютера. Сопоставление томов описано в документации по Docker. Сопоставления томов для контейнера можно просмотреть с помощью окна «Контейнеры» в Visual Studio.

Ниже перечислены тома, которые подключаются в контейнере:

Громкость	Description
Папка приложения	Содержит папку проекта, в которой располагается файл Dockerfile.
Папки пакетов NuGet	Содержит пакеты NuGet и резервные папки, которые считываются из файла obj.csproj.nuget.g.props в проекте.
Удаленный отладчик	Содержит компоненты, необходимые для запуска отладчика в контейнере, в соответствии с типом проекта. См. раздел «Отладка».
Исходная папка	Содержит контекст сборки, который передается в команды Docker.

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

Громкость	Description
Папка приложения	Содержит папку проекта, в которой располагается файл Dockerfile.
HotReloadAgent	Содержит файлы для агента горячей перезагрузки.
HotReloadProxy	Содержит файлы, необходимые для запуска службы, которая позволяет агенту перезагрузки узла взаимодействовать с Visual Studio на узле.
Папки пакетов NuGet	Содержит пакеты NuGet и резервные папки, которые считываются из файла obj.csproj.nuget.g.props в проекте.
Удаленный отладчик	Содержит компоненты, необходимые для запуска отладчика в контейнере, в соответствии с типом проекта. Это объясняется более подробно в разделе Отладка.
Исходная папка	Содержит контекст сборки, который передается в команды Docker.
TokenService.Proxy	Содержит файлы, необходимые для запуска службы, которая позволяет VisualStudioCredential взаимодействовать с Visual Studio на узле.

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

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

В целях диагностики можно включить определенные журналы средств контейнеров. Эти журналы можно включить, задав определенные переменные среды. Для проектов одного контейнера переменная среды — это MS_VS_CONTAINERS_TOOLS_LOGGING_ENABLED переменная среды, которая затем входит в %tmp%\Microsoft.VisualStudio.Containers.Tools систему. Для проектов %tmp%\Microsoft.VisualStudio.DockerCompose.Tools Docker Compose это MS_VS_DOCKER_TOOLS_LOGGING_ENABLED значит, что затем выполняет вход.

Если ведение журнала включено и вы используете прокси-сервер маркера для проверки подлинности Azure, учетные данные проверки подлинности могут быть записаны как обычный текст. См. статью «Настройка проверки подлинности Azure».

Отладка

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

В быстром режиме Visual Studio вызывается docker build с аргументом, который сообщает Docker создать только первый этап в Dockerfile (обычно этап base ). Это можно изменить, задав свойство MSBuild, DockerfileFastModeStage описанное в свойствах MSBuild для контейнеров. Остальные этапы процесса выполняет сама среда Visual Studio с учетом содержимого Dockerfile. Поэтому, когда вы изменяете файл Dockerfile, например для настройки среды контейнера или установки дополнительных зависимостей, изменения должны вноситься на первом этапе. Любые пользовательские шаги, размещенные в dockerfile build , publish или final этапы не выполняются.

Данная оптимизация производительности применяется только при сборке в конфигурации отладки. В конфигурации выпуска сборка выполняется в контейнере, как указано в Dockerfile.

Чтобы отключить оптимизацию производительности и выполнить сборку, как указано в Dockerfile, присвойте свойству ContainerDevelopmentMode значение Regular в файле проекта следующим образом:

 Regular

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

При запуске отладки (F5) используется ранее запущенный контейнер, если это возможно. Если вы не хотите повторно использовать имеющийся контейнер, можно выбрать в Visual Studio команду Перестроить или Очистить, чтобы использовался новый контейнер.

Процесс запуска отладчика зависит от типа проекта и операционной системы контейнера:

Сценарий	Процесс отладчика
Приложения .NET Core (контейнеры Linux)	Visual Studio скачивает vsdbg и сопоставляет его с контейнером. Затем он вызывается в программе с соответствующими аргументами ( dotnet webapp.dll ), после чего к процессу привязывается отладчик.
Приложения .NET Core (контейнеры Windows)	Visual Studio использует onecoremsvsmon и сопоставляет его с контейнером. После этого он запускается в качестве точки входа, а затем Visual Studio устанавливает подключение к нему и привязывает его к программе. Этот процесс аналогичен типовой настройке удаленной отладки на другом компьютере или виртуальной машине.
Приложения .NET Framework	Visual Studio использует msvsmon и сопоставляет его с контейнером. После этого он запускается в составе точки входа, где Visual Studio может установить подключение к нему и привязать его к программе.

Изменение образа контейнера для среды отладки и рабочей среды

Чтобы изменить образ контейнера для среды отладки и рабочей среды, измените этап base . Добавьте настройки в Dockerfile в раздел базового этапа; как правило, это первый раздел в Dockerfile. Дополнительные сведения о командах Dockerfile см. в разделе Справочник по Dockerfile в документации по Dockerfile.

FROM mcr.microsoft.com/dotnet/aspnet:6.0 AS base WORKDIR /app EXPOSE 80 EXPOSE 443 # FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build WORKDIR /src COPY ["WebApplication3/WebApplication3.csproj", "WebApplication3/"] RUN dotnet restore "WebApplication3/WebApplication3.csproj" COPY . . WORKDIR "/src/WebApplication3" RUN dotnet build "WebApplication3.csproj" -c Release -o /app/build FROM build AS publish RUN dotnet publish "WebApplication3.csproj" -c Release -o /app/publish FROM base AS final WORKDIR /app COPY --from=publish /app/publish . ENTRYPOINT ["dotnet", "WebApplication3.dll"]

Изменение образа контейнера только для среды отладки

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

Чтобы изменить контейнер только для отладки, создайте этап, а затем используйте свойство DockerfileFastModeStage MSBuild, чтобы указать Visual Studio использовать настроенный этап при отладке. Дополнительные сведения о командах Dockerfile см. в разделе Справочник по Dockerfile в документации по Dockerfile.

В следующем примере мы устанавливаем пакет procps-ng , но только в режиме отладки. Этот пакет предоставляет команду pidof , требуемую Visual Studio, но не используется в образе Mariner, используемом здесь. Этап, который мы используем для отладки в быстром режиме, — это debug , пользовательский этап, определенный здесь. Этап быстрого режима не должен наследоваться от этапа или publish наследовать его непосредственно от build base этапа, так как Visual Studio подключает том, содержащий все необходимое для запуска приложения, как описано ранее в этой статье.

#See https://aka.ms/containerfastmode to understand how Visual Studio uses this Dockerfile to build your images for faster debugging. FROM mcr.microsoft.com/dotnet/aspnet:6.0-cbl-mariner2.0 AS base WORKDIR /app EXPOSE 80 EXPOSE 443 FROM base AS debug RUN tdnf install procps-ng -y FROM mcr.microsoft.com/dotnet/sdk:6.0-cbl-mariner2.0 AS build WORKDIR /src COPY ["WebApplication1/WebApplication1.csproj", "WebApplication1/"] RUN dotnet restore "WebApplication1/WebApplication1.csproj" COPY . . WORKDIR "/src/WebApplication1" RUN dotnet build "WebApplication1.csproj" -c Release -o /app/build FROM build AS publish RUN dotnet publish "WebApplication1.csproj" -c Release -o /app/publish FROM base AS final WORKDIR /app COPY --from=publish /app/publish . ENTRYPOINT ["dotnet", "WebApplication1.dll"]

В файле проекта добавьте этот параметр, чтобы указать Visual Studio использовать ваш пользовательский этап debug при отладке.

   debug

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

Точка входа контейнера

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

Тип контейнера	Точка входа
Контейнеры Linux	В качестве точки входа используется tail -f /dev/null , представляющая собой бесконечный цикл ожидания, в рамках которого обеспечивается выполнение контейнера. Когда приложение запускается через отладчик, это отладчик, который отвечает за запуск приложения (т dotnet webapp.dll . е. ). При запуске без отладки инструментарий выполняет docker exec -i dotnet webapp.dll для запуска приложения.
Контейнеры Windows	Точка входа — это то, что C:\remote_debugger\x64\msvsmon.exe /noauth /anyuser /silent /nostatus запускает отладчик, поэтому он прослушивает подключения. Этот метод применяется, когда отладчик запускает приложение. При запуске без отладки используется команда docker exec . Для веб-приложений .NET Framework точка входа несколько отличается: к команде добавляется ServiceMonitor .

Тип контейнера

Точка входа

Контейнеры Linux

В качестве точки входа используется tail -f /dev/null , представляющая собой бесконечный цикл ожидания, в рамках которого обеспечивается выполнение контейнера. Когда приложение запускается через отладчик, это отладчик, который отвечает за запуск приложения (т dotnet webapp.dll . е. ). При запуске без отладки инструментарий выполняет docker exec -i dotnet webapp.dll для запуска приложения.

Контейнеры Windows

Точка входа — это то, что C:\remote_debugger\x64\msvsmon.exe /noauth /anyuser /silent /nostatus запускает отладчик, поэтому он прослушивает подключения. Этот метод применяется, когда отладчик запускает приложение. При запуске без отладки используется команда docker exec . Для веб-приложений .NET Framework точка входа несколько отличается: к команде добавляется ServiceMonitor .

Точку входа контейнера можно изменить только в проектах docker-compose. В проектах с одним контейнером сделать это нельзя.

Приложения ASP.NET Core с поддержкой SSL

Инструменты для контейнеров в Visual Studio поддерживают отладку в приложениях ASP.NET Core с поддержкой SSL с использованием сертификата разработки так же, как и при работе без контейнеров. Для этого Visual Studio выполняет несколько дополнительных действий для экспорта сертификата и предоставления контейнеру доступа к нему. Ниже приведена процедура, выполняемая средой Visual Studio при отладке в контейнере.

С помощью средства dev-certs проверяется наличие доверенного сертификата разработки на хост-компьютере.
Сертификат экспортируется в папку %APPDATA%\ASP.NET\Https с использованием надежного пароля, который находится в хранилище секретных ключей пользователей для этого приложения.
Том подключает следующие каталоги:
- %APPDATA%\Microsoft\UserSecrets
- %APPDATA%\ASP.NET\Https

ASP.NET Core ищет сертификат, соответствующий имени сборки в папке Https , поэтому он сопоставляется с контейнером в этом пути. Путь к сертификату и пароль также можно определить с помощью переменных среды ( ASPNETCORE_Kestrel__Certificates__Default__Path и ASPNETCORE_Kestrel__Certificates__Default__Password ) или в JSON-файле секретных ключей пользователей, например следующим образом:

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

Дополнительные сведения о поддержке SSL в приложениях ASP.NET Core в контейнерах см. в разделе Размещение образов ASP.NET Core с Docker через HTTPS.

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

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

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

Русские Блоги

Компиляция программ C / C ++ в Visual Studio Code [1] -MinGW-W64

Каталог статей

Предисловие
Инструменты / программное обеспечение для подготовки
меры
- 1. Установите VS Code
- 2. Установите расширение C / C ++ для VS Code.
- 3. Установите MinGW-W64.
- 4. Добавьте MinGW-W64 в путь
- 5. Создайте новый проект.
- 6. Создайте и отредактируйте файл конфигурации в VS Code.
  - task.json
  - launch.json
  - c_cpp_properties.json
  - О папке .vscode
  Предисловие
  
  Visual Studio Code (далее VS Code) — один из самых популярных редакторов кода на данный момент. Он имеет открытый исходный код, кроссплатформенный, поддерживает несколько языков, богатые расширения и удобный пользовательский интерфейс. В то же время он учитывает функции некоторых IDE, таких как IntelliSense, компиляция, Отладка и т. Д. Сделали его популярным среди программистов. Но поскольку это, по сути, просто текстовый редактор, когда он был впервые установлен, в нем не было ничего, кроме основных функций редактирования, что заставляло некоторых пользователей, только начинающих работать, путаться. Поэтому, основываясь на моем собственном опыте, я кратко расскажу об установке VS Code и MinGW-W64, а также о том, как использовать MinGW-W64 для компиляции программ C / C ++ во вновь установленном VS Code.
  
  Инструменты / программное обеспечение для подготовки
  - Windows 10
  - Visual Studio Code
  - MinGW-W64
  меры
  
  1. Установите VS Code
  
  Сначала мы начнем сОфициальный сайт VS CodeСкачайте последнюю версию, откройте установщик и согласитесь с соглашением.
  
  Для других задач подбирайте их по мере необходимости. Рекомендуется проверить их все. Так будет намного удобнее для дальнейшей работы
  
  Подтвердите правильность и начните установку.
  
  Запустите VS Code, чтобы проверить, может ли он работать нормально
  
  2. Установите расширение C / C ++ для VS Code.
  
  Нажмите кнопку «Расширение» на правой боковой панели.
  
  Выберите тот, который показан на рисунке ниже, нажмите «Установить», чтобы установить
  
  Здесь нам нужно только это одно расширение. Фактически, VS Code имеет множество полезных расширений, что является одной из причин, почему VS Code так популярен. В будущем будет возможность опубликовать отдельную статью, в которой будут представлены эти часто используемые плагины и способы их использования.
  
  3. Установите MinGW-W64.
  
  Мы начинаем сОфициальный сайт MinGW-W64Скачайте установщик и выполните установку
  
  После «Далее» измените параметры, как показано на рисунке ниже, а затем перейдите к следующему шагу.
  
  На этом этапе обратите внимание, что каталог установки по умолчанию C:\Program Files\mingw-w64\x86_64-8.1.0-win32-seh-rt_v6-rev0 , Но чтобы предотвратить некоторые возможные ошибки, мы должны установить его в путь без пробелов, например C:\mingw-w64\x86_64-8.1.0-win32-seh-rt_v6-rev0 (В этом руководстве это используется в качестве примера, как показано ниже)
  
  После нажатия кнопки «Далее» начнется установка.
  Воспользуйтесь предоставленной мной ссылкой, чтобы загрузить программу онлайн-установки. Если читатели столкнутся с проблемами, связанными с сетью, вы можете найти автономный установочный пакет соответствующей версии в Интернете.
  После завершения установки нажмите «Далее», а затем «Готово».
  
  4. Добавьте MinGW-W64 в путь
  
  Теперь нам нужно поместить двоичный файл в каталог MinGW-W64. C:\mingw-w64\x86_64-8.1.0-win32-seh-rt_v6-rev0\mingw64\bin (Измените этот путь на свой собственный) Добавьте в системную переменную окружения Путь, метод работы следующий
  Откройте панель управления и выберитеСистема и безопасность> Система , А затем щелкните порядок, как показано ниже, чтобы добавить переменные среды
  
  Или обратитесь к другому моему руководству:Как добавить Python в системную переменную окружения Path в Win10, Метод аналогичен
  
  5. Создайте новый проект.
  
  Сначала создадим новый проект. Создайте новую папку в своем любимом каталоге, я создам здесь новую hello_world папка. Войдите в папку, щелкните правой кнопкой мыши пустое пространство и выберите «Открыть с помощью кода». (Вы также можете открыть папку в программе VS Code)
  
  После открытия нажмите кнопку ниже, чтобы создать новый файл с именем hello_world.cpp
  
  Примечание. Необходимо вручную ввести расширение файла. .cpp , Чтобы правильно определить тип файла и включить IntelliSense
  
  Затем вводим следующие
```
#include int main()  std::cout  <"Hello World!"  ::endl; return 0; > 
```
  Ctrl + S сохранить
  
  6. Создайте и отредактируйте файл конфигурации в VS Code.
  
  Затем нам нужно сгенерировать файлы конфигурации, необходимые для компиляции (Compile) и отладки (Debug). Сначала мы генерируем файл конфигурации, используемый для компиляции tasks.json
  
  task.json
  
  Нажмите Ctrl+Shift+P Сочетание клавиш, во всплывающем окне найдите Задачи, выберите Настроить задачу сборки по умолчанию.
  
  и выберите g++ Это третий на картинке ниже
  
  Теперь у нас есть файл конфигурации по умолчанию. tasks.json следующим образом
  
  Примечание: мы можем получить больше информации об этом файле по ссылке в комментарии
  
  Теперь вернемся к hello_world.cpp , Вы можете использовать его напрямую Ctrl+Shift+B Ярлык для компиляции файла
  
  Вы можете видеть, что скомпилированный hello_world.exe файл. Нажмите Ctrl + Сочетание клавиш, чтобы открыть Терминал с VS Code, введите . \ hello_world.exe`, вы можете запустить напрямую
  
  launch.json
  
  Когда мы включаем GDB для отладки, нам понадобится еще один launch.json
  выберите в верхней строке менюDebug > Add Configuration…
  
  и выберите C++ (GDB/LLDB)
  
  , затем выберите g++ Вон тот
  
  VS Code автоматически запустит отладку и сгенерирует launch.json Файл, как показано ниже
  
  Теперь отладка по умолчанию запускается в терминале ниже. Если нам нужно отдельное окно командной строки, мы можем добавить «externalConsole»: false средний false Чтобы true , А затем отлаживайте эффект следующим образом
  
  Примечание. Подробнее об этом файле можно узнать по ссылке в комментарии к файлу launch.json.
  
  c_cpp_properties.json
  
  Если мы хотим дополнительно настроить соответствующую конфигурацию расширения C / C ++, мы можем создать c_cpp_properties.json , Есть два способа использования UI и json
  Ctrl+Shift+P , Найдите c / c ++, выберите любое из следующих изображений (пользовательский интерфейс — графическая операция, JSON — метод редактирования текста)
  
  Ниже приводится обзор параметров (без усечения).
  
  Здесь нет необходимости в дополнительных операциях, просто установите его на мое изображение выше.
  
  О папке .vscode
  
  Мы видим еще один в папке .vscode В папке находится только что сгенерированный файл конфигурации. Поскольку то, что мы создали раньше, является общими файлами шаблонов, каждый раз, когда мы создаем новый проект в будущем, нам нужно только .vscode Скопируйте в соответствующую папку, отредактируйте и настройте по мере необходимости, вы можете напрямую использовать сочетания клавиш для компиляции и отладки, без необходимости повторять процесс снова
  
  хвостик
  
  На данный момент руководство по использованию MinGW-W64 для компиляции программ C / C ++ в Visual Studio Code закончено.
  
  Это руководство написано на основе моего собственного опыта. Если есть упущения и ошибки, вы можете исправить меня.
  Похожие публикации: