------msg---------
Will you be doing this on a system that has Outlook on it, and can therefore take advantage of the outlook objects, or no?
A couple of interesting items related to this here:
http://bytes.com/topic/visual-basic-net/answers/358054-reading-outlook-msg-files
http://www.priasoft.com/products-outlook-msg-developers-api.aspx
their in binary format not text format, to read binary format you need to know the data structure of the file.
The .msg format is not documented.
The "easiest" way to read it would be to have the App that defines the
format read it, in this case Outlook.
The following site provides a plethora of information on using Outlook from..NET.
http://www.microeye.com/resources/res_outlookvsnet.htm
Outlook uses the OLE structured storage file format to write the .msg files.
To read these files you have to use the OLE api. There's a set of VB.NET
classes that wraps this API in my site:
Based on the numbers you are showing, it appears that each MAPI Property is
stored as a separate Stream. Interesting!
http://msdn.microsoft.com/library/de...properties.asp
Outlook Msg file parser dll, for retrival of information (such as sender name and address, recipieants names and address, body text, email header form outlook msg file, without using outlook. Either using mapi or ole2 to parse the structured storage file
But the simplest way is to automate Outlook. You may find the following links helpful: Outlook is a singleton, that means only one instance of the application can be run in the system. So, you can use Process.Start method for opening a .msg file. After opening you can use the Outlook object model for doing the required modifications. The SaveAs method of the MailItem class saves the Microsoft Outlook item to the specified path and in the format of the specified file type. If the file type is not specified, the MSG format (.msg) is used. Be aware, Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, ASP.NET, DCOM, and NT Services), because Office may exhibit unstable behavior and/or deadlock when Office is run in this environment.
If you are building a solution that runs in a server-side context, you should try to use components that have been made safe for unattended execution. Or, you should try to find alternatives that allow at least part of the code to run client-side. If you use an Office application from a server-side solution, the application will lack many of the necessary capabilities to run successfully. Additionally, you will be taking risks with the stability of your overall solution. Read more about that in the Considerations for server-side Automation of Office article. As a workaround, you may also consider using third-party components designed for the server-side execution.
All formats listed on the sheet are Exchange Server Protocol Documents, not Outlook. So, you can assume all Outlook versions support them (of course, if they can connect to the corresponding Exchange server).
|