Just leaving a note here in case anyone has a similar problem.
I had a third party MSG previewer fall over on emails generated by MsgKit, as I had no access to any logging, I resorted to doing binary compares (and using OpenMCDF's structured storage explorer) to compare the MsgKit email and that same email after having been run through MFCMAPI.
The two things that jumped out at me were.
The order of the storage entries differed after MFCMAPI touched the files.
MFCMAPI removed 4 bytes (0's) from the end of the __properties.version1.0 storage entry.
I addressed point 1, by having Message.cs initialise the Properties stream in it's constructor. Which resulted in me having the same order in the two files, making comparing much easier. But it wasnt until I addressed point 2 that my problem went away, this was achieved by just removing the blank 4 byte insertion in Properties.cs/WriteProperties within the Message size insertion block.
Fixed in latest commit. Don't know why I added those 4 bytes but probably read it somewhere. The MSG file seems to work without problems when opening it in Outlook when the 4 bytes are removed.
Hey
Just leaving a note here in case anyone has a similar problem.
I had a third party MSG previewer fall over on emails generated by MsgKit, as I had no access to any logging, I resorted to doing binary compares (and using OpenMCDF's structured storage explorer) to compare the MsgKit email and that same email after having been run through MFCMAPI.
The two things that jumped out at me were.
I addressed point 1, by having Message.cs initialise the Properties stream in it's constructor. Which resulted in me having the same order in the two files, making comparing much easier. But it wasnt until I addressed point 2 that my problem went away, this was achieved by just removing the blank 4 byte insertion in Properties.cs/WriteProperties within the Message size insertion block.
Greg