Backward compatibility of 10.2 ArcMap AddIns with ArcMap 10.1

5229
15
Jump to solution
01-16-2014 07:28 AM
Highlighted
New Contributor III
Hi all,

are there any experiences with ArcMap AddIns built in Version 10.2 to be used in an ArcMap 10.1 installation?

We plan to upgrade to Win8 / Visual Studio 2012. But as I learned from the system requirements, 2012 is only supported with ArcGIS 10.2.

We still have to support several 10.1 installations, which probably won't be upgraded so soon. What's the recommended solution?

Thanks in advance
Fossi
Reply
0 Kudos
1 Solution

Accepted Solutions
Highlighted
Regular Contributor
Back to the original question...

Addins are ArcGIS-version specific. A 10.2 compiled Addin won't work with 10.1, even if the underlying ArcObjects code is 10.1 compatible. It's also true vice-versa.

If you have clients running 10.1 you may need to keep an installation with ArcGIS 10.1 & Visual Studio 2008 or 2010 in order to develop new solutions for them.

View solution in original post

15 Replies
Highlighted
Regular Contributor
Speaking for the Java API, from 10.0 to 10.1 the esriLicenseProductCode constants changed.

from esriLicenseProductCodeArcInfo to esriProductCodeAdvanced

So if you are checking for licensing in your code, you might run into this.

Can't say it will change again in 10.2.  The Java docs for 10.2 point to the 10.1 publication.  I have no idea about the .NET API.

But then again, 10.2 "is" a 10.1 service pack, right?  Are they still calling it that?
Highlighted
Regular Contributor
What is different between the dot.dot release and a service pack?

I don't know how ESRI determines that.


It adds confusion when discussing software compatibly between Arc and other software packages (especially if other software follows a similar pattern of naming their versions)  ie. (some software package) Version 8 is compatible with Arc 10.0, Version 10 is compatible with Arc 10.1, and version 12 will be compatible with Arc 10.2.  I know compatibility matrices are helpful, but when talking about software with people who are not familiar with all the different versions it seems like unnecessary added confusion.  It also creates confusion when talking about compatibility between different pieces of ArcGIS software.

And also ArcView, ArcInfo, ArcGIS Desktop (Advanced).  Product name changes are just as hard to address with non-gis people because they think it's a different product altogether.

Wouldn't it be great if GIS software was a spec, like HTML.  And After HTML 5, the name just remains HTML, and all the new functionality just gets added to the spec.  And it's up to the implementers of the spec to make sure it gets added?  Wow...

Perhaps one day when ESRI becomes a full web platform, that might happen.  Kind of like functionality in ArcGIS Online, it just shows up and I don't have to upgrade anything.
Highlighted
Regular Contributor
Back to the original question...

Addins are ArcGIS-version specific. A 10.2 compiled Addin won't work with 10.1, even if the underlying ArcObjects code is 10.1 compatible. It's also true vice-versa.

If you have clients running 10.1 you may need to keep an installation with ArcGIS 10.1 & Visual Studio 2008 or 2010 in order to develop new solutions for them.

View solution in original post

Highlighted
Regular Contributor
Back to the original question...

Addins are ArcGIS-version specific. A 10.2 compiled Addin won't work with 10.1, even if the underlying ArcObjects code is 10.1 compatible. It's also true vice-versa.

Maybe in .NET, but in Java, I have an Add-in developed in 10.0 and it works fine in 10.2 with no code changes required.
Reply
0 Kudos
Highlighted
MVP Honored Contributor
Maybe in .NET, but in Java, I have an Add-in developed in 10.0 and it works fine in 10.2 with no code changes required.


I would have agreed with you last week, but I just came across an example where an Add-in I created in 10.0 didn't quite work on 10.2. I opened the project in 10.2, updated the references (but made no other code changes) and recompiled it. It then worked correctly in 10.2
Highlighted
Regular Contributor
Your Add-in was written in Java?

I just tested one today.  A customer has an old Add-in (Java) that I gave them two years ago.  I moved it to a 10.2 ArcMap to see what I needed to change and it works fine. 

Full disclosure, I am not doing anything version specific in this Add-in.  If I had been checking the license level, I would have had to recompile it to use the correct esriLicenseProductCode constant.

The Add-in edits a shapefile.
Reply
0 Kudos
Highlighted
MVP Honored Contributor
Your Add-in was written in Java?

I just tested one today.  A customer has an old Add-in (Java) that I gave them two years ago.  I moved it to a 10.2 ArcMap to see what I needed to change and it works fine. 

Full disclosure, I am not doing anything version specific in this Add-in.  If I had been checking the license level, I would have had to recompile it to use the correct esriLicenseProductCode constant.

The Add-in edits a shapefile.


This Add-in was in .NET. The problem it was having was writing output of a goeprocessing tool to a geodatabase. Once I changed the references, the output was created successfully.
Reply
0 Kudos
Highlighted
Regular Contributor
I think you and Mr. Neilsen are correct when it comes to .NET Add-ins because the references you add to your project are compiled to specific versions in Visual Studio.

I don't have, haven't had so far, this problem with Java.  Other than version specific changes to ArcObjects Java code that I mentioned regarding licensing constants.  I'm sure this will probably change now that the cat is out of the bag.

I'm not sure why more people aren't coding in Java in the ESRI platform. 

I thought about compiling a Top 10 Reasons to switch to Java for the New Year, but never got working on it.
Reply
0 Kudos
Highlighted
MVP Honored Contributor
I think you and Mr. Neilsen are correct when it comes to .NET Add-ins because the references you add to your project are compiled to specific versions in Visual Studio.

I don't have, haven't had so far, this problem with Java.  Other than version specific changes to ArcObjects Java code that I mentioned regarding licensing constants.  I'm sure this will probably change now that the cat is out of the bag.

I'm not sure why more people aren't coding in Java in the ESRI platform. 

I thought about compiling a Top 10 Reasons to switch to Java for the New Year, but never got working on it.


Have you tested whether anything you have written for 10.2 in Java is backwards compatible?
Reply
0 Kudos