Agile GIS : Need a better way to deploy
With growing interest in Agile GIS development, this might be a good time to suggest how ESRI could make Agile easier. Since the Agile Manifesto demands frequent deliveries of working software, ease of deployment becomes more important. Below is a suggestion to make ArcGIS desktop more Agile by making it more like ArcGIS Explorer.
I really like how ArcGIS Explorer custom tasks can be installed by end users without Admin privs. Details are here. This capability is Agile friendly. With Desktop however, I don’t see an easy way to build installation packages that don’t require Admin privs for installation. Since many sites I work with require someone from the IT department (with Admin privs) to come install software updates, things can really slow down, especially around the holidays.
While it would be possible to write an ArcMap extension that discovers and loads extensions from .NET assemblies in a manner similar to ArcGIS Explorer, loading commandbars is problematic. Last time I checked, accessing IDocument.Commandbars inside of IExtension.Startup crashes arcmap. Extensions really need to all be loaded before commandbars since the commands on the commandbars often expect extensions to be loaded. So while I could have an extension that loads other extensions via Reflection, Activator.CreateInstance, and IExtensionManagerAdmin.AddExtension, I don’t see a way to do this for command bars.
The crux of the problem seems to be exclusive reliance on COM Categories for discovery of customized components. It would be great if ArcMap would also scan special file folders at startup. These folders would be named similar to the COM Categories, e.g. ESRI Mx Commandbars. Arcmap would then use Reflection to instantiate these objects at startup. I guess we might need some metadata telling it which classes I want registered, or maybe it would be OK if there is no metadata just assume that if a class implements IToolBardef, then it should get loaded.
How do we prevent someone from replacing our assemblies with malicious ones? I’m not clear if/how ArcGIS Explorer accomplishes this, but we should probably think about it. I guess strong naming could be used.
The Memory Leak 
Hi Kirk,
I think the answer to the problem with malicious code is using strongly typed assemblies.
Thank You,
Vish
http://viswaug.wordpress.com
Kirk,
Great post. I think you’re right about the reliance on COM categories. Generally, there’s too much registry manipulation involved with deploying and ArcGIS customization.
I’d be surprised if there’s a change for 9.3 but I think a native .Net ArcGIS desktop at 10.0 would go a long way toward fixing this issue.
Bill
Kirk,
Great post! Although most of my work has been deployed into Citrix envrionments, I can certainly see the issue.
One option we’ve used in the past which may be a partial solution is to have a dynamic command bar. On the first release of your package, the admin user would have to register the commandbar on the end user’s system. But after that, the commandbar can use reflection or whatever you want to actually populate itself. In our situation we built secured commands which were exposed to the user based on their credentials (checked with AzMan). There was a database of tools which contained their progid, and we could just spin them up from there (I’d have to check to see exactly how we created them). The only wrinkle was that the assemblies needed to be in ArcGIS/bin or the GAC.
Cheers,
Dave
@vish
Yes, I see now AGX uses strong names to prevent malicious dlls from being loaded.
@Bill
Yes, now that you mention it the whole issue of how to migrate apps from COM to .NET and how to replace COM categories must be something faced by other apps, not just ESRI’s. I’ve never seen any other app that leverages COM categories to the extent that ArcGIS does.
@Dave
I like the database approach you outline. Currently the same toolbars show up regardless of what mxd a user opens, based on what’s in the Normal.mxt. This is not always desireable. I’ve always felt there needs to be an optional way to bypass the Normal.mxt, and show only the toolbars that were visible when the mxd was last saved. Your database approach seems like another useful option, potentially allowing central administration of GUIs. I guess at some point ESRI will need to catch up with the new MS Office way of doing things they will revisit the role of the Normal.mxt, and hopefully make deployment easier, maybe even allowing ClickOnce deployment. http://msdn2.microsoft.com/en-us/library/t71a733d(VS.80).aspx
Regards, Kirk
Feature Analyst (FA) is a product that does just what you are suggesting. (www.vls-inc.com)
Once FA is installed on your machine, you can create plugins using the FA API. These are then dropped in a special plugins folder.
When ArcGIS loads up – FA is loaded as an extension. FA then goes through the known plugin folders and loads those plugins. The plugins can contain commands, menus and toolbars.
In addition, one of the coolest features of the FA API is that once you have written a plugin for FA, it will be available in any of the platforms that you buy FA for. (This includes ERDAS Imagine, GeoMedia, SocetSet – to name a few).
One thing I forgot to mention – is that the plugins you write – have to be written against the Feature Analyst API.
Come to think of it, I did a similar thing for one of my customers. We used an config file to dynamically load commands into an existing CommandBar. I had forgotten about that. We also included a dynamic “property page” tool that could be used to configure each of the commands.
@Raj –
Thanks for the info. Is FA able to load dockable windows based on plugin info without COM Category registration?
@Bill –
Property pages… that reminds me of another area that a plugin architecture described by something like FA would have a hard time with. Suppose you had a custom layerextension, odds are you’d like to see a propertypage for it when the user right clicks on it in the TOC and chooses “Properties…”. If its not in the ESRI Layer Property Pages category, it won’t be considered. I guess they don’t call the interface ICOMPropertypage for nothing.
Kirk
I just remembered, that there is a way to add commandbars at startup by setting a listener to IDocumentEvents and then adding a new commandbar when OnNewDocument or OnOpenDocument fires. Could be done by looping through each IItemDef in the IToolbarDef and calling IToolbarDef.GetIteminfo, then Activator.CreateInstance using the uid. This is a pain though, and still there’s not a similar thing for property pages, dockable windows, etc.
@Kirk
In our case, we did a custom property page implementation. Each command on the CommandBar may have been written by a different developer and needed its own settings. Rather than clutter the CommandBar with each command and a corresponding configuration tool, we had a command that popped up a configuration dialog. On the left hand side, it listed the commands that had registered property pages. If you clicked that tool name, displayed the assicated property page on the right and you could save your settings.
I used a Windows API call to plaster each property page into the dialog (we had VB6 and .NET property pages displaying). So this one wasn’t a property page implementation in the most orthodox sense of the term. But you’re correct; if you do it by the book, you have to use a COM interface.