Incorporate feedback round 2

Author: ghogen

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

@@ -24,14 +24,20 @@ To build a containerized solution from the command line, you can usually use the
 docker build -f Dockerfile ..
 ```
 
-When you initially add Docker support to a project, you can provide a different folder for the build context. You can also set it in the project file by setting the `DockerfileContext` property. For example,
+You can set the build context in the project file by setting the `DockerfileContext` property. For example,
 
 ```xml
 <PropertyGroup>
    <DockerfileContext>contextfolder</DockerfileContext>
 </PropertyGroup>
 ```
 
+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.
+
+:::moniker range=">=vs-2022"
+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.
+:::moniker-end
+
 ## Use MSBuild
 
 ::: moniker range=">=vs-2022"

docs/containers/container-debug-customization.md

@@ -44,7 +44,7 @@ The process of running the debugger depends on the type of project and container
 |Scenario|Debugger process|
 |-|-|
 | **.NET Core apps (Linux containers)**| Visual Studio downloads `vsdbg` and maps it to the container, then it gets called with your program and arguments (that is, `dotnet webapp.dll`), and then debugger attaches to the process. |
-| **.NET Core apps (Windows containers)**| Visual Studio uses `msvsmon` or `onecoremsvsmon` and maps it to the container, runs it as the entry point and then Visual Studio connects to it and attaches to the program. This is similar to how you would normally set up remote debugging on another computer or virtual machine. The `onecoremsvsmon` version is only used in cases where `msvsmon` can't run, for example, in Windows Nano Server.|
+| **.NET Core apps (Windows containers)**| Visual Studio uses `msvsmon` or `onecoremsvsmon` and maps it to the container, runs it as the entry point and then Visual Studio connects to it and attaches to the program. This is similar to how you would normally set up remote debugging on another computer or virtual machine. |
 | **.NET Framework apps** | Visual Studio uses `msvsmon` and maps it to the container, runs it as part of the entry point where Visual Studio can connect to it, and attaches to the program.|
 
 For information on `vsdbg.exe`, see [Offroad debugging of .NET Core on Linux and OS X from Visual Studio](https://github.com/Microsoft/MIEngine/wiki/Offroad-Debugging-of-.NET-Core-on-Linux---OSX-from-Visual-Studio).

docs/containers/container-entry-point.md

@@ -24,7 +24,7 @@ Visual Studio uses a custom container entry point depending on the project type
 :::moniker range=">=vs-2022"
 |Container type|Entry point|
 |-|-|
-| **Linux containers** | The entry point is `dotnet --roll-forward Major /VSTools/DistrolessHelper/DistrolessHelper.dll --wait`. It's the debugger that is responsible to run the app (that is, `dotnet webapp.dll`), even when not debugging.|
+| **Linux containers** | For .NET 6 and later, the entry point is `dotnet --roll-forward Major /VSTools/DistrolessHelper/DistrolessHelper.dll --wait`. For .NET 5 and earlier, the entry point is `tail -f /dev/null`. These processes use an infinite wait to keep the container running when the app is not running. When the app is launched, with or without debugging, it's the debugger that is responsible to run the app (that is, `dotnet webapp.dll`) and keep the container running.|
 | **Windows containers**| The entry point is something like `C:\remote_debugger\x64\msvsmon.exe /noauth /anyuser /silent /nostatus` which runs the debugger, so it's listening for connections. For .NET Framework web apps, the entry point is slightly different where `ServiceMonitor` is added to the command.|
 :::moniker-end
 

docs/containers/edit-and-refresh.md

@@ -18,10 +18,6 @@ This article illustrates how to use Visual Studio to start an app in a local Doc
 
 If you already have a project of a supported type, Visual Studio can create a Dockerfile and configure your project to run in a container. See [Container Tools in Visual Studio](overview.md).
 
-:::moniker range=">=vs-2022"
-Also, in Visual Studio 17.10 and later, [Hot Reload](../debugger/hot-reload.md) is supported in containers.
-:::moniker-end
-
 ## Prerequisites
 
 To debug apps in a local Docker container, the following tools must be installed:
@@ -115,6 +111,12 @@ Often, changes require further inspection. You can use the debugging features of
    ![Screenshot showing part of the code for Index.cshtml.cs in Visual Studio with a breakpoint set to the left of a code line that is highlighted in yellow.](media/edit-and-refresh/vs-2022/breakpoint.png)
    :::moniker-end
 
+:::moniker range=">=vs-2022"
+## Hot reload
+
+Also, in Visual Studio 17.10 and later, [Hot Reload](../debugger/hot-reload.md) is supported in containers, although be aware that in a container, you have to refresh the page to see changes. If the change is to a CSS file, you again have to refresh the page to see those changes. Note also that updates to scoped CSS files (`.razor.css` files, see [ASP.NET Core Blazor CSS isolation](/aspnet/core/blazor/components/css-isolation)) are not supported as part of hot reload.
+:::moniker-end
+
 ## Create a .NET Framework console app
 
 This section presents how to debug a .NET Framework console app project in a local Docker container by first showing how to add Docker support to the project. It's important to recognize that different project types have different levels of Docker support. There are even different levels of Docker support for .NET Core (including .NET 5 and later) console app projects versus .NET Framework console app projects.