我有一个包含以下项目的解决方案：
当我在Visual Studio中添加Docker支持时，这就是添加的Docker文件。
FROM microsoft/dotnet:2.1-aspnetcore-runtime AS base
WORKDIR /app
EXPOSE 80
FROM microsoft/dotnet:2.1-sdk AS build
WORKDIR /src
COPY ServiceStackDockerTest/ServiceStackDockerTest.csproj ServiceStackDockerTest/
COPY ServiceStackDockerTest.ServiceModel/ServiceStackDockerTest.ServiceModel.csproj ServiceStackDockerTest.ServiceModel/
COPY ServiceStackDockerTest.ServiceInterface/ServiceStackDockerTest.ServiceInterface.csproj ServiceStackDockerTest.ServiceInterface/
RUN dotnet restore ServiceStackDockerTest/ServiceStackDockerTest.csproj
COPY . .
WORKDIR /src/ServiceStackDockerTest
RUN dotnet build ServiceStackDockerTest.csproj -c Release -o /app
FROM build AS publish
RUN dotnet publish ServiceStackDockerTest.csproj -c Release -o /app
FROM base AS final
WORKDIR /app
COPY --from=publish /app .
ENTRYPOINT ["dotnet", "ServiceStackDockerTest.dll"]
它将docker文件添加到启动项目（/ServiceStackDockerTest）中。
这在Visual Studio中效果很好。当我调试并击中断点时，该图像将生成并运行。
但是，当我尝试使用docker正常构建此映像时，由于找不到.csproj文件的路径，因此无法正常工作。
我认为发生这种情况是因为Visual Studio正在使用卷共享，因此它可以访问父文件夹，或者正在以某种方式更改Dockerfile的运行范围。
但是，在我的CI管道中，它在docker build上运行ServiceStackDockerTest/Dockerfile，该文件夹将此文件夹复制到docker，并且无权访问其父文件夹。 VS dockerfile中的路径都是从父目录到docker文件所在的路径。
Microsoft为什么要建立这样的支持？确保在CI管道中构建dockerfile是一项常见任务。
解决此问题的最佳方法是什么，这样我仍然可以在Visual Studio中实时重新加载容器的同时进行调试，还可以在CI管道中构建映像？
答案 0 :(得分：0)
因此，答案实际上非常简单。在CI管道中，只需将构建上下文更改为父文件夹即可。
要在本地构建，请从父文件夹docker build -f SSDockerTest2\Dockerfile .运行此文件，然后在父目录的上下文中运行它。