Possible to load in an email in MSG file format, modify content of selected attachments, save back as MSG file?

GroupDocs.Total Product Family
22

Okay, my bad - it does allow setting the property value.

Now, testing with simple MSG files attached:

asposetest.zip (107.8 KB)
test.zip (40.5 KB)

With simple code as follows, i.e. just loading the MSG file and then saving it right back:

            using Metadata metadata = new(msgFile);
            MsgRootPackage root = metadata.GetRootPackage<MsgRootPackage>();
            MsgPackage msg = root.EmailPackage;
            metadata.Save();

For the 1st MSG test file, the above causes the MSG content to become messed up.

For the 2nd MSG test file, the Save fails with exception:

Error: The data of attachment can’t be null.
Parameter name: data
at Aspose.Email.Mapi.MapiAttachmentCollection.Add(String name, Byte[] data)
at GroupDocs.Metadata.Formats.Email.MsgRootPackage.(MsgPackage )
at GroupDocs.Metadata.Formats.Email.MsgRootPackage.pfq4rhh3tnxzrhuh6z5nyqfxm3nvff3j?? ?(Stream )

23

@jarrodwee

Can you please clarify if you were using GroupDocs.Metadata or GroupDocs.Total in this case?

24

GroupDocs.Metadata.NETFramework 25.3

25

@jarrodwee

Thank you for the update. We’re looking into this issue.

26

Any updates on this issue?

Noticed that with GroupDocs.Total.NETFramework 25.7, the original HTML Body is not retained when simply calling Save - it appears to have been simplified and embedded images are missing.

Also noticed that the PR_SENT_REPRESENTING_NAME_W property changed from simply “Jarrod Wee” to “Jarrod Wee </O=EXCHANGELABS/OU=EXCHANGE…>”

27

@jarrodwee

As I can see all the issues linked to this topic were resolved. Can you please clarify what code you’re running and what source file is used?

28

Samples and source code in my post above dated 9th April.

29

@jarrodwee

Got it, thank you! Will take a look and update you.

30

Just tested with GroupDocs.Total.NETFramework 25.9 with the asposetest.msg sample which I provided on 9th April.

Attached are screenshots of the output when simply loading the msg sample and then saving it back out using the sample code that was provided back then.

image.png (135.1 KB)

image.png (93.8 KB)

As per observations in 27th Aug, the screenshots show the following:

The original HTML Body is not retained when simply calling Save - it appears to have been simplified and embedded images are missing.

The PR_SENT_REPRESENTING_NAME_W property changed from simply “Jarrod Wee” to “Jarrod Wee </O=EXCHANGELABS/OU=EXCHANGE…>”

Please advise if these issues are being looked into as we are looking at the feasibility of switching completely to GroupDocs.Total for our projects.

31

@jarrodwee

It looks like the issues attached to this topic have already been resolved. Let me take another look at this scenario in the context of GroupDocs.Total.

Since you were previously using the .NET Framework, could you clarify whether you plan to work with GroupDocs.Total (.NET) or the GroupDocs.Total.NETFramework package?

Also, are there any other issues that might be blocking your transition to GroupDocs.Total?

32

GroupDocs.Total.NETFramework, thanks.

For now, transitioning completely to GroupDocs.Total is impossible because the basic functionality of loading in a MSG file, accessing the EmailPackage, and then simply saving it back without any modification doesn’t work at all.

I’m quite certain there will be other hurdles to overcome once we are able to start with testing it proper.

1 Like
33

May I check whether GroupDocs.Metadata is being worked on to fix the above showstopper issue?

34

@jarrodwee

While Metadata issue was closed as Resolved I have checked that the actual issue is still not fixed. With using code and sample MSG files you provided I can see that Metadata changes some properties and transport message headers, for example

Property Source Destination
Sender Email Jarrod Wee Jarrod Wee </O=EXCHANGELABS/OU=EXCHANGE ADMINISTRATIVE GROUP (FYDIBOHF23SPDLT)/CN=RECIPIENTS/CN=3A8554A49A4C40DE97B5F5052E6105A5-JARROD>

I have opened the issue TOTALNET-350 and reported it to the responsible team.

35

@jarrodwee

This issue was fixed in GroupDocs.Total for .NET 26.4 now the sender field is not changed when processing it with GroupDocs.Metadata. No changes to code needed.

Have a nice day!

36

Just tested - still doesn’t work.

Besides the Sender Email being messed up, note also that:

“The original HTML Body is not retained when simply calling Save - it appears to have been simplified and embedded images are missing.”

What is worst is that simple MSG conversion to PDF format is now BROKEN with the following stack trace:

OnConversionFailed: Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.
at System.Reflection.RuntimeModule.GetTypes(RuntimeModule module)
at System.Reflection.RuntimeModule.GetTypes()
at System.Reflection.Assembly.GetTypes()
at .()
at .()
at .()
at Aspose.Html.Configuration…()
at Aspose.Html.Configuration…ctor()
at ?. ()
at ? ?.( , ConvertOptions, ConverterSettings , CancellationToken )
at ? . ? ( , ConvertOptions, CancellationToken )
at .( ? [] , , ConvertOptions , CancellationToken )
at . ( , ConvertOptions, CancellationToken )
at ?.??? , , ConvertOptions , ConverterSettings , CancellationToken )
— End of stack trace from previous location where exception was thrown —
at .(Exception )
at (Object )
at .(MethodBase , Boolean)
at . ( , )
at ()
at . (Boolean )
— End of stack trace from previous location where exception was thrown —
at .(Exception )
at (Object )
at .()
at .?( , )
at ()
at . (Boolean )
— End of stack trace from previous location where exception was thrown —
at .(Exception )
at (Object )
at .()
at .(Object , UInt32)
at . (Boolean )
at . (Boolean )
at . ()
at .(Object[] , Type[], Type[] , Object[] )
at .(Stream , String, Object[] , Type[] , Type[] , Object[] )
at (Stream , String, Object[] )
at ?.MoveNext()
at .??? , ConverterSettings, CancellationToken )
at (CancellationToken )

37

@jarrodwee

I’m sorry for not informing you directly in this post that binding redirects are now required to be added to you project file. Unfortunately, auto binding redirects can’t properly detect what binding redirects are required therefore LoaderException is being thrown.

Please check this sample application
TOTALNET-350.ZIP (236.5 KB) that contains App.config with binding redirects list. Also you can find list of binding redirects in the package readme https://www.nuget.org/packages/GroupDocs.Total.NETFramework#readme-body-tab.

Let me also add App.config listing here:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <!--
        Mirrors the redirects in the GroupDocs.Total.NETFramework package's
        content/app.config.install.xdt. PackageReference projects don't apply
        XDT transforms, so we add them here manually. Each newVersion is the
        actual AssemblyVersion of the deployed dll (NOT the NuGet package
        version - they differ for many system pkgs, e.g. pkg
        System.Text.Encoding.CodePages 9.0.2 ships AssemblyVersion 9.0.0.2).
      -->
      <dependentAssembly>
        <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-13.0.0.0" newVersion="13.0.0.0" />
        <publisherPolicy apply="no" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Drawing.Common" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="6.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Text.Encoding.CodePages" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-9.0.0.2" newVersion="9.0.0.2" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Buffers" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.0.5.0" newVersion="4.0.5.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Memory" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.0.5.0" newVersion="4.0.5.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Numerics.Vectors" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.1.6.0" newVersion="4.1.6.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Runtime.CompilerServices.Unsafe" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-6.0.3.0" newVersion="6.0.3.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Security.AccessControl" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="6.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Security.Cryptography.Pkcs" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-8.0.0.0" newVersion="8.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Security.Permissions" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-8.0.0.0" newVersion="8.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Security.Principal.Windows" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-5.0.0.0" newVersion="5.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Diagnostics.DiagnosticSource" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-8.0.0.1" newVersion="8.0.0.1" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Text.Json" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-6.0.0.11" newVersion="6.0.0.11" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Text.Encodings.Web" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-6.0.0.1" newVersion="6.0.0.1" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.ValueTuple" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.0.5.0" newVersion="4.0.5.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.IO.Compression" publicKeyToken="b77a5c561934e089" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.1.2.0" newVersion="4.1.2.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="Microsoft.Extensions.Logging.Abstractions" publicKeyToken="adb9793829ddae60" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-7.0.0.0" newVersion="7.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="Microsoft.Bcl.AsyncInterfaces" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="6.0.0.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
</configuration>

Currently we’re working towards avoiding .NET Standard deps in GroupDocs.Total but it would take some time.

38

Thanks, managed to sort out the binding redirects.

However, confirmed that the below two issues still persist:

  1. Sender Email still messed up.
  2. The original HTML Body is not retained when simply calling Save - it appears to have been simplified and embedded images are missing.
39

@jarrodwee

Thanks for the feedback. Can you send your output file?

40

Output file attached.

asposetest.msg.saved.zip (106.4 KB)

41

@jarrodwee

Thanks, let me take a look and analyze what went wrong.