Error: It was not possible to find any installed .NET Core SDKs

Docker.Net Core

Docker Problem Overview


When I run the command docker run -i -t myProject it shows error:

> It was not possible to find any installed .NET Core SDKs Did you mean to run .NET Core SDK commands? Install a .NET Core SDK from: https://aka.ms/dotnet-download

However, I do have the .NET Core SDK installed and the PATH is correct (followed here: https://docs.microsoft.com/en-us/aspnet/core/test/troubleshoot?view=aspnetcore-3.1#no-net-core-sdks-were-detected).

What's more, my project only needs runtime .NET Core SDK.

Does anyone know what might be the issue?

When running dotnet --info I got:

.NET Core SDK (reflecting any global.json): Version: 3.1.101 Commit: b377529961

Runtime Environment: OS Name: Windows OS Version: 10.0.18363 OS Platform: Windows RID: win10-x86 Base Path: C:\Program Files (x86)\dotnet\sdk\3.1.101\

Host (useful for support): Version: 3.1.1 Commit: a1388f194c

.NET Core SDKs installed: 3.1.101 [C:\Program Files (x86)\dotnet\sdk]

.NET Core runtimes installed: Microsoft.AspNetCore.App 3.1.0 [C:\Program Files (x86)\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 3.1.1 [C:\Program Files (x86)\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.NETCore.App 3.1.0 [C:\Program Files (x86)\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 3.1.1 [C:\Program Files (x86)\dotnet\shared\Microsoft.NETCore.App] Microsoft.WindowsDesktop.App 3.1.0 [C:\Program Files (x86)\dotnet\shared\Microsoft.WindowsDesktop.App] Microsoft.WindowsDesktop.App 3.1.1 [C:\Program Files (x86)\dotnet\shared\Microsoft.WindowsDesktop.App]

To install additional .NET Core runtimes or SDKs: https://aka.ms/dotnet-download

Docker Solutions


Solution 1 - Docker

For me it happened when I had wrong ENTRYPOINT in my DOCKERFILE

# Build runtime image
FROM mcr.microsoft.com/dotnet/core/aspnet:3.1
WORKDIR /app
COPY --from=build-env /app/out .
ENTRYPOINT ["dotnet", "SampleAppForDocker.dll"]

Make sure that you run correct dll in your ENTRYPOINT. I had wrong name of dll file.

Solution 2 - Docker

I had this issue, but my ENTRYPOINT was correct. The issue was with stale or a corrupt mcr.microsoft.com/dotnet/core/sdk:3.1 image. So I purged everything and rebuilt the docker image.

For those unaware, this is how to do that:

Remove all docker containers: docker rm -f $(docker ps -a -q)
Remove all docker images:     docker rmi -f $(docker images)

After that, it worked fine.

Solution 3 - Docker

In case of linux, the case sensitivity is important. In my case the problem was with (btw. it was working as Windows container)

ENTRYPOINT ["dotnet", "backendapi.dll"]

as the library name was written with different case. It was fixed once the entrypoint got named correctly as

ENTRYPOINT ["dotnet", "BackendAPI.dll"]

Solution 4 - Docker

I followed the .Net Core app tutorial given by Microsoft, and ran into the same issue. I had the docker file set up as:

FROM mcr.microsoft.com/dotnet/aspnet:3.1
COPY bin/release/netcoreapp3.1/publish/ App/
WORKDIR /App
ENTRYPOINT ["dotnet", "NetCore.Docker.dll"]

but it did not pull the mcr.microsoft.com/dotnet/aspnet image to base my build on (I'm assuming, because I'm not an expert on this matter yet). I did a pull request for the aspnet image:

docker pull mcr.microsoft.com/dotnet/aspnet:3.1

and it created this image. I then built my project's docker image, and created my container. My container and app functioned as intended after the abovementioned.

Solution 5 - Docker

In my case it was the problem of working directory. In Dockerfile you should be in the same working directory where your execution dll is placed. As follows : Dockerfile

Solution 6 - Docker

On my case it was a space after double quotes:

ENTRYPOINT ["dotnet", " MyAssembly.dll"]

After removing it it worked.

Solution 7 - Docker

In my case it was not related to docker. The "arguments" attribute in web.config had an error, the name of dll was incorrect. HTH.

Solution 8 - Docker

Ensure your dll is copied from the publishing location to /app. Maybe your publishing configuration overrides that.

As suggested by @KarlGreen, ENTRYPOINT ["ls", "."] shows you if the dll was actually copied to the /app folder. In my case it wasn't, ls only listed web.config and wwwroot. If I published the Debug configuration instead, then the dll would be copied so there's some difference in publishing configuration, although I'm not sure what exactly. The output option to the publish command was not honored, but overridden by something else unknown to me.

I worked around it by explicitly copying the release output with a copy command e.g.

COPY --from=build-env /app/bin/Release/netcoreapp3.1 .

Solution 9 - Docker

For me is I forgot to copy published folder from the build step into the final step.

...
FROM build AS publish
RUN dotnet publish  --configuration Release --output /dist

FROM base AS final
COPY --from=publish /dist .
...

Solution 10 - Docker

I had the same error and as it turned out, I had accidentally mounted the application path of the container to the host system:

# Dockerfile
# ...
WORKDIR /var/myapp
# ...
# docker-compose.yml
services:
  myapp:
    // ...
    volumes:
      - /c/docker/myapp:/var/myapp     // <--- Had to be removed
    ports:
      - "80:5000"

Changing the volumes mapping resolved the issue.

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestioniristanView Question on Stackoverflow
Solution 1 - DockerKrzysztof MadejView Answer on Stackoverflow
Solution 2 - DockerSilent KayView Answer on Stackoverflow
Solution 3 - DockermybraveView Answer on Stackoverflow
Solution 4 - DockerStephan SchoemanView Answer on Stackoverflow
Solution 5 - Dockeruser1785103View Answer on Stackoverflow
Solution 6 - DockerSlipmpView Answer on Stackoverflow
Solution 7 - DockerashilonView Answer on Stackoverflow
Solution 8 - DockerJBSnorroView Answer on Stackoverflow
Solution 9 - DockerRobotronxView Answer on Stackoverflow
Solution 10 - DockerDaniel VeihelmannView Answer on Stackoverflow