The “HOW” of the ESRI AddIn


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”….

Allison R

One thought on “The “HOW” of the ESRI AddIn

  1. Tana Haluska

    Thanks for the interesting read Allison. Have you heard of any problems with run-time errors of ESRI addins (developed in 10.0, deployed in 10.1) that reference local paths on the developer’s computer? One of the users of our addin is experiencing this error below. Note my local computer path a couple lines down. This path is in one of the .dll files of the addin. Thanks, tlh
    Exception text: System.InvalidCastException: Unable to cast object of type ‘System.__ComObject’ to type ‘ESRI.ArcGIS.Catalog.GxCatalogClass’.
    at ShorelineAddin.modPublic.GetShorelineDirectory() in E:\Users\thaluska\v10addin_Current\ShorelineAddin\ShorelineAddin\modPublic.vb:line 450
    at ShorelineAddin.frmScenarioSettings.cmdStartHere_Click(Object sender, EventArgs e) in E:\Users\thaluska\v10addin_Current\ShorelineAddin\ShorelineAddin\frmScenarioSettings.vb:line 415
    at System.Windows.Forms.Control.OnClick(EventArgs e)
    at System.Windows.Forms.Button.OnClick(EventArgs e)
    at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
    at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
    at System.Windows.Forms.Control.WndProc(Message& m)
    at System.Windows.Forms.ButtonBase.WndProc(Message& m)
    at System.Windows.Forms.Button.WndProc(Message& m)
    at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
    at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
    at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

    Reply

Got something to say?

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s