32位VB6应用程序需要自动化64位Outlook才能在不提示用户的情况下发送电子邮件

Question

我有一个32位的旧版VB6应用程序，它使用COM组件自动化Outlook发送电子邮件。要求是电子邮件需要显示在Outlook中的“已发送邮件”文件夹中。更糟糕的是，不允许应用程序弹出通常的安全，警告或确认消息。

这个应用程序在64位Office出现之前没有任何问题。 32位进程无法自动化64位Outlook。

我提出的想法如下：

1. 用a交换COM组件 在CCW中运行的.NET WCF客户端 （.NET假装是COM）

2. 此COM组件调用WCF 使用netTcpBinding作为64位进程运行的服务。

3. WCF服务（作为LOCAL SYSTEM运行）然后启动64位 控制台应用程序作为用户，和 使用扩展MAPI 图书馆发送电子邮件。

第三步的原因有两个：

1. MAPI会要求确认是否 你告诉它发一封电子邮件。 扩展MAPI没有。这意味着 我们必须编译C ++ Extended 具有正确64位的MAPI库 来自Microsoft的头文件，并“调用” 来自我们的.NET代码。

2. 在WCF中模拟用户（松散地使用术语） 导致错误的注册表 蜂巢装载。换言之，何时 扩展MAPI尝试加载 来自HKCU的简介失败了。这个 意味着我们必须为正确的用户“RunAs”启动一个新流程。

这一切在实践中都有效，但我需要对以下内容进行一些解释：

如果我在命令行参数中运行控制台应用程序及其所需的所有信息，则MAPI无法登录。但是，如果我将此相同的代码编译为具有1个Form的Windows应用程序，并且在表单的OnLoad（）方法中使用完全相同的代码，那么它会成功。任何人都可以解释原因吗？

要从WCF服务运行“WinForms”应用程序作为当前登录的用户（不是LOCAL SYSTEM），我执行了以下操作以获取正确的令牌：

sessionID = (int)WTSGetActiveConsoleSessionId();
ret = WTSQueryUserToken(sessionID, out currentToken);

这有什么办法吗？当然，使用WCF的内置模拟会更好。

Answer 1

  

    

32位进程无法自动化64位Outlook

  

不完全正确，如果您可以在进程外创建COM对象，它将起作用。选项包括创建一个小的.exe，作为COM对象的工厂服务。

请参阅this SO post