MAPI和托管代码体验?[关闭]

有一个单独的helper exe,它接受命令行参数(或管道到其标准输入),执行所需的操作,并从主应用程序调用该参数。这样可以将MAPI内容保留在主应用程序的进程空间之外。好吧,您仍然在混合使用MAPI和.NET,但这只是一个很短的过程。假设mapi和clr开始导致运行时间较长的进程出现问题。

我们用的是德米特里·斯特布列琴科的 Redemption Data Objects 库,它允许我们在JScript中编写这样的“填充”代码并调用该代码,从而使clr和mapi世界保持在不同的进程中,但以受支持的方式。

@克里斯·福尼尔正在写入非托管dll。这不起作用,因为问题是混合了MAPI和托管代码 在同一过程中 .

mapisenddocuments已弃用,可能会被删除。 您应该改为使用mapisendmail。 见 Simple MAPI

调用进程。从 Mailto: protocol (如下所示)将提供基本功能,但不提供附件。

Process.Start("mailto:name@domain.com?subject=TestCode&Body=Test Text");

可以对附件路径执行此操作,但此选项仅适用于某些旧版本的Outlook,如98。我想这是因为潜在的安全风险。

如果有人使用outlook.exe,它将在outlook 2003(和2007取决于设置)下发出安全警告。

您应该能够生成一个非托管的dll,该dll执行您希望使用mapi的操作,然后从托管代码中调用该dll。我不会写一个直接的mapi包装器,但它可以执行该非托管dll中包含的mapi所需的所有功能。这可能是从托管代码使用MAPI最安全的方法。

你也可以用 Outlook Redemption ,这是由托管代码支持的;我不确定它是否有简单的mapisenddocuments替换,但如果您有问题,dmitry很有用。

至于“撞车和烧伤”,这是一位微软支持人员的另一句话, here

这类事情基本上是可行的。你写的时候它会起作用的。当你测试它的时候,它就会工作。当你的客户评估它时,它会起作用。然后,一旦客户部署了它-砰!这就是它决定开始出现问题的时候。微软不会帮你的,因为我们一开始就告诉过你不要这么做。:)

我使用mapisendmail函数和几个内部类来包装其他一些与mapi相关的结构。只要这是唯一的用途,就有可能安全地完成这项工作,因为它需要密切关注各种非托管数据类型和内存分配/释放和GC。虽然它仍然不受支持,但我在生产代码中使用它(尽管它还没有发货)。

当我问Matt Stehle这个问题时,我得到的回答是:

我真的不知道这样做的更好的方法,你在这里遇到的任何问题都可能在支持的场景中重现(即VB6或非托管C++)。只需知道,如果您遇到过这样的情况,问题是由从.NET调用的函数引起的,我们没有任何其他建议您不要使用.NET。

不完全是对使用它的一种祝福,但也没有说有任何其他选项可以从托管代码中实现这一点。

下面的代码没有像这样使用mapi,但它打开了带有任意附件的“撰写邮件”窗口。

(实际上,它完全没有经过测试,但我在一个我认为有效的应用程序中找到了它)

using Microsoft.Office;
using Microsoft.Office.Core;

...

Outlook.Application outlook = new Outlook.Application();
Outlook.MailItem mail = (Outlook.MailItem) outlook.CreateItem(Outlook.OlItemType.olMailItem);

mail.BodyFormat = Outlook.OlBodyFormat.olFormatRichText;
mail.HTMLBody = "stuff";
mail.Subject = "more stuff";
string file = File.ReadAllBytes(...);
mail.Attachments.Add(file, Outlook.OlAttachmentType.olByValue, 1, file)

mail.Display(false);

对于那些有MAPI经验的人来说,要想从非托管代码(Read:CurrimeC++)中准确地完成你想要的代码,就需要更少的时间来键入这个帖子并读取响应(不冒犯)。

你很幸运,你需要的功能是有限的。您所需要的只是一个简单的C++实用程序,它可以在命令行上获取您需要的参数,并发出正确的MAPI调用。然后,就像执行任何其他进程一样,从托管代码中获取所有这些实用程序。

高温高压