Enable native code debugging to deep into COM-object
Asked Answered
W

2

14

I have some code that uses a 3rd-party lib (ArcObjects) exposed by COM. So for instance there´s the IGeometry-interface.

IGeometry geometry = GetGeometry();

Now when I want to look at the objects members I open a QuickWatch:

enter image description here

I´ve read several issues that all point to the "enable native code debugging"-option in Visual Studio 2015. I´ve already enabled that option to no avail.

How can I get the debugger to expose the members of the COM-object?

EDIT: When working with VS2010 and .NET 3.5 this works:

enter image description here

Waltner answered 22/5, 2018 at 11:53 Comment(7)
Perhaps this is your answer : learn.microsoft.com/en-us/visualstudio/debugger/…Eupepsia
@rak No, thats the exact same I´m already doing.Waltner
Do you have the pdb file associated to your dll ?Eupepsia
@Eupepsia Nope, but actually I don´t want to debug the code, just olook t its (public) interface. This should work without pdb AFAIK.Waltner
The debugger engine is limited in its powers to inspect COM interfaces, native debugging does not change that. You might have a shot from "Dynamic view", it then tries to use the IDispatch members to get info about the type. But if IDispatch.GetTypeInfo() returns null then that is not going to happen. Try using geometry.IsEmpty to ensure the plumbing is okay. Find other victims of this product at the gis.stackexchange.com site.Gorrono
@HansPassant That´s really annyoing. I thought that was not unique to ArcGIS and thus posted this question here instead of at gis. "Dynamic View" didn´t help either, thanks anyway.Waltner
You know I didn't do it, right? Telling me that is annoying does not help me help you.Gorrono
S
5

As suggested in the comments I posted that question on gis.stackexchange.com also, from which I quote our solution:

In Visual Studio under Tools-->Options-->Debugging enable the option "Use Managed Compatibility Mode".

Sundin answered 22/5, 2018 at 11:53 Comment(1)
This worked for me in Visual Studio 2019- while the "Embed Interop Types" option described above had no effect. Any idea why this works, though?Rovner
G
11

Enabling unmanaged debugging can only have a useful side-effect if you also have the PDB and the source code for the component. You don't, vendors of these kind of components don't disclose it. The only reason you can see anything at all is because you let VS generate the interop assembly for the COM component. Which converts the declarations in the type library for the component into equivalent .NET types. Like IGeometry, most probably actually a C++ class under the hood.

Which is the big difference between the top view and the bottom screen-shots. Starting with VS2010 and .NET 4.0, this interop assembly is no longer needed. Called "type embedding", in general a highly useful feature, it avoids the need to deploy the PIA for a component. A very big deal in particular for Office interop.

Type embedding aggressively removed types and members that are not used in the source code. What is left is embedded into your final assembly, thus removing the need to deploy the interop assembly or PIA. Or in other words, you can't see IGeometry.Envelope back in the debugger because your source code doesn't use the property. It got stripped by the type embedding plumbing.

That is easy to fix. Select the COM reference in your project's Reference node and set its "Embed Interop Types" property to False. You can leave it that way after testing, don't forget then to also deploy the interop assembly.

Gorrono answered 22/5, 2018 at 11:53 Comment(2)
So type embedding puts all those interop-types, that wrap the native types into appropriate .NET.types, into the calling assembly? But omitting all those members that aren´t used within that calling assembly? So if I´d use IGeometry.SomeMember somewhere in my code I would see its value in the debugger, but for IGeometry.Envelope not, as it´s not actually used in my code?Waltner
"Embed Interop Types" already is set to false in our environment. We also rely on the ArcObjects-assemblies in our environment which seem to function as Primary Interop-Assembly (PIA). However even with those we cannot get any more meaningful information out of the objects.Waltner
S
5

As suggested in the comments I posted that question on gis.stackexchange.com also, from which I quote our solution:

In Visual Studio under Tools-->Options-->Debugging enable the option "Use Managed Compatibility Mode".

Sundin answered 22/5, 2018 at 11:53 Comment(1)
This worked for me in Visual Studio 2019- while the "Embed Interop Types" option described above had no effect. Any idea why this works, though?Rovner

© 2022 - 2024 — McMap. All rights reserved.