<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Calling managed code from unmanged C++.  ArcGIS Pro CoreHost SDK. in ArcGIS Pro SDK Questions</title>
    <link>https://community.esri.com/t5/arcgis-pro-sdk-questions/calling-managed-code-from-unmanged-c-arcgis-pro/m-p/1698394#M13507</link>
    <description>&lt;P&gt;Hello,&amp;nbsp; This question would be targeted to one of the devs on Pro SDK.&amp;nbsp; Here is a quick background.&lt;/P&gt;&lt;P&gt;We have a large C++ geospatial application that integrates with geodatabase access.&amp;nbsp; We used to call ArcObjects directly in our DB library code to manipulate geodatabases.&amp;nbsp; We went 64 bit, ArcMap didn't, so I made an a separate 32bit application that took on the responsibilities of accessing the geodatabase and talked to it from our app via IPC..&amp;nbsp; Pro came out as 64 bit, we needed to support both users of ArcMap and Pro, so we made a decision to access via the same method and wrote a 64 bit C# app to access geodatabases and communicate via IPC the same as the 32 bit ArcObject standalone app. Now ArcMap goes bye bye. To increase performance I am investigating bringing it back in process of our large geospatial application and get rid of both standalone app.&lt;/P&gt;&lt;P&gt;Sure I can wrap the C# calls I need&amp;nbsp; in C++, either by CLI, marshalling, or dog forbid, even COM.&amp;nbsp; I know when I've been debugging code I've seen symbols down deep that look very familiar to ArcObject interfaces.&amp;nbsp; I'm pretty sure you guys didn't re-write the entire geodatabase access in .NET, or maybe you did and this question is moot.&amp;nbsp; If at the core of the SDK there still lies ArcObject code, how hard would it be to expose that for direct C++ API access?&amp;nbsp; I'm sure all of the new functionality is written in C#, but we don't need a lot of the fancy stuff.&amp;nbsp; Just basic read/write.&amp;nbsp; Any thoughts?&lt;/P&gt;&lt;P&gt;I realize this is a shot in the dark and don't expect much from this post, but maybe, just maybe, I can glean something from responses that will assist me in this arduous task.&lt;/P&gt;&lt;P&gt;Cheers,&lt;/P&gt;&lt;P&gt;-Mr. Bill&lt;/P&gt;</description>
    <pubDate>Fri, 24 Apr 2026 21:14:05 GMT</pubDate>
    <dc:creator>BillSmith</dc:creator>
    <dc:date>2026-04-24T21:14:05Z</dc:date>
    <item>
      <title>Calling managed code from unmanged C++.  ArcGIS Pro CoreHost SDK.</title>
      <link>https://community.esri.com/t5/arcgis-pro-sdk-questions/calling-managed-code-from-unmanged-c-arcgis-pro/m-p/1698394#M13507</link>
      <description>&lt;P&gt;Hello,&amp;nbsp; This question would be targeted to one of the devs on Pro SDK.&amp;nbsp; Here is a quick background.&lt;/P&gt;&lt;P&gt;We have a large C++ geospatial application that integrates with geodatabase access.&amp;nbsp; We used to call ArcObjects directly in our DB library code to manipulate geodatabases.&amp;nbsp; We went 64 bit, ArcMap didn't, so I made an a separate 32bit application that took on the responsibilities of accessing the geodatabase and talked to it from our app via IPC..&amp;nbsp; Pro came out as 64 bit, we needed to support both users of ArcMap and Pro, so we made a decision to access via the same method and wrote a 64 bit C# app to access geodatabases and communicate via IPC the same as the 32 bit ArcObject standalone app. Now ArcMap goes bye bye. To increase performance I am investigating bringing it back in process of our large geospatial application and get rid of both standalone app.&lt;/P&gt;&lt;P&gt;Sure I can wrap the C# calls I need&amp;nbsp; in C++, either by CLI, marshalling, or dog forbid, even COM.&amp;nbsp; I know when I've been debugging code I've seen symbols down deep that look very familiar to ArcObject interfaces.&amp;nbsp; I'm pretty sure you guys didn't re-write the entire geodatabase access in .NET, or maybe you did and this question is moot.&amp;nbsp; If at the core of the SDK there still lies ArcObject code, how hard would it be to expose that for direct C++ API access?&amp;nbsp; I'm sure all of the new functionality is written in C#, but we don't need a lot of the fancy stuff.&amp;nbsp; Just basic read/write.&amp;nbsp; Any thoughts?&lt;/P&gt;&lt;P&gt;I realize this is a shot in the dark and don't expect much from this post, but maybe, just maybe, I can glean something from responses that will assist me in this arduous task.&lt;/P&gt;&lt;P&gt;Cheers,&lt;/P&gt;&lt;P&gt;-Mr. Bill&lt;/P&gt;</description>
      <pubDate>Fri, 24 Apr 2026 21:14:05 GMT</pubDate>
      <guid>https://community.esri.com/t5/arcgis-pro-sdk-questions/calling-managed-code-from-unmanged-c-arcgis-pro/m-p/1698394#M13507</guid>
      <dc:creator>BillSmith</dc:creator>
      <dc:date>2026-04-24T21:14:05Z</dc:date>
    </item>
    <item>
      <title>Re: Calling managed code from unmanged C++.  ArcGIS Pro CoreHost SDK.</title>
      <link>https://community.esri.com/t5/arcgis-pro-sdk-questions/calling-managed-code-from-unmanged-c-arcgis-pro/m-p/1699153#M13519</link>
      <description>&lt;P&gt;I am kind of wondering if anyone there has played with AOT compilation to usable native C++ code?&amp;nbsp;&amp;nbsp;&lt;A href="https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/?tabs=windows%2Cnet8#aot-compatibility-analyzers" target="_blank" rel="noopener"&gt;https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/?tabs=windows%2Cnet8#aot-compatibility-analyzers&lt;/A&gt;&lt;/P&gt;&lt;P&gt;Thx, -Mr. Bill&lt;/P&gt;</description>
      <pubDate>Wed, 29 Apr 2026 19:29:51 GMT</pubDate>
      <guid>https://community.esri.com/t5/arcgis-pro-sdk-questions/calling-managed-code-from-unmanged-c-arcgis-pro/m-p/1699153#M13519</guid>
      <dc:creator>seenohearnospeaknoevil</dc:creator>
      <dc:date>2026-04-29T19:29:51Z</dc:date>
    </item>
  </channel>
</rss>

