Unable to debug dotnet core GenericHost docker container

Question

I am using Linux containers on the latest Windows build Windows 10 2004 and enabled WSL 2 and Docker Desktop 2.3.0.3 (45519).

I right click the docker-compose file, and select Set as Startup Project .

I then hit F5 to debug.

I can see the image running with docker ps however breakpoints are not being hit.

I cannot view Logs (on the Visual Studio Containers window) as it says:

It was not possible to find any compatible framework version
The framework 'Microsoft.AspNetCore.App', version '3.1.0' was not found.
  - No frameworks were found.

You can resolve the problem by installing the specified framework and/or SDK.

The specified framework can be found at:
  - https://aka.ms/dotnet-core-applaunch?framework=Microsoft.AspNetCore.App&framework_version=3.1.0&arch=x64&rid=debian.10-x64

I have installed the SDKs from the link given above.

Build output is below:

1>------ Build started: Project: Libertas.Host.Tickers.ScheduledTasks, Configuration: Debug Any CPU ------
1>Libertas.Host.Tickers.ScheduledTasks -> C:\Users\User\Source\Repos\myrepo\Libertas\src\Libertas.Host.Tickers.ScheduledTasks\bin\Debug\netcoreapp3.1\Libertas.Host.Tickers.ScheduledTasks.dll
1>docker build -f "C:\Users\User\Source\Repos\myrepo\Libertas\src\Libertas.Host.Tickers.ScheduledTasks\Dockerfile" --force-rm -t libertashosttickersscheduledtasks:dev --target base  --label "com.microsoft.created-by=visual-studio" --label "com.microsoft.visual-studio.project-name=Libertas.Host.Tickers.ScheduledTasks" "C:\Users\User\Source\Repos\myrepo\Libertas\src"
1>Sending build context to Docker daemon  1.362MB
1>
1>Step 1/4 : FROM mcr.microsoft.com/dotnet/core/runtime:3.1-buster-slim AS base
1> ---> 86a2e7d45948
1>Step 2/4 : WORKDIR /app
1> ---> Running in d1ed1740d43e
1>Removing intermediate container d1ed1740d43e
1> ---> 90bd1703e28d
1>Step 3/4 : LABEL com.microsoft.created-by=visual-studio
1> ---> Running in 2626d5865d89
1>Removing intermediate container 2626d5865d89
1> ---> da74703374d2
1>Step 4/4 : LABEL com.microsoft.visual-studio.project-name=Libertas.Host.Tickers.ScheduledTasks
1> ---> Running in 7a381e7ea47a
1>Removing intermediate container 7a381e7ea47a
1> ---> fd2dd439cce6
1>Successfully built fd2dd439cce6
1>Successfully tagged libertashosttickersscheduledtasks:dev
1>SECURITY WARNING: You are building a Docker image from Windows against a non-Windows Docker host. All files and directories added to build context will have '-rwxr-xr-x' permissions. It is recommended to double check and reset permissions for sensitive files and directories.
1>docker rm -f 9ff95181e06801ed3d4b4d5743397604b743d77c840f2047fb2caee046e5d8eb
1>Error: No such container: 9ff95181e06801ed3d4b4d5743397604b743d77c840f2047fb2caee046e5d8eb
1>docker run -dt -v "C:\Users\User\vsdbg\vs2017u5:/remote_debugger:rw" -v "C:\Users\User\Source\Repos\myrepo\Libertas\src\Libertas.Host.Tickers.ScheduledTasks:/app" -v "C:\Users\User\Source\Repos\myrepo\Libertas\src:/src/" -v "C:\Users\User\AppData\Roaming\Microsoft\UserSecrets:/root/.microsoft/usersecrets:ro" -v "C:\Users\User\.nuget\packages\:/root/.nuget/fallbackpackages" -e "DOTNET_USE_POLLING_FILE_WATCHER=1" -e "NUGET_PACKAGES=/root/.nuget/fallbackpackages" -e "NUGET_FALLBACK_PACKAGES=/root/.nuget/fallbackpackages" --name Libertas.Host.Tickers.ScheduledTasks_1 --entrypoint tail libertashosttickersscheduledtasks:dev -f /dev/null
1>ba95df9d32d6a0af07b1eab32af606131e075b2afff664c4003dbe3eae349543
========== Build: 1 succeeded, 0 failed, 6 up-to-date, 0 skipped ==========

My Dockerfile is below:

#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/core/runtime:3.1-buster-slim AS base
WORKDIR /app

FROM mcr.microsoft.com/dotnet/core/sdk:3.1-buster AS build
WORKDIR /src
COPY ["Libertas.Host.Tickers.ScheduledTasks/Libertas.Host.Tickers.ScheduledTasks.csproj", "Libertas.Host.Tickers.ScheduledTasks/"]
COPY ["Libertas.Application.Tickers.ScheduledTasks/Libertas.Application.Tickers.ScheduledTasks.csproj", "Libertas.Application.Tickers.ScheduledTasks/"]
COPY ["PolygonIo.WebSocket/PolygonIo.WebSocket.csproj", "PolygonIo.WebSocket/"]
RUN dotnet restore "Libertas.Host.Tickers.ScheduledTasks/Libertas.Host.Tickers.ScheduledTasks.csproj"
COPY . .
WORKDIR "/src/Libertas.Host.Tickers.ScheduledTasks"
RUN dotnet build "Libertas.Host.Tickers.ScheduledTasks.csproj" -c Release -o /app/build

FROM build AS publish
RUN dotnet publish "Libertas.Host.Tickers.ScheduledTasks.csproj" -c Release -o /app/publish

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "Libertas.Host.Tickers.ScheduledTasks.dll"]

I am unable to hit any breakpoints or even confirm if the app is running. I have a Generic Host app, and I don't even hit the breakpoint of the first line within public static void Main(string[] args) .

Pointers much appreciated.

UPDATE AND FIX

So this was the smoking gun, in particular as this was a console application, and not a AspNetCore app.

It was not possible to find any compatible framework version
The framework 'Microsoft.AspNetCore.App', version '3.1.0' was not found.
  - No frameworks were found.

You can resolve the problem by installing the specified framework and/or SDK.

The specified framework can be found at:
  - https://aka.ms/dotnet-core-applaunch?framework=Microsoft.AspNetCore.App&framework_version=3.1.0&arch=x64&rid=debian.10-x64

I found one of my referenced libraries had a reference to Grpc.AspNetCore .

Once i moved this code out, it was able to run (I can confirm before the container instance was not running), with full debugging.

It compiled OK, the container ran, the application within the container never seemed to launch.

QUESTION I would like to get to the bottom of why, as i don't fully understand how this fixed everything and what can be done to avoid in future (seems any console app that references a library that accidentally or otherwise references an AspNetCore dependency could have the same issue).

Answer 1

I had run into a similar problem... well, I think that the reasons are quite similar, in my case, I could not do anything, I could not even build the project, I had compiling errors, 'simple' ones... lol... let's say that using system; was erring and some other libraries that are there by default.

After a lot of investigation, I found out that my project was in net standard 2.0, but one of the nuget packages was for net standard 2.1, removing that package and finding a way to fix that part of the code resolved the problem.

The reason I believe was similar to what you are after, when adding the libraries, you are adding external code, external code that you don't control, so if the external library was referencing to another library that was not compatible with your project, like in my case, so I believe that the libraries were fighting to decide if it was meant to be a console or a web server app, have you tried to see the process that was created?

I also had a look at the library that you are mentioning ( https://www.nuget.org/packages/Grpc.AspNetCore ) and then click on dependencies and then there is this package:

Grpc.AspNetCore.Server.ClientFactory

which may have caused the crash.

Be careful with nuget packages, they are pretty cool and 'useful' but look at the dependencies, sometimes it is better to do your own code, that was my lesson. For more details: https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/dependencies

Answer 2

QUESTION I would like to get to the bottom of why, as i don't fully understand how this fixed everything and what can be done to avoid in future (seems any console app that references a library that accidentally or otherwise references an AspNetCore dependency could have the same issue).

In Visual Studio Solution Explorer shows us the dependency tree with Nuget Packages and above that is the Frameworks listing Microsoft.NETCore.App :

This is how we can see the GitHub Repo references AspNetCore:

<FrameworkReference Include="Microsoft.AspNetCore.App" />

How can I stop this from happening?

1. Check Solution Explorer for Frameworks.
2. Have Unit Tests on the config and dependencies.
3. Always review the Package Dependancies you import.

---

If you're looking for the canonical story it's over here .

---

The problem Iria discusses can be prevented with NuGet Version ranges and wildcards notation. When referring to package dependencies, NuGet supports using interval notation for specifying version ranges, summarized as follows:

+-----------+---------------+-------------------------------------------------------+
| Notation  | Applied rule  |                      Description                      |
+-----------+---------------+-------------------------------------------------------+
| 1.0       | x ≥ 1.0       | Minimum version, inclusive                            |
| (1.0,)    | x > 1.0       | Minimum version, exclusive                            |
| [1.0]     | x == 1.0      | Exact version match                                   |
| (,1.0]    | x ≤ 1.0       | Maximum version, inclusive                            |
| (,1.0)    | x < 1.0       | Maximum version, exclusive                            |
| [1.0,2.0] | 1.0 ≤ x ≤ 2.0 | Exact range, inclusive                                |
| (1.0,2.0) | 1.0 < x < 2.0 | Exact range, exclusive                                |
| [1.0,2.0) | 1.0 ≤ x < 2.0 | Mixed inclusive minimum and exclusive maximum version |
| (1.0)     | invalid       | invalid                                               |
+-----------+-------------

When you're adding Packages enforce a version, this way you keep track of your dependancies with different versions (and ultimately versions of the .net framework).

Answer 3

Change the BASE image to use as.net instead of runtime . The runtime image does not contain the AS.NET libs.

runtime:3.1-buster-slim

to

as.net:3.1-buster-slim

This also works for newer releases of .NET.