Select to view content in your preferred language

Show version of ArcGIS required to open LYR, MXD, or Layer package

03-29-2011 05:00 AM
Status: Open
Labels (1)
Esri Contributor

ArcGIS should automatically record version of ArcGIS required to open LYR, MXD, or Layer package in the File properties.

Now it's impossible to understand which version was used to create LYR, MXD, MPK, LPK file, and which version is required to open.

This would be a great help for python scripting if this was a parameter that could be read from the mxd properties.
It would be nice to be able to detect this information in python with a previous version to trap errors!! 

For example: I am working with 10.0 and trying to open and manipulate map documents. Currently I get a fatal error when trying to list the data frames in a map document that is 10.1 - nonetype object is not callable.

I supposed I can check for "None" to be returned on the arcpy.mapping.mapdocument(myfile) and trap for it, but I would like to be able to report back an informative error message to the user, instead of "Gee, I don't know what happened"

This would be very useful. Given it's never been comented on by ESRI I assume they have no wish to add it or there is a technical limiation with the MXD format which means they can't add it but don't wish to say their is a limiation.

They are the only reasons I can think of as to why this such useful feature has not been introduced. There may be others.

In the mean time there is a Python script which works for anyone using version 10.0 onwards:
Apologeis that should have read there and not their. Unforunately there is no way to delete comments on here or edit them. Also the Google Chrome browser spellchecker doesn't work and there doesn't seem to be an alternative supplied.
I would like this to be available within the parameters of a layerfile object independent of the MXD (that the layerfile may or may not be located within). Programatically testing for and using the arcpy mapping module saveACopy function to back-version 10.3 versions to 10.2 is my end-game. 


This is what I was looking for back from my comment in 2013, so maybe by 2021 this might get implemented.  But then again ArcGIS for Desktop mxds might be deprecated by then in favor or Pro anyway.


Still no response from ESRI. Unbelievable. 


I put in an enhancement request several years ago on this one but it's gone nowhere.  The use case we had for years is this.  We have people who collaborate on MXDs but not all users are running the same version of ArcMap. It would be extremely helpful if ArcMap could be setup to save an MXD back to it's version so that the MXD can be modified by users running a newer version of ArcMap and not create an MXD that can't be opened by the author. 

Where this really comes into play is when running a script to update SDE datasources on all MXDs recursively.  I ran into an issue earlier this year when the script I had written was run using 10.4.1.  A handful of our users are still at 10.2 but there was no way programmatically to determine that so I saved everything out at 10.4 version. That left MXDs at the wrong version for users of 10.2. 


Unbelievable?  For Esri, sadly, no.  The saddest part of all is how simple something like this would be to implement.  MXD files are just OLE files, which is the same nuts-and-bolts file format used by MS Word, Excel, and many others.  See my response to Randy below for an example on getting information outside of Esri products.


Randy, I hear ya, we operate in a multi-version environment and have for years.  It blows me away how Esri actually changes the file format with each release, I can't think of another company that does that.  Versions might change, but file formats typically span multiple software versions, at least for most companies.

Anyhow, moving on to an actual helpful comment, go check out arcgis 10.0 - Using ArcPy to determine ArcMap document version? - Geographic Information Systems Sta... .  Since Esri packages oletools with their ArcMap Python distributions, you should be able to run the code in the bottom response as is.