You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When trying construct a ZipArchive "on the fly" and serve it from the Web API, I have to turn-on the ASP.NET synchronous I/O mode, otherwise I get an exception when trying to create or write to ZIP entries. So far, I have encountered exceptions:
when calling Stream.WriteAsync on the stream returned from ZipArchiveEntry.Open,
and when calling ZipArchive.CreateEntry repeatedly (see the attached project).
Reproduction Steps
The following controller action illustrates the problem:
[HttpGet]publicasync Task Get(){using(varzip_archive=new ZipArchive(Response.Body, ZipArchiveMode.Create,true)){varzip_entry= zip_archive.CreateEntry("test.txt");awaitusing(varstream= zip_entry.Open()){// System.InvalidOperationException: 'Synchronous operations are disallowed. Call WriteAsync or set AllowSynchronousIO to true instead.'await stream.WriteAsync(Encoding.UTF8.GetBytes("Hello ZIP!"));}}}
Here is a small project which illustrates the problem:
If you access the route /zip or /zip2 you'll see the exception in the debugger and the corresponding diagnostic page in the browser.
Expected behavior
The ZIP archive is constructed and served without throwing any exceptions.
Actual behavior
The following exception is thrown:
System.InvalidOperationException: 'Synchronous operations are disallowed. Call WriteAsync or set AllowSynchronousIO to true instead.'
Regression?
No response
Known Workarounds
The exception can be avoided by setting IHttpBodyControlFeature.AllowSynchronousIO, as mentioned in aspnetcore / #7644.
That, of course, allows the ZIP code to "hog" the thread. It would be much better to upgrade the ZIP code to support true asynchronous I/O, which would benefit scalability and also remove the need for this workaround.
Configuration
.NET 8
Windows 11 Pro
x64
Other information
No response
The text was updated successfully, but these errors were encountered:
This exception is originating from the backing stream you're passing to ZipArchive. So I guess the bug here is that ZipArchive has no way of knowing that the backing stream requires Async calls and Zip internally uses synchronous calls to write parts of the archive.
Changes here would probably be a feature request for new API that indicates how Zip should interact with the backing stream. I think for now you're better to use workaround listed - or use a different stream to write to.
So I guess the bug here is that ZipArchive has no way of knowing that the backing stream requires Async calls and Zip internally uses synchronous calls to write parts of the archive.
I'm calling WriteAsync on the stream returned from ZipArchiveEntry.Open. Shouldn't that be enough for Zip to "know" that it should use asynchronous calls internally?
Description
When trying construct a
ZipArchive
"on the fly" and serve it from the Web API, I have to turn-on the ASP.NET synchronous I/O mode, otherwise I get an exception when trying to create or write to ZIP entries. So far, I have encountered exceptions:Stream.WriteAsync
on the stream returned fromZipArchiveEntry.Open
,ZipArchive.CreateEntry
repeatedly (see the attached project).Reproduction Steps
The following controller action illustrates the problem:
Here is a small project which illustrates the problem:
ZipAspAsyncIO.zip
If you access the route
/zip
or/zip2
you'll see the exception in the debugger and the corresponding diagnostic page in the browser.Expected behavior
The ZIP archive is constructed and served without throwing any exceptions.
Actual behavior
The following exception is thrown:
Regression?
No response
Known Workarounds
The exception can be avoided by setting
IHttpBodyControlFeature.AllowSynchronousIO
, as mentioned in aspnetcore / #7644.That, of course, allows the ZIP code to "hog" the thread. It would be much better to upgrade the ZIP code to support true asynchronous I/O, which would benefit scalability and also remove the need for this workaround.
Configuration
.NET 8
Windows 11 Pro
x64
Other information
No response
The text was updated successfully, but these errors were encountered: