This document is archived and information here might be outdated.  Recommended version.


Extending ArcObjects (ArcObjects .NET 10.4 SDK)

Extending ArcObjects


Summary
The ArcGIS family of applications relies on ArcObjects to provide data management, map presentation functionality, and more. Because the platform is Component Object Model (COM)-based, you can customize ArcObjects to the lowest level. You can create your own components to plug in to the existing framework, tailoring the platform to your specific workflow.
The key to creating such components is a thorough understanding of the ArcObjects framework and surrounding issues. This topic describes how to create components for the ArcObjects platform.
Additional topics in this section cover prerequisites, getting started, reasons for creating custom objects, and a recap of key ArcObjects and COM concepts.

In this topic


Customizing ArcGIS

ArcGIS was designed with extensibility in mind; not just extensibility to allow the product to grow with successive releases, but also to allow third party developers to customize and extend the product. Because Esri used Microsoft COM to create the ArcObjects platform, upon which ArcGIS is built, the entire system is potentially open to customization down to a low level.
As an ArcObjects developer, you should already be familiar with the ArcObjects development options available to you. You should also be familiar with the ArcGIS Developer Help system, which details each class and interface within ArcObjects and helps you construct effective client code.
Extending ArcObjects is aimed at developers who want to extend the core ArcObjects object models, creating custom objects that plug seamlessly into the ArcGIS environment.
The topics in this section build on the knowledge contained in the Developer Help system, to show how these same interfaces can be implemented in your own custom objects. This approach allows you to transparently build-in custom functionality to the ArcGIS applications, tailored specifically to your requirements.

Creating custom objects

You may have customized the basic ArcGIS applications for one of several reasons: to automate simple repetitive tasks, streamline your workflow, create new functionality, or produce third party solutions and add-ons to ArcGIS.
In any of these cases, you need to determine the right solution for the task by considering many issues, for example the technically possible options for a solution to your task (there may be numerous possible solutions for each task). You also need to consider your choice (or restrictions) of development environment and the options available for distributing the chosen solution to your users.

Custom object solutions

When your task is defined, you may find that it points naturally toward a custom object solution. For example, you may require a symbol that is slightly different from the symbols available, or you may want to use the functionality of a layer, but your data source is not supported. In such cases, you may decide to extend ArcGIS by creating your own custom version of the required class or classes.
In the Introduction to COM topic, you were informed that COM allows ArcObjects objects to be reused at a binary level, meaning that third party developers do not require access to source code to extend the system even at the lowest level.
Objects encapsulate the manipulation methods and the data that characterizes each instantiated object behind a well-defined interface. This promotes structured and safe system development, since the client of an object is protected from knowing any of the details of how a particular method is implemented. COM does not specify how an application should be structured; as an application programmer working with COM, language, structure, and implementation details are left up to you. In this way, COM development is based on trust between the implementer and the user of the functionality.
The description above may raise immediate questions; you are free to implement interfaces and produce classes that plug in to the existing ArcGIS framework, but the framework trusts you to implement things correctly, even though you do not know how existing classes have implemented the functionality internally. Therefore, you need to know some ground rules for creating new classes.
The extensible model has both benefits and drawbacks to you as a third party developer. You benefit from the open opportunity to customize the ArcGIS framework by creating new COM objects. Your challenge is to produce objects that behave as expected, performing the tasks the ArcGIS client application is expecting to be done.
By using a custom class as part of your programming solution, you can achieve tight integration of your solution into ArcGIS, because the ArcGIS application can create and use objects as it would standard objects. Your solution may require no changes to the ArcGIS user interface (UI). Often, you will be able to provide all the required UI customization as standard-looking UI additions. You may also find it useful to create custom classes if you need to provide your new functionality to another developer rather than simply to other end users.
You will find extending ArcObjects useful if you need to extend or customize the functionality in ArcGIS by producing classes and applications that are intended for distribution beyond your own desktop. You will learn about these types of customizations in the other topics included in this section.