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

У меня есть решение, которое содержит несколько проектов. Я хочу создать образ 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}"
    }
  }
}

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

Всего 1 ответ

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

РЕДАКТИРОВАТЬ

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

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

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

Есть идеи?

10000