Dotnet-docker: VS2019, Automated Dockerfile throws SDK not found error. .Netcore 3

Created on 10 May 2019  路  13Comments  路  Source: dotnet/dotnet-docker

Hi,

When I try run my docker file for my .netcore 3.0 app, I am receiving the following error from within the container:

It was not possible to find any compatible framework version

The specified framework 'Microsoft.AspNetCore.App', version '3.0.0-preview5-19227-01' was not found.

  • No frameworks were found.

Steps to reproduce the issue

  1. Build docker file:
FROM mcr.microsoft.com/dotnet/core/runtime:3.0-buster-slim AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443

FROM mcr.microsoft.com/dotnet/core/sdk:3.0-buster AS build
WORKDIR /src
COPY ["APP.ApplicationAPI/APP.ApplicationAPI.csproj", "EthereumBlockchainProcessor.ApplicationAPI/"]
COPY ["APP.Storage/APP.Storage.csproj", "APPProcessor.Storage/"]
COPY ["APP/APPProcessor.csproj", "APPProcessor/"]
RUN dotnet restore "APPProcessor.ApplicationAPI/APPProcessor.ApplicationAPI.csproj"
COPY . .
WORKDIR "/src/APPProcessor.ApplicationAPI"
RUN dotnet build "APPProcessor.ApplicationAPI.csproj" -c Release -o /app

FROM build AS publish
RUN dotnet publish "APPProcessor.ApplicationAPI.csproj" -c Release -o /app

FROM base AS final
WORKDIR /app
COPY --from=publish /app .
ENTRYPOINT ["dotnet", "APPProcessor.ApplicationAPI.dll"]
  1. Run the following command: docker build -t processor .
  2. docker run --name=processor -e ASPNETCORE_ENVIRONMENT=Development -d -p 5000:80 -t processor:latest

    Expected behavior

Run docker container and be able to connect to the docker container.

Actual behavior

Error:

It was not possible to find any compatible framework version

The specified framework 'Microsoft.AspNetCore.App', version '3.0.0-preview5-19227-01' was not found.

  • No frameworks were found.

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

The .NET Core frameworks can be found at:

Additional information (e.g. issue happens only occasionally)

Project csproj file: 
<Project Sdk="Microsoft.NET.Sdk.Web">

  <PropertyGroup>
    <TargetFramework>netcoreapp3.0</TargetFramework>
    <UserSecretsId>68db4d34-4296-4a4c-b9a5-5dfed77bc06a</UserSecretsId>
    <DockerDefaultTargetOS>Linux</DockerDefaultTargetOS>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore.Hosting.Abstractions" Version="2.2.0" />
    <PackageReference Include="Microsoft.AspNetCore.SignalR.Client" Version="1.1.0" />
    <PackageReference Include="Microsoft.EntityFrameworkCore" Version="2.2.4" />
    <PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="2.2.4" />
    <PackageReference Include="Microsoft.VisualStudio.Azure.Containers.Tools.Targets" Version="1.7.8" />
  </ItemGroup>

  <ItemGroup>
    <ProjectReference Include="..\EthereumBlockchainProcessor.Storage\EthereumBlockchainProcessor.Storage.csproj" />
  </ItemGroup>

  <ItemGroup>
    <Content Update="appsettings.Development.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
      <CopyToPublishDirectory>PreserveNewest</CopyToPublishDirectory>
    </Content>
    <Content Update="appsettings.json">
      <CopyToOutputDirectory>Always</CopyToOutputDirectory>
      <CopyToPublishDirectory>PreserveNewest</CopyToPublishDirectory>
    </Content>
  </ItemGroup>

</Project>

Output of docker version

 Version:           18.09.2
 API version:       1.39
 Go version:        go1.10.8
 Git commit:        6247962
 Built:             Sun Feb 10 04:12:31 2019
 OS/Arch:           windows/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          18.09.2
  API version:      1.39 (minimum version 1.12)
  Go version:       go1.10.6
  Git commit:       6247962
  Built:            Sun Feb 10 04:13:06 2019
  OS/Arch:          linux/amd64
  Experimental:     false

Output of docker info

Containers: 2 Running: 1 Paused: 0 Stopped: 1 Images: 330 Server Version: 18.09.2 Storage Driver: overlay2 Backing Filesystem: extfs Supports d_type: true Native Overlay Diff: true Logging Driver: json-file Cgroup Driver: cgroupfs Plugins: Volume: local Network: bridge host macvlan null overlay Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog Swarm: inactive Runtimes: runc Default Runtime: runc Init Binary: docker-init containerd version: 9754871865f7fe2f4e74d43e2fc7ccd237edcbce runc version: 09c8266bf2fcf9519a651b04ae54c967b9ab86ec init version: fec3683 Security Options: seccomp Profile: default Kernel Version: 4.9.125-linuxkit Operating System: Docker for Windows OSType: linux Architecture: x86_64 CPUs: 2 Total Memory: 1.934GiB Name: linuxkit-00155d614101 ID: HPJZ:QTXC:DHDK:PLYL:7UPA:7OKE:U2FL:BBI2:IRIX:HYHH:GQIQ:QLNQ Docker Root Dir: /var/lib/docker Debug Mode (client): false Debug Mode (server): true File Descriptors: 30 Goroutines: 53 System Time: 2019-05-10T10:00:18.5563673Z EventsListeners: 1 Registry: https://index.docker.io/v1/ Labels: Experimental: false Insecure Registries: 127.0.0.0/8 Live Restore Enabled: false Product License: Community Engine

question

Most helpful comment

In my case, this error appear when there is incorrect DLL filename in ENTRYPOINT.
For debug, try:

$ docker run --entrypoint /bin/bash -it [image]
(in docker) ls

All 13 comments

It appears that you are trying to use the runtime image to run an ASP.NET app. To run a Framework Dependent ASP.NET app you would need to use the aspnet image.

Try changing the first line in your Dockerfile to use the aspnet image.

Current:

FROM mcr.microsoft.com/dotnet/core/runtime:3.0-buster-slim AS base

Suggested:

FROM mcr.microsoft.com/dotnet/core/aspnet:3.0-buster-slim AS base

Perfect, that seemed to work. Getting a different error, and not sure if it is relevant to this forum but will post here anyway:

Unhandled Exception: System.Exception: Cannot connect to SQL Server Browser. Ensure SQL Server Browser has been started. ---> System.Net.Internals.SocketExceptionFactory+ExtendedSocketException: Resource temporarily unavailable

Closing issue as guidance was provided on the .NET Docker related issue. The SQL Server issue looks like a good question to post on StackOverflow where the audience is much larger.

I'm using mcr.microsoft.com/dotnet/core/aspnet:3.0 but I still get It was not possible to find any installed .NET Core SDKs

$ dotnet restore
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

And I tried to run bash on it,

Status: Downloaded newer image for mcr.microsoft.com/dotnet/core/aspnet:3.0
root@a2036d0d556e:/# dotnet --info
  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

Host (useful for support):
  Version: 3.0.0
  Commit:  95a0a61858

.NET Core SDKs installed:
  No SDKs were found.

.NET Core runtimes installed:
  Microsoft.AspNetCore.App 3.0.0 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 3.0.0 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

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

UPDATED

Use mcr.microsoft.com/dotnet/core/sdk:3.0 instead.

I've been fighting this both on the OSX VS side and Windows VS side for about a year now. Since other people are getting this issue I figured I would add my info. Seeing @kinosang's response yesterday gave me hope but unfortunately I'm still getting the error.

It should be stated that out of five micro services they'll work totally fine for an undefined amount of time, then all of the sudden a specific 1 will stop working. It's 96% of the time the same micro service, but has occurred with other services in the past. It's also not just my machine when debugging, it's other team members.

Here's what I've done.

  • I've combed the DockerFile to see if there's any differences.
  • I've fixed my docker-compose.yml to be what was posted here. It _was_ what they stated in the post, but I've corrected that.
  • I've dug into the docker-compose.vs.debug.g.yml to see if there's anything odd and nothing stands out to me.
  • I've tried deleting all of the images in Docker and restarting fresh.
  • I've tried the above which was to just set the initial stage in the DockerFile to use the skd: and not the aspnet:
  • I've also tried bashing to the container, which is running by the way, and running dotnet --info with the result below. It should be noted that when changing it to sdk: it did say that it had the SDK installed and that all the other micro services that do work, also have the same output.
  • While I was bashed in, I tried to run the app manually and it works perfectly.
  It was not possible to find any installed .NET Core SDKs
      https://aka.ms/dotnet-download

Host (useful for support):
  Version: 3.0.0
  Commit:  95a0a61858

.NET Core SDKs installed:
  No SDKs were found.

.NET Core runtimes installed:
  Microsoft.AspNetCore.App 3.0.0 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 3.0.0 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

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

The error log in the Debug console in VS 2019 is the following.

-------------------------------------------------------------------
You may only use the Microsoft .NET Core Debugger (vsdbg) with
Visual Studio Code, Visual Studio or Visual Studio for Mac software
to help you develop and test your applications.
-------------------------------------------------------------------
-------------------------------------------------------------------
You may only use the Microsoft .NET Core Debugger (vsdbg) with
Visual Studio Code, Visual Studio or Visual Studio for Mac software
to help you develop and test your applications.
-------------------------------------------------------------------
-------------------------------------------------------------------
You may only use the Microsoft .NET Core Debugger (vsdbg) with
Visual Studio Code, Visual Studio or Visual Studio for Mac software
to help you develop and test your applications.
-------------------------------------------------------------------
-------------------------------------------------------------------
You may only use the Microsoft .NET Core Debugger (vsdbg) with
Visual Studio Code, Visual Studio or Visual Studio for Mac software
to help you develop and test your applications.
-------------------------------------------------------------------
-------------------------------------------------------------------
You may only use the Microsoft .NET Core Debugger (vsdbg) with
Visual Studio Code, Visual Studio or Visual Studio for Mac software
to help you develop and test your applications.
-------------------------------------------------------------------
  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
The target process exited without raising a CoreCLR started event. Ensure that the target process is configured to use .NET Core. This may be expected if the target process did not run on .NET Core.

Update

How I fixed it _this time_ was by doing a docker-compose up --build and letting it fail since the VS containers were already up. I then clicked play in VS and it started working.

In my case, this error appear when there is incorrect DLL filename in ENTRYPOINT.
For debug, try:

$ docker run --entrypoint /bin/bash -it [image]
(in docker) ls

Hi,

So I faced a similar issue recently and searched everywhere but it was to no avail. I discovered the solution recently and just wanted to share it in-case anyone is facing the same problem.

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

In this snippet of the Dockerfile, simply replace yourapp.dll with app/yourapp.dll
i.e:

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

Since it was calling the path of the dotnet executable and tried to search for your .dll file, it couldn't find it simply because it was in another directory in the container so it tried to register it as a command which lead to the issue of not finding any SDK installed. Hope this was able to help someone.

@Kandeel441, Have you run your image interactively and inspected the file layout - e.g. docker run -it --rm --entrypoint /bin/bash <your-image>? I am wondering if you by chance have nested app folders - /app/app/yourapp.dll? Given the WORKDIR /app instruction, I wouldn't expect you would need to specify it in "app/yourapp.dll".

To update where I'm at now and to hopefully give a bit more perspective into my personal problem, in the case this happens for anyone else, here's what my problem most likely was. I don't know what the cause was still, but this is what I've done to fix it.

My issue was I had two microservices with similar names and utilizing some of the same libraries.

  1. Merch
  2. Merch-Admin: This used the same domain layer library in the project. However I _did_ make sure my build priorities were correct multiple times and they were as expected.

What was happening before in my previous post was that Merch would start failing as I stated and then I would have to docker-compose up --build, let it fail because VS was still running and then stopping then clicking run again. _This however didn't always work, but most of the time it did._

Now what I've done since my last post is take out the Merch-Admin service from the compose and compose-override file so that it never builds/debugs in VS anymore. This was a few months ago and it's been 100% working since.

TL;DR: What I found was either the services using the same library (which is unlikely because they share many other libraries in the project) or more likely they had similar names.

@MichaelSimons I have tried running it interactively and I was able to run it normally using dotnet myapp.dll But it failed when I tried running it through docker-compose, but I think I finally know the main problem, It was because I was mapping my docker volume like so:

    volumes:
      -.:/app

When the docker volume was connected it has overwritten the contents of the container /app directory with my local directories and hence the problem of not finding the .dll file and SDK started. It only appeared to work for me after being overwritten because I actually had an app folder which contained myapp.dll that I used to develop with locally. Sorry for the trouble 馃槄

Just for anyone who finds this thread and none of the above fixes apply, I had the same error and it turned out that I'd stupidly forgotten the step in the Dockerfile where you copy the DLL into the image...

WORKDIR /app
COPY src/MyProject/bin/Release/netcoreapp3.1/publish .

And for other people stumbling on this who might have generated their Dockerfile from the vscode Docker extension. If you have specified an AssemblyName in your .csproj file that is different from the name of your project, then the name of the .dll file in the ENTRYPOINT line will be wrong.

In my case my projects name is Physio.Server.WebApi.csproj but I have specified it to have AssemblyName: Habitlab.Physio.Server.WebApi. This meant that the ENTRYPOINT generated was:

ENTRYPOINT ["dotnet", "Physio.Server.WebApi.dll"]

But should have been:

ENTRYPOINT ["dotnet", "Habitlab.Physio.Server.WebApi.dll"]

I have created the following bug on the vscode extension to correct the issue: https://github.com/microsoft/vscode-docker/issues/1583

I faced this same issue, then what I did was:

  • docker run --entrypoint /bin/bash -it [image]

I was able to get inside the container.

After getting inside the container, I ran dotnet command to check if it was installed, it was.

Then I listed all files and realized that my project dll's name was not same as it was on Visual Studio. For some reason someone renamed the output dlls.

Then I just changed my ENTRYPOINT correctly from:

ENTRYPOINT ["dotnet", "Simulacao.Application.API.dll"]
to
ENTRYPOINT ["dotnet", "MissingNameSpace.Simulacao.Application.API.dll"]

Rebuild the image and it worked!

Was this page helpful?
0 / 5 - 0 ratings