Let's say I have multiple WebApi projects in one solution. There's also some common projects which are class libraries (core, data access), and all of those web apis have project references to those class libraries. I want to have a separate Dockerfile in each of those apis, but since they have those project references it becomes complicated. The way Microsoft solves this (when you enable docker support) is that they build the Dockerfile with the context set at the solution root level. The problem with that is that everything gets copied into the image, including the other api code. If you try to manually copy what you need then the paths get weird in terms of relativity to the dockerfile, since the context is set to the solution root level, not at the Dockerfile level. If you execute the build command at the Dockerfile level (the path where your Dockerfile is), then you don't have access to the outer referenced projects. There are some other workarounds with mounting the referenced projects as volumes but all of these approaches have some drawbacks. So which solution would be the cleanest for this problem?

CodePudding user response：

If you do a multistage build where you dotnet build the .csproj file for the webapi you want, then it doesn't matter that much that too much source code gets copied into the build stage.

Only the webapi and it's dependent projects will be built, so you'll only get what you need in the final image.