This is a guest post written by Mike Miller, the author and teacher of our new Programming ArcObjects with .NET for ArcGIS 10 class. The next session of this class will be delivered online beginning January 21st, 2013. This course will also be taught in a traditional classroom setting in Seattle, WA at the King County GIS Center from February 25th-27th.
In this first of two posts on creating ArcGIS Desktop add-ins with ArcObjects and .NET we’ll take a look at the history of programming with ESRI products as well as introduce the concept of creating add-ins with .NET. The second post will cover the details of how you create the add-ins.
History of Programming with ESRI Products
First to put things in a historical context (from the ESRI perspective at least). In the beginning (1982) there was Workstation Arc/INFO. At that time very few people had desktop PC’s and what they had were expensive and limited so Arc/INFO was developed for more powerful UNIX workstations. ESRI did eventually release a limited set of functions as PC Arc/Info which used dBase III for its database. ArcInfo included a scripting language called AML which was a procedural language used to extend the functionality of ArcINFO.
By 1995 Desktop PC’s had become more common, more powerful, and easier to use so ESRI released ArcView, intended to simply view data created in ArcInfo. But as things tend to go, people wanted more capability and more power and ESRI added editing and advanced spatial analysis capability to ArcView and it became a full-featured GIS platform and they even included an object oriented programming language called Avenue
When ESRI developed Arcview they used a development toolkit called Open Interface which was a cross-platform interface that could be deployed on Microsoft Windows, Unix, and even MacIntosh. But as computers became more powerful and more people used GIS and demanded more features ESRI ran up against some limitations in ArcView and Avenue which were being pushed far beyond their intended purposes. So ESRI looked around to see what development platforms were available. They chose Microsoft.
By this time Windows had essentially won the PC battle and PCs were becoming powerful enough to run large complicated software. It seemed like the gold-standard. So they completely re-wrote ArcINFO from the ground up using a Microsoft technology called COM. At the time it was the largest implementation of COM ever, even larger than Microsoft Office, so it was a huge undertaking.
They called the new software ArcGIS and because they used COM they were able to expose all of its functionality to developers without actually releasing the source code. ArcGIS itself was actually written using ArcObjects so that anything you could possibly do in ArcGIS you could do programmatically with ArcObjects. From a developers standpoint this was fantastic. But it required learning a whole new language and more in the way of basic programming knowledge. It was not as accessible to the end user as AML or Avenue.
There were two ways to access ArcObjects, Visual Basic for Applications was included with ArcGIS and allowed you to write ArcObjects programs from within ArcGIS. Or you could create COM components outside of ArcGIS using a COM compliant language like Visual Basic or Visual C++. This allowed greater flexibility but also was more complicated and required Visual Studio. But things progressed and Microsoft developed .NET technology which was incompatible with VBA and they began phasing out VBA.
ESRI saw the writing on the wall and looked around at what was available again and saw Python. Python was cross-platform which allowed it to be used on non-windows machines, and it was independent of Microsoft. It had a lot of flexibility and ESRI decided to include it to allow basic scripting of geoprocessing tasks in 9.0. They still had ArcObjects but they offered Python and the Geoprocessing framework as a more accessible way to extend ArcGIS.
In ArcGIS 10 ESRI phased out VBA completely and included Python in the core ArcGIS products. They also exposed more functionality with ArcPy, ArcPy.mapping, ArcPy.sa, ArcPy.ga, ArcPy.da module. This seems to be the wave of the future. This is only my opinion but I think ESRI has a bit of buyers remorse after going whole hog with Microsoft in 2000 and are looking for options to go back to a more cross-platform environment down the road and Python may give them that opportunity.
BUT
ArcGIS is still written with ArcObjects. ArcObjects is not going away anytime soon. It was Microsoft’s decision to deprecate VBA not ESRI’s. There is a huge amount of code out there written using ArcObjects and nobody wants to re-write it for Python, even if they could
EVERYTHING in ArcGIS is exposed to ArcObjects. There are no limitation.
Python has quite a few limitations of its own. If you are a software developer the Visual Studio development environment is far superior to Python but more complicated and more expensive.
So ESRI had a dilemma. How do they prepare for the future and provide a simple, free, scripting environment for end-users but still allow the flexibility that ArcObjects provides and allow users to continue using their existing VBA code base.
Introducing Add-Ins
What they came up with is the Add-In framework. Writing ArcObjects code using COM is more complicated than most GIS Users want to deal with. It requires components to be registered through the windows system registry and that is opening a large bag of worms that most GIS users would prefer not to deal with. Deployment requires installation software that handles the work of registration but it is another learning curve that keeps GIS developers from focusing on GIS.
Add-Ins are much simpler. The basic framework occurs in declarative XML which is relatively easy to read. There is no need to register components or deal with complicated installation programs. Add-Ins are a single file that you can give to people via e-mail or over through the web. Clicking on the add-in file automatically installs it on the system and its functionality is there when you open ArcGIS. It can even be put on a network share so that an entire corporation can have access to the add-in without a need to install on individual machines.
So, if you are new to programming in general or at least to programming in a GIS environment, which development environment should you choose? As you can gather, there are a lot of options out there.
Python has a lot of things going for it, especially if you are primarily a GIS user and simply want to automate some processes. If the current ArcPy modules will do what you need, or if you are patient enough to wait until ESRI exposes more functionality (which they are doing all the time) then you might want to invest in learning Python.
Or if you want to be able to run geoprocessing scripts in a UNIX environment you are stuck with Python because ArcObjects is based on COM and will only work on windows machines.
If you are just starting out as a GIS developer it might be a good idea to start with Python and look into ArcObjects if you find it doesn’t meet your needs. Because Python seems to be the wave of the future and ESRI is putting a lot of effort into making it useful for extending GIS functionality.
Advantages of Using ArcObjects
ArcObjects also has a lot of things going for it. If you are already familiar with ArcObjects you might find Python extremely frustrating because the development environment is extremely limited and the functionality is also limited. Especially if you need a more complex user interface than provided through ArcToolbox. In particular if you already have an existing codebase that you’ve been working on for years you probably don’t want to re-write it all.
Again, ArcGIS is written using ArcObjects. It would theoretically be possible to completely rewrite ArcGIS using ArcObjects so there are really no limitations on what you can do with it.
In particular, any type of user interface that you can imagine can be developed with ArcObjects. Anything that you see other windows programs doing you can likely re-create in Visual Studio, while Python is limited to the ArcToolbox interface.
I’ve mentioned the development environment a few times. What I mean by that is Visual Studio which has a visual interface for creating user interfaces using drag and drop methods. Also the code editor is amazing with AutoComplete and Intellisense and context specific help. It makes it much more efficient to write error-free code. And if you fail to write error-free code on your first attempt the debugging environment is also amazing. Python has none of these features and if you spend a lot of time programming it is probably well worth your time and money to purchase Visual Studio and use it for extending GIS
There are other things that you simply can’t do in Python. These include feature class extensions, server object extensions, and creating an entire ArcGIS extension. Finally, performance is also an issue. ArcObjects is compiled code while Python is interpereted. As such it is generally much faster and so if performance is critical, you should consider ArcObjects.
The Add-In Framework
The add-in framework relies on a declarative XML document rather than COM registration to let ArcGIS know what components and assemblies are part of the Extension.
XML is a tag based language similar to HTML. A major difference is that the tags can be defined to represent anything rather than conforming to a specified standard. This allows individuals to create their own schemas for what tags to use and how they should be implemented. Thus the name Extendable Markup Language
ESRI devised a schema for ArcGIS add-ins that includes things like the name of the add-in, the author, the version number, and the target. The version number is checked automatically and if it is a newer version it will be installed automatically. The target could be ArcMap, ArcCatalog, ArcGlobe, etc. Then it lists the items that are in the add-in, such as buttons, tools, combo boxes. It also lists item groups that are menus and toolboxes that list the individual items on them.
In the next post in this series we’ll show you how to create a simple add-in for ArcGIS Desktop using ArcObjects and .NET.
