I’m using Kestrel for the hosting engine, either .NET Core 3.1 or .NET 5.0
I’m getting an exception thrown from the SendResponseAsync method n the SoapBinding when trying to send an artifact response back to the service provider.
It appears, from the stack trace, that a synchronous flush is being used to write the response. The problem is that SynchronousIO is disabled.
Are you calling FlushAsync, or relying on a dispose to flush the response content ?
—> System.InvalidOperationException: Synchronous operations are disallowed. Call WriteAsync or set AllowSynchronousIO to true instead.
at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpResponseStream.Write(Byte[] buffer, Int32 offset, Int32 count)
at System.IO.StreamWriter.Flush(Boolean flushStream, Boolean flushEncoder)
at System.IO.StreamWriter.Dispose(Boolean disposing)
at System.IO.TextWriter.Dispose()
at ComponentSpace.Saml2.Bindings.Soap.SoapBinding.SendResponseAsync(String message)
— End of inner exception stack trace —
at ComponentSpace.Saml2.Bindings.Soap.SoapBinding.SendResponseAsync(String message)
at ComponentSpace.Saml2.SamlProvider.ProcessArtifactResolveAsync(XmlElement artifactResolveElement)
at ComponentSpace.Saml2.SamlIdentityProvider.ResolveArtifactAsync()
We were relying on the dispose but this no longer works by default with later .NET Core releases. We now call FlushAsync.
Please contact support@componentspace.com for an update.
Please contact support@componentspace.com for an update.
In what version was this fixed ?
Please contact support@componentspace.com for an update.
In what version was this fixed ?[/quote]
it still appears to be a problem with 3.6.0, I switched to the latest trial version to verify.
The fix is included in the soon to be released v3.7.0.
Please contact support@componentspace.com for an update.
Please contact support@componentspace.com for an update.
version 3.7.0 is forcing me up to upgrade an ASP.NET Core 3.1 app to some .NET 5.0 dependencies, yet AspNetCore has a 2.2.x minimum. This wasn't the case with the previous version we're using. ( looks like the minimum was changed in v 3.6.0)
I'm now getting a compilation error as I'm explicitly referencing 3.1.x of common dependencies and getting the NU1601 build error. We have other 3rd party libraries that target netCoreApp3.1 and .NET 5.0 separately and enforce 3.x and 5.0 dependencies.
I can't see any way around this error.. Please advise.
Prior to version 3.5.0 we targeted .NET Standard 2.0 only. In version 3.5.0 we targeted both .NET Standard 2.0 and 2.1. For the .NET Standard 2.0 build, the dependency versions haven’t changed. In version 3.6.0, we updated the dependencies for the .NET Standard 2.1 build as you listed.
Are you asking that the Microsoft.Extensions.* not use v5.0.0? What version would you want to be used?
We could look at targeting .NET Standard 2.0, .NET Standard 2.1 and .NET 5 separately.
Are you asking that the Microsoft.Extensions.* not use v5.0.0? What version would you want to be used?
We could look at targeting .NET Standard 2.0, .NET Standard 2.1 and .NET 5 separately.
https://www.nuget.org/packages/ComponentSpace.Saml2/3.5.0
NetStandard 2.1 compatibility started with .NET Core 3.0 ( realistically 3.1) but now you have the issue with NetCoreApp3.1 targeting problems with some dependencies... as highlighted here.
As it stands, I cannot use any version higher than 3.5.0 because of the enforced 5.0.0 dependencies with NetStandard 2.1, and I can't use v 3.5.0 because of the issue originally raised. Do you have any suggestions ?
another thought ... are there actually any differences between the NetStandard2.0 and NetStandard 2.1,given AspNetCore.Authentication and AspNetCore.Http dependencies are still 2.2. I could create a wrapper project that forces NetStandard 2.0 for .NET 3.1 and NetStandard 2.1 for Net 5.0... but if there are functional changes between NetStandard 2.0 and 2.1, then I may break all the .NET Core 3.1 web apps
There are some minor code differences between the .NET Standard 2.1 and 2.1 versions.
I’d like to better understand the issue and come up with a better solution if possible.
Could you give me the specifics of the package incompatibilities you’re seeing with your project? You’re welcome to email these if you prefer.
If I create an ASP.NET Core project that targets .NET Core 3.1 and add the 3.7.0 release it builds cleanly.
If, for example, I add a reference to Microsoft.Extensions.Logging v3.1.17 it’ll naturally cause a version conflict. The solution would be to move to the latest release of the Microsoft.Extensions.Logging package as this is also compatible with .NET Core 3.1 projects.
Or are you saying doing this would cause conflicts with other packages referenced by your project?
My test project with the following compiles.
netcoreapp3.1
I'd like to better understand the issue and come up with a better solution if possible.
Could you give me the specifics of the package incompatibilities you're seeing with your project? You're welcome to email these if you prefer.
If I create an ASP.NET Core project that targets .NET Core 3.1 and add the 3.7.0 release it builds cleanly.
If, for example, I add a reference to Microsoft.Extensions.Logging v3.1.17 it'll naturally cause a version conflict. The solution would be to move to the latest release of the Microsoft.Extensions.Logging package as this is also compatible with .NET Core 3.1 projects.
Or are you saying doing this would cause conflicts with other packages referenced by your project?
My test project with the following compiles.
netcoreapp3.1
Yes, this conflicts with other packages that target NetCoreApp3.1 and .NET 5.0 separately. NetCoreApp3.1 versions define dependencies between 3.1.x and < 5.0, and Net 5.0 >= 5.0. This due to the way some Microsoft packages in the 3.x space themselves target NetCoreApp3.1 so those packages could not target NetStandard 2.1. (and I suspect why you've left Microsoft.AspNetCore.Http dependency at 2.2)
I understand that this is not a easy situation to solve, and is mostly due to Microsoft's (IMHO) insane version strategy for .NET Core 3.1. Unfortunately we have packages that were built for .NET Core 3.1 (targeting NetCoreApp3.1) and then subsequently .NET 5.0 and relied on API changes between the 2 versions so they cannot be brought together by either moving to 5.x or regressing NETCoreApp3.1 back to 2.x and netstandard 2.x.
The latest release of Microsoft.AspNetCore.Http is v2.2.2. That’s the reason we use that version.
My apologies, but I’m still not following.
Could you give a specific example (ie what packages and their version numbers) so I can create a project and reproduce the issue?
Please contact support@componentspace.com for an update.
I'm still getting this exception with the artifact binding with 3.7.0.
ComponentSpace.Saml2.Exceptions.SamlBindingException: Failed to send the SAML response over SOAP.
---> System.InvalidOperationException: Synchronous IO APIs are disabled, see AllowSynchronousIO.
at Microsoft.AspNetCore.Server.HttpSys.ResponseBody.Flush()
at Microsoft.AspNetCore.Server.HttpSys.ResponseStream.Flush()
at System.IO.StreamWriter.Flush(Boolean flushStream, Boolean flushEncoder)
at System.IO.StreamWriter.Dispose(Boolean disposing)
at System.IO.TextWriter.Dispose()
at ComponentSpace.Saml2.Bindings.Soap.SoapBinding.SendResponseAsync(String message)
--- End of inner exception stack trace ---
at ComponentSpace.Saml2.Bindings.Soap.SoapBinding.SendResponseAsync(String message)
at ComponentSpace.Saml2.SamlProvider.ProcessArtifactResolveAsync(XmlElement artifactResolveElement)
at ComponentSpace.Saml2.SamlIdentityProvider.ResolveArtifactAsync()
The dispose method will still call Flush on the underlying writer, even if there is nothing in the buffer. It appears you are calling FlushAsync, but still using the synchronous dispose.
See https://docs.microsoft.com/en-us/dotnet/standard/garbage-collection/implementing-disposeasync
I’ll see if I can reproduce the issue.
Please email support@componentspace.com so you can receive a fix to try.