.Net Core 3.1 Synchronous operations are disallowed Exception

[matthiaslischka]

Steps to reproduce

1. Create a ZIP archive with .Net 3.1 web api.
2. Call ZipOutputStream.PutNextEntry

Actual behavior

System.InvalidOperationException: 'Synchronous operations are disallowed. Call WriteAsync or set AllowSynchronousIO to true instead.'

 	System.Private.CoreLib.dll!System.IO.Stream.WriteByte(byte value)	Unknown
 	ICSharpCode.SharpZipLib.dll!ICSharpCode.SharpZipLib.Zip.ZipOutputStream.WriteLeShort(int value)	Unknown
 	ICSharpCode.SharpZipLib.dll!ICSharpCode.SharpZipLib.Zip.ZipOutputStream.WriteLeInt(int value)	Unknown
 	ICSharpCode.SharpZipLib.dll!ICSharpCode.SharpZipLib.Zip.ZipOutputStream.PutNextEntry(ICSharpCode.SharpZipLib.Zip.ZipEntry entry)	Unknown

The problem seems to be that .Net 3.1 disables "synchronous operations" by default and as workaround you can set "AllowSynchronousIO" to true in startup.

However, I wonder if this should/could be fixed with a PutNextEntryAsync method.
To be honest, I don't yet understand the underlying issue completely though.

Version of SharpZipLib

1.3.0

[piksel]

Setting AllowSynchronousIO = true means that this check is bypassed for everything, which is not ideal. The main reason for not having async variants of our methods (apart from the huge amount of work it would be to implement) is that compression is inherently CPU-bound, and just doing the writes async would give very little benefit.

I think the right way to handle this is to either do the compression in a background job and return a JobID that can be polled for the result or something similar.
Awaiting a Task.Run() that does the compression might also be a solution, that would at least let the request be awaited (and allow it to handle other requests) while compressing. It mostly depends on the size (or compression time rather) of the thing being processed.

[matthiaslischka]

How about creating the file in a memory stream and at the end copying this memory stream async to the response stream?

[piksel]

ZipOutputStream is just a stream abstraction, it can operate on a memory stream or a file stream just as well. If you do the zip creation using a MemoryStream in a task that is awaited and then async-copy the MS to the output stream it should probably be fine.

[matthiaslischka]

AllowSynchronousIO can be enable for single calls as well. We are probably going with that as we only need the ZIP to bundle together some small files for single file download. We don't even really need compression.

var syncIOFeature = HttpContext.Features.Get<IHttpBodyControlFeature>();
if (syncIOFeature != null)
{
    syncIOFeature.AllowSynchronousIO = true;
}

See: dotnet/aspnetcore#7644

It still feels wrong somehow.