What was the issue with message extraction from PST fixed by EMAILNET-41653 in 25.11?
The fix addressed a defect where Aspose.Email failed to read the PR_NATIVE_BODY_INFO (PidTagNativeBody) property when extracting a message from a PST file.
In earlier releases the PersonalStorage/MapiMessage APIs returned null for this property even though it existed in the PST (as seen via MFC MAPI). EMAILNET‑41653 corrected the extraction logic so the native‑body information is now returned correctly in version 25.11.
Are you sure that is correct? I’m still getting null for that property with version 25.11.
The fix in EMAILNET‑41653 addresses a defect where the PR_NATIVE_BODY_INFO (PidTagNativeBody) property was read as null from PST messages in earlier releases – the issue was corrected in version 25.11 (Professionalize.Discourse).
If you still receive null with 25.11, please provide the following so we can reproduce the behavior:
- Exact Aspose.Email for .NET version (including build number) and runtime (e.g., .NET 6, .NET Framework 4.8).
- A minimal code snippet that loads the PST and accesses the property (e.g.,
MapiMessage.NativeBodyInfoorMapiMessage.Properties[MapiPropertyTag.PR_NATIVE_BODY_INFO]). - Confirmation that the PST file indeed contains the native‑body property (you can verify with MFC MAPI or Outlook).
- Any licensing information (full license vs. evaluation) that might affect PST parsing.
With that information we can verify whether the fix is applied correctly or if a regression exists. If possible, also test with the latest Aspose.Email build (e.g., 25.12) to see whether the issue persists. Once we have the repro details we can log an internal issue.