In this topic
About the different deployment options
There are 3 types of deployment mechanisms that can be utilized by developers and end users when working with add-ins. As a developer you are at a stage in the development cycle that you are ready to deploy your add-in for local testing purposes or to share it with the users in your organization or broader GIS community. The first method of deployment, and probably the most relevant for Java developers, will look at how Eclipse is used to deploy extensions.
Using Eclipse to deploy
The ESRI provided plug-in for Eclipse are used to help you build and develop your add-ins. Once the projects are completed, you are ready to test or share your ArcGIS Desktop customizations with others. This phase of the development cycle is also supported with the Eclipse plug-in. The following will show you how to use the add-in editor in Eclipse to help deploy your add-in:
The first method of deployment described in the preceding document fits into a pull mechanism model for deployment. The pull mechanism means that you, as the developer, will export the add-in and, by default, Eclipse will deploy it to a well known location. In this scenario, you make the decision to deploy and consume the add-ins. The well known location is significant because all ArcGIS Desktop applications monitor this location and automatically install the add-in. Each desktop application knows which add-in applies to itself and will only consume those add-ins. As seen in the documentation, you can change this default location when your intention is to create a deployable add-in for sharing purposes. In this scenario your end user can make a decision to install or ignore the add-in.
Using double-click deployment
The second mechanism, double-click deployment, assumes that you already have a .esriaddin file from another colleague, e-mail, file share, and so on. This mechanism is user friendly and will likely not be used by a developer unless they are attempting to consume an add-in. The following documentation will look at the double-click deployment method in greater detail:
The second method of deployment also fits into a pull mechanism model. Either you or your end users can make the decision to install the customization or not. When versioning is discussed, you or a user will also be able to decide if they want the update an existing add-in.
Using the add-in manager
The third mechanism, Add-In Manager, like the double-click deployment method, assumes that you already have an .esriaddin file available. The Add-In manager can be used to setup a file share location that is used by a given ArcGIS Desktop application when scanning for .esriaddin files. In addition, the Add-In Manager can be used to uninstall add-ins from the application. This approach to deployment has a number of considerations and they are discussed in greater detail in the following documentation:
The third method of deployment fits into a push mechanism model. Since the Add-In Manager can add shared file locations to monitor, desktop applications will automatically consume any add-in that is pushed to that shared location without the permission of an end user. The new well known location can be used by a developer to push new add-ins or versions. This approach is advantageous if the add-in is consumed by a large number of individuals in an organization.
| Development licensing | Deployment licensing |
|---|---|
| ArcView | ArcView |
| ArcEditor | ArcEditor |
| ArcInfo | ArcInfo |