Hace aproximadamente un año, recuerdo que cuando queríamos ejecutar la aplicación en la ventana acoplable con fines de desarrollo, ejecutamos la aplicación con dotnet watch run . pero en actualizaciones recientes, la plantilla crea una versión de publicación y la ejecuta. Estoy de acuerdo en que es bueno para la producción. pero ¿por qué la versión de desarrollo se ha ido por completo? Busqué mucho pero no pude encontrar por qué sucedió este cambio.
algo como esto:
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-restoreahora, en cada cambio, necesitamos publicar la aplicación para tener una ventana acoplable que funcione nuevamente.
Vi que la depuración funciona bien en Visual Studio con este nuevo enfoque, pero estoy confundido acerca de cómo Visual Studio puede conectarse al contenedor y realizar una depuración remota. y más sorpresa estoy acerca de cómo Visual Studio puede depurar una aplicación que se publica en modo de lanzamiento.
pero ahora se ve así:
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"]Indicando lo obvio, pero por si acaso: dotnet watch espera los cambios en el archivo y luego vuelve a compilar sin necesidad de reiniciar manualmente.
Todavía es posible usar dotnet watch pero no obtiene ninguna ventaja en una situación de contenedor cuando copia archivos. Como la copia de los archivos se lleva a cabo en el momento de la creación del contenedor y los copia en una ubicación de origen dentro de la imagen y, por lo tanto, cualquier cambio en su base de código no se reflejará cuando el contenedor se esté ejecutando, incluso si usa dotnet watch.
Si desea utilizar dotnet watch, intente montar el directorio de origen como un volumen dentro del contenedor :)
Puedes usar algo como lo siguiente:
docker run --rm -it -p < port >:< port > -v ~/< sourcedirectory >:/< destination >/ -w /< destination >/aspnetapp mcr.microsoft.com/dotnet/core/sdk:3.0 dotnet watch runEl indicador -v representa el volumen si eso no fuera obvio. Si desea agregar un volumen a un Dockerfile, puede leer sobre Dockerfile y volúmenes aquí . Y dotnet mira aquí . Y los volúmenes de Docker específicamente aquí . Y, por último, encontré en mi historial de donde obtuve el comando de ejecución de la ventana acoplable .