ComponentSpace

Forums



SoapBinding ( Artifact response ) is throwing an exception when Sending a response


SoapBinding ( Artifact response ) is throwing an exception when...

Author
Message
slaneyrw
slaneyrw
New Member
New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)

Group: Forum Members
Posts: 11, Visits: 62
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()

ComponentSpace
ComponentSpace
ComponentSpace Development
ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)

Group: Administrators
Posts: 3.2K, Visits: 11K
We were relying on the dispose but this no longer works by default with later .NET Core releases. We now call FlushAsync.

Please contact [email protected] for an update.

Regards
ComponentSpace Development
slaneyrw
slaneyrw
New Member
New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)

Group: Forum Members
Posts: 11, Visits: 62
ComponentSpace - 7/19/2021
We were relying on the dispose but this no longer works by default with later .NET Core releases. We now call FlushAsync.

Please contact [email protected] for an update.

In what version was this fixed ?
slaneyrw
slaneyrw
New Member
New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)

Group: Forum Members
Posts: 11, Visits: 62
slaneyrw - 7/21/2021
ComponentSpace - 7/19/2021
We were relying on the dispose but this no longer works by default with later .NET Core releases. We now call FlushAsync.

Please contact [email protected] for an update.

In what version was this fixed ?

it still appears to be a problem with 3.6.0, I switched to the latest trial version to verify.
ComponentSpace
ComponentSpace
ComponentSpace Development
ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)

Group: Administrators
Posts: 3.2K, Visits: 11K
The fix is included in the soon to be released v3.7.0.

Please contact [email protected] for an update.


Regards
ComponentSpace Development
slaneyrw
slaneyrw
New Member
New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)

Group: Forum Members
Posts: 11, Visits: 62
ComponentSpace - 7/21/2021
The fix is included in the soon to be released v3.7.0.

Please contact [email protected] 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)

  <dependency id="Microsoft.AspNetCore.Authentication" version="2.2.0" exclude="Build,Analyzers" />
  <dependency id="Microsoft.AspNetCore.Http" version="2.2.2" exclude="Build,Analyzers" />
   <dependency id="Microsoft.Extensions.Caching.Memory" version="5.0.0" exclude="Build,Analyzers" />
   <dependency id="Microsoft.Extensions.Logging" version="5.0.0" exclude="Build,Analyzers" />
   <dependency id="Microsoft.Extensions.Options.ConfigurationExtensions" version="5.0.0" exclude="Build,Analyzers" />
    <dependency id="System.Security.Cryptography.Xml" version="5.0.0" exclude="Build,Analyzers" />

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.
ComponentSpace
ComponentSpace
ComponentSpace Development
ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)

Group: Administrators
Posts: 3.2K, Visits: 11K
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.

Regards
ComponentSpace Development
slaneyrw
slaneyrw
New Member
New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)

Group: Forum Members
Posts: 11, Visits: 62
ComponentSpace - 7/28/2021
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.
v 3.5.0, which targeted NetStandard 2.1, had dependencies consistent with your AspNetCore versions... >= 2.2.1|
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

ComponentSpace
ComponentSpace
ComponentSpace Development
ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)

Group: Administrators
Posts: 3.2K, Visits: 11K
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.


<PropertyGroup>
    <TargetFramework>netcoreapp3.1</TargetFramework>
</PropertyGroup>

<ItemGroup>
    <PackageReference Include="ComponentSpace.Saml2" Version="3.7.0" />
    <PackageReference Include="Microsoft.Extensions.Logging" Version="5.0.0" />
</ItemGroup>




Regards
ComponentSpace Development
slaneyrw
slaneyrw
New Member
New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)

Group: Forum Members
Posts: 11, Visits: 62
ComponentSpace - 7/29/2021
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.


<PropertyGroup>
    <TargetFramework>netcoreapp3.1</TargetFramework>
</PropertyGroup>

<ItemGroup>
    <PackageReference Include="ComponentSpace.Saml2" Version="3.7.0" />
    <PackageReference Include="Microsoft.Extensions.Logging" Version="5.0.0" />
</ItemGroup>



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.
GO


Similar Topics


Execution: 0.000. 2 queries. Compression Enabled.
Login
Existing Account
Email Address:


Password:


Select a Forum....












Forums, Documentation & Knowledge Base - ComponentSpace


Search