We Keep Coding

.net 6 minimal api docker issue: error CS5001: Program does not contain a static 'Main' method suitable for an entry point

I have seen a number of similar questions but none seem to represent exactly the issue I am facing. When I create a folder structure as follows:
./
./src
./src/test
Then navigate to ./src/test and run dotnet new webapi -lang c#, this will create a minimal API which works fine. I can also run dotnet publish -c RELEASE -o out /p:Version=1.0.0 without any issues.
When I then try create a docker file at the root level with the following contents:
FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build
ARG BUILDCONFIG=RELEASE
ARG VERSION=1.0.0
COPY ./src/test/test.csproj ./src/test/
RUN dotnet restore ./src/test/test.csproj
COPY ./src/ ./
WORKDIR ./src/test/
RUN dotnet publish -c $BUILDCONFIG -o out /p:Version=$VERSION
FROM mcr.microsoft.com/dotnet/sdk:6.0
WORKDIR /app
COPY --from=build /src/test/out ./
EXPOSE 5000
ENTRYPOINT ["dotnet", "test.dll"]
I get the following output:
=> ERROR [build 6/6] RUN dotnet publish -c RELEASE -o out /p:Version=1.0.0 2.5s
------
> [build 6/6] RUN dotnet publish -c RELEASE -o out /p:Version=1.0.0:
#11 0.511 Microsoft (R) Build Engine version 17.1.0+ae57d105c for .NET
#11 0.511 Copyright (C) Microsoft Corporation. All rights reserved.
#11 0.511
#11 0.931 Determining projects to restore...
#11 1.153 All projects are up-to-date for restore.
#11 2.400 CSC : error CS5001: Program does not contain a static 'Main' method suitable for an entry point [/src/test/test.csproj]
I tried a few things, including setting the OutputType in the csproj to Exe, DockerDefaultTargetOS to both win/linux and a few other suggestions I found in other threads but ultimately I always get the same error. Any ideas whay might be wrong?

The error message is not explicative.
The real error is on the line of COPY ./src/ ./. With this cmd you copy the CONTENT of the src folder (test) into the ROOT of the container.
It should be COPY ./src/ /src/ or (better) ./src /src
Try to comment out ALL except the first 9 rows, build the container and run
docker run --rm -it <imagename> /bin/sh to see yourself.
Since you try to build an empty folder the compiler raise the error that not found the main method (in reality it not find anything...)

I had the same issue using Visual Studio (Preview) on the Mac. Moved the Dockerfile to the solution root folder then everything worked.
Visual Studio for some reason put the Dockerfile at \Users\robk\git\Play-With-Containers\Play-With-Containers\Dockerfile after Right-click > Add > Add Docker Support. (this also where the .csproj file is)
Dragged the Dockerfile up one level to \Users\robk\git\Play-With-Containers then it worked.

How to properly configure docker-compose.yml file created by Visual Studio (IDE)

I am running C# in latest version of VS 2019 (Pro) on latest Windows 10 (Pro)
I converted my project (using MS Assistant) from Net Framework to Net 5.0.
All works well -> until I containerize.
Pre-containerization: My process architecture:
Logger TseLogger
Search engine shard 1 of 2 (TseShard -shardId 0)
Search engine shard 2 of 2 (TseShard -shardId 1)
Note that the 'shard' code is the identical code. The distinction is the 'shardId' run-time parameter.
In my solution I want to start 1 logger and 2 shards.
I could not figure out how to tell VS to start 2 copies of the same project (each with its own runtime parameters) so (as a kludge so I could test it) I cloned the TseShard project into 'TseShard 2' project and added it to the list of projects to start.
I could now set breakpoints anywhere in the code and debug (single-step as needed).
I am happy as a pig-in-you-know-what.
Next step was to containerize the projects.
So I want to generate 2 images
Logger (TseLogger)
Search engine shard (TseShard)
And, from the images, generate 3 containers: 1 logger and 2 shards.
I added Orchestration (docker-compose) support to my solution and Docker support to my TseLogger and TseShard projects.
I edited the auto-generate (by VS 2019) docker-compose.yml file:
version: '3.4'
services:
tselogger:
image: ${DOCKER_REGISTRY-}tselogger-2-3-0-6
build:
context: .
dockerfile: TseLogger/Dockerfile
tseshard0:
image: ${DOCKER_REGISTRY-}tseshard0-2-3-0-6
build:
context: .
dockerfile: TseShard/Dockerfile
ports: [52949]
volumes:
- d:/MyData:/MyData
command: -shardId 0
tseshard1:
image: ${DOCKER_REGISTRY-}tseshard1-2-3-0-6
build:
context: .
dockerfile: TseShard/Dockerfile
ports: [52950]
volumes:
- d:/MyData:/MyData
command: -shardId 1
Note that I added the suffix '-2-3-0-6' (code assembly version) to the images.
Note also that I named the shard services as 'tseshard0' and 'tseshard1'
My expectation is that it allows me to keep images of different code versions so Production can run a stable release while Dev will run new (test) releases.
My expectation is that I can reuse the same docker image (based on docker build of TseShard/Dockerfile) for both shards.
Anyway, it builds (seemingly correct).
For all its worth, the auto-generated (by VS) TseShard/Docker file (I did not edit this one):
#See https://aka.ms/containerfastmode to understand how Visual Studio uses this Dockerfile to build your images for faster debugging.
FROM mcr.microsoft.com/dotnet/runtime:5.0 AS base
WORKDIR /app
FROM mcr.microsoft.com/dotnet/sdk:5.0 AS build
WORKDIR /src
COPY ["TseShard/TseShard.csproj", "TseShard/"]
COPY ["Utils/Utils.csproj", "Utils/"]
COPY ["BinarySerialization/BinarySerialization.csproj", "BinarySerialization/"]
COPY ["Interfaces/Interfaces.csproj", "Interfaces/"]
COPY ["JsonCompare/JsonCompare.csproj", "JsonCompare/"]
COPY ["Networking/Networking.csproj", "Networking/"]
COPY ["FilterScoring/FilterScoring.csproj", "FilterScoring/"]
COPY ["DataAccess/DataAccess.csproj", "DataAccess/"]
COPY ["TseClient/TseClient.csproj", "TseClient/"]
RUN dotnet restore "TseShard/TseShard.csproj"
COPY . .
WORKDIR "/src/TseShard"
RUN dotnet build "TseShard.csproj" -c Debug -o /app/build
FROM build AS publish
RUN dotnet publish "TseShard.csproj" -c Debug -o /app/publish
FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "TseShard.dll"]
I set breakpoints at 'Main' for the logger and the shard code C# modules.
Finally, I start the docker-compose project.
It builds properly (so it seems).
Issue #1: I get an error message box from VS saying: Can not find the container with the name starting with 'TseShard' (see image below)
Issue #2: I'm not sure why it is looking for a container named 'TseShard' (which is the project name, not the image name, and not the service name).
Issue #3: The Output window from Container Tools shows:
========== Debugging ==========
docker ps --filter "status=running" --filter "label=com.docker.compose.service" --filter "name=^/TseShard$" --format {{.ID}} -n 1
========== Debugging ==========
docker ps --filter "status=running" --filter "label=com.docker.compose.service" --filter "name=^/TseShard$" --format {{.ID}} -n 1
Clearly the 'docker ps' is filtering on "name=^/TseShard$" which is looking for exactly 'TseShard'.
But I only defined services for TseShard0 and TseShard1.
See attached images.
Docker shows that the Logger is still running, and the two shards exited.
For sure, I did not reach a breakpoint (at the literal start of 'Main').
I would appreciate any help in setting up the debugging correctly so that I could set break points.
I am ultimately planning to get this to work on Linux 2 on AWS.
Many thanks in advance.

web api does not start up with NetCore 3 web api in linux container on azure

I am trying to "dockerize" this clean architecture template for .net Core 3. I use the docker pull request here as the base for my proff of concept app. This is a .net core 3 webapi project with an Angular front end as the client app.
WHAT I HAVE:
The base code from the pull request works locally.
An initial problem I had to overcome was setting the cert for identity server 4 in a local non development env, I had to mount a volume with the cert and reference it from the appsettings.json file like
"IdentityServer": {
"Key": {
"Type": "File",
"FilePath": "/security/mycert.pfx",
"Password": "MyPassword"
}
}
I set up a CI/CD pipeline in azure to build the project and deploy the image to an azure container registry
I set up a CI/CD release to deploy the docker image to a Web App for Containers (Linux) web app. Both these steps work properly
MY PROBLEM:
The web app loads and runs the container and the angular front end is shown. However, it appears that the web api is not running. Any attempt to hit an endpoint of the web api returns the following error in the browser console:
GET https://.....azurewebsites.net/_configuration/CleanArchitecture.WebUI 404 (Not Found)
Error: Uncaught (in promise): Error: Could not load settings for 'CleanArchitecture.WebUI' Error: Could not load settings for 'CleanArchitecture.WebUI'
CleanArchitecture.WebUI is the name of the assembly that is the entry point in the dockerfile:
ENTRYPOINT ["dotnet", "CleanArchitecture.WebUI.dll"]
All other aspects of the front end work properly, only calls to "backend" api fail.
Another issue is that if I get the docker logs from the azure container, there are no errors shown.
WHAT I TRIED
I tried to add "dotnet CleanArchitecture.WebUI.dll" to the startup command of the container in the container settings of the web app, but that just throws an error that it can't find CleanArchitecture.WebUI.dll
I have tried to increase the logging level ("LogLevel": "Default": "Debug") to get more details, but no additional error details are shown in the docker logs.
It might be an error loading the Identity Server 4 certificate, but there are no errors to confirm this problem.
Here is my docker compose file that is used by the azure pipeline:
version: '3.4'
services:
webui:
image: ${DOCKER_REGISTRY-}webui
build:
context: .
dockerfile: src/WebUI/Dockerfile
environment:
- "UseInMemoryDatabase=false"
- "ASPNETCORE_ENVIRONMENT=Production"
- "ConnectionStrings__DefaultConnection=myconnection"
- "ASPNETCORE_Kestrel__Certificates__Default__Password=mypass"
- "ASPNETCORE_Kestrel__Certificates__Default__Path=/security/mycert.pfx"
ports:
- "5000:5000"
- "5001:5001"
volumes:
- mcpdata:"/security:/"
restart: always
mcpdata is the name of the azure file share that gets mounted and contains the actual cert
here is my azure-pipeline.yml for the CI/CD:
trigger:
- staging
resources:
- repo: self
variables:
# Container registry service connection established during pipeline creation
dockerRegistryServiceConnection: '****'
imageRepository: 'cleanarchitecture'
containerRegistry: '****.azurecr.io'
dockerComposeFilePath: '$(Build.SourcesDirectory)docker-compose.Production.yml'
tag: '$(Build.BuildId)'
# Agent VM image name
vmImageName: 'ubuntu-latest'
stages:
- stage: Build
displayName: Build and push stage
jobs:
- job: Build
displayName: Build
pool:
vmImage: $(vmImageName)
steps:
- task: Docker#2
displayName: Build and push an image to container registry
inputs:
command: buildAndPush
repository: $(imageRepository)
dockerComposeFile: $(dockerComposeFilePath)
containerRegistry: $(dockerRegistryServiceConnection)
tags: staging
QUESTION?
Can someone help me figure out why it appears like my web api is not running but no errors are thrown. At a minimum I would be happy if someone could help me see the errors in the docker logs.
thanks in advance

I tried to repeat, with "clean architecture" using the following (note, I'm using zsh on MacOS, but the same should work on Windows/Linux too):
take clean_architecture
dotnet new --install Clean.Architecture.Solution.Template
dotnet new ca-sln
The documentation suggests, clicking F5 in Visual Studio will start the template, although I had to do:
cd src/WebUI/ClientApp
npm install
At this point the app starts locally by hitting F5. Note, what happens here is that ASP.Net Core forwards requests to the dev server, so effectively, this does ng serve --port 53543 AND starts Asp.Net Core (Kestrel in my case) on port 5001, browsing to http://127.0.0.1:53543 provides the angular page directly. Browsing to https://localhost:5001 brings up the same angular page, as forwarded by ASPNetCore to Angular. All very confusing... Detailed more here
Note in Startup.cs the following lines of code exist, these are usually set based on the environment variable ASPNETCORE_ENVIRONMENT
if (!env.IsDevelopment())
{
app.UseSpaStaticFiles();
}
-- and within "app.UseSpa"
if (env.IsDevelopment())
{
spa.UseAngularCliServer(npmScript: "start");
}
Anyway, it looks like you've got that environment variable set to Production, which should just serve the built files from the ClientApp\dist folder (rather than forwarding to the dev server) that suggests that if you see the Angular, then the .Net Core service is running... I'll try and rebuild the Dockerfiles first...
FROM mcr.microsoft.com/dotnet/core/aspnet:3.1-buster-slim AS base
ENV ASPNETCORE_URLS=https://+:5001;http://+:5000
WORKDIR /app
EXPOSE 5000
EXPOSE 5001
FROM mcr.microsoft.com/dotnet/core/sdk:3.1-buster AS build
RUN curl -sL https://deb.nodesource.com/setup_12.x | bash -
RUN apt install -y nodejs
WORKDIR /src
COPY ./src/WebUI/WebUI.csproj src/WebUI/
COPY ./src/Application/Application.csproj src/Application/
COPY ./src/Domain/Domain.csproj src/Domain/
COPY ./src/Infrastructure/Infrastructure.csproj src/Infrastructure/
RUN dotnet restore "src/WebUI/WebUI.csproj"
COPY . .
WORKDIR "/src/src/WebUI"
RUN dotnet build "WebUI.csproj" -c Release -o /app/build
FROM build AS publish
RUN dotnet publish "WebUI.csproj" -c Release -o /app/publish
FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "CleanArchitecture.WebUI.dll"]
Then build and run as follows:
# build takes a while
docker build -f ./src/WebUI/Dockerfile -t clean-architecture .
# note, this fails first time, because I set up as clean_architecture so the entry point is incorrect
docker run --rm -it -p 5000:5000 -p 5001:5001 clean-architecture
# run the container and override the entrypoint
docker run --rm -it --entrypoint /bin/bash clean-architecture
# From within the container...
root#93afb0ad21c5:/app# dotnet clean_architecture.WebUI.dll
# note, in .Net 3.1, you can also do this directly, as follows:
root#93afb0ad21c5:/app# ./clean_architecture.WebUI
Now there is a problem with LocalDB: System.PlatformNotSupportedException: LocalDB is not supported on this platform.
Switch appsettings.Production.json to be "UseInMemoryDatabase": true
The problem then appears to be certificates...
I created a certificate using:
dotnet dev-certs https -ep ./https/clean-arch.pfx -p anything
For IdentityServer, I change appSettings.Production.json as follows:
"IdentityServer": {
"Key": {
"Type": "File",
"FilePath": "/app/https/https/clean-arch.pfx",
"Password": "anything"
}
}
and then running on Linux, probably means running Kestrel, which means we need to provide HTTPS certs there too, which I did by setting the following in Program.cs
public static IHostBuilder CreateHostBuilder(string[] args) =>
Host.CreateDefaultBuilder(args)
.ConfigureWebHostDefaults(webBuilder =>
{
webBuilder.ConfigureKestrel((context, options) =>
{
options.AllowSynchronousIO = true;
options.Listen(IPAddress.Loopback, 5000, listenOptions =>
{
listenOptions.UseConnectionLogging();
listenOptions.Protocols = Microsoft.AspNetCore.Server.Kestrel.Core.HttpProtocols.Http1AndHttp2;
});
options.Listen(IPAddress.Any, 5001, listenOptions =>
{
listenOptions.UseConnectionLogging();
listenOptions.Protocols = Microsoft.AspNetCore.Server.Kestrel.Core.HttpProtocols.Http1AndHttp2;
listenOptions.UseHttps(new System.Security.Cryptography.X509Certificates.X509Certificate2("/app/https/https/clean-arch.pfx", "anything"));
});
});
webBuilder.UseStartup<Startup>();
});
At each stage I built the app in docker using...
\clean_architecture $ docker build -f ./src/WebUI/Dockerfile -t clean-architecture .
/clean_architecture $ docker run --rm -it -v /Users/monkey/src/csharp/clean_architecture/:/app/https/ -p 5000:5000 -p 5001:5001 --entrypoint /bin/bash clean-architecture
... and once running in bash (in docker), I used the following to start the application:
root#c5b4010d03be:/app# ./clean_architecture.WebUI
Good luck, hope that helps. Note, if it works in Docker, on your machine, it should work in Azure. I'll look at getting it going in Azure another day. Happy to upload my code to GitHub if it would help?

thanks to 0909EM for the huge effort in answering the question, but the solution was different.
I figured out what was going on. There are two issues.
The docer-compose.override.yml file looks like:
version: '3.4'
services:
webui:
environment:
- "ASPNETCORE_ENVIRONMENT=Development"
- "SpaBaseUrl=http://clientapp:4200"
clientapp:
image: ${DOCKER_REGISTRY-}clientapp
build:
context: src/WebUI/ClientApp
dockerfile: Dockerfile
depends_on:
- webui
restart: on-failure
db:
ports:
- "1433:1433"
notice the line dockerfile: Dockerfile in the src/webui/clientapp context. This dockerfile was overwriting the proper docker file in src/webui during the azure pipeline build. For some reason when I run the following command locally: docker-compose -f 'docker-compose.Production.yml' up --build it does not pull in the docker-compose.override settings, but the override settings do get used in the azure pipeline build.
Therefore, the angular dockerfile is the only one built and that image does not contain the .net core web api project. Which explains why I see the front end but cannot get to the api endpoints and also why the dockerfile has no .net core errors.
I was able to fix this in two ways.
First: rename the dockerfile in src/webui/clientapp to Dockerfile.clientapp and change the line in the docker.overrride file to dockerfile: Dockerfile.clientapp
SECOND: just remove the docker override file from the online repository that the azure pipeline pulls from.
As a result the proper dockerfile is used and the web api project is in the image.
The second issue: Now that the proper image is running, the .net core web api throws an error about loading the cert for identity server. This confirms my suspicion. Because this issue is not related to my original question about getting the web api running in the container, i have opened another question about it.

How can I use .Net Core 3.0 image in Google Cloud?

I'm using Google Cloud to host my .Net Core 2.2 application, but I want to update it to 3.0. My app.yaml looks like this
service: api
runtime: aspnetcore
env: flex
I know that I can specify the .Net Core version in runtime section. But Google Cloud Container Registry doesn't have .Net Core 3.0. I've checked it here.
Should I make a custom container then? I have zero experience with docker. Maybe there is a ready-to-go container somehow.
I didn't found any roadmap for update .Net Core images in public Container Registry.
#update
Solution
It's working!
My dockerfile looks like this:
FROM mcr.microsoft.com/dotnet/core/sdk:3.1 AS build-env
WORKDIR /app
# Copy csproj and restore as distinct layers
COPY MyProject.csproj ./
RUN dotnet restore
# Copy everything else and build
COPY . ./
RUN dotnet publish /app/MyProject.csproj -c Release -o ./out --nologo
# Build runtime image
FROM mcr.microsoft.com/dotnet/core/aspnet:3.1
WORKDIR /app
COPY --from=build-env /app/out/ .
EXPOSE 8080
ENV ASPNETCORE_URLS=http://*:8080
ENV ASPNETCORE_ENVIRONMENT=production
ENV TAPTAKE_SEED=false
ENTRYPOINT ["dotnet", "MyProject.dll"]
And my new app.yaml
service: api
runtime: custom
env: flex
env_variables:
ASPNETCORE_ENVIRONMENT: "production"
# Note this manual scaling is only for development
manual_scaling:
instances: 1
resources:
cpu: 1
memory_gb: 4
disk_size_gb: 10
And my cloudbuild.yaml:
steps:
# Build
- name: 'gcr.io/cloud-builders/dotnet'
args: [ 'publish', '-c', 'Release' ]
dir: 'MyProject'
# Migrations
- name: 'gcr.io/cloud-builders/dotnet'
args: [ 'ef', 'database', 'update' , '--configuration', 'Production']
dir: 'MyProject'
env:
- 'ASPNETCORE_ENVIRONMENT=production'
# DEPLOY
- name: 'gcr.io/cloud-builders/gcloud'
args: ['app','deploy','MyProject/bin/Release/netcoreapp3.1/publish/app.yaml', '--verbosity=debug']
timeout: '1200s'

Since you are already using the Flexible environment, one possible solution would be to set the runtime to custom and then use a Dockerfile to specify the image that you would like, which in this case is .Net Core 3.0.
As an example, the app.yaml file can be re-written like such:
service: api
runtime: custom
env: flex
We could also write the Dockerfile on top of the example given in the official docker docs
FROM mcr.microsoft.com/dotnet/core/sdk:3.0 AS build-env
WORKDIR /app
# Copy csproj and restore as distinct layers
COPY *.csproj ./
RUN dotnet restore
# Copy everything else and build
COPY . ./
RUN dotnet publish -c Release -o out
# Build runtime image
FROM mcr.microsoft.com/dotnet/core/aspnet:3.0
WORKDIR /app
COPY --from=build-env /app/out .
ENTRYPOINT ["dotnet", "aspnetapp.dll"]
Again, this is only one of the possible solutions. Google has an article that describes 4 ways you can deploy a .Net Core application. Granted, it is a few years old, but concepts should still apply. As an overview, you can:
Deploy from Visual Studio directly using the Cloud Tools for Visual Studio extension
Deploy a Framework Dependent Deployment bundle with "dotnet publish"
Deploy to App Engine flexible environment with a custom Dockerfile
Deploy to Container Engine with a custom Dockerfile

ASP.NET Core docker build error

I'm new to ASP.NET Core and docker.
I've created a simple ASP.NET Core 2.0 app and try to use docker with it on Windows. However, I get this error:
Your Docker server host is configured for 'Linux', however the docker-compose project targets 'Windows'.
Although it seems to be pretty informative error, I can't find where to 'configure host for Windows'

It is docker-compose.dcproj file where you can set up the OS you want to target:
<DockerTargetOS>Linux</DockerTargetOS>
To switch docker daemon to the same OS you can use Docker tray icon or Docker Settings window (accessible from the same menu):

Well basically the answer of Celestin Bochis and Pavel Agarkov are great. However since .net core 2.2 at least, the os of docker is stored in the .csproj file.
<Project Sdk="Microsoft.NET.Sdk.Web">
<PropertyGroup>
<TargetFramework>netcoreapp2.2</TargetFramework>
<DockerDefaultTargetOS>Linux</DockerDefaultTargetOS>
...
</PropertyGroup>
...
</Project>
And also don't forget to modify your docker file. The images should be the correct one. For .net core 2.2 That is :
Linux:
Microsoft/dotnet:2.2-aspnetcore-runtime AS base
microsoft/dotnet:2.2-sdk AS build
Windows:
microsoft/dotnet:2.2-aspnetcore-runtime-nanoserver-1803
microsoft/dotnet:2.2-sdk-nanoserver-1803

Make sure to choose the correct OS when you Enable docker support:
Your docker daemon has to target Linux containers as well.

If the docker is running on the windows machine then you need to change the value of "DockerTargetOS" should be "Windows" in .dcproj file.
Unload the docker project from visual studio and edit the project and set the value "Windows" to "DockerTargetOS".
<DockerTargetOS>Windows</DockerTargetOS>

I got this error when I created the project to target Windows and later wanted to switch it to target to Linux. The steps are a little bit more involved if you want to use Linux containers instead:
Unload docker-compose, edit the DockerTargetOS to Linux, then reload the project
Go to docker-compose.yml. Make sure that the backslash is a forward slash. Should look like "WebApplication/Dockerfile"
On the Dockerfile, for the base use "microsoft/aspnetcore:2.0" and for build, use "microsoft/aspnetcore-build:2.0" so it should look like this:
FROM microsoft/aspnetcore:2.0 AS base
WORKDIR /app
EXPOSE 80
FROM microsoft/aspnetcore-build:2.0 AS build
WORKDIR /src
COPY WebApplication7/WebApplication.csproj WebApplication/
RUN dotnet restore WebApplication/WebApplication.csproj
COPY . .
WORKDIR /src/WebApplication
RUN dotnet build WebApplication.csproj -c Release -o /app
Right click on the Docker tray icon > settings > Shared Drives > pick the drive your project resides in.