Debugging .Net4 COM registered assembly from Win32

2019-05-08 01:15发布

This is a very simple setup, I can't believe but I didn't find anybody with the same problem so far...

Create a .Net4 class library in VS2010. Create a simplest possible COM object:

[ComVisible(true)]
[Guid("CD157EBC-C89D-40b6-B531-E85FF4B3AE9A")]
[InterfaceType(ComInterfaceType.InterfaceIsIUnknown)]
public interface IAcorn
{
    bool Foo(string moo);
}


[ComVisible(true)]
[ClassInterface(ClassInterfaceType.None)]
[Guid("854B7690-C1C4-40c4-8059-B4F3450B30D0")]
public class Acorn : IAcorn
{
    public Acorn()
    {
    }

    public bool Foo(string moo)
    {
        return true;
    }
}

Set "Register for COM interop" option for the assembly. Set "platform target" to x86.

Create a Win32 client using Delphi, import the object, instantiate it using normal instantiation (translates to CoCreateInstance(ClassID, nil, CLSCTX_INPROC_SERVER or CLSCTX_LOCAL_SERVER, IUnknown, Result))

Run the Win32 application, everything works fine.

Try to debug the COM object from VS2010. Set the class library Debug option to start an external program, point to the executable you just created. When you launch the Win32 app from VS210, the program crashes (with StackOverflow) at the attempt to instantiate the COM.

Change the Target framework to .Net 3.5 Launch the debugging from VS2010, everything works including debugging.

Note - This is also a problem when using either CLR Hosting or unmanaged export COM instantiation. Both methods work with .Net4 but debugging is not possible.

The question is standard - why does this happen and is there a workaround?

1条回答
贼婆χ
2楼-- · 2019-05-08 01:39

The .NET framework and Delphi may set or expect different values in the FPU control word.

That problem can be avoided by setting the register explicitly, before calling .NET code and resetting it after the .NET code is done:

How can I set and restore FPU CTRL registers?

查看更多
登录 后发表回答