-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Stack Overflow exception with SslStream and NetCoreApp mix of 2.1 and 3.x #38185
Comments
Tagging subscribers to this area: @dotnet/ncl |
I may misunderstand the use case but IO don't think it is safe to mix random assemblies from .NET versions. |
I took closer look and here is what is going on. 2.1 does not have correct ref assemblies. That was fixed by @stephentoub in dotnet/corefx#29658 but it was not ported back to 2.1. With that base does not resolve properly and that creates code loop and eventually fills up stack. in windbg
I think best option here is targeting 3.1 (if possible) for the wrapper or avoiding the missing functions. |
Nice catch @wfurt |
Isn't .NET Core SDK supposed to be backwards compatible? |
It would. But since 2.1 is missing WriteAsync in reference assembly, you will not be able to use it. |
You should be able to service it in 2.1. Normally we don't touch reference assemblies in servicing, but since this is a case of a compatible change that the implementation already supports I think it is OK. 2.1 ships the reference assemblies with every servicing event via the Microsoft.NETCore.App package, so I think the change here is to simply make the fix to the reference assembly source. Of course for SqlClient to be able to use such a fix they'd need to rebuild using that updated package. SqlClient could also try to build against some private set of reference assemblies if you wanted, since this change doesn't actually ship inside the component that could be done to help unblock things quicker. |
@DavoudEshtehari is it blocking you? Do you have a business case for us to fix it in 2.1 servicing? |
Hi @karelz
We have several issues related to the PR #579 that are blocked by this issue.
If I understood correctly, besides the sample app, you can try the PR I mentioned.
You're right. I have no idea for a workaround. If you have any proven idea please, let me know. |
Below issues are waiting for PR dotnet/SqlClient#579:
As for workaround for driver issue, we have below:
Although we do ship netcoreapp3.1 DLL with NuGet - that should not surface this issue, however, this is a bleak possible case where if users end up using netcoreapp2.1 DLL when targeting anything above it. |
@CarnaViire will start the port. @cheenamalhotra will you be able to validate the change prior to checkin? |
Sure, let us know when changes are ready to be tested. |
Sample app is good, we should try end-to-end validation as well though Triage: We should take just the relevant APIs needed here, not the entire PR. |
As per offline communication with SqlClient team, We discovered that the SqlClient nuget package provides both 2.1 and 3.1 versions of the library. It means that for 3.1+ applications, 3.1 version will be resolved, not 2.1, so the repro with projects provided in the issue does not seem to represent SqlClient scenarios. Given that there is no customer hitting it and given that it seems SqlClient users are not going to hit the problem on supported versions (2.1 or 3.1+), we decided that we should wait with servicing until we have real customer reports of hitting the problem. |
Description
Hi dotnet/runtime team,
I found an issue in
Ubuntu 16.04
when I was using theSslStream
. At first, I tried to reproduce it in a sample application in Ubuntu, and at last, I am able to reproduce it inWindows
. I don't know if there is a similar issue with other types!The issue happens when you try to use an assembly with
NetCore 2.1
in another project withNetCore 3.x
(I have not checked theNetCore 5.0
preview).You can find the sample application here.
Here are the sample outputs:
nercoreapp3.0
in the 'Demo' project.If you change the
TargetFramework
of the projectClassLibraryA
tonercoreapp3.1
fromnetcoreapp2.1
, or changeTargetFramework
of the projectDemo
tonercoreapp2.1
it will work without exception.The text was updated successfully, but these errors were encountered: