{"id":1147,"date":"2011-10-19T09:26:43","date_gmt":"2011-10-19T07:26:43","guid":{"rendered":"http:\/\/mariusbancila.ro\/blog\/?p=1147"},"modified":"2012-11-23T12:57:34","modified_gmt":"2012-11-23T10:57:34","slug":"accessing-64-bit-native-com-server-from-a-managed-client","status":"publish","type":"post","link":"https:\/\/mariusbancila.ro\/blog\/2011\/10\/19\/accessing-64-bit-native-com-server-from-a-managed-client\/","title":{"rendered":"Accessing 64-bit Native COM Server From a Managed Client"},"content":{"rendered":"

Not long ago I ran into a COM interop problem that was a bit tricky to fix. So I’m sharing the problem and the solution here in case others encounter the same problem.<\/p>\n

I had this native in-proc COM server that initially was built only for x86. It was used in a native MFC application as well as a C# Windows Forms application, where it was added as a COM reference. Both worked nicely. But then I needed to port the MFC app to the x64 platform, so I had to do the same with the in-proc COM server. They both worked correctly, but the managed app, which had to be available also both as 64-bit and 32-bit (even on 64-bit machines), was broken. Eventually I traced the problem to some COM method calls which were a bit atypical, because the arguments to the methods were not COM “native” types, but custom structures.<\/p>\n

These structures looked like this:<\/p>\n

\r\n[uuid(6F13C84D-0E01-48cd-BFD4-F7071A32B49F)] struct S\r\n{\r\n      long a;\r\n      BSTR b;\r\n      long c;\r\n      BSTR d;\r\n      long e;\r\n      BSTR f;\r\n      BSTR g;\r\n      BSTR h;\r\n      BSTR i;\r\n      long j;\r\n      BSTR k;\r\n      long l;\r\n      BSTR m;\r\n      long n;\r\n};\r\n<\/pre>\n
and the COM method signature:<\/p>\n
\r\n[id(42)] HRESULT GetListOfStructs(SAFEARRAY(struct S)* arrRes);\r\n<\/pre>\n
When you add a COM reference to a .NET assembly, Visual Studio runs tlbimp.exe<\/a> to generate a .NET assembly with equivalent definitions to the type definitions found in the COM type library. This interop assembly is used to access the COM server. It contains Runtime Callable Wrappers that bridge the two worlds together. By default, the interop assembly, generated in the project’s output folder, is called Interop.<comname>Lib.dll<\/strong>. For instance if the COM server is called NativeCOMServer, the interop assembly is called Interop.NativeCOMServerLib.dll.<\/p>\n
The wrapper that was generated in the interop assembly had the following signature for the aforementioned method:<\/p>\n
\r\n[DispId(42)]\r\nvoid GetListOfStructs(ref Array arrRes);\r\n<\/pre>\n
and therefore used like this:<\/p>\n
\r\nSystem.Array result = null;\r\nobj.GetListOfStructs(ref result);\r\n<\/pre>\n
The call was performed correctly, the native code was executing, but as soon as it was returning an access violation exception was occurring. Thanks to Hans Passant<\/a> I figured the problem was rooted in the way Visual Studio generates the interop assembly. The generated RCW didn’t know how to handle the custom structure correctly. Probably different padding on the two sides generated the access violation. <\/p>\n
The trick was to generate the interop assembly directly, as a custom build step in the COM server project, and include it as an assembly reference in the managed project. Here are the commands for the custom build (must to make sure you have the correct path to the 32-bit and the 64-bit version of tlbimp.exe):<\/p>\n
\r\n\\TlbImp.exe $(TargetPath) \/out:$(TargetDir)\\NativeCOMLib.Interop.dll \/primary  \/keyfile:mykey.snk \/machine:x86\r\n\r\n\\TlbImp.exe $(TargetPath) \/out:$(TargetDir)\\NativeCOMLib.Interop.dll \/primary  \/keyfile:mykey.snk \/machine:x64\r\n<\/pre>\n
The result was a wrapper with methods like this:<\/p>\n
\r\n[DispId(42)]\r\nvoid GetListOfStructs(ref S[] arrRes);\r\n<\/pre>\n
which of course had to be called like this:<\/p>\n
\r\nS[] result = null;\r\nobj.GetListOfStructs(ref result);\r\n<\/pre>\n
To include either one or the other in the C# project I had to manually change the project file, since Visual Studio does not know conditional references, a feature available in MSBuild. I didn’t build the managed app for Any CPU because it had to be able to run as 32-bit on 64-bit machines, so I had two configurations, one for x86 and one fore x64.<\/p>\n
\r\n    <Reference Condition=\" '$(Platform)' == 'x86' \" Include=\"NativeCOMServer.Interop, \r\n               Version=1.0.0.0, Culture=neutral, PublicKeyToken=f5b9312191a42d52, processorArchitecture=x86\">\r\n      <SpecificVersion>False<\/SpecificVersion>\r\n      <HintPath>..\\Bin\\NativeCOMServer.Interop.dll<\/HintPath>\r\n    <\/Reference>\r\n    <Reference Condition=\" '$(Platform)' == 'x64' \" Include=\"NativeCOMServer.Interop, \r\n               Version=1.0.0.0, Culture=neutral, PublicKeyToken=f5b9312191a42d52, processorArchitecture=x64\">\r\n      <SpecificVersion>False<\/SpecificVersion>\r\n      <HintPath>..\\Bin64\\NativeCOMServer.Interop.dll<\/HintPath>\r\n    <\/Reference>\r\n<\/pre>\n
But this time the wrappers were able to bridge the call and everything worked smoothly. <\/p>\n
The lesson learned is that when you have COM custom structures you should not rely on the way Visual Studio generates the interop assembly. You should build the interop explicitly (maybe as a custom build step, like I did) and include it as an assembly reference to your managed project.<\/p>\n
CodeProject<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
Not long ago I ran into a COM interop problem that was a bit tricky to fix. So I’m sharing the problem and the solution here in case others encounter the same problem. I had this native in-proc COM server that initially was built only for x86. It was used in a native MFC application … Read more<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_uag_custom_page_level_css":"","advgb_blocks_editor_width":"","advgb_blocks_columns_visual_guide":"","_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_feature_clip_id":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2},"jetpack_post_was_ever_published":false},"categories":[13,237,11,7,211],"tags":[451,461,301,300,299,302,55],"class_list":["post-1147","post","type-post","status-publish","format-standard","hentry","category-net","category-64bit","category-csharp","category-c","category-com","tag-c","tag-com","tag-interop","tag-managed","tag-native","tag-tlbimp","tag-visualstudio"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t