IOException in ZipArchiveEntry.OpenInUpdateMode when printing #9418
Comments
singhashish-wpf
added
Investigate
I had to update the sample app slightly to work correctly under .NET 4.7.2 (but the primary point still stands). The updated code runs under net472 but still crashes under net8.0-windows. Replace the two lines to create the // create a temporary package
var tempFilePath = Path.Combine(Path.GetTempPath(), Path.GetRandomFileName());
Package package = Package.Open(tempFilePath, FileMode.Create, FileAccess.ReadWrite);
// create a temporary XPS document using that package
string tempFilePath2 = Path.GetTempFileName();
PackageStore.AddPackage(new Uri(tempFilePath2), package);
var tempDocument = new XpsDocument(package, CompressionOption.Normal, tempFilePath2); |
|
Suggestion: If you could write directly to FlowDocument, there is no need to nest another layer of XpsDocument. In this case, just use printWriter.Write(((IDocumentPaginatorSource) flowDocument).DocumentPaginator, printTicket); Analysis: I tried using Close() to close the first opening, but it didn't seem to work. In the official sample program (https://learn.microsoft.com/zh-cn/dotnet/desktop/wpf/documents/printing-overview?view=netdesktop-8.0#xpsdocumentwriter), it also seems to avoid opening the XpsDocument file multiple times for reading and writing. |
|
The FlowDocument is a simplification for this repro; it's not used by the application where this problem was first discovered (which uses a custom DocumentPaginator and draws directly to a Visual, then saves everything to an XpsDocument so it can show a "print preview" on screen, then prints that XpsDocument). |
|
The exception is coming from
That value comes from That value comes from the wpf/src/Microsoft.DotNet.Wpf/src/ReachFramework/Packaging/XpsManager.cs Lines 140 to 159 in 0be453c Which comes from the wpf/src/Microsoft.DotNet.Wpf/src/ReachFramework/Packaging/XpsDocument.cs Lines 156 to 166 in 0be453c Thus, it seems like the bug may be getting triggered from printing an XPS Document that is still open for writing. I updated the code to close and reopen the document. This allows it to be printed successfully: bgrainger/Bug6842@4d5eabc. I have applied this fix to our complex WPF application and it resolves the bug. I believe this is still a regression from .NET Framework (and perhaps could manifest in other code paths?) but it is now less serious for us. |
Description
This is a repost of #6842 with a repro.
In a WPF application ported to .NET 8.0 from .NET Framework 4.7.2, printing a complex document throws an exception, and nothing prints. (The Microsoft Print to PDF driver writes a 0-byte file.)
Reproduction Steps
Clone https://github.com/bgrainger/Bug6842. Build and run the app. Press the Print button. (If your default printer is "Print to PDF" or similar, specify a file name to print to when the Save dialog appears.) The application crashes.
The minimal code to repro is:
Expected behavior
The FlowDocument (with an embedded image) is printed to the selected printer.
Actual behavior
The application crashes and nothing is printed.
Regression?
This is a regression from .NET Framework 4.7.2 and affects my company's product that was ported from that version.
It was present in .NET 6.0 (see #6842).
Known Workarounds
Yes; see comment: #9418 (comment).
Impact
Our application can't print on Windows when running on .NET 8.0.
Configuration
Other information
A possible fix is in this PR: #6843.
The text was updated successfully, but these errors were encountered: