Difference in capabilities between Add-Ins and COM Extensions?

[DominicRorke]

Hi, I'm trying to work out what the difference is between Add-Ins and classic COM based extension models in terms of the capability of each approach, and when to use one approach instead of the other?

It is clear to see that Add-Ins have a number of benefits in terms of the speed of development, ease of distribution and maintenance etc, and it is useful to have the option of the Add-In distribution model, but is there any limit to the complexity of what can be developed with Add-Ins as opposed to COM registered extensions?

The ESRI 9.4 topic 'Roadmap for ArcGIS desktop customisation' seems to pitch Add-Ins as being a lighter weight development option for providing small customisations, whilst COM registered extensions requiring installers are pitched as "Custom components to add new functionality" (sounds like these can do more complex stuff); but surely the same custom code can be used and developed, and ArcObjects extended to the same extent and complexity with either approach?  Is it actually the case that both development models are as capable as each other?

Is it that there are benefits to the COM extension approach when multiple developers are working on an extension, as opposed to the Add-In model?

Is it that the COM extension is the clear choice when developing an extension on a commercial basis, as extension licensing and the requirement to have an administrator control on application distribution make COM extensions more appropriate for this scenario?

How does one decide which approach is most suitable, as the boundary between the two approaches appears to be rather blurred?

If you could provide some clarity on this it would be appreciated.

Many thanks,

Dominic

[DominicRorke]

From further investigation into this, I came across the following in the ArcObjects SDK help: "ArcGIS Desktop applications support a fixed set of add-in types including the most popular types used in the classic COM based extensibility model introduced in previous versions of ArcGIS."

...so any customisation to ArcMap that is not covered by this fixed set of types is not possible with Add-Ins.  Having read this, it is now easier to see how one would decide between Add-Ins and classic COM based extensions. So I take it that renderers, feature symbols, layers, editor customizations, geodatabase class extensions, and plug-in data sources, and also ArcFM AutoUpdaters etc would not be implementable via the Add-In framework (most of these being listed as advantages of classic COM extensions in the Customising desktop applications Roadmap)?

If you can confirm my findings or have any comments to add then that would be appreciated.

Thank you.

[RalfGottschalk]

is there any limit to the complexity of what can be developed with Add-Ins as opposed to COM registered extensions?

Yes.  Add-Ins are designed to create common customizations that extend basic functionality within the ArcGIS desktop framework, such as buttons, tools, toolbars, dockable windows, etc. which you could package up as an extension.  There are many customizations that are still only available with COM components, such as custom layers, geodatabase extensions, and custom renders, to name a few.  Also, Add-Ins are only available through ArcGIS Desktop (ArcMap, ArcCatalog, ArcGlobe, ArcScene), so you could not create an Add-In for ArcGIS Server or ArcGIS Engine.

but surely the same custom code can be used and developed, and ArcObjects extended to the same extent and complexity with either approach?  Is it actually the case that both development models are as capable as each other?

Though Add-Ins and custom components all use ArcObjects, the limitation comes down to (as stated above) how much of the system you can extend.  To create a desktop customization before Add-Ins, you would have to create a class that implements all the interfaces that the particular customization implements and register it in the correct component category.  If this customization was a button, you would just implement ICommand.  (Or if you are using .NET you could just use the Base Class.)  Add-Ins make it easy for you to create this type of customization because the Add-In takes care of all this stuff you would need to do to get the customization working, instead you can focus on the business logic of your customization.

If you wanted to create a custom layer, you would have to create a class that implements ILayer, IGeoDataset, etc. (these depend of the type of layer you are trying to create).  Add-Ins do not have the equivalent of this, so you could not create a custom layer that works like a layer in ArcGIS, even though you have access to all the ArcObjects that would allow you to create the layer.

Is it that there are benefits to the COM extension approach when multiple developers are working on an extension, as opposed to the Add-In model?

The only difference here is how it plugs into the system, so if you have some sort of source code manager or whatever.  To my knowledge, there really should not be any difference here.

Is it that the COM extension is the clear choice when developing an extension on a commercial basis, as extension licensing and the requirement to have an administrator control on application distribution make COM extensions more appropriate for this scenario?

Add-Ins could be used for commercial uses, it would be up to the developer to come up with their own licensing scenario.

How does one decide which approach is most suitable, as the boundary between the two approaches appears to be rather blurred?

Ultimately deciding when to use Add-Ins versus custom components really depends on your use case and deployment needs.  I think the biggest difference with Add-Ins is that they are easily to deploy and update.  You could, for example, develop an Add-In for your organization, put it on a network location, point ArcMap to that location, and every time ArcMap spins up it would use that Add-In.  If you need to update the Add-In just replace the Add-In with your updated version and the next time ArcMap is launched the new Add-In will be used.

I hope this helps.

[GeraldMarbury]

@domrorke thanks for starting this dialog.. I share all of your questions.

Counterparts less powerfull?
Another question I have is if there is a known ticking lifespan to COM customizations.

I understand that there are limited customizations in the Addin framework. However, it also appears the the addins couterparts that ARE available are less powerful.  For example, you can't change the bitmap, or tooltip or any other attribute persisted inthe XML, dynamically in an addin button like you can an ICommand.  If COM is ticking like VBA and VB6 did. Then should the addin sustitutes be less powerfull than their counterparts?


Ideal World
The major benefits that COM provides are discovery (COM Categories) and interfaces.  Interfaces are interfaces and all the supported langanges have them.   Discovery is the essential part and addins solve the discovery problem beutifully, better than COM did.

In an ideal world, I would like to see the ability to add the same interfaces (ICommand, IExtension, ITool, ILayer etc) to .NET classes that do not have to be comvisible or registered in a COMCatagory but are discovered using xml files like the addin framework. Is this where ESRI is moving with tools like ESRIRegAsm?

The addin process depends on inheritance which is a great idea. Ideally I whish interfaces could still be used too, ESRI.ArcGIS.Desktop.Addin.IButton for example. Then I could have a button that works in both frameworks. A simular framework to this methodology is the ADO.NET framework. You have DBConnection to inherit from but it also implements IDBConnection.

[DominicRorke]

Gottralf,

thanks for taking the time to reply.  Appreciated.

[GreigOldford]

I'm afraid I still can't figure out where to find a comprehensive list of exposed and unexposed ArcObjects for Add-ins.  Is there one?

I have an existing extension that implements ILayer to retrieve info on the layers in the TOC - is this possible with an Add-in?

[Anonymous User]

I have an existing extension that implements ILayer to retrieve info on the layers in the TOC - is this possible with an Add-in?

No, its not possible with an add-in at 10.0. You cannot implement an interface in the add-in class. You can write it and the code will compile but internally the cast to the interface will fail and nothing will happen. You will be able to do this at 10.1 however. The restriction with component categories still applies (ie. you cant specify any -- except for some editor construction tools at 10.1).