Veelgestelde vragen

Question

Hoi! voor de volgende code:

 Aspose.Email.Mime.ContentType ct = new Aspose.Email.Mime.ContentType();

ct.MediaType = "application/msword";

ct.CharSet = "ISO-2022-JP";

Attachment att = new Attachment("Test.doc", ct);

Console.WriteLine(att.ContentType.Name);

att.ContentType.Name retourneert de naam van het bijgevoegde document. Is dit verwacht gedrag?

Antwoord: Ja, dit is verwacht gedrag. Als ContentType.Name niet expliciet is ingesteld, wordt de bestandsnaam als naam genomen.

Vraag:

Waarom maakt ExchangeWebServiceClient.FetchMessage van ingebedde afbeeldingen bijlagen?

Antwoord: Microsoft Exchange Server heeft zo’n functionaliteit als ‘Contentconversie, wat het proces is van het correct opmaken van een bericht voor elke ontvanger. De beslissing om contentconversie op een bericht uit te voeren hangt af van de bestemming en het formaat van het te verwerken bericht.

Met andere woorden, voor onbekende clients kan de server de berichtopmaak aanpassen volgens de serverinstellingen (om het meest geschikte berichtformaat te selecteren). Zoals je begrijpt, is het meest universele formaat voor elke client ’text/plain’ en deze instellingen zijn configureerbaar op de server.

Let op: Outlook is een bekend e‑mailclient voor Microsoft Exchange Server (in het geval dat MS Outlook een oudere versie heeft dan de server). Dit betekent dat Exchange Server het berichtformaat aanpast op basis van de mogelijkheden van Outlook. In ons geval, wanneer ExchangeWebServiceClient probeert een bericht op te halen, zijn de mogelijkheden van onze componenten onbekend voor MS Exchange. De server geeft het bericht aan de componenten in het eenvoudigste formaat (text/plain). Met andere woorden er zijn geen html‑delen in de serverrespons. In deze situatie worden afbeeldingen in het bericht opgenomen als bijlagen.

Er is een manier om het beschreven probleem te vermijden. Als het bericht op de server de Content‑Type: multipart/alternative heeft en een van de onderdelen is text/plain, dan wordt dit bericht onveranderd naar de client doorgestuurd. Afbeeldingen worden in dit geval in de berichtinhoud weergegeven omdat het bericht ook een html‑onderdeel bevat. In het huidige scenario wordt het bericht via MS Outlook aan MS Exchange toegevoegd en als gevolg is de Content‑Type van het bericht niet ‘multipart/alternative’. Daardoor ontstaat er een probleem wanneer we proberen het bericht op te halen. Bijvoorbeeld hier zijn voorbeelden van soortgelijke problemen: één(http://support.risualblogs.com/blog/2011/02/24/html-mails-sent-via-owa-and-outlook-2011-are-received-as-plain-text-mails-externally/), twee(http://forums.mozillazine.org/viewtopic.php?f=39&t=628678), drie(http://stackoverflow.com/questions/4681798/how-do-i-send-html-multipart-alternative-from-exchange-web-services-2010-sp1). Als conclusie is de situatie die in het probleem wordt beschreven (afbeeldingen opgenomen in het bericht als bijlagen) geen bug van Aspose‑componenten. Het is een functie die specifiek is voor de Exchange‑server.

Question: Hoe haal ik gegevens uit de "oleData.mso"‑bijlage die ik krijg bij het lezen van een MapiMessage met een geïntegreerd OLE‑object?

Answer: bestanden zoals "oleData.mso" verwijzen naar het Microsoft Compound Document‑formaat (MCDF) en helaas valt de ondersteuning voor zulke bestanden buiten de scope van Aspose.Email. Er zijn echter enkele open‑source .NET‑bibliotheken, bijvoorbeeld OpenMCDF, die gebruikt kunnen worden om de inhoud van dergelijke bestanden te lezen en op te slaan op schijf.

Question: Kunnen we in parallelle threads naar hetzelfde PST‑bestand schrijven met dezelfde objecten?

Answer: Nee, thread‑veiligheid is in dit geval niet gegarandeerd. Het schrijven van berichten moet in één thread gebeuren. Het product moet echter correct werken met verschillende objecten vanuit verschillende threads.