Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The type initializer for 'System.Data.SqlClient.SNILoadHandle' threw an exception, dll not found #2168

Closed
enricoribelli opened this issue Jul 2, 2018 · 2 comments

Comments

@enricoribelli
Copy link

enricoribelli commented Jul 2, 2018

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:

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?

@docker-robott
Copy link
Collaborator

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

@docker-robott
Copy link
Collaborator

Closed issues are locked after 30 days of inactivity.
This helps our team focus on active issues.

If you have found a problem that seems similar to this, please open a new issue.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle locked

@docker docker locked and limited conversation to collaborators Jun 29, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants