[Release/3.1] Change XPS document creation to use FileAccess.ReadWrite instead of FileAccess.Write #2081
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…multiple ZipArchiveEntries to be open concurrently when using FileAccess.Write. This is a requirement of the XPS serialization stack in WPF. As such, we need to create XPS documents as FileAccess.ReadWrite in order to allow this behavior.
ghost
requested a review
from 
rladuca
added
* NO MERGE *
vatsan-madhavan
approved these changes
Oct 22, 2019
rladuca
changed the title
rladuca
removed
the
* NO MERGE *
ghost
locked as resolved and limited conversation to collaborators
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Related to #1985
5.0 PR: #2073
Description
In .NET Core 3.0 System.IO.Compression's ZipArchive does not support multiple ZipArchiveEntries to be open concurrently when using FileAccess.Write. This is a requirement of the XPS serialization stack in WPF. As such, we need to create XPS documents as FileAccess.ReadWrite in order to allow this behavior.
NOTE: These sort of changes have been used as a workaround in different, but related cases pre-GA of .NET Core 3 and have worked well. Codifying them in the product itself helps move developers forward and gives some time to consider a re-design of the XPS serialization stack.
Customer Impact
XPS creation when a customer chooses FileAccess.Write will get an exception from:
https://github.com/dotnet/corefx/blob/861259bf87d8e4ee2c4f8dab31b73d377faff77d/src/System.IO.Compression/src/System/IO/Compression/ZipArchive.cs#L411
Developers have been instructed to use FileAccess.ReadWrite as a workaround, but this isn't always applicable to library code.
Regression
Yes. This is a regression from .NET Framework 4.8 due to switching to
System.IO.CompressionandSystem.IO.Packagingand can potentially block developers from moving their applications to .NET Core.Risk - Low
The public facing functions that need altering here are on creation of an XPS document where there would generally have been Write access. Switching to ReadWrite should present no problem. There is potential for some optimizations to be lost from within the compression and packaging libs, but that is preferable to throwing an exception.
The internal functions are being changed as a precaution but are generally concerned with printing streams which are, generally, ReadWrite underneath. This merely creates the package in the same access mode as the stream.