Search code examples
c#xpssolidworksxpsdocument

XpsDocument GetFixedDocumentSequence return null for files generated by a specific computer

Solidworks generate "EDRWX" files. Usually, those are opened with Microsoft XPS viewer.

Issue :
An application use .net XPSDocument to open them and do some manipulation with them before printing. The faulting method is "GetFixedDocumentSequence". It returns null with files generate from a specific computer. It does so even when the application is running on the specific computer. But it is working fine with file generated by other computer.

enter image description here

When trying to open the file with XPS document viewer, it's fail to open saying it can't be opened. However, it does open on the specific computer that created it. If this computer print a normal XPS file from microsoft word, others computer are able to open it normally with XPS document viewer. Also, "EDRWX" file generated by others computers are easily opened with XPS document viewer on every computer including the specific one.

More specification :
The specific computer run under windows 8.1.
Others computers run under windows 7.
The application run with .net Framework 4.0.

Here is a "EDRWX" dummy file generated by the specific computer.
Here is a "EDRWX" dummy file generated by one of the others computers.

What is the cause of the issue and how can it be fixed?

Sidenote : I have been investigating for almost 3 days....So I'm getting angry at the problem. May be your eyes can see what I don't anymore for being sucked into it this much.

In my digging, I found this difference between the two files. enter image description here

Solution

  • The failing EDRWX files are not XPS files, they are Open XPS files. The two formats are very similar, however as you have discovered, XPSDocument doesn't support OpenXPS. I am not aware of any .net API that directly supports Open XPS, however microsoft did release standalone converter tools that you may be able to leverage.

    Another alternative, which may or may not work, is to try to force SolidWorks to generate xps instead of oxps on the failing machine. It is possible that solidworks is using the xps document writer to generate these files, in which case changing the output format as described here may resolve the issue.