Vishful thinking…

Deployment hassles with the ‘black box’ MXD file format

Posted in ArcGIS, ESRI by viswaug on July 18, 2009

The MXD file format has always remained a ‘black box’ with its proprietary binary file format which cannot be opened or modified without ArcMap / ArcCatalog / ArcObjects. It’s even got a voodoo doctor that magically treats all its ailments, the ‘MXD Doctor’ software utility. This is fine in the most of the desktop world where the user most probably has access to ArcMap / ArcCatalog. But in the world of server applications that use ArcGIS Server, it does become quite a hassle. The problem occurs during the deployment phase. During the development and the demo phase, we might have prepared the MXD file with all the layers referencing FeatureClasses in the development / demo  geodatabase. But when you move the MXD to the production environment, the layers should now be modified to reference the FeatureClasses from the production geodatabase. Well, to switch the FeatureClass data source reference for the layers in the MXD, you will need access to ArcMap / ArcCatalog. IMHO, I don’t believe that we should be installing ArcMap / ArcCatalog in the production server environment, especially for a reason like the one mentioned above. Installing a full-blown desktop GIS software on a server environment might not make the IT folks very happy and might open up / expose security vulnerabilities. Given the binary nature of the MXD file, I can’t open up the file in a text editor and switch the data sources. And AFAIK, I don’t believe that there is a tool / script that will help make the switch of the data sources without the need for ArcMAP / ArcCatalog. Also, it is not just the MXD file format, the other ESRI file format like ‘.sde’ and ‘.gds’ etc all are in a binary format which makes deployment more painful that it should really be.

15 Responses

Subscribe to comments with RSS.

  1. Rachel said, on July 18, 2009 at 4:56 pm

    MXD Path editor?
    http://webhelp.esri.com/arcgisserver/9.3.1/java/index.htm#unix_mxd_editor.htm
    You also get it when you install Engine Java.
    not sure if there is a .net version – i don’t think so, but you should be able to make your own very quickly in .NET, a little .net windows forms app that uses the arcobjects installed as part of the SOC dlls.
    But yeah, not like the good ol 3.x days, open in notepad, change the paths.

  2. STH said, on July 18, 2009 at 7:32 pm

    Thats the beauty of ESRI and all other big corporations trying to “protect” their product.

  3. TonyB said, on July 19, 2009 at 9:25 pm

    All you need are the esri .net assemblies and then write a script to update the links.

  4. Shane said, on July 20, 2009 at 2:02 am

    I feel your pain. It also hurts when you have required password changes to the spatial database. Each layer in the MXD has to be updated with the new password. Sure, you can crank out AO code to make the changes as was suggested. However, this seems like a lot of hoops to jump through to satisfy something so common. A xml version of the mxd would be nice.

  5. SephiB said, on July 20, 2009 at 6:03 am

    I guess they are trying to get the need for additional ArcGIS Desktop licenses! the AGS price is not high enough…

  6. mapbutcher said, on July 20, 2009 at 10:47 am

    http://mapbutcher.com/blog/?p=57

    The new MSD format (zipped XML) goes some way to dealing with what appears to be a nice bit of vendor lock in.

    • Anastasia Aourik said, on September 16, 2009 at 5:03 pm

      I’ve looked at the zip that is the MSD file and I don’t see anything that will help globallly updateg the DATASOURCE of all layers from one sde server to another.

      I agree Vish in that the binary nature of all these interelated dependency files makes it difficult to deploy and maintain when passwords change.

      Perhaps some master mxd web.config file is in order….

      Does anyone know if ESRI 9.4 will address these issues?

  7. Andrew said, on August 5, 2009 at 1:38 am

    A workaround for modifying the source of a map document layers’ is to break the relative paths of the map document by coping the mdx to some other folder. This action will break the source to the layers in the mdx, and then provide an oppurtunitity for the user to mass repair the broken map layers. From there, repair the broken map layers to point at the target SDE geodatabase. The mdx is now set to point at the target database and can be deployed in the target environment assuming that the target environment uses the same credentials to access the SDE geodabase.

  8. MXD Pah update « said, on August 8, 2009 at 4:18 pm

    […] Pah update By iamlaksh1 Many times  I have faced same problem as described in this post. During application deployment phase of we may need to change all the data-source path to prod […]

  9. MXD Path update « said, on August 8, 2009 at 4:23 pm

    […] Path update By iamlaksh1 Many times  I have faced same problem as described in this post. During application deployment phase of we may need to change all the data-source path to prod […]

  10. Eric said, on September 29, 2009 at 10:54 pm

    We get around the problem at work by creating SQL Server Aliases to the development databases on our dev machines and build our maps against those aliases. In production we create identical aliases pointing to the production database. This way the MXDs think they are talking to the same database no matter where they are hosted.

    Of coarse this solution relies on using SQL Server for your database. Other databases may have a similar concept though.

    • viswaug said, on September 29, 2009 at 10:58 pm

      Cool. That seems like a great way to tackle part of the issue. Will definitely try to use it in my projects. Thanks for the tip.

      Thank You,
      Vish

  11. MRB said, on October 27, 2009 at 9:41 pm

    I think the SQL Server alias solution will only if the datasets are identical in each of the servers. However, if the datasets are different, say 6 months behind in production, from developemnt then this threoy will not hold. Is this true or am I missing something? Please help as we are laso in need of repointing all our datasets (ArcSDE) when we move from one database server to the next.

  12. MRB said, on October 27, 2009 at 9:42 pm

    I think the SQL Server alias solution will only work if the datasets are identical in each of the servers. However, if the datasets are different, say 6 months behind in production, from developemnt then this threoy will not hold. Is this true or am I missing something? Please help as we are laso in need of repointing all our datasets (ArcSDE) when we move from one database server to the next.

    • Eric said, on November 8, 2009 at 2:30 am

      @MRB The SDE database on each SQL Server instance needs to have the same name and unfortunately (and this is the part of this solution I don’t like) a user with the same name and password on each. However, the datasets within do not need to be identical as long as they are not radically different from each other (the dev MXD references a feature class that doesn’t exist on the prod database). The age of the data should not matter.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: