We have a situation where we are creating a mail merged document, and the document looks fine. However, as soon as it is sent through Outlook, the file is no longer valid and presents a File Conversion dialog when launched in Word. If the generated file is opened and resaved with Word before sending, the received file is fine.
It seems that MS Outlook tampers with attached document files, making some changes in the document properties and then rewriting the attached files. As far as I can see MS Outlook does this when sending e-mails, not when receiving them.
MS Outlook appears to tamper with all .DOC files sent through it, not just the ones generated by Aspose.Words. You can see when the file is received it is a bit longer than the original.
Although such behaviour from MS Outlook sounds strange, it does not affect the validity of documents produced by Aspose.Words except the file that you have.
We will research the matter further. I have logged this problem to our defect base as issue #1016. Meanwhile you can zip the document files or change the attachment file extension to “.do_” for example to avoid being tampered by MS Outlook.
Thanks as always for the prompt response. While your workaround would solve the issue (short term), the emails/documents we are generating are sent to customers who are not entirely tech savvy enough to be able to rename attachments. I’m trying some programmatic work arounds, but so far, all I’ve got is repeatable corruptability. Interestingly, not all templates have the issue, so it would appear to be something either specific to the template we are using, or it may have something to do with the data that is merged in. I’m trying to eliminate the data as the culprit as I find that much more unlikely.
I found something that seems to make a difference (why it does, I have no idea)… The text at the bottom of the template that says “Page 3 of 3”… if that text is removed the document looks fine after being sent. If that text is added back in and re-merged, the problem reappears.
I have asked at the Outlook support newsgroup as to why Outlook messes with attached documents but MVPs there failed to provide any meaningful answer as to why it does occur and if it could be switched off.
We will try to find out what causes Outlook to sometimes fail to resave the Aspose generated documents correctly and fix it if posiible. I will post a notification here if we will find any solution to this problem.
If I create a new message in MS Outlook and drag the file I want to attach and drop it in the message window, then send it. The file comes through modified as we’ve seen before. In those rare cases the file actually becomes corrupted.
However, if I right click on the file I want to send in Windows Explorer and select email as attachment, this creates a new message for me with the file attached. If I send this file, the file comes through NOT modified by Outlook and therefore always valid.
Ok, so the issue that was currently only in Aspose.Words has now appeared in Aspose.Cells (actually we are using version 3.5.1.7 of the older namespace dll). I wish there were an obvious way to cross-post here - if you decide to move this to a different thread, please just email that this was done.
I’ve attached two Excel files, one before the send through Outlook, and one after. The received Excel document is corrupted. I was able to determine something of interest though I don’t know anything about the internal storage of an Excel file to begin to postulate what my findings mean. FYI, we are saving the file in the Excel97 format.
If the two files are examined with a binary editor, the 48 bytes of data from 0x00000030 to 0x0000005F are slightly different - there’s also some trailing stuff that Outlook appends at the end of the received file that appears to be benign. If I replace those 48 bytes in the received file with the original 48 bytes from the send file, it returns the Excel document to a valid format.
This is really driving our customers nuts - our work around for now is to take the document and resave it using the Microsoft application, then reattach it. However, the whole point is to be able to generate documents and attach them to emails programatically, which isn’t working 100% of the time.
The problem document can be saved in memory to an Excel2003 format, then resaved in memory back as an Excel97 document and the issue appears to go away… I’ve attached that particular version of the file as a before and after as well.
Lastly, the same day we had an issue with word documents generating and sending through Outlook (again, please see attached). I did a binary comparison between the original file and sent file… only three bytes stand between this being a good document and it being a bad document after it’s sent. They are at:
0x00000030, 0x00000031, and 0x00000080
Any idea what those bytes are used for? Or why Outlook would want to set them to those invalid values?
Sorry for not updating, I thought I posted a message regarding this issue.
We’ve developed a fix for this problem. Same code is used both in Aspose.Words and in Aspose.Cells so that’s why the same problem could have appeared in both. I’ve already provided the updated code to the Aspose.Cells team so it should be in their next release. The fix will also be in the upcoming Aspose.Words release in the next day or two.
The issue happened only in some files when they are of an exactly “page size” in the structured storage terms. Basially the way our code wrote structured storage FAT was not completely compatible with the way MS Outlook “quick-modified” it when doing its dirty job of modifying the file.