Instead, the add-in dlls are zipped up and placed in a known folder.
#Arcgis vs qgis windows#
The categories of add-ins is much smaller, and discovery doesn't rely on the windows registry.
#Arcgis vs qgis 64 Bit#
Then again maybe with 64 bit this won't matter.Īt 10.0 Esri introduced Add-ins. That way when arcmap starts it could avoid relocation by loading into those addresses.
If so, once a user has arcmap running with the dlls loaded that he will typically use he could run a routine that would write the dll base addresses to a config file. Still, I wonder if a config file could be created instructing where the dll should be loaded into memory. Since there are so many dlls of different sizes being loaded knowing this ahead of time for an ArcObjects customization would be very difficult. When you create a dll in Visual Studio there is a place where you can specify the base address for the dll to load into. I'm not sure what the relocation cost is, but it must be significant.Ĭ:\Program Files (x86)\ArcGIS\Desktop10.0\Bin\Categories.exe While this provides a very fine-grained level of customization, it also means that all these fine grains need to be discovered and loaded at run time. These categories also contain dog food - Esri uses them not only to discover 3rd party customizations, but also out of the box functionality.
The best way I've found to get a feel for ArcGIS extensibility is to take a look at Esri's COM component categories found in the registry.Įach category represents a place where users can register dlls containing classes that implement an Esri interface. Unfortunately there seems to be at least some tradeoffs between extensibility and performance. I'm not that familiar with QGIS, but I wonder how it compares with ArcGIS in terms of extensibility.
0 kommentar(er)
