Aspose.Words.FileCorruptedException on Version 16.6.0 and up - cannot find part of document with DocumentFormat.OpenXml relationships

The Word document template is being populated with data on fields, and sub-documents via XML using the DocumentFormat.OpenXml SDK, then later packaged as DocumentFormat.OpenXml.Packaging.WordprocessingDocument and saved as stream. The stream is then used to create a new instance of Aspose.Words.Document.

This still works on version 16.5.0 of Aspose.Words.
However, when upgraded to 16.6.0 up to the latest version, this doesn’t work anymore.
The error says:

Aspose.Words.FileCorruptedException: The document appears to be corrupted and cannot be loaded. ---> System.InvalidOperationException: Cannot find part 'subdocument123.docx'.
   at   .
(String [1])
   at    .      (String [1])
   at    .[1](    [1])
   at   .[1](    [1],     
)
   at   .
 (    [1],     
)
   at    .
(    [1])
   at    .[1](    [1])
   at    .
(    [1])
   at    .[1](DocumentBase [1])
   at 
   .[1]()
   at 
   .      
()
   at    .[1]()
   at    .
()
   at Aspose.Words.Document.
(Stream [1], LoadOptions 
)
   --- End of inner exception stack trace ---
   at Aspose.Words.Document.
(Stream [1], LoadOptions 
)
   at Aspose.Words.Document.[1](Stream [1], LoadOptions 
). . . . . . . . 

The problem occurs when a ‘relationship’ is added in the XML (schema of DocumentFormat.OpenXml SDK) of the main document.
The subdocument relationship looks like this:
<w:subDoc r:id="rId9" xmlns:r="http://schemas.openxmlformats.org/officeDocument/2006/relationships" xmlns:w="http://schemas.openxmlformats.org/wordprocessingml/2006/main" />

Please take note that the issue doesn’t happen in version 16.5.0 and below.
Higher than that, the error above occurs.

@sqpd,

Please ZIP and upload the Word DOCX document (you’re getting this problem with) here for testing. We will then investigate the issue on our end and provide you more information.

Hi,

Please see the attached sample file.
Thanks.
sample_files.zip (68.5 KB)

@sqpd,

After an initial test with the licensed latest (21.2) version of Aspose.Words for .NET, I was unable to reproduce this exception on my end. Please see the following output PDF files which were generated on my end:

So, we suggest you to please upgrade to the latest version of Aspose.Words for .NET.

Hi,

The error also occur in version 21.2.
I can see in your example PDF files that skabelon159 didn’t merge the subdokument17.
Our current implementation is that the subdokument17 will be merged as part of skabelon159 - and this is done via DocumentFormat.OpenXml relationship as I’ve stated in the very first thread.

@sqpd,

It would be great if you please also create a standalone simplified Console Application (source code without compilation errors) that helps us to reproduce this problem/exception on our end and attach it here for testing. Please do not include Aspose.Words DLL files in it to reduce the file size. We will then investigate this scenario further and provide you more information.

AsposeWordTest.zip (378.2 KB)

Hi,

Please see the attached console app.
You need to open this in Visual Studio 2019 with .NET Framework 4.7.2.
Please also take note that the old license file is included in the source code to be able to run it properly.
I have tested this in version Aspose.Words 16.5.0 and there’s no error. But when I use Aspose.Words version 16.6.0, the error occurs.
If you are going to test this with the latest version of Aspose.Words, you need to replace the content of the Aspose.Words.lic with your license of the latest version. I intentionally not include our own latest license file due company policies.

Please let me know if there are issues with the source code.

Thank you.

@sqpd,

We have logged this problem in our issue tracking system with ID WORDSNET-22001. We will further look into the details of this problem and will keep you updated on the status of correction. We apologize for your inconvenience.

Hi,

I would like to follow up regarding the result of Analysis - it seems the status is complete.
Does this mean you will provide a fix for this on your next release?

@sqpd,

The document produced by your code is invalid because of at least following two reasons:

<w:p w:rsidR="00C362C9" w:rsidP="00EB689C" w:rsidRDefault="00C362C9" w14:paraId="4E64C296" w14:textId="77777777">
    <w:p w:rsidRPr="00A272C6" w:rsidR="00275F0F" w:rsidP="005B3E03" w:rsidRDefault="00A272C6" w14:paraId="052DBC30" w14:textId="7016FFF3">
                skipped
    <w:sectPr w:rsidRPr="005B3E03" w:rsidR="005B3E03" w:rsidSect="00E925FD">
        <w:headerReference w:type="even" r:id="rId7" />
        <w:headerReference w:type="default" r:id="rId8" />
        <w:footerReference w:type="even" r:id="rId9" />
        <w:footerReference w:type="default" r:id="rId10" />
        <w:headerReference w:type="first" r:id="rId11" />
        <w:footerReference w:type="first" r:id="rId12" />
                skipped
    </w:sectPr>
</w:p>
  1. Paragraphs (and sectPr) are inside another paragraph.
  2. Footer/Header references rId9/10/11/12 are wrong. rId9 references to the subdocument ‘subdokument17.docx’, rId10 to the ‘fontTable.xml’, rId11 to the ‘theme/theme1.xml’, rId12 just don’t exist. Specs say ‘If the relationship type of the relationship specified by this element is not http://purl.oclc.org/ooxml/officeDocument/relationships/footer, is not present, or does not have a TargetMode attribute value of Internal, then the document shall be considered non-conformant.’

So, MS Word and Aspose.Words can’t open it until you remove that sectPr and ‘parent’ para. It worked in old version because we were not checking these scenarios back then. Please tell, do you really need this document to open by using latest Aspose.Words’ versions? Of course we can add some special processing; but we doubt we should do it. Main reason - this file cannot be opened by MS Word and we try to follow MS Word’s behavior in every minor details.

Maybe it’s better to modify document generator and produce valid files which can be opened by both MS Word and Aspose.Words? If you agree, we can help to investigate errors in output documents and suggest generator code changes.