With the move away from ArcGIS Desktop towards ArcGIS Pro comes a move away from ArcObjects…but to what? The answer is two-fold…the ArcGIS Pro .NET SDK, and ArcGIS Pro Arcpy! This post examines the ArcGIS Pro .NET SDK, its uses and limitations, and explains why ArcObjects is not dead…yet.
Some readers may be thinking that the natural progression from ArcObjects would be towards Pro .NET, but this is only true in some circumstances. The Pro SDK is obviously the replacement for desktop plug-in development, but what of standalone desktop applications (i.e. those that do not run as a plugin in ArcGIS Desktop or ArcGIS Pro)? This is where things become much fuzzier.
ArcObjects has a massive set of classes in an equally impressive array of libraries, providing developers the ability to get much deeper into the core ArcGIS functionality than is possible with arcpy. For instance, if you wish to trace a geometric network, you can go far with arcpy, but you cannot get the fine-grained control required to traverse a geometric network junction-by-edge-by-junction, examining owning features as you go, that is possible with ArcObjects. The amount of functionality available for standalone application development is so broad that it is possible to write an entire ArcGIS Desktop replacement desktop application utilizing ArcObjects. However, with the flexibility of the libraries and the breadth of functionality available comes downsides…specifically, the sheer overwhelming complexity of the ArcObjects class model and the need to class-cast over and over (and over) again in order to get at the desired functionality.
Seasoned ArcObjects developers will be happy to know that the Pro .NET SDK does away with the interface-style model that requires the constant class-casting of ArcObjects, which should make for much more legible code, along with easier upgrades and a better path to taking advantage of new functionality when new versions of the SDK are released. They will also be overjoyed to know that there are real exceptions in the Pro .NET SDK! No longer are we writing logic to try and determine what a COMException is actually telling us…we’ve got a variety of exception types that in and of themselves tell us much of what we need to know, so exception handling becomes much more useful. People will also be happy to find extensive use of the C# synchronicity model (i.e. async and await), meaning that your applications should be much more responsive than was possible with ArcObjects. However, what of standalone desktop application development?
As it turns out, the majority of the Pro SDK can ONLY be used for Pro plugins, and NOT for standalone desktop applications. There are really only 2 Pro libraries that can be used to develop standalone applications (that can only be run on a machine which has ArcGIS Pro installed)…ArcGIS.Core and ArcGIS.CoreHost (see https://github.com/Esri/arcgis-pro-sdk/wiki/proconcepts-CoreHost for further information). All of the other libraries can be used only in ArcGIS Pro plugin development…and if you try to bring in these other libraries and use them in a standalone application, you may end up scratching your head for a bit while trying to determine why nothing is running, as the exception you receive does not explicitly call out the lack of desktop session as the root cause. The ArcGIS.Core library provides a lot of functionality for direct geodatabase interaction (feature classes, tables, geometry, relationships) so one can play with the underlying data to one’s heart’s content, but if you want to, say, open an ArcGIS Pro project file and determine the layers in which a given geodatabase feature class participates, you’re barking up the wrong tree with the Pro .NET SDK. When you do get to this point, you will end up using Pro arcpy if you really need to access ArcGIS Pro functionality but not from within a running ArcGIS Pro desktop session.
So, with all the functionality available in the Pro SDK, and with the fact that it will only become better and more fully-featured over time, and with both plugins and standalone applications covered by a combination of Pro .NET SDK and Pro arcpy, does this mean that you’re done with ArcObjects? Close, but not quite. Notwithstanding the fact that porting any ArcObjects-based functionality to ArcGIS Pro and/or Pro arcpy will be a full rewrite of said functionality (which, depending on the application size, is a barrier to moving away from ArcObjects in and of itself), there are certain things that simply cannot be done in any of the ArcGIS programming interfaces except ArcObjects. The aforementioned fine-grained geometric network analysis is one such thing. With that in mind, if you are looking at porting an ArcObjects application to Pro, ensure that you have mapped out the functions to be ported to an extent that you are satisfied that the functionality is possible via a Pro programming interface.
If this post whets your appetite for getting hands-on with the ArcGIS Pro .NET SDK, further information can be found athttps://pro.arcgis.com/en/pro-app/sdk/