Closed 0x4Graham closed 5 years ago
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.
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
-------------------------------------------------------------------
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.
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.
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:
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!
I faced this same issue, then what I did was:
1 - I changed my output folder from
RUN dotnet publish -c Release -o output
To
RUN dotnet publish -c Release -o .
2 - I logged the container using:
docker run --rm -it --entrypoint bash <container-name>
And 3 - I ensured that the .dll specified in my ENTRYPOINT ["dotnet", "MyApp.dll"]
was there.
Hi,
When I try run my docker file for my .netcore 3.0 app, I am receiving the following error from within the container:
Steps to reproduce the issue
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"]
Project csproj file:
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
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```