How do you build and ArcObjects stand alone application to run on ArcGIS 10.0, 10.1, and 10.2 without rebuilding for each version?

5812
9
07-13-2015 02:28 PM
Toddfrisvold1
New Contributor II

I have an ArcObjects 10.0 VB.Net stand alone application I built and want to install on various ArcGIS system at different release levels, 10.0, 10.1, 10.2, ... I am able to compile on each version and run only on that version but I would like to compile once and be able to install and run on all versions. When I run on a version (10.2) not matching the compiled version (10.0), I get an error: Error encountered in frmMain.Load #53 - Could not load file or assembly 'ESRI.ArcGIS.Version, Version=10.0.0.0, Culture=neutral, PublicKeyToken=8fc3cc631e44ad86' or one of its dependencies. The system cannot find the file specified."

I have tried compiling on 10.0, 10.1, and 10.2 and I get the similar error (just change the message to Version=10.0.0.0 or Version=10.1.0.0 or Version 10.2.0.0) when I run on a different version.

I looked at the ArcGIS 10.2 ESRIRegsm.exe.config file and it looks like there is an attempt to map older version requests to the latest installed version:

<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">

  <dependentAssembly>

    <assemblyIdentity name="ESRI.ArcGIS.Version" culture="" publicKeyToken="8fc3cc631e44ad86"/>

    <bindingRedirect oldVersion="9.3.0.0-10.1.0.0" newVersion="10.2.0.0"/>

  </dependentAssembly>

</assemblyBinding>

But that does not appear to be working???

Is it possible to compile once and run it on all version of the major release (ie 10.X)? If so, can you send me some instructions on how to do this?

Tags (2)
9 Replies
FreddieGibson
Occasional Contributor III

As far as I know ArcObjects applications are version specific and need to compiled at each release. The only supported forward compatible option would be to leverage the Add-Ins framework.

For what you're trying to do have you tried setting the Copy Local property of the ArcObjects dlls to True and the Specific Version property to False? I haven't tested this recently, but I believe I was able to get this to work in the past.

Toddfrisvold1
New Contributor II

Freddie,

Thanks for the reply.  As you can see, I did get the Local Copy=True and Specific Version=False to work... but this requires me to release the ESRI Assemblies/DLL's with my installation package and I thought this was against ESRI licensing rules???  This solution as you proposed or doing a separate installation for each version of ArcGIS supported with Local Copy=False are the only options I have working so far.

Is the ESRIRegAsm.exe.config redirect from older versions to the latest version supposed to work???  I would have guessed that would have been the solution to redirect my 10.0.0.0 requests to the newer 10.1.0.0 or 10.2.0.0 installed assemblies???

Todd

0 Kudos
FreddieGibson
Occasional Contributor III

Hi Todd,

From what I've always been taught the ArcObjects SDK is rather limited on this topic. The only supported way to accomplish your task would be to build an application for each version of the software and require that your clients install the version that matches their environment.

I honestly understand how frustrating this can be because I often find myself testing applications ranging from 9.3.X to 10.3.X in both Windows and Linux environments. As a result of ArcGIS Desktop not supporting side by side installs I typically have to manage 4 or more machines. The hack I mentioned earlier is an un-supported workflow I sometimes implement when I need to quickly test a simple application prior to compiling it at each release and moving it to production. I'm not sure of the legal implications of this workflow if you were to implement it on a production application.

The only ArcObjects functionality that would provide the flexibility in forward compatibility you're needing would be the Add-Ins framework. The catch would be that this would require that your logic be executed in an ArcGIS Desktop application (i.e. ArcMap, ArcCatalog, ArcScene, ArcGlobe). Would it be possible for you to migrate to the Add-Ins framework or does your business requirements require that you have a standalone application?

If you do require a standalone application have you ever considered migrating to the ArcGIS for Runtime APIs? They would allow you to build applications that aren't stuck to a particular version of Desktop and don't require the massive footprint needed by the ArcGIS Desktop or ArcGIS Engine installs.

Toddfrisvold1
New Contributor II

An Add-In architecture would not work for this application, it is a data extraction application that runs in a few modes:

1) nightly after the reconciling and Posting and cleanup activity in a batch mode

2) On demand in a command line mode

3) Interactively in a GUI mode (This one would be ok as an Add-In)

Also, This process does change detection using versions and does full object extraction including internal edge/junction connectivity.

This process might be a candidate for the ArcGIS Runtime APIs but I have not verified the complete geodatabase internals are available through that API (connectivity down to the edge/junction level), I will need to investigate that further.

I still do not understand why my application calls to the ESRI assemblies that are newer than the assemblies I compiled against would not be redirected.  Nobody has been able to answer my question about why the redirects are defined in the ESRIRegAsm.exe.config file if they don't actually work????  Can you or anyone else answer this??

And my next question is why is it against the license agreement to distribute the .DLL files if the end user still needs to have a valid license to run them???  Shouldn't ESRI allow ArcObjects developers to package the DLLs with their released install packages because they still will required a license to run???

So... unless someone can instruct me on how to compile an ArcObjects stand alone application to run on the compiled version of ArcGIS and newer, I will be forced to build install packages for all ArcGIS releases my customers expect to run this application on (10.0, 10.1, 10.2, 10.3).

0 Kudos
PaulDavidson1
Occasional Contributor III

Hey Freddy:

If I can insert a comment here....

You mentioned maintaining 4 machines (or more) for dealing with all the ArcGIS versions you need to support.

Have you considered the Virtual world?

We use VMware to setup each environment as needed.

Much easier than hardware.

And then look at using Vagrant for spinning up the work environments.

I'm still working on that piece of the puzzle but it looks to be quite helpful.

Cheers

0 Kudos
Toddfrisvold1
New Contributor II

I have run four tests I ran:

Test 1)  I build my application on ArcGIS 10.2 with DLL's excluded and installed on the ArcGIS 10.2 system and it did find the global assemblies from the ArcGIS 10.2 installation and all ran fine.

Test 2) I build my application on ArcGIS 10.0 with DLL's excluded and installed on the ArcGIS 10.0 system and it did find the global assemblies from the ArcGIS 10. installation and all ran fine.

Test 3) I build my application on ArcGIS 10.0 with DLL's excluded and installed on both a ArcGIS 10.1 and an ArcGIS 10.2 system and on both systems my app did not find/redirect to the global assemblies from the ArcGIS 10.1/ArcGIS 10.2. installation and my app existed with the error message "Could not load file or assembly ESRI.ArcGis.Version, Version 10.0.0.0".

Test 4) I built my application on ArcGIS 10.0 with local DLL's included in the installation package (I know we are not supposed to do this, just testing) and installed it on both an ArcGIS 10.1 system and an ArcGIS 10.2 system and both ArcGIS 10.1 and ArcGIS 10.2 run well on the respective systems and my application ran well on both systems too. I assume my application was using the locally installed ArcGIS 10.0 DLLs from my app install package,  and the ArcGIS 10.1 and ArcGIS 10.2 system ran well using the global assemblies/DLLs installed by the ArcGIS 10.1 and ArcGIS 10.2 installations however I should not be releasing ESRI DLLs with my application.

So... if newer ArcGIS installations/assemblies (ie 10.1, 10.2, 10.3...)  are supposed to support/redirect applications/assembly requests written on older versions (ie 10.0), I need help making this happen. If this is supposed to be supported, we should be able to make my Test 3 above run.

Any ideas on how to make this work???  Is the intent by ESRI to support this???  If anyone has any ideas to solve this, let me know and I can test it.

0 Kudos
thejuskambi
Occasional Contributor III

Have you tried to install 10.2 version on 10.0 & 10.1? Any results.

0 Kudos
Toddfrisvold1
New Contributor II

yes... and if I don't include the DLL's with my installation... I can not get the app to run on a system with a mismatched ArcGIS installed, either a newer version or an older version as you suggested.

0 Kudos
JeroenTicheler
New Contributor

Hi Todd, I know this is an old thread, but did you manage to resolve the issue? I am running in the same problem and also would like to only build two versions of our application (one for AG 10.1-10.3 and one for 10.4-10.6, because of the difference in .NET framework).

I can get it to work for the extension itself, but when I try to run it in standalone mode (as a CLI application) I receive the dreaded message "Could not load file or assembly ...".

0 Kudos