Skip to content

Commit 8838505

Browse files
Learn Build Service GitHub AppLearn Build Service GitHub App
authored andcommitted
Merging changes synced from https://github.com/MicrosoftDocs/visualstudio-docs-pr (branch live)
2 parents b07d2c1 + f0e4387 commit 8838505

29 files changed

+1344
-196
lines changed

.github/workflows/clean-repo.yml

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -17,7 +17,7 @@ jobs:
1717

1818
steps:
1919
- name: Harden Runner
20-
uses: step-security/harden-runner@ec9f2d5744a09debf3a187a3f4f675c53b671911 # v2.13.0
20+
uses: step-security/harden-runner@f4a75cfd619ee5ce8d5b864b0d183aff3c69b55a # v2.13.1
2121
with:
2222
egress-policy: audit
2323

auto-publish.yaml

Lines changed: 0 additions & 45 deletions
This file was deleted.

docs/containers/add-container-support.md

Lines changed: 163 additions & 23 deletions
Large diffs are not rendered by default.

docs/containers/container-build-from-command-line.md

Lines changed: 84 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -3,27 +3,66 @@ title: Build a containerized Visual Studio project from the command line
33
author: ghogen
44
description: Build a container project in Visual Studio using the command line, either with MSBuild.exe or using Docker build, and learn how to enable detailed build logs.
55
ms.author: ghogen
6-
ms.date: 09/17/2024
6+
ms.date: 9/10/2025
77
ms.subservice: container-tools
88
ms.topic: how-to
99
---
1010

1111
# Build a container project from the command line
1212

13-
If you want to build a container project with a Dockerfile outside of Visual Studio, you can use `docker build`, `MSBuild`, `dotnet build`, or `dotnet publish` to build from the command line.
13+
:::moniker range="visualstudio"
14+
If you want to build a container project with a Dockerfile outside of Visual Studio, you can use `docker build` (or `podman build`), or `dotnet publish /t:PublishContainer` to build from the command line.
1415

15-
:::moniker range=">=vs-2022"
16-
If you're using the .NET SDK build type, you don't have a Dockerfile, so you can't use `docker build`; instead, use `MSBuild`, `dotnet build` or `dotnet publish` to build on the command line.
16+
If you're using the .NET SDK build type, you don't have a Dockerfile, so you can't use `docker build` or `podman build`; instead, use `dotnet publish /t:PublishContainer` to build on the command line.
1717
:::moniker-end
1818

19+
:::moniker range="vs-2022"
20+
If you want to build a container project with a Dockerfile outside of Visual Studio, you can use `docker build` or `dotnet publish /t:PublishContainer` to build from the command line.
21+
22+
If you're using the .NET SDK build type, you don't have a Dockerfile, so you can't use `docker build`; instead, use `dotnet publish /t:PublishContainer` to build on the command line.
23+
:::moniker-end
24+
25+
:::moniker range="vs-2019"
26+
If you want to build a container project with a Dockerfile outside of Visual Studio, you can use `docker build` or `dotnet publish /t:PublishContainer` to build from the command line.
27+
:::moniker-end
28+
29+
:::moniker range="visualstudio"
30+
31+
## Prerequisites
32+
33+
- [Docker Desktop](https://hub.docker.com/editions/community/docker-ce-desktop-windows) or [Podman Desktop](https://podman-desktop.io/downloads).
34+
- [Visual Studio](https://visualstudio.microsoft.com/downloads/?cid=learn-onpage-download-cta), or for Podman support, [Visual Studio (Insiders)](https://visualstudio.microsoft.com/insiders/?cid=learn-onpage-download-cta), with the **ASP.NET and web development**, **Azure development** workload, and/or **.NET desktop development** workload installed.
35+
36+
:::moniker-end
37+
::: moniker range="vs-2022"
38+
39+
## Prerequisites
40+
41+
- [Docker Desktop](https://hub.docker.com/editions/community/docker-ce-desktop-windows).
42+
- [Visual Studio](https://visualstudio.microsoft.com/downloads/?cid=learn-onpage-download-cta) with the **ASP.NET and web development**, **Azure development** workload, and/or **.NET desktop development** workload installed.
43+
44+
:::moniker-end
45+
46+
::: moniker range="vs-2019"
47+
48+
## Prerequisites
49+
50+
- [Docker Desktop](https://hub.docker.com/editions/community/docker-ce-desktop-windows)
51+
- [Visual Studio 2019 or later](https://visualstudio.microsoft.com/downloads/?cid=learn-onpage-download-cta) with the **ASP.NET and web development**, **Azure development** workload, **.NET desktop development**, and/or **.NET Core cross-platform development** workload installed.
52+
53+
:::moniker-end
54+
55+
:::moniker range="<=vs-2022"
1956
## Use Docker build
2057

21-
To build a containerized solution from the command line, you can usually use the command `docker build <context>` for each project in the solution. You provide the *build context* argument. The *build context* for a Dockerfile is the folder on the local machine that's used as the working folder to generate the image. For example, it's the folder that you copy files from when you copy to the container. In .NET Core projects, the default is to use the folder that contains the solution file (.sln). Expressed as a relative path, this argument is typically ".." for a Dockerfile in a project folder, and the solution file in its parent folder. For .NET Framework projects, the default build context is the project folder, not the solution folder.
58+
To build a containerized solution from the command line, you can usually use the command `docker build <context>` for each project in the solution. You provide the *build context* argument. The *build context* for a Dockerfile is the folder on the local machine that's used as the working folder to generate the image. For example, it's the folder that you copy files from when you copy to the container. In .NET Core projects, the default is to use the folder that contains the solution file (.sln or .slnx). Expressed as a relative path, this argument is typically ".." for a Dockerfile in a project folder, and the solution file in its parent folder.
2259

2360
```cmd
2461
docker build -f Dockerfile ..
2562
```
2663

64+
For .NET Framework projects, the default build context is the project folder, not the solution folder.
65+
2766
You can set the build context in the project file by setting the `DockerfileContext` property. For example,
2867

2968
```xml
@@ -32,21 +71,54 @@ You can set the build context in the project file by setting the `DockerfileCont
3271
</PropertyGroup>
3372
```
3473

74+
:::moniker-end
75+
76+
:::moniker range="visualstudio"
77+
## Use Docker build or Podman build
78+
79+
To build a containerized solution from the command line, you can usually use the command `docker build <context>` (or `podman build <context>`) for each project in the solution. You provide the *build context* argument. The *build context* for a Dockerfile is the folder on the local machine that's used as the working folder to generate the image. For example, it's the folder that you copy files from when you copy to the container. In .NET Core projects, the default is to use the folder that contains the solution file (.sln or .slnx). Expressed as a relative path, this argument is typically ".." for a Dockerfile in a project folder, and the solution file in its parent folder.
80+
81+
```cmd
82+
docker build -f Dockerfile ..
83+
```
84+
85+
```cmd
86+
podman build -f Dockerfile ..
87+
```
88+
89+
You can set the build context in the project file by setting the `ContainerBuildContext` property. For example,
90+
91+
```xml
92+
<PropertyGroup>
93+
<ContainerBuildContext>contextfolder</ContainerBuildContext>
94+
</PropertyGroup>
95+
```
96+
97+
:::moniker-end
98+
3599
Relative paths in the Dockerfile are relative to the build context, so if you change the context, be sure to update the relative paths accordingly.
36100

37-
:::moniker range=">=vs-2022"
101+
:::moniker range="vs-2022"
38102
With Visual Studio 17.11 and later, when you add Docker support to a project, you can specify a folder for the build context. If you want to change the build context, you could delete the Dockerfile (if it doesn't have other changes you want to keep), and rerun **Add Docker support**, this time specifying the new build context. The new Dockerfile will have relative paths updated to correspond to the new build context.
39103
:::moniker-end
40104

105+
:::moniker range="visualstudio"
106+
When you add container support to a project, you can specify a folder for the build context. If you want to change the build context, you could delete the Dockerfile (if it doesn't have other changes you want to keep), and rerun **Add Container Support**, this time specifying the new build context. The new Dockerfile will have relative paths updated to correspond to the new build context.
107+
:::moniker-end
108+
41109
## Use MSBuild
42110

43111
::: moniker range=">=vs-2022"
44112
> [!NOTE]
45-
> This section describes how you can customize your Docker containers when you choose the Dockerfile container build type. If you are using the .NET SDK build type, the customization options are different, and the information in this article isn't applicable. Instead, see [Containerize a .NET app with dotnet publish](/dotnet/core/docker/publish-as-container?pivots=dotnet-8-0).
113+
> This section describes how you can customize your containers when you choose the Dockerfile container build type. If you are using the .NET SDK build type, the customization options are different, and the information in this article isn't applicable. Instead, see [Containerize a .NET app with dotnet publish](/dotnet/core/docker/publish-as-container?pivots=dotnet-8-0).
46114
::: moniker-end
47115

116+
:::moniker range="vs-2022"
117+
48118
Dockerfiles created by Visual Studio for .NET Framework projects (and for .NET Core projects created with versions of Visual Studio prior to Visual Studio 2017 Update 4) aren't multistage Dockerfiles. The steps in these Dockerfiles don't compile your code. Instead, when Visual Studio builds a .NET Framework Dockerfile, it first compiles your project using MSBuild. When that succeeds, Visual Studio then builds the Dockerfile, which simply copies the build output from MSBuild into the resulting Docker image. Because the steps to compile your code aren't included in the Dockerfile, you can't build .NET Framework Dockerfiles using `docker build` from the command line. You should use MSBuild to build these projects.
49119

120+
:::moniker-end
121+
50122
To build an image for single Docker container project, you can use MSBuild with the `/t:ContainerBuild` command option. This command tells MSBuild to build the target `ContainerBuild` rather than the default target `Build`. For example:
51123

52124
```cmd
@@ -65,7 +137,12 @@ To view the MSBuild logs, see [Obtaining build logs with MSBuild](../msbuild/obt
65137

66138
## Build from the command line
67139

140+
:::moniker range="<=vs-2022"
68141
Visual Studio uses Fast Mode (if enabled) to produce a container image configured to work best for development and debugging, so we don't recommend copying the docker build commands from the Output window after a Fast Mode build. To build a standard image without nonstandard optimizations, you can right-click on the Dockerfile and choose the **Build Docker image** option.
142+
:::moniker-end
143+
:::moniker range="visualstudio"
144+
Visual Studio uses Fast Mode (if enabled) to produce a container image configured to work best for development and debugging, so we don't recommend copying the `docker build` or `podman build` commands from the Output window after a Fast Mode build. To build a standard image without nonstandard optimizations, you can right-click on the Dockerfile and choose the **Build Image** option.
145+
:::moniker-end
69146

70147
Visual Studio uses the `dev` tag to designate images that it has specially prepared to optimize the startup time during debugging. However, these images shouldn't be used outside of the context of Visual Studio. This tag is an indication the images have nonstandard modifications and customizations, for example, to support Fast Mode debugging. See [Customize Docker containers in Visual Studio](container-build.md).
71148

0 commit comments

Comments
 (0)