Select to view content in your preferred language

ArcGIS Pro AddIn 3x Version Compatibility

1600
7
04-18-2023 02:07 PM
MichaelWen_Timmons
Occasional Contributor

I developed a Pro AddIn using Pro version 3.1. However when I try to run it on a machine with ArcGIS Pro 3.0 installed I got this error message: 'This add-in cannot be loaded because it targets an incompatible version of ArcGIS Pro. Current Version 3.0.   Add-in targets 3.1'

Is there a way to compile an AddIn that works across all Pro 3x versions?

0 Kudos
7 Replies
KrisCulin
Frequent Contributor

In your config.daml file, change your desktopVersion attribute to 3.0.  That should get it working.

 

Kris

0 Kudos
Wolf
by Esri Regular Contributor
Esri Regular Contributor

You should ONLY develop and test your add-in with the MINIMUM ArcGIS Pro version that your add-in targets.  So for example, if you develop with ArcGIS Pro version 3.1 your AddInInfo tag in the config.daml should only be reading like this:

 

<AddInInfo id="..." version="x.x" desktopVersion="3.1.41833">

 

You cannot simply change the desktopVersion attribute to 3.0 because the ArcGIS Pro API is enhanced with each release and new API classes, properties, and methods are ADDED to the API.  To maintain compatibility no API classes, properties, etc are removed with a new release, since that would break compatibility.  So if you develop under ArcGIS Pro 3.1 and use any property, class or method that was added with the 3.1 release and you set desktopVersion to 3.0, your add-in will not work with a ArcGIS Pro 3.0 desktop release.

See ProConcepts Advanced Topics · Esri/arcgis-pro-sdk Wiki (github.com)

MichaelWen_Timmons
Occasional Contributor

So if I want to create an .esriAddinX file that works for Pro 3.0 then I'll need to regress my Pro to 3.0 on the development machine? 

0 Kudos
Wolf
by Esri Regular Contributor
Esri Regular Contributor

That's recommended:  you develop using the same ArcGIS Pro version as your minimum target ArcGIS Pro version.  Needless to say, if you know for sure that you're not using any newly introduced 3.1 API enhancements, you can just set the desktopVersion to 3.0 and test your Add-in's functionalities on a 3.0 machine.  I actually do this quite often because i am always on the latest daily build (3.2.x now) and often i have to make a sample add-in for somebody on this forum who is still using 3.0 or 3.1.  But i also know what functionality we added in the latest releases.  If i have to make a sample for 2.9 or earlier i use a Virtual machine with an ArcGIS Pro 2.x environment. 

0 Kudos
MichaelWen_Timmons
Occasional Contributor

So we need 1 version of esriAddinX for each version of Pro 3.x that we support? That seems inconvenient. We were able to use the same file for all of Pro 2.x.

0 Kudos
Wolf
by Esri Regular Contributor
Esri Regular Contributor

Regarding:

"So we need 1 version of esriAddinX for each version of Pro 3.x that we support?"

Answer: No.

Regarding: 

"We were able to use the same file for all of Pro 2.x."

If by saying the 'same file' you mean the 'esriaddinx' file (resulting from a build), then the same rules apply for Pro 3.x as for Pro 2.x.

If you developed a 3.0 release of an Add-in using Pro 3.0 that Add-in (esriaddinx file) doesn't have to be rebuilt for all subsequent releases of 3.x.  You don't have to touch those Add-ins at all, they will work for all 3.x releases of ArcGIS Pro.

From your replies above i had assumed that you want to develop under a newer release of ArcGIS Pro (i.e. 3.1) and then deploy the esriaddinx on an older release (i.e. 3.0) then you might have a problem due to the reasons i stated above.

 

0 Kudos
TimSexton1
Frequent Contributor

We are finding this not to be true in regards to ArcGIS Pro maintained daml Ids.  We are seeing some of these ArcGIS Pro daml Ids change from 3.1 to 3.2.  This breaks compatibility if an addin was developed to target 3.1 that references an ArcGIS control by it's 3.1 daml Id when the addin is running on ArcGIS Pro 3.2 and has a different daml Id there.  Is there a better method to doing this other than relying on these daml Ids that seem to change randomly as Esri refactors them randomly between each release?  A good example of this is the 3.1 daml id "esri_fieldsview_commitButton" that in 3.2 is "esri_mapping_fieldsview_commitButton"

Tags (2)
0 Kudos