当从针对任何CPU的C＃项目中调用此代码时，为什么此代码会引发System.AccessViolationException？

Question

我的ATL项目中有这个IDL：

[
    object,
    uuid(61B0BFF7-E9DF-4D7E-AFE6-49CC67245257),
    dual,
    nonextensible,
    pointer_default(unique)
]
interface ICrappyCOMService : IDispatch {
    typedef
        [
            uuid(C65F8DE6-EDEF-479C-BD3B-17EC3F9E4A3E),
            version(1.0)
        ]
    struct CrapStructure {
        INT ErrorCode;
        BSTR ErrorMessage;
    } CrapStructure;
    [id(1)] HRESULT TestCrap([in] INT errorCode, [in] BSTR errorMessage, [in, out] CrapStructure *crapStructure);
};
[
    uuid(763B8CA0-16DD-48C8-BB31-3ECD9B9DE441),
    version(1.0),
]
library CrappyCOMLib
{
    importlib("stdole2.tlb");
    [
        uuid(F7375DA4-2C1E-400D-88F3-FF816BB21177)      
    ]
    coclass CrappyCOMService
    {
        [default] interface ICrappyCOMService;
    };
};

这是我在C ++中的实现：

STDMETHODIMP CCrappyCOMService::InterfaceSupportsErrorInfo(REFIID riid)
{
    static const IID* const arr[] = {
        &IID_ICrappyCOMService
    };
    for (int i = 0; i < sizeof(arr) / sizeof(arr[0]); i++) {
        if (InlineIsEqualGUID(*arr[i], riid))
            return S_OK;
    }
    return S_FALSE;
}

STDMETHODIMP CCrappyCOMService::TestCrap(INT errorCode, BSTR errorMessage, CrapStructure *crapStructure) {
    memset(crapStructure, 0, sizeof(CrapStructure));
    crapStructure->ErrorCode = errorCode;
    crapStructure->ErrorMessage = errorMessage;
    CComPtr<ICreateErrorInfo> x;
    ICreateErrorInfo* pCreateErrorInfo;
    CreateErrorInfo(&pCreateErrorInfo);
    pCreateErrorInfo->AddRef();
    pCreateErrorInfo->SetDescription(errorMessage);
    pCreateErrorInfo->SetGUID(IID_ICrappyCOMService);
    pCreateErrorInfo->SetSource(L"Component.TestCrap");
    IErrorInfo* pErrorInfo;
    pCreateErrorInfo->QueryInterface(IID_IErrorInfo, (void**)&pErrorInfo);
    pErrorInfo->AddRef();
    SetErrorInfo(0, pErrorInfo);
    pErrorInfo->Release();
    pCreateErrorInfo->Release();
    printf("Going to return %d...\n", errorCode);
    return errorCode;
}

我在C＃中这样称呼它：

static void Main(string[] args)
{
    var service = new CrappyCOMService();
    var crapStructure = new CrapStructure();
    try
    {
        service.TestCrap(-1, "This is bananas.", ref crapStructure);
    }
    catch (COMException exception)
    {
        Console.WriteLine(exception.ErrorCode);
        Console.WriteLine(exception.Message);
    }
    Console.WriteLine(crapStructure.ErrorCode);
    Console.WriteLine(crapStructure.ErrorMessage);
}

如果我从针对x64的C＃项目中运行代码，则一切正常。 问题是，当我从以C＃中的Any CPU为目标的项目中调用TestCrap方法时，它将引发System.AccessViolationException 。 这是为什么？ 我可以验证一下，当它抛出System.AccessViolationException ，它仍然会向控制台窗口显示Going to return -1...。

编辑 ：我缩小了复制步骤。 抱歉，但是我忘了添加。使用x64版本（针对x64的ATL项目和针对Any CPU的C＃测试项目）编译代码，然后再转换回Any CPU版本（ATL项目）时，似乎会发生这种情况。 （针对Win32）和针对任何CPU的C＃测试项目）。

编辑 ：我已经缩小了更多的错误。 首先，看起来Any CPU C＃项目始终使用x64版本的COM对象，因此，我的ATL项目的版本必须先编译才能传播任何代码，因为x64系统上的Any CPU确实要在x64上下文中运行。 此外，它看起来像是一行crapStructure->ErrorMessage = errorMessage; 导致System.AccessViolationException 。 它会在该行的COM世界中执行代码，但返回C＃世界时，它将抛出异常。

编辑 ：在C ++中， printf("%d\\n", sizeof(CrapStructure)); 结果为16 。 从C＃开始， Console.WriteLine(Marshal.SizeOf(typeof(CrapStructure))); 也得到16 。 但是，,，再读一遍，这是一个无用的检查，正如汉斯在这里的答案所提到的： 如何检查结构消耗的字节数？

编辑 ：我尝试做tlbimp CrappyCOM.dll /out:CrappyCOMx86Managed.dll并从我的任何以CPU​​为目标的 C＃项目中使用CrappyCOMx86Managed.dll ，但它再次引发了System.AccessViolationException 。 我认为这是因为它再次转到系统上已注册的x64 COM对象，所以我使用regsvr32取消注册了x64 COM对象。 再次运行代码并注册了x86 COM对象，它抱怨由于以下错误而导致检索具有CLSID {F7375DA4-2C1E-400D-88F3-FF816BB21177}的组件的COM类工厂失败：80040154未注册类（HRESULT的异常） ：0x80040154（REGDB_E_CLASSNOTREG））。 我发现将tlbimp生成的存根中的x86 COM对象作为目标的唯一方法是将C＃项目的构建目标修改为x86，然后代码可用于测试我的x86 COM对象，所以这种情况似乎对我而言，这是一个有争议的问题，因为我想让任何CPU专门针对我的x86 COM对象或具有正确结构大小的x64 COM对象。 COM在C＃中是一场灾难。

Answer 1

对于x64和x86版本，可能（隐式）使用相同的类型库（.TLB）或包含.TLB的DLL。

问题是您的TLB定义了非托管结构，并且该结构布局在32位和64位模式（大小，偏移量，...）下将有所不同。

在.NET中，要确保在使用不同的处理器体系结构进行编译时，不会引用相同的Interop程序集（由TLB通过隐式tlbimp COM引用生成）。

使用标准Visual Studio工具正确实现它可能很棘手。

如果仍要使用这样的结构（在自动化世界中有点奇怪），建议您自己使用tlbimp.exe构建Interop程序集，并像正常的.NET程序集一样简单地引用这些Interop程序集，但要取决于位（您将可以使用.csproj中的'Condition'属性进行调整，而不是直接使用COM引用。