In this topic
- About the different deployment options
About the different deployment options
There are three 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 geographic information system (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-ins 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 for Desktop customizations with others. This phase of the development cycle is also supported with the Eclipse plug-in. For more information about using the add-in editor in Eclipse to deploy your add-in, see How to deploy an add-in from Eclipse.
The first method of deployment (described in the previously referenced How to deploy an add-in from Eclipse), fits into a pull mechanism model for deployment. The pull mechanism means that you, as the developer, exports the add-in and by default, Eclipse deploys 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 for Desktop applications monitor this location and automatically installs the add-in. Each desktop application knows which add-in applies to itself and only consumes those add-ins. As seen in this topic, 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. For more information about double-click deployment, see How to use double-click deployment.
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 to 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 set up a file share location that is used by a given ArcGIS for 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 How to deploy using the Add-In Manager.
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 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|
|ArcGIS for Desktop Basic||ArcGIS for Desktop Basic|
|ArcGIS for Desktop Standard||ArcGIS for Desktop Standard|
|ArcGIS for Desktop Advanced||ArcGIS for Desktop Advanced|