MAPISendMail致桌面桥转换的UWP应用崩溃，求邮件发送替代方案

我之前处理过类似的Desktop Bridge打包应用的邮件发送问题，MAPI确实会因为UWP沙箱的兼容性限制导致崩溃，给你三个靠谱的替代方案，按易用性和适用场景排序：

这是UWP原生支持的轻量方案，直接通过系统唤起默认邮件客户端，代码改动最小，但有个局限：不支持本地文件附件，只能添加公开可访问的URL附件。

如果你的场景不需要附件，或者附件是在线链接，用这个最省事：

#include <winrt/Windows.System.h>
#include <winrt/Windows.Foundation.h>
#include <atlstr.h>

using namespace winrt;
using namespace Windows::System;
using namespace Windows::Foundation;

BOOL SendEmail(HWND hParentWnd, LPCTSTR pStrEmailAddrTo, LPCTSTR pStrSubject, LPCTSTR pStrMsg, LPCTSTR pFilePathAttachment)
{
    BOOL bRes = FALSE;
    try
    {
        CStringA mailtoUrl;
        mailtoUrl.Format("mailto:%s", CW2A(pStrEmailAddrTo));
        
        if (pStrSubject && pStrSubject[0])
        {
            mailtoUrl.AppendFormat("?subject=%s", Uri::EscapeComponent(CW2A(pStrSubject)).c_str());
            if (pStrMsg && pStrMsg[0])
            {
                mailtoUrl.AppendFormat("&body=%s", Uri::EscapeComponent(CW2A(pStrMsg)).c_str());
            }
        }
        
        Uri mailtoUri(to_hstring(mailtoUrl));
        Launcher::LaunchUriAsync(mailtoUri).get();
        bRes = TRUE;
    }
    catch (...)
    {
        bRes = FALSE;
    }
    return bRes;
}

这是微软官方推荐的适配UWP/Desktop Bridge的方案，完全兼容沙箱环境，支持添加本地文件附件，功能和原MAPI的场景匹配度最高。

下面是适配你原函数逻辑的C++示例：

#include <winrt/Windows.ApplicationModel.Email.h>
#include <winrt/Windows.Storage.h>
#include <winrt/Windows.Foundation.h>
#include <atlstr.h>

using namespace winrt;
using namespace Windows::ApplicationModel::Email;
using namespace Windows::Storage;
using namespace Windows::Foundation;

BOOL SendEmail(HWND hParentWnd, LPCTSTR pStrEmailAddrTo, LPCTSTR pStrMsg, LPCTSTR pStrSubject, LPCTSTR pFilePathAttachment)
{
    BOOL bRes = FALSE;
    try
    {
        EmailMessage message;

        // 设置主题和正文
        if (pStrSubject && pStrSubject[0])
        {
            message.Subject(to_hstring(pStrSubject));
        }
        if (pStrMsg && pStrMsg[0])
        {
            message.Body(to_hstring(pStrMsg));
        }

        // 添加收件人
        if (pStrEmailAddrTo && pStrEmailAddrTo[0])
        {
            EmailRecipient recipient(to_hstring(pStrEmailAddrTo));
            message.To().Append(recipient);
        }

        // 添加本地附件
        if (pFilePathAttachment && pFilePathAttachment[0])
        {
            // 注意：如果文件在应用私有目录（比如LocalFolder），直接访问即可
            // 如果是外部文件，需要确保应用有对应的访问权限，或者通过文件选择器获取
            StorageFile attachmentFile = StorageFile::GetFileFromPathAsync(to_hstring(pFilePathAttachment)).get();
            EmailAttachment attachment(attachmentFile);
            message.Attachments().Append(attachment);
        }

        // 唤起系统邮件撰写界面，和原MAPI的MAPI_DIALOG效果一致
        EmailManager::ShowComposeNewEmailAsync(message).get();
        bRes = TRUE;
    }
    catch (...)
    {
        // 可以在这里添加具体的异常处理，比如文件不存在、权限不足等
        bRes = FALSE;
    }
    return bRes;
}

关键注意点： #

• 如果附件是应用私有目录（如LocalFolder）的文件，API可以直接访问；如果是系统其他位置的文件，要么通过文件选择器让用户手动选择（无需额外权限），要么在应用清单中声明broadFileSystemAccess权限（仅适用于桌面桥应用，且需要用户同意）。
• 这个API会唤起系统默认邮件应用（比如Outlook、Mail），用户可以直接编辑后发送，体验和原MAPI一致。

如果你的应用需要更复杂的邮件操作，比如后台自动发送邮件、访问用户邮件箱内容等，可以使用Outlook的REST API。这个方案相对复杂，需要：

1. 在Azure AD注册应用，获取客户端ID和相关权限（比如Mail.Send）
2. 引导用户完成OAuth2.0授权，获取访问令牌
3. 通过REST API构造邮件（附件需要转成Base64编码）并发送

一般来说，桌面桥应用用前两个方案就足够覆盖需求了，这个方案只适合有特殊需求的场景。

内容的提问来源于stack exchange，提问作者c00000fd