Much of what I have read about Esri Add-Ins describe these unique containers of custom ArcGIS Desktop functionality as having behaviours that make deployment, installation and development “easier”. That is, easier than that required by their predecessor – the Classic COM component, which became an essential for Desktop customisation when ArcObjects first hit the scene in the late 90’s.
I have “walked through” numerous help references and tutorials that are based around the Esri Add-In type, but none that I have found articulate the “how” of the Esri Add-In. That is, how can the Add-In type have such new and appealing deployment characteristics ? – There is many a forum posting and support request focused on the intricacies of COM registration and deployment; The first Add-In type , to which we were introduced at Desktop 10.0, utilises ArcObjects libraries; ArcObjects libraries are COM libraries. How then, could the Esri Add-In model employ ArcObjects “COM” libraries, without the need for registration on the underlying operating system?
….And so for an explanation: The thing with the Esri Add-In type is that it utilises a “framework” for deployment, enabling the distribution of custom ArcGIS Desktop functionality, without being “tied” to deployment requirements of a single Desktop API. This was most clearly seen at 10.1, when Python was added to the available Desktop APIs that may be utilised to incorporate GIS functionality within a created Esri Add-In.
That is, the framework is such that, irrespective of the GIS business logic being coded in ArcObjects or Python, the deployment model is consistent: distribute the Esri Add-In file to users, and it’s presence at a known folder location means that it will be installed within the applicable Desktop application (ie. ArcMap, ArcCatalog, ArcScene, or ArcGlobe), when that Desktop application opens. Integral to this process is the config.xml file that is contained within the Esri Add-In file. – The config.xml file is read when the applicable ArcGIS Desktop application starts up, and consequently the ArcGIS Desktop application acquires the information it needs to load the subject Esri Add-In customisation onto the opening Desktop application interface.
– For example, during the ArcMap start-up process, ArcMap checks for Esri Add-In files at a known folder location(s); If it finds an Esri Add-In file, ArcMap then reads the Esri Add-In’s metadata information from the Add-In’s contained config.xml file. As a result, the component type(s) packaged within the Esri Add-In are discovered and able to be added to the ArcMap interface. For the case of the Esri Add-In utilising ArcObjects for its GIS functionality, the subject Esri Add-In contains a compiled dll. Under the Classic COM deployment model this dll would have needed to be registered, but under the Esri Add-In model, the requirement to register the dll with a subject component category on the underlying operating system has become redundant. – Redundant to a humble folder location, and the smarts of an “all descriptive” config.xml.
Given the “redundancy” of COM component registration to the Esri Add-In install model then, the “natural” progression at ArcGIS 10.1 was for the Esri Add-In model to include Python as a supported language for authoring required GIS business logic.
– Like the ArcObjects authored Esri Add-In, the Python Esri Add-In can be thought of as a file archive from which Desktop customisation is extracted at start-up; And like the ArcObjects ESRI Add-In, the Python Esri Add-In is discovered as a consequence of its presence at a known folder location. Of course though, the Python Esri Add-In is not created in .Net or Java, it is created via the Esri-supplied utility : the Python Add-In Wizard. This downloadable wizard allows for the user to specify desired component types (buttons, tools, menus, toolbars etc.), and then, for each component created, Python event code is attached.
The final point of note regarding the “how” of Esri Add-Ins, is in relation to the Esri Add-In file structure.
-The Esri Add-In file is really just like a zip file, with an alternate file extension : *.esriaddin. Contained within this archive is the aforementioned config.xml file which defines the properties and structure of the Esri Add-In; there is operational code (ArcObjects or Python) which provides required GIS functionality; and there are resource files (images, data, etc.) that support the subject functionality. To explore further then, the “.esriaddin” file extension could be replaced with “.zip”, and the archive content could be extracted into a nominated folder. From there, the files that constitute an Esri Add-In, that are read and loaded at Desktop start-up, may be observed.
It is true that the Esri Add-In type does not support the inclusion of custom classes or all UI types that could otherwise be created via the classic COM model. Irrespective though, the Esri Add-In type allows for creation of the most widely used component types, via a much simpler deployment model – a model that is less “black-box” and more “user-friendly”….