XpsDocument GetFixedDocumentSequence return null for files generated by a specific computer

Question

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.

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.

XPS files are zip archives - you can open it with WinRar and see xml files inside for possible differences. Each page is separate xml. — i486, Feb 17 '16 at 15:39
@i486, good point, this is what I did to pinpoint the "difference" between the files. — AXMIM, Feb 17 '16 at 15:43

score 2 · Accepted Answer · answered Feb 16 '16 at 18:29

2

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.

answered Feb 16 '16 at 18:29

Jon

3,065
1
19
29

Somehow, I can't find the standalone converter tools on the web. It's all point out to a windows update package that I already have installed on my computer. – AXMIM Feb 17 '16 at 14:35
Find the exe searching for XpsConverter.exe on my disk drive. Will try to use this application within my application. Thanks you – AXMIM Feb 17 '16 at 15:41

score 1 · Answer 2 · answered Feb 17 '16 at 21:51

Like Jon pointed out, the issue is that starting with windows8, solidworks use OXPS format no matter what. Changing default format in Group Policy worked for others applications but Solidworks didn't care. So I ended up using the only tool provided by Microsoft thus far to handle the situation. Which is the converter application that come with a windows update package. Once installed, the converting application can be found here : C:\Program Files (x86)\Windows Kits\8.0\bin

There is a x86 version and a x64 one.

Here is an usage example in the console.

So added the converter appplication next to my application and in my application I silently launch the converter. Here is a method that show how I did it. The method convert the given file to XPS format if necessary. But the resulted conversion must be another file, because the tool can't overwrite the file it is converting.

private string EnsureFileIsUnderXPSFormat(string fileName)
{
    string retValue = fileName;
    string convertedFileName = System.IO.Path.GetDirectoryName(fileName).TrimEnd(System.IO.Path.DirectorySeparatorChar) + System.IO.Path.DirectorySeparatorChar + System.IO.Path.GetFileNameWithoutExtension(fileName) + "_converted" + System.IO.Path.GetExtension(fileName);
    Version win8version = new Version(6, 2, 9200, 0);
    if (Environment.OSVersion.Platform == PlatformID.Win32NT && Environment.OSVersion.Version >= win8version || true)
    {
        System.Diagnostics.ProcessStartInfo startInfo = new System.Diagnostics.ProcessStartInfo();
        startInfo.Arguments = "/XPS /InputFile=" + fileName + " /OutputFile=" + convertedFileName;
        string applicationFolderPath = AppDomain.CurrentDomain.BaseDirectory.TrimEnd(System.IO.Path.DirectorySeparatorChar) + System.IO.Path.DirectorySeparatorChar;
        startInfo.FileName = applicationFolderPath + "xpsconverter.exe";
        //if (Environment.Is64BitOperatingSystem)
        //  startInfo.FileName = @"C:\Users\maxiveil\Desktop\testConversion\xpsconverter.exe";
        //else
        //  startInfo.FileName = @"C:\Users\maxiveil\Desktop\testConversion\xpsconverter.exe";
        startInfo.WindowStyle = System.Diagnostics.ProcessWindowStyle.Hidden;
        startInfo.CreateNoWindow = true;
        using (System.Diagnostics.Process processus = System.Diagnostics.Process.Start(startInfo))
        {
            processus.WaitForExit();
            if (processus.ExitCode != 0)
            {
                throw new Exception("Failed to convert OXPS file(" + fileName + ") to XPS format. Error code : " + processus.ExitCode.ToString());
            }
        }
        retValue = convertedFileName;
    }
    return retValue;
}

N.B : The converter application doesn't care if you try to convert a XPS format file to XPS format file. So the "windows8 if" is optional.

XpsDocument GetFixedDocumentSequence return null for files generated by a specific computer

2 Answers2

Linked