We have a small CoreHost application targeting .NET 8 that works with Pro 3.4-3.6. To make it also work with Pro 3.7 we changed the .NET target to 10. We expect the new version to work with Pro 3.4-3.7 as .NET supports backward compatibility and Pro 3.7 can load add-ins targeting .NET 6-10. The application (as recommended) loads Pro assemblies from the Pro binaries folder.
After changing the .NET target, the application works OK with Pro 3.7 but throws an exception with Pro 3.4-3.6. The CoreHost assembly is loaded and initialized correctly but the exception is thrown when it calls the Geodatabase class constructor.
Any suggestions?
Thanks
Dejan
Hi. The behaviour is expected or at least unsurprising.
ArcGIS Pro 3.7 moving to .NET 10 does not mean a CoreHost application rebuilt for .NET 10 remains backward compatible with Pro 3.4–3.6. For CoreHost applications, the target framework must match the .NET runtime generation used by the ArcGIS Pro version whose assemblies are being loaded. Esri’s .NET 10 migration guidance states that Pro 3.7 requires .NET 10, Pro 3.3–3.6 require .NET 8, and rebuilding under a new target framework loses backward compatibility with previous Pro releases. The recommended approach is to maintain a .NET 8 CoreHost build for Pro 3.4–3.6 and a .NET 10 CoreHost build for Pro 3.7+, optionally using a small launcher to choose the correct binary based on the installed Pro version.