Ensure ComManagedStream seekable wrapper stream has position of 0 (…
#12970
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.
…#12953)
PORTS #12953 - DO NOT SQUASH
Until .NET 5,
ComManagedStream(thenGPStream) would wrap a non-seekable stream in aMemoryStreamusing theMemoryStream(Byte[])constructor. This results in a stream with a position of 0.dotnet/runtime commit 136527537e6 (Improve perfromance for loading from Stream on Windows (dotnet/corefx#31142), 2018-07-20) updated this logic to instead use
CopyToto populate the wrappingMemoryStream. This results in a stream with a non-zero position.It seems that this non-zero position causes some issues in downstream code when using
Image.FromStreamto load.emfand.wmffiles, resulting inLoadGdipImageFromStreamreturning a status of 2 and thus an exception.Seek the wrapping
MemoryStreamback to the beginning after copying the source stream into it to prevent this exception.Microsoft Reviewers: Open in CodeFlow