Run dotnet test inside docker container - docker

I want to run the dotnet test command inside a docker container but I just cannot figure out where to put the command. The project is a .NET Core 2.1 test project. The reason for this is that I want to run end-to-end integration tests which require all my containers to be running.
DockerFile:
FROM microsoft/dotnet:2.1-runtime AS base
WORKDIR /app
FROM microsoft/dotnet:2.1-sdk AS build
WORKDIR /src
COPY *.sln ./
COPY Sombra.IntegrationTests/Sombra.IntegrationTests.csproj Sombra.IntegrationTests/
COPY . .
WORKDIR /src/Sombra.IntegrationTests
RUN dotnet build -c Release -o /app
FROM build AS publish
RUN dotnet publish -c Release -o /app
FROM base AS final
WORKDIR /app
COPY --from=publish /app .
ENTRYPOINT ["dotnet", "test", "Sombra.IntegrationTests.csproj"]
docker-compose.yml
version: '3'
services:
sombra.integrationtests:
image: sombra.integrationtests
build:
context: .
dockerfile: Sombra.IntegrationTests/Dockerfile
depends_on:
- rabbitmq

You're using a runtime image to invoke the sdk command test. Your final is from base and base is from runtime.
I've successfully used unit tests as intermediate step while building the container but never integration tests with docker-compose. The key difference is I used a RUN command instead of the entrypoint/cmd so the tests are already executing while building the container. The main advantage is that there is no final image when the tests fail. But then again, this were pure unit tests and no integration tests. Although I can imagine that this will also work.
Here is my full example:
FROM microsoft/dotnet:2.0-sdk AS build-env
WORKDIR /app
# copy csproj and restore as distinct layers
COPY test.sln ./test.sln
COPY program/program.csproj ./program/program.csproj
COPY program.tests/program.tests.csproj ./program.tests/program.tests.csproj
RUN dotnet restore
# copy everything else and build
COPY . ./
RUN dotnet test program.tests -c Release
RUN dotnet publish program -c Release -o /app/out
# build runtime image
FROM microsoft/dotnet:2.0-runtime
WORKDIR /app
COPY --from=build-env /app/out ./
ENTRYPOINT ["dotnet", "program.dll"]

There is a good blog about this. A guide to setting up a .NET Core project using Docker, with integrated unit and component tests
In this blog look for component tests which is equivalent to what you are trying to do.
Below dockerfile is working for me. This can be build as docker image and then can be used for running integration tests.
FROM mcr.microsoft.com/dotnet/sdk:5.0 AS build
WORKDIR /src
COPY *.sln .
COPY ["Somthing.Business/Somthing.Business.csproj", "Somthing.Business/"]
COPY ["tests/Somthing.Business.IntegrationTests/Somthing.Business.IntegrationTests.csproj", "tests/Somthing.Business.IntegrationTests/"]
COPY "Directory.*.props" . # this is centralized package manager for a project
RUN dotnet restore "tests/Somthing.Business.IntegrationTests/Somthing.Business.IntegrationTests.csproj"
COPY . .
RUN dotnet build "tests/Somthing.Business.IntegrationTests/Somthing.Business.IntegrationTests.csproj"
FROM build AS testrunner
WORKDIR /src/tests/Somthing.Business.IntegrationTests
CMD ["dotnet", "test", "--no-restore"]

You don't provide us with an error log or something, but my guess is that you're trying to run dotnet test Sombra.IntegrationTests.csproj on an image that doesn't have the dotnet sdk installed (only the dotnet runtime).
The dotnet runtime is a version of dotnet core that cannot execute commands (like test and build). It can only execute dll's (hence the name "runtime").

Related

can't build .net core API image in docker

I am trying to build image for .net core 3.1 web api project but unable to build image
i get stuck at restoring project packages via dotnet restore
i get stuck at when i use dotnet build command ( does not find the solution or project file)
Directory Structure
https://i.stack.imgur.com/J7sMq.png
FROM mcr.microsoft.com/dotnet/core/sdk:3.1 as base
#FROM mcr.microsoft.com/dotnet/core/aspnet:3.1-nanoserver-1903 AS base
WORKDIR /app
#copy all project and solution files
COPY ./SSFS.Service/.csproj ./SSFS.Service/
COPY ./SSF.EDM/.csproj ./SSF.EDM/
COPY ./API/.csproj ./API/
COPY ./.sln ./
WORKDIR /app/API
RUN dotnet restore "SSFAPI.csproj"
#copy rest of files
COPY . .
WORKDIR /app
#build the project to restore packages
RUN dotnet build --source "./SSFAPI.sln" -c Release -o /publish
#public the project to a folder
RUN dotnet publish --source "SSFAPI.sln" -c Release -o /publish
FROM base AS final
EXPOSE 80
WORKDIR /app
COPY --from=base /app/publish .
ENTRYPOINT ["dotnet", "SSFAPI.dll"]
output of above is as below
https://i.stack.imgur.com/xqoKv.png
If i build the project using dotnet command then out is as shown below
Output is as below
https://i.stack.imgur.com/t9bV5.png
The Dockerfile is set up to be run from the solution root. You're probably running docker build from the project directory (i.e. where the Dockerfile actually is).

Did you mean to run dotnet SDK commands? Please install dotnet SDK from

I am trying to dockerize my Angular ASP.NET Core WebAPI.
I have the following dockerfile created:
FROM mcr.microsoft.com/dotnet/core/sdk:2.2.105 AS build-env
WORKDIR /app
# Copy csproj and restore as distinct layers
COPY src/Fightplan_v1/Fightplan_v1.csproj ./
# Copy everything else and build
COPY . ./
RUN dotnet restore
RUN dotnet publish -c Release -o /app
# Build runtime image
FROM mcr.microsoft.com/dotnet/core/aspnet:2.2
WORKDIR /app
COPY --from=build-env /app .
ENTRYPOINT ["dotnet", "Fightplan_v1.dll"]
The structure of my project is as follows:
The WebApi project is located inside the "src/Fightplan_v1" folder.
I am able to build my image fine using the following command:
docker build -f fp.dockerfile -t test .
When I try to run the image using:
docker run -it test
I get the following error:
Did you mean to run dotnet SDK commands? Please install dotnet SDK from:
https://go.microsoft.com/fwlink/?LinkID=798306&clcid=0x409
The project is build on dotnet core 2.2.105 so what this ofcourse tells me is that the image does not have the necessary dotnet core sdk installed. But as you can see in the dockerfile the sdk version I am downloading is 2.2.105.
I read here that the ENTRYPOINT is case sensitive and I have checked this several times now.
If I do a dotnet publish locally and go into the bin/Debug/netcoreapp2.2 I will find a DLL file called "Fightplan_v1.dll". Which is the name I assume I need to add to ENTRYPOINT?
I might just be missing some other steps here but I am not sure what.
Any help would be much appreciated!
I think your docker file should be like this
ENTRYPOINT ["Fightplan_v1.dll"]
Or if this not work try this
CMD ASPNETCORE_URLS=http://*:$PORT dotnet Fightplan_v1.dll
I was missing a COPY . . in the dockerfile after dotnet restore. I guess I was missing some .cs files in order for it to be compiled correctly.
The working dockerfile ended up looking like this:
FROM mcr.microsoft.com/dotnet/core/sdk:2.2.105 AS build-env
WORKDIR /app
# Copy csproj and restore as distinct layers
COPY src/Fightplan_v1/Fightplan_v1.csproj ./
# Copy everything else and build
COPY . ./
RUN dotnet restore
COPY . .
RUN dotnet publish -c Release -o /app
# Build runtime image
FROM mcr.microsoft.com/dotnet/core/aspnet:2.2
WORKDIR /app
COPY --from=build-env /app .
ENTRYPOINT ["dotnet", "Fightplan_v1.dll"]

"An assembly specified in the application dependencies manifest was not found" using docker

I am trying to dockerize an an angular aspnet core 2.2 webapi using the following dockerfile:
FROM mcr.microsoft.com/dotnet/core/sdk:2.2.105 AS build
WORKDIR /src
# Copy csproj and restore as distinct layers
COPY ["Fightplan_v1/Fightplan_v1.csproj", "Fightplan_v1/"]
COPY ["Fightplan_v1.Autogenerate/Fightplan_v1.Autogenerate.csproj", "Fightplan_v1.Autogenerate/"]
COPY ["Fightplan_v1.Autogenerate.Test/Fightplan_v1.Autogenerate.Test.csproj", "Fightplan_v1.Autogenerate.Test/"]
COPY ["Fightplan_v1.Database/Fightplan_v1.Database.csproj", "Fightplan_v1.Database/"]
COPY ["Fightplan_v1.Helpers/Fightplan_v1.Helpers.csproj", "Fightplan_v1.Helpers/"]
COPY ["Fightplan_v1.Jobs/ConvertImagestoBlob/Fightplan_v1.ConvertImagestoBlob.csproj", "Fightplan_v1.Jobs/ConvertImagestoBlob/"]
COPY ["Fightplan_v1.Models/Fightplan_v1.Models.csproj", "Fightplan_v1.Models/"]
COPY ["Fightplan_v1.Shared/Fightplan_v1.Shared.csproj", "Fightplan_v1.Shared/"]
RUN dotnet restore "Fightplan_v1/Fightplan_v1.csproj"
# Copy everything else and build
COPY . .
WORKDIR "/src/Fightplan_v1"
RUN dotnet build "Fightplan_v1.csproj" -c Release -o /app
FROM build AS publish
RUN dotnet publish "Fightplan_v1.csproj" -c Release -o /app
# Build runtime image
FROM mcr.microsoft.com/dotnet/core/aspnet:2.2 AS runtime
WORKDIR /app
COPY --from=build /app .
EXPOSE 80
ENTRYPOINT ["dotnet", "Fightplan_v1.dll"]
The build command used is:
docker build -f .\fp.dockerfile -t test .
The build goes through fine but when I try to run it using:
docker run -p 5100:80 -it test
I get the following error:
I have tried:
Adding -r linux-x64 to the end of publish to define the runtime: RUN dotnet publish "Fightplan_v1.csproj" -c Release -o /app -r linux-x64
Adding <PublishWithAspNetCoreTargetManifest>false</PublishWithAspNetCoreTargetManifest> to my .csproj file
None of the above fixes work unfortunately.
Since this is combined poject of an angular application and a webapi I might be missing some installations/dependencies?
You are copying the runtime files from wrong layer
COPY --from=build /app .
Try to change it to
COPY --from=publish /app .
Also, you probably need to separate out path in build and publish steps:
RUN dotnet build "Fightplan_v1.csproj" -c Release -o /app/build
RUN dotnet publish "Fightplan_v1.csproj" -c Release -o /app/publish
and then copy runtime files from the publish folder
COPY --from=publish /app/publish .
Edit. Basically, you need to copy publish artifacts into runtime, not build. Build will produce deps.json, which will lists all external dependencies, and during runtime this libraries are resolving using NuGet cache, if it is empty you will see an error. To copy dependencies along with project files you need to run publish.
So I assume, that theoretically dotnet build can be omitted, and is using only to discover compilation errors on early stage of docker build.

How to copy a csproj file using docker without visual studio and without docker compose?

I just started a new solution with a .NET Core Project (2.1) using visual studio 15.8.8. It can run and debug it by setting the docker compose file as a startup project. It works!
Logically, I should be able to build the docker image with a simple commandline statement. However, it complains that the csproj cannot be found. This is strange. The file exist and as I told, I can run it from visual studio. I tried it from one directory up and the directory that has the dockerfile. Same problem.
How can I solve this? The only thing I want is simply build my image and then run it by just using docker commands.
Dockerfile
FROM microsoft/dotnet:2.1-aspnetcore-runtime AS base
WORKDIR /app
EXPOSE 80
FROM microsoft/dotnet:2.1-sdk AS build
WORKDIR /src
COPY ["TryNewDocker2/TryNewDocker2.csproj", "TryNewDocker2/"]
RUN dotnet restore "TryNewDocker2/TryNewDocker2.csproj"
COPY . .
WORKDIR "/src/TryNewDocker2"
RUN dotnet build "TryNewDocker2.csproj" -c Release -o /app
FROM build AS publish
RUN dotnet publish "TryNewDocker2.csproj" -c Release -o /app
FROM base AS final
WORKDIR /app
COPY --from=publish /app .
ENTRYPOINT ["dotnet", "TryNewDocker2.dll"]
Het is the compose file:
version: '3.4'
services:
trynewdocker2:
image: ${DOCKER_REGISTRY}trynewdocker2
build:
context: .
dockerfile: TryNewDocker2/Dockerfile
Logically, I want "docker-compose up" to keep working when fixing this problem.
This is caused by the wrong root folder for the file path in dockerfile.
For launching from Docker, its root folder is C:\Users\...\repos\TryNewDocker2, but while running from command, its root fodler is C:\Users\...\repos\TryNewDocker2\TryNewDocker2, so the path for TryNewDocker2.csproj has changed from TryNewDocker2/TryNewDocker2.csproj to TryNewDocker2.csproj
Try dockerfile below:
FROM microsoft/dotnet:2.1-aspnetcore-runtime AS base
WORKDIR /app
EXPOSE 59162
EXPOSE 44342
FROM microsoft/dotnet:2.1-sdk AS build
WORKDIR /src
COPY ["TryNewDocker2.csproj", "TryNewDocker2/"]
RUN dotnet restore "TryNewDocker2/TryNewDocker2.csproj"
COPY . ./TryNewDocker2/
WORKDIR "/src/TryNewDocker2"
RUN dotnet build "TryNewDocker2.csproj" -c Release -o /app
FROM build AS publish
RUN dotnet publish "TryNewDocker2.csproj" -c Release -o /app
FROM base AS final
WORKDIR /app
COPY --from=publish /app .
ENTRYPOINT ["dotnet", "TryNewDocker2.dll"]
Update
For working in both Docker and command, do not change your dockerfile, and from path below to run your command with specifying the dockerfile path.
C:\Users\...\repos\TryNewDocker2>docker build -t gogo -f TryNewDocker2/Dockerfile .
For those of you who end up here years later like I did, I'll share my experience.
My problem was caused by the auto-generated Dockerfile that came from Visual Studio's "add > Docker Support..." was on the same level as my .csproj file.
The specific line causing me trouble was COPY ["MyApp/MyApp.csproj", "MyApp/"] which should have been just COPY ["MyApp.csproj", "MyApp/"]. Removing the extra MyApp/ in front of the .csproj got the build working fine.
Special thanks to Edward in the answer above for pointing me in the right direction.

Why does the ASP.NET Core Multi-Stage Dockerfile use 4 Stages

This is the default multi-stage Dockerfile when you click on 'Add Docker Support' in Visual Studio on an ASP.NET Core site.
FROM microsoft/aspnetcore:2.0 AS base
WORKDIR /app
EXPOSE 80
FROM microsoft/aspnetcore-build:2.0 AS build
WORKDIR /src
COPY WebApplication1.sln ./
COPY WebApplication1/WebApplication1.csproj WebApplication1/
RUN dotnet restore
COPY . .
WORKDIR /src/WebApplication1
RUN dotnet build -c Release -o /app
FROM build AS publish
RUN dotnet publish -c Release -o /app
FROM base AS final
WORKDIR /app
COPY --from=publish /app .
ENTRYPOINT ["dotnet", "WebApplication1.dll"]
Why have they chosen to use four stages, starting and finishing with the base stage. Also, why create a publish stage using the same build base image. Why does the Dockerfile not look like this with three stages:
FROM microsoft/aspnetcore-build:2.0 AS build
WORKDIR /src
COPY WebApplication1.sln ./
COPY WebApplication1/WebApplication1.csproj WebApplication1/
RUN dotnet restore
COPY . .
WORKDIR /src/WebApplication1
RUN dotnet build -c Release -o /app
FROM build AS publish
RUN dotnet publish -c Release -o /app
FROM microsoft/aspnetcore:2.0 AS final
WORKDIR /app
EXPOSE 80
COPY --from=publish /app .
ENTRYPOINT ["dotnet", "WebApplication1.dll"]
Is there some advantage to this that I am missing?
The file effectively equivalent to below
FROM microsoft/aspnetcore-build:2.0 AS build
WORKDIR /src
COPY WebApplication1.sln ./
COPY WebApplication1/WebApplication1.csproj WebApplication1/
RUN dotnet restore
COPY . .
WORKDIR /src/WebApplication1
RUN dotnet build -c Release -o /app
RUN dotnet publish -c Release -o /app
FROM microsoft/aspnetcore:2.0 AS base
EXPOSE 80
WORKDIR /app
COPY --from=build /app .
ENTRYPOINT ["dotnet", "WebApplication1.dll"]
Now the reason they may have chosen 4 build stage might be any of the two
Presentational
Future changes
So it may be that it depicts a
base -> build -> publish -> deploy the build
The size with 2 build stage would also the same as this one. So there is no obvious difference between the 2 stage and the 4 stage. It becomes a matter preference, representation and all. Nothing technologically different
There is no programatic reason for using 4 stages.
In the first stage just configuration is changed. In the third stage the image is not changed. The only use of FROM build AS publish to have a new alias.
I think there is no use of taking care of later changes in the build structure of docker. (The 4 stage code probably does that.) Use versioned images, just like in your example. E.g. 2.0 instead of latest. This way incomatibility can be avoided. If there will be changes in the way of the build, you can catch up with it.
The docker recommendation works with no csproj name specified, as using *.csproj. That works for most of the projects, producing about 350MB image-size.

Resources