Не удалось скопировать: запрещенный путь вне контекста сборки: ../API.Common.AspNetCore/API.Common.AspNetCore.csproj ()

Question

У меня есть решение, которое содержит несколько проектов. Я хочу создать образ Docker проекта, поэтому я добавил Dockerfile через поддержку Docker. Проект, в который я добавил Dockerfile, имеет зависимости сборки от других проектов на том же уровне. Когда я пытаюсь запустить проект через Docker, я получаю следующую ошибку:

Не удалось скопировать: запрещенный путь вне контекста сборки: ../API.Common.AspNetCore/API.Common.AspNetCore.csproj ()

C: \ Users \ user.nuget \ packages \ microsoft.visualstudio.azure.containers.tools.targets \ 1.4.10 \ build \ Container.targets (258,5): ошибка CTP1001: Произошла ошибка при попытке сборка образа Docker.

Dockerfile:

FROM mcr.microsoft.com/dotnet/core/aspnet:2.1-stretch-slim AS base
WORKDIR /app
EXPOSE 80

FROM mcr.microsoft.com/dotnet/core/sdk:2.1-stretch AS build
WORKDIR /src
COPY ["API.Customer/API.Customer.csproj", "API.Customer/"]
COPY ["../API.Common.AspNetCore/API.Common.AspNetCore.csproj", "../API.Common.AspNetCore/"]
COPY ["API.Customer.Eventing/API.Customer.Eventing.csproj", "API.Customer.Eventing/"]
COPY ["API.Customer.Errors.Database.AspNetCore/API.Customer.Errors.Database.AspNetCore.csproj", "API.Customer.Errors.Database.AspNetCore/"]
COPY ["API.Customer.Errors.AspNetCore/API.Customer.Errors.AspNetCore.csproj", "API.Customer.Errors.AspNetCore/"]
RUN dotnet restore "API.Customer/API.Customer.csproj"
COPY . .
WORKDIR "/src/API.Customer"
RUN dotnet build "API.Customer.csproj" -c Release -o /app

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

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

LaunchSettings.json:

{
  "iisSettings": {
    "windowsAuthentication": false,
    "anonymousAuthentication": true,
    "iisExpress": {
      "applicationUrl": "http://localhost:5002",
      "sslPort": 0
    }
  },
  "profiles": {
    "IIS Express": {
      "commandName": "IISExpress",
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Dev"
      }
    },
    "STARS.API.Customer.Schools": {
      "commandName": "Project",
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Dev"
      },
      "applicationUrl": "http://localhost:5002"
    },
    "Docker": {
      "commandName": "Docker",
      "launchUrl": "{Scheme}://localhost:{ServicePort}"
    }
  }
}

Пожалуйста, дайте мне знать, если вам требуется дополнительная информация.

---

Answer 1

Вы пытаетесь скопировать проект API.Common.AspNetCore в каталог над рабочим каталогом (../). Это невозможно. Я понимаю, что вы делаете это, потому что вам нужно поддерживать относительные ссылки на пути проекта, но единственный способ сделать это - внедрить другие проекты еще на один уровень. Например, вместо копирования API.Customer.csproj в API.Customer/, скопируйте в foo/API.Customer/. Затем, для вашего API.Common.AspNetCore проекта, вы можете скопировать в API.Common.AspNetCore/.

EDIT

Думая об этом больше, ошибка, вероятно, связана с противоположной стороной уравнения, но приведенная выше часть также имеет значение. Короче говоря, в Docker есть концепция рабочего или сборочного каталога, который контекстуален каталогу, из которого запускается команда Docker. Если вы работаете с контейнерами Linux в Windows, это становится еще более интересным, поскольку весь этот рабочий каталог фактически копируется в виртуальную машину MobyLinux, работающую в Hyper-V.

В любом случае, из-за этого вам нужно быть осторожным с тем, где вы запускаете команды Docker. Если вам нужен контекст родительского каталога, то вам нужно не использовать этот родительский каталог, так что у вас есть доступ к нему и, конечно же, к вашему проекту. По иронии судьбы, это не то, о чем вам действительно нужно думать для отдельного Dockerfile, поскольку традиционно у вас нет других участвующих приложений, когда вы работаете с Dockerfile напрямую. И наоборот, когда вы управляете несколькими приложениями Docker, вы традиционно используете файл docker-compose.yml, который будет на родительском уровне для всех участвующих приложений. В любом случае, запуск этих файлов непосредственно в папках, в которых они существуют, обеспечит весь необходимый контекст.

Ваша проблема заключается в том, что вы эффективно катаетесь на двух концепциях, поэтому вам нужно быть намного более осторожным в том, каков ваш реальный контекст, когда вы запускаете команды Docker. Если у вас есть docker-compose.yml, я бы рекомендовал запустить его вместо Dockerfile (ов) напрямую. В Visual Studio вам просто нужно добавить поддержку оркестровки, а не добавлять файлы Docker напрямую. Это добавит Dockerfile, но также добавит проект docker-compose, а затем запустит docker-compose.yml, вместо того, чтобы создавать каждое изображение напрямую, используя Dockerfile.

Answer 2

Как говорит @Chris Pratt, если у вас есть несколько проектов в решении, лучше всего использовать файл docker-compose.yml. Но если по какой-то причине вам нужно напрямую использовать Dokerfile и указать контекст, вы можете добавить следующую строку в ваш файл *. Csproj .

<PropertyGroup>
    ...
    <DockerfileContext>../..</DockerfileContext>
</PropertyGroup>

Например, ../.., чтобы вернуться один раз. Отметьте здесь .