如何在.Net Core 3,Visual Studio 2019和docker中使用“dotnet watch run”

q9rjltbz  于 2023-10-23  发布在  .NET
关注(0)|答案(3)|浏览(138)

我正在使用Visual Studio 2019使用Docker和.NET Core 3。我通过将Dockerfile添加到我的项目(右键单击项目-> Add -> Docker Support)来容器化我的应用程序,并且我能够启动它,但现在我想在容器中使用dotnet watch run
这是生成的Dockerfile:

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

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

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

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

我把它修改成这样:

FROM mcr.microsoft.com/dotnet/core/sdk:3.0-buster AS build
ENV DOTNET_USE_POLLING_FILE_WATCHER 1
WORKDIR /src
EXPOSE 80
EXPOSE 443
COPY ["DockerTestApp/DockerTestApp.csproj", "DockerTestApp/"]
RUN dotnet restore "DockerTestApp/DockerTestApp.csproj"
ENTRYPOINT ["dotnet", "watch", "run"]

容器以dotnet watch run启动,但未检测到任何文件更改,也未触发重建。
我是否必须从我的代码目录中挂载一个卷到容器中才能让它工作?
谢谢.

更新

这个Dokerfile

FROM mcr.microsoft.com/dotnet/core/sdk:3.0

ENV DOTNET_USE_POLLING_FILE_WATCHER 1

WORKDIR /app
COPY . .
ENTRYPOINT dotnet watch run  --urls=https://+:5001 --project DocketTestApp.csproj

这个docker-compose.yml

version: '3.4'

services:
  dotnet-watch-docker-example:
    container_name: dotnet_watch_docker_example
    image: giuseppeterrasi/dotnet-watch-docker-example
    build:
      context: ./DocketTestApp/
    ports:
      - 5001:5001
    volumes:
      - './DocketTestApp/:/app/'
    depends_on: 
      - db
  db:
    image: mysql
    restart: always
    ports:
        - "3306:3306"
    environment:
      MYSQL_ROOT_PASSWORD: testPassword
      MYSQL_DATABASE: testDB
      MYSQL_USER: testUser
      MYSQL_PASSWORD: test

它可以工作,但是如果我添加一个DbContext,如果容器启动,Visual Studio就会丢失实体框架引用。如果我停止容器并重新加载Visual Studio,一切正常。
为什么?为什么?

2023年更新

使用Visual Studio 2022 17.7或更高版本,这是完全支持的开箱即用!GitHub问题参考

t0ybt7op

t0ybt7op1#

当你想在本地运行dotnet watch run时,你可以省略使用自定义Dockerfile。
考虑以下docker-compose.yml文件:

version: '3.4'

services:
  dotnet-watch-docker-example:
    container_name: dotnet_watch_docker_example
    image: mcr.microsoft.com/dotnet/core/sdk:3.0
    ports:
      - 5001:5001
    volumes:
      - ./DockerTestApp:/app
    working_dir: /app
    command: dotnet watch run

合成文件不是从基本dotnet sdk映像创建自定义映像,而是简单地基于基本dotnet sdk映像启动一个容器。然后,它创建一个卷,将包含项目的本地目录Map到容器内的目录/app。然后将容器内的工作目录设置为/app,最后在容器内运行dotnet watch run命令。
要修复Entity框架引用的问题,请在项目目录中添加以下Directory.Build.props文件。此文件指示MSBUILD根据执行环境将/bin和/obj文件放置在不同的目录(容器/本地)中。这样,就不会出现冲突。

<Project>
    <PropertyGroup>
        <DefaultItemExcludes>$(DefaultItemExcludes);$(MSBuildProjectDirectory)/obj/**/*</DefaultItemExcludes>
        <DefaultItemExcludes>$(DefaultItemExcludes);$(MSBuildProjectDirectory)/bin/**/*</DefaultItemExcludes>
    </PropertyGroup>
    <PropertyGroup Condition="'$(DOTNET_RUNNING_IN_CONTAINER)' == 'true'">
        <BaseIntermediateOutputPath>$(MSBuildProjectDirectory)/obj/container/</BaseIntermediateOutputPath>
        <BaseOutputPath>$(MSBuildProjectDirectory)/bin/container/</BaseOutputPath>
    </PropertyGroup>
    <PropertyGroup Condition="'$(DOTNET_RUNNING_IN_CONTAINER)' != 'true'">
        <BaseIntermediateOutputPath>$(MSBuildProjectDirectory)/obj/local/</BaseIntermediateOutputPath>
        <BaseOutputPath>$(MSBuildProjectDirectory)/bin/local/</BaseOutputPath>
    </PropertyGroup>
</Project>
8fsztsew

8fsztsew2#

像这样改变入口点,

ENTRYPOINT dotnet watch run --no-restore

这将在发生新更改时重建服务器。

w7t8yxp5

w7t8yxp53#

obj/bin/文件夹中的文件在本地机器和Docker容器中必须不同。如果它们重叠,您将得到错误。
要解决这个问题,您可以更改obj/bin/的位置,@Mike Hawkins解释说。
但也有另一种解决方案。
绑定挂载卷会用本地bin/obj/覆盖你的docker bin/obj/目录,为了避免这种覆盖,你必须告诉docker bin/obj/文件夹不应该从外部覆盖。这可以通过另一个(匿名)卷来实现。Docker会评估你所有的卷,如果它们重叠,那么较长的内部路径会领先。
您可以在Dockerfile中定义此卷

VOLUME ["/app/path/to/bin"]
VOLUME ["/app/path/to/obj"]

或者在docker-compose中

volumes:
      - ./DockerTestApp:/app
      - /app/path/to/bin
      - /app/path/to/obj

这种方法的缺点是需要显式键入整个解决方案中的所有bin/obj/文件夹路径。

相关问题