1

Trying to deploy a multi-project app to azure using pipelines. After trying various combinations (pipeline log is showing about 75/80 runs in the last couple of days), it looks like the problem is with the Dockerfile by Visual Studio 2019 or with the Azure Pipeline somewhere.

Here's what I've narrowed it down to:

Project A-

  1. create a vs asp.net core webapp project, say test1sp,
  2. select the checkbox which says create solution and project in the same folder,
  3. select docker support (I selected Linux) or add it later
  4. no code added, the boilerplate code runs fine as-is
  5. add it to GitHub
  6. create a project/pipeline in azure, source Github, I use the classic editor without YAML
  7. create a docker build/push task and setup, I choose the most basic options, subscriptions, etc.
  8. build works great, I also added a deploy to app service task and it deploys to the app service

Project B - my project is called demo8

Same as project A, except for step #2 - do NOT select create solution and project in the same folder. Follow the rest of the steps and now you should get this error.

Step 7/17 : COPY ["demo8/demo8.csproj", "demo8/"]
...
...
##[error]COPY failed: file not found in build context or excluded by .dockerignore: stat demo8/demo8.csproj: file does not exist

It works fine on localhost/docker. So, I'm guessing maybe vs2019 uses some more tolerant implementation to patch it over. Or, there's a problem with azure's implementation or something else?

I am relatively new to Dockerfile editing and see lots of detailed/complex scenarios, hopefully, someone can shed some light on how to get it working?

Here's a screenshot of the project files/structure:

structure

UPDATE - Moving the Dockerfile to the solution folder in project B makes it work in azure BUT

  • then it does NOT work in Visual Studio, no debugging, etc.
  • make a copy of Dockerfile in project & parent folders ( + keep in sync )
  • BUT if your solution has multiple projects like mine then
  • you have to name the Dockerfile different to have unique names in the parent folder
  • and modify the pipelines to use respective file names

Posting it here in case it helps someone.

fatihyildizhan
  • 8,614
  • 7
  • 64
  • 88
Kumar
  • 10,997
  • 13
  • 84
  • 134

3 Answers3

0

The code in the Dockerfile must have the relative path to the folder level that the Dockerfile is in.

Tow ways to solve the problem. One is the change the code in the Dockerfile, for the project B, you can change the COPY code like this:

COPY ["demo8.csproj", "demo8/"]

Another way is to move the Dockerfile to the path that matches your COPY code. But in this way, it may affect other codes in your Dockerfile.

And you'd better plan your projects in different folders and create the Dockerfile for each project in different folders.

Charles Xu
  • 29,862
  • 2
  • 22
  • 39
  • yes agreed, i posted a workaround above that works but it's klutzy at best and ignores the DRY principle at least ! can't ascertain if the problem is in the code generation in vs2019 or in the azure pipeline again given that the code is auto generated – Kumar May 08 '21 at 05:47
  • @Kumar Actually, I think the DRY principle depends on you, not the Docker. Docker is the tool that only helps you package the running environment. So you need to do the DRY yourself. – Charles Xu May 10 '21 at 02:02
  • @Kumar Any updates on this question? Does it solve your problem? If it solves your problem please accept it. – Charles Xu May 17 '21 at 06:39
  • @Kumar Any updates on the question? Does it solve your problem? – Charles Xu May 28 '21 at 01:44
0

I just ran into this problem with a default console app in VS2022. I fixed it by changin the "Build context" parameter in the ADO build pipeline's Docker "build and push" step from the default of ** to **/.. so that the working directory was the solution folder, which matches VS (AFAIK).

Josh
  • 6,944
  • 8
  • 41
  • 64
0

Similar to @Josh's answer above -- I explicitly set

buildContext: '$(Build.SourcesDirectory)'

in the Docker task in the Azure Pipelines YML file, and it worked like a charm.

Something for the Azure pipelines template maintainer(s) to look into perhaps?

Spyros
  • 61
  • 1
  • 3