nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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

VytautasGipiskis

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

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

Find more posts tagged with

Map Authoring

Status: Open

Comments

MikeVolz

This would be a great help for python scripting if this was a parameter that could be read from the mxd properties.

DanelleMalget

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"

THanx!

TimLangner

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:
http://gis.stackexchange.com/questions/62090/arcpy-method-to-determine-arcmap-document-version

TimLangner

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.

ChrisWoodward1

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.

drewcole232_1-1663009865230.png

BenBaker1_0-1663010581576.png

MikeVolz

Chris:

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.

PhilLarkin1

Still no response from ESRI. Unbelievable.

RandyKreuziger

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.

JoshuaBixby

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.

JoshuaBixby

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 Stack Exchange . Since Esri packages oletools with their ArcMap Python distributions, you should be able to run the code in the bottom response as is.

NiekGoorman1

This should simply be shown under the Map Document Properties - it's unbelievable that this was never added despite repeated calls for it over so many years.

BrittanyBurson

This would be really useful information, in my case for map packages but any desktop item would apply. For now I seem to only be able to find this by attempting to open the package and encountering the error, which isn't great from a technical support stance. We have several versions of Pro in use across our organization.

JillHeyser

Or at a minimum, arcpy.mp.LayerFile and any other layer sensitive operation should fail gracefully when in inappropriate version is encountered.