what is the rationale about not using dotnet watch in docker anymore

Question

in about a year ago I remember when we want to run the app in docker for development purpose, we run the app with the dotnet watch run. but in recent updates, the template is creating a publish version and run that one. I agree that it's good for production. but why the development version is gone completely? I searched a lot but couldn't find why this changed happened.

something like this:

FROM microsoft/aspnetcore-build:2.0

# Required inside Docker, otherwise file-change events may not trigger
ENV DOTNET_USE_POLLING_FILE_WATCHER 1

# Set a working dir at least 2 deep. The output and intermediate output folders will be /code/obj and /code/bin
WORKDIR /code/app

# By copying these into the image when building it, we don't have to re-run restore everytime we launch a new container
COPY web.csproj .
COPY NuGet.config .
COPY Directory.Build.props .
RUN dotnet restore

# This will build and launch the server in a loop, restarting whenever a *.cs file changes
ENTRYPOINT dotnet watch run --no-restore

now on each change, we need to publish the app to have a working docker again.

I saw that the debugging works fine in visual studio with this new approach, but I'm confused about how the visual studio is able to attach to the container and do remote debugging. and more surprise I am about how visual studio is able to debug an application that is published in release mode?

but now it look like this:

FROM microsoft/dotnet:2.2-aspnetcore-runtime AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443

FROM microsoft/dotnet:2.2-sdk AS build
WORKDIR /src
COPY ["MyProject.csproj", "MyProject"]
COPY ["MyProject.Common.csproj", "MyProject.Common"]
RUN dotnet restore "MyProject.csproj"
COPY . .
WORKDIR "/src/MyProject"
RUN dotnet build "MyProject.csproj" -c Release -o /app

FROM build AS publish
RUN dotnet publish "MyProject.csproj" -c Release -o /app

FROM base AS final
WORKDIR /app
COPY --from=publish /app .
ENTRYPOINT ["dotnet", "MyProject.dll"]

Answer 1

Stating the obvious but in case: dotnet watch waits for file changes and then recompiles without you needing to restart manually.

It's still possible to use dotnet watch but you don't get any advantages in a container situation when your copying files. As the copying of the files takes place at the container build time and copies them to a source location inside the image and thus any changes to your code base won't be reflected when the container is running even if your using dotnet watch.

If you want to use dotnet watch look into mounting the source directory as a volume inside the container :)

You can use something like the following:

docker run --rm -it -p < port >:< port > -v ~/< sourcedirectory >:/< destination >/ -w /< destination >/aspnetapp mcr.microsoft.com/dotnet/core/sdk:3.0 dotnet watch run

The -v flag stands for volume if that wasn't obvious. If you wish to add a volume to a Dockerfile you can read about Dockerfile & Volumes here. And dotnet watch here. And Docker volumes specifically here. And lastly I found the in my history where I got the docker run command from.