-
Notifications
You must be signed in to change notification settings - Fork 280
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
Regression with published application: PlatformNotSupportedException #445
Comments
I figured this out, after almost a solid week of debugging... There was a change in dotnet build in 3.0+ that meant dotnet build now pulls nuget packages in whereas before it did not. So if you don't specify --runtime to the build command and it runs before publish, it will pull in the default dlls, then publish will see the dlls are there and not update them with the correct ones for the platform/runtime. It still seems strange to me though, because in my dockerfile I am on Linux so I would expect dotnet build without --runtime to pull in the "unix" dll of SqlClient. But I guess it doesn't. https://docs.microsoft.com/en-us/dotnet/core/whats-new/dotnet-core-3-0#build-copies-dependencies |
Cool! I've been wrapping my head around this one, and saw same problem, it is due to "lib" folder dlls getting copied which is not expected in Linux or even Dotnet Core. Runtime libraries should override. According to Nuget documentation here:
Which makes sense but doesn't seem to be true in this case? I was able to make it work by adding this target to csproj: <Target Name="PreventCopyOfLibDlls" AfterTargets="ResolveReferences">
<ItemGroup>
<ReferenceCopyLocalPaths Remove="@(ReferenceCopyLocalPaths)" Condition="'%(ReferenceCopyLocalPaths.RuntimeIdentifier)' == ''" />
</ItemGroup>
</Target> If there is no runtime identifier (applies to lib*.dll), we don't want those to be included. Related argument could be that Also that seems to be applicable to |
Hi @davedx Also to add:
This is true since we ship runtimes for "unix", which is expected to be a fallback folder for any related runtime.
Can you elaborate to which version of SqlClient worked well for you before? |
Hi @davedx As per comment https://github.com/dotnet/runtime/issues/33046#issuecomment-593714200 this behavior is by design. Let me know for any more questions you have. |
Hi @cheenamalhotra, Thanks a lot for following up on this issue, it's appreciated. I confirm this is caused by the sdk's behaviour and it's not sqlclient's fault :) Maybe it would be nice to add a line about this to the FAQ entry for PlatformNotSupported Exception to help future travellers. Have a good week. |
Describe the bug
We have a .NET core application that is built and published inside a dockerfile. When we upgraded EF core to 3.1 and deployed our app, it started crashing at runtime in the SqlClient constructor with a PlatformNotSupportedException. After some investigation we determined the issue is related to how SqlClient is deployed with dotnet publish; also upgrading only SqlClient in isolation would result in the same crash. Running a shell inside the docker image it appears the correct SqlClient DLL for the platform (Linux) is not copied to the root of the application.
One workaround is to remove the --runtime linux-x64 flag from dotnet publish. Then it works. But this produces a different type of build (not self contained).
To reproduce
Clone this repo: https://github.com/davedx/sqlclient-repro
Then run:
docker build -t efgs -f ./Dockerfile.custom.dotnet.3.1 .
docker run efgs
Expected behavior
Previous to upgrading SqlClient, this dockerfile and deploy process worked and app would run without crashing.
Further technical details
Microsoft.Data.SqlClient version: 1.0.19269.1
.NET target: (Core 3.1)
SQL Server version: (SQL Server 2019)
Operating system: (Docker container)
Additional context
There seems to be a related issue here: dotnet/runtime#29522
But we are on a newer version of dotnet core than the version in the above issue that fixed the issue. I'm happy to also open an issue no that repo if you think it's an issue with a different component but thought I had to start somewhere. :)
The text was updated successfully, but these errors were encountered: