XPS documents in .NET Core can't be opened

[wstaelens]

Besides the impersonation limitation I reported earlier we have also found that XPS documents coming from a virtual printer can't be opened in .NET Core.

We first have to extract the XPS files, combine all part files to a single file and then create the XPS file again. Then we can open an XPS file in .NET Core.

Is this by design or a bug?

Because we don't have to do this in .NET Full Framework.

[GrabYourPitchforks]

Please clarify the problem you're experiencing so that we can route the issue appropriately. Are you receiving a runtime exception? (If so, please provide the exception message and repro code.) Are you receiving no exception at runtime but still seeing incorrect behavior?

[no-response[bot]]

This issue has been automatically closed due to no response from the original author. Please feel free to reopen it if you have more information that can help us investigate the issue further.

[olowk]

When opening an XPS file which is created from a V4 XPS printer driver we can't access the 'FixedDocumentSequenceReader' because it's null. Code below works perfect in full framework but doesn't in .net Core 3.1

 using(var strm = File.OpenRead("path to xps file"))
{
      var package = Package.Open(strm, FileMode.Open, FileAccess.Read);
      var inMemoryPackageName = string.Format("memorystream://{0}.xps", Guid.NewGuid());
      PackageStore.AddPackage(new Uri(inMemoryPackageName), package);
      var xpsDoc = new System.Windows.Xps.Packaging.XpsDocument(package, CompressionOption.Fast, inMemoryPackageName);
      var fixedDocSeqReader = xpsDoc.FixedDocumentSequenceReader;
      var printTicket = fixedDocSeqReader.PrintTicket; //<- nullreferenceexception here because fixeddocumentsequencereader is null
}

[svick]

@olowk I think you should open a new issue about that, instead of commenting on a closed one.

[wstaelens]

@svick it is reopened, as @olowk and I tested the same.

Due to covid we could not respond earlier and the bot closed the issue... 🥱

[GrabYourPitchforks]

Thanks for the repro code! I'll get someone to transfer this to the WPF repo so that the appropriate area owners will get notification of the issue.

[ryalanms]

Thank you for the report, @olowk. Which versions of .NET Core and Windows are you using?

[olowk]

I am using .net core 3.1 and Windows 10 updated to latest version.

[wstaelens]

@GrabYourPitchforks @terrajobst did you ever test this? We are still having these issues after all these months.

.NET SDK 5.0.202 .NET runtime 5.0.5 Windows 10 20H2 (19042.928) Windows Server 2019 1809 (17763.1879)

[ThomasGoulet73]

@wstaelens Could you provide a XPS file that you cannot open on .Net Core. I tried to reproduce your issue but it worked on my machine.

Thank you.

[wstaelens]

Files were a bit too big, zip file 200mb can be found here on onedrive: https://1drv.ms/u/s!ArFv7v_tfAlngrQFZNhqp6HU-vkDMQ?e=WWhie5

You will find:

00 pdf printed
01 captured incoming job
02 xps dump
03 xps modified for .net core

00 is the pdf that I print to V4 driver.

01 is the job that I captured as .prn.

02 is an xps file using .content extension that we work with but you can just rename it to .xps. This XPS file can be opened and read in .NET Framework. Not in .NET Core / .NET 5

03 is an xps file using .content extension that we work with but you can just rename it to .xps. This XPS file has been modified so that .NET Core / .NET 5 can open it!

When you go to 02 and 03 and rename the .content(=.xps) to .zip you will see that in the received XPS job [Content_Types].xml, DiscardControls.xml and FixedDocumentSequence.fdseq are directories containing many separate files. (same for /Documents/1/FixedDocument.fdoc etc...)

.NET Framework is able to open an .XPS with all these separate files.
In .NET Core/.NET 5 we cannot open this. We first have to convert the many separate files into single files.

This is the problem that we are facing (besides XPS being terribly slow).

[ThomasGoulet73]

Hey @wstaelens,

I've done some digging and the problem is the splitted files in .piece file.

In .Net Framework, the code for System.IO.Packaging.* was in WindowsBase. It seems that for .Net Core, this code was moved to its own assembly/nuget package in https://github.com/dotnet/runtime.

The version in WindowsBase supports .piece file while the version in System.IO.Packaging assembly does not. I don't really know if the exclusion of .piece support in .Net Core was on purpose.

I'm not sure who the owner of System.IO.Packaging is but according to this, its not owned by the WPF team.

Tagging @adamsitnik, @carlossanlop and @Jozkee because it looks like they are the area owners (See "Notes" in the area owners file).

Thanks

[wstaelens]

Thanks @ThomasGoulet73 I'm surprised nobody else has seen this 😮 😞 I don't understand why XPS driver/template (Visual Studio) produces an XPS file which is not compatible with .NET Core/.NET 5. (or there might be, an undocumented setting that we are not aware of.) Really strange that we are the first to report this. I hope that XPS printing could be improved and that the performance issues as mentioned will also be tackled.

From the link you provided, I'll tag some other users also from the system.xml/system.io: @ericstj @jeffhandley @davidfowl @HongGit @StephenMolloy @buyaa-n @joperezr @krwq

/ rant / When you work in a niche market (printing/drivers/etc...), the attention of/at microsoft is already not great and not everything is sexy, but some things are really showstoppers. Knowing that this often has an impact on thousands of our and other customers because printing is still essential in MANY companies. It is possible that we might have an incorrect driver configuration, but I hope it is not because of undocumented settings... After all these years our team is getting tired to searching for workarounds and fixes because the core basics are not 100%. / /rant /

[ThomasGoulet73]

Hey @wstaelens,

I understand your frustration but also I looked in .Net repos and I haven't seen any issue about the usage of .piece file which leads me to believe that it is not used a lot because it's not supported at all in .Net Core. Also, from what I've seen, it's not a simple on/off switch that can enable .piece support, there is a non-trivial amount of code required to make it work.

Maybe some configuration is required in your XPS driver to disable .piece files. You might want to look into that.

My advice would be to open an issue in dotnet/runtime to request support for .piece so that member of the .Net team responsible of this area can respond.

Thanks

[wstaelens]

@ThomasGoulet73 we'll have a look if we can see something in our driver but searching for .piece in the Microsoft documentation doesn't give any results. I hope it has something to do with Interleaving Mode, we'll test this.

On the other hand I somebody at the Microsoft team (which one?) should adjust .NET 5 (.NET Core) so that XPS files with .piece files can be opened, because this is being produced here by default and it works in .NET Framework 4.8 by default.

(and as always hoping that there will be some XPS performance and memory improvements... 🤞)

[wstaelens]

Please see https://github.com/dotnet/runtime/issues/51929#issuecomment-835808702 from @kevincathcart

[wstaelens]

😢 🤞 🐼 bump

[wstaelens]

For updates see: https://github.com/dotnet/runtime/issues/51929#issuecomment-1166404820

Prototype code: https://github.com/dotnet/runtime/compare/main...KevinCathcart:interleave

[wstaelens]

any updates?

[wstaelens]

@lindexi can you maybe add this code from Kevin to a PR so that it can be fixed?

code: https://github.com/dotnet/runtime/compare/main...KevinCathcart:interleave

(PR: https://github.com/dotnet/runtime/pull/78374 )

(info: https://github.com/dotnet/runtime/issues/51929#issuecomment-1310821136 )

[lindexi]

@wstaelens Sorry, I'm afraid I don't have enough free time to finish such a big job

[ThomasGoulet73]

@wstaelens I believe this issue can be closed since this issue is unrelated to WPF and the PR that adds interleaving support (dotnet/runtime#97898) was merged in main today. Further discussion about this issue should be held in dotnet/runtime#51929 to be able to talk with the right people.