-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
XpsDocumentWriter.Write fails with NotSupportedException #1363
Comments
Related to #585 and PR #1311 - you may want to retry with nightly builds of preview8 - but I don't think your case is actually fixed yet, since the PR was mostly about reading streams, not writing them. [edit] actually I think the PR #1311 is broken, because it wraps writing into a memory stream. While it may no longer throw it probably doesn't flush the writes to the original stream either. |
@weltkante Thanks for linking. I've downloaded already the latest nightly build, but it's not fixed yet. Yes, PR #1311 looks like it is fixing it. Let's see. |
@thomasclaudiushuber does this still throw in nightly preview8 or just drops data silently? If it still throws I may want to open a separate issue for revisiting PR #1311 because I think it doesn't handle wrapping writable streams correctly. |
@weltkante I just tried it again. It throws exactly the same exception on preview8-013410. I've updated the preview version in the issue to that version. |
I'll look at this in the context of the broader discussion about the seekability change. From the testing we did on the backend, it looked like everything was fine with the passthrough, but perhaps we missed a scenario. |
I just dipped into this and it looks like there are some parts of the code in ReachFramework that were missed when wrapping the GetStream functions in #1311 . In light of @weltkante's comments I want to make 100% certain that these parts can use the same extensions without breaking. |
Nothing in this repro goes through the extension functions as far as I can tell. This actually may be a bug within packaging.
WPF is asking for a The call |
I don't see how WPF is influencing these calls, I'm going to write a repro without using WPF and see if I can cause the same problem to occur with a reasonable console app. If I can do that I will file a bug on CoreFX and convert this to tracking. |
I'm wondering how the streams you were seeing in the existing extension method calls were ever seekable, weren't they coming from the same zip implementation? For what its worth writable streams not beeing seekable could be by design as well, because it allows streaming them through the compressor in a write-through way. If they were seekable they'd had to buffer everything and compress on Dispose. |
Opening an existing document as ReadWrite gave me a seekable stream. That's an entirely different path than Create. The ReadWrite path would open a deflate stream and read the entire stream into memory, basically what we were doing to wrap it. |
Sorry meant to link the place where it loads as well: |
Tagging as a bug for now, will switch to tracking if we can prove and file a bug on CoreFX. |
I am not sure this is truly by design, because they are assuming it is seekable by calling SetLength. That doesn't seem to make any sense to me. Anyway, haven't gotten around to reproducing it in a console app yet, if I can do that then it's definitely a bug since underlying stream implementations should not cause a bug via legitimate public API usage. |
I was able to get a very simple repro in a console app:
This will follow the same stream creation path and throw I'll file a bug on CoreFX and also see if I can get some workaround here. |
Found a workaround. Simply open the XpsDocument as This forces CoreFX to use the "update" path, which gives back a seekable stream. |
Filed this bug on CoreFX: https://github.com/dotnet/corefx/issues/39816 Will convert this to tracking. |
@ericstj is this by design? i remember in a few cases having to make similar changes as this to get seekability. Is there a matrix of all the different combinations of modes and the expected/supported functionality? |
Assigning to @stevenbrix as he is working on CoreFX bug. |
The PR in dotnet/corefx is out: dotnet/corefx#40319 |
Is this already solved? as we experience the same "NotSupportedException" on a server 2012r2 with XpsDocumentWriter.Write |
I don't think this is fixed yet, because the user here also complains about this issue: |
Problem description:
XpsDocumentWriter.Write fails with NotSupportedException with the message "This stream from ZipArchiveEntry does not support seeking."
Actual behavior:
Message:
System.NotSupportedException : This stream from ZipArchiveEntry does not support seeking.
Stack Trace:
at WrappedStream.ThrowIfCantSeek()
at WrappedStream.SetLength(Int64 value)
at ZipWrappingStream.SetLength(Int64 value)
at ZipPackagePart.GetStreamCore(FileMode streamFileMode, FileAccess streamFileAccess)
at PackagePart.GetStream(FileMode mode, FileAccess access)
at PackagePart.GetStream(FileMode mode)
at XmlPartEditor.OpenDocumentForWrite()
at XpsPackagingPolicy.AcquireXmlWriterForFixedDocumentSequence()
at XpsSerializationManager.AcquireXmlWriter(Type writerType)
at DocumentSequenceSerializer.get_XmlWriter()
at DocumentSequenceSerializer.PersistObjectData(SerializableObjectContext serializableObjectContext)
at ReachSerializer.SerializeObject(Object serializedObject)
at XpsSerializationManager.SaveAsXaml(Object serializedObject)
at XpsDocumentWriter.SaveAsXaml(Object serializedObject, Boolean isSync)
at XpsDocumentWriter.Write(FixedDocumentSequence fixedDocumentSequence)
Expected behavior:
It should just create the XPS like in .NET Framework.
Minimal repro:
I've created a test project with a single test that shows the problem. The test succeeds on .NET Framework, but fails on .NET Core: https://github.com/thomasclaudiushuber/XpsNetCoreTests
The text was updated successfully, but these errors were encountered: