You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Contacting a dotnet core API running inside a container allows me to call the database
Actual behavior
The type initializer for 'System.Data.SqlClient.SNILoadHandle' threw an exception, Unable to load shared library 'sni.dll'
Information
I am running a .net core API in a linux container. The api is correctly build, which means that when I run it through powershell dotnet command, it is correctly hosted in Kestrel and I am able to call it with all its features, including contacting the db.
Inside the container instead, the result is not correct and I have the feeling that there is something wrong with the location of the dlls. My dockerfile looks like this:
FROM microsoft/aspnetcore-build:2.0 AS build-env
WORKDIR /app
COPY PublishOutput/. ./
FROM microsoft/aspnetcore-nightly:2.1.0-preview2-alpine
WORKDIR /app
COPY --from=build-env /app .
ENTRYPOINT ["dotnet", "Api.Web.dll"]
I am using microsoft/aspnetcore-nightly:2.1.0-preview2-alpine because I had a similar problem with the libuv.dll being missing (and found the answer to solve my problem here aspnet/KestrelHttpServer#2415) but already then it looked to me a bit suspicious. In the PublishOutput there are all the dlls published by visual studio. Amongst these dlls there was libuv.dll and there is also the sni.dll which is complaining now about. What am I missing? Is the dockerfile wrong by any chance?
The text was updated successfully, but these errors were encountered:
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale comment.
Stale issues will be closed after an additional 30d of inactivity.
Prevent issues from auto-closing with an /lifecycle frozen comment.
If this issue is safe to close now please do so.
Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle stale
Expected behavior
Contacting a dotnet core API running inside a container allows me to call the database
Actual behavior
The type initializer for 'System.Data.SqlClient.SNILoadHandle' threw an exception, Unable to load shared library 'sni.dll'
Information
I am running a .net core API in a linux container. The api is correctly build, which means that when I run it through powershell dotnet command, it is correctly hosted in Kestrel and I am able to call it with all its features, including contacting the db.
Inside the container instead, the result is not correct and I have the feeling that there is something wrong with the location of the dlls. My dockerfile looks like this:
I am using microsoft/aspnetcore-nightly:2.1.0-preview2-alpine because I had a similar problem with the libuv.dll being missing (and found the answer to solve my problem here aspnet/KestrelHttpServer#2415) but already then it looked to me a bit suspicious. In the PublishOutput there are all the dlls published by visual studio. Amongst these dlls there was libuv.dll and there is also the sni.dll which is complaining now about. What am I missing? Is the dockerfile wrong by any chance?
The text was updated successfully, but these errors were encountered: