2

I am currently trying to build an ESRI Addin that supports multiple versions of ArcGIS (10.0 & 10.1). The project targets .net framework 3.5 and is built in the ArcGIS 10 environment. The referenced ESRI dlls are set to specific version false. The addin works correctly within both versions of ArcGIS.

With the addin we are also shipping geoprocessing tools created in the .net environment (KBFunctionFactory & IGPFunction2). The tool builds and functions correctly within the different versions of ArcGIS (once registered with ESRIRegAsm). However, when background processing is turned on the tool returns error “000816: The tool is invalid”

Looking in to the error it suggested that it could be related to 64 bit processing. I have experimented with building the dll for 64 bit but it makes no difference, the same error still occurs. I do not currently have 64 bit processing installed and to keep things simple let’s assume I am not looking to support 64 bit processing.

Edit: when compiling the dll any CPU following the above article and trying to register on the 10.1 machine it fails to create the registry file. No error, esriregasm.exe just says it failed. Creating the reg file on the 10.0 machine and adding this to the 64 bit registry does not work either.

I have tested building the dlls on a 10.1 machine with the .net 3.5 framework and the tool functions fine in 10.1. It does therefore not seem to be related to the .net 3.5 framework. As the tool works in foreground mode it would seem that it is not an ArcObjects version issue.

My questions are:

  1. Should it be possible to create a .net geoprocessing object to target multiple versions of ArcGIS 10 with background processing?
  2. What in the background processing framework makes the tool invalid when moving from 10.0 to 10.1?
  3. If it is not possible to target multiple versions how using ArcObjects could I disable background processing on the tool? See for example the “ESRI Metadata Translator” which runs in the foreground even if background processing is enabled

EDIT: Thanks to all that helped answer, in particular @KHibma. In review to these questions:

  1. ESRI say this is not supported here. Our research seems to find that everything works so far except background processing
  2. I still don't have an answer to this. It does not work with either 32bit or 64bit processing so it does not seemed to be related to this.
  3. It is possible to disable background processing at 10.1 using the new interface. It is not possible to do this at 10.0
1
  • 1
    This is a very technical question specific to ESRI, you are likely to get a better response if you post this question on the ESRI forum site
    – Hornbydd
    Commented Sep 5, 2013 at 9:43

2 Answers 2

3

I don't work enough with the SDK enough to tell you anything about 10.0 vs 10.1 and compiling.

I can tell you that the underlying architecture for background processing changed in between 10.0 and 10.1. However as far as I understand it, this change should not have had any impact on a custom tool. If your tool works in desktop (foreground), then it should work in background (32bit). The 816 error is fairly generic yes, but it basically means that the tool cannot be found/used (as you already know). Like I said, if the tool works in DT, it should work in BG. I've only ever seen 816 thrown in regards to "works in desktop, but fails in 64BIT- BG". Your best bet might be to contact TechSupport. They'll ask you to share your tool and see if it works for them.

To answer your third question, at 10.1 a new interface was added which allows you to force the tool to run in the foreground. You can read more about it here.

I realize you said you aren't going to worry about 64-bit BG right now but you found the right KB article which explains how to register your tool for 64bit. Because you're referencing that I assume you're working with C# or VB, not C++. If you haven't seen it, theres a little bit of developer information regarding 32/64bit here.

EDIT: Small code fragment for IGPToolBackground

public class CopyFeaturesFunction : IGPFunction2, IGPToolBackground
{
    …… IGPFunction2 methods ….
    public bool CanRunInBackground
    {
        get
        {
            return true;
        }
        set
        {
            return;
        }
    }
 }
8
  • +1 Great info. I suppose you'd have whatever class is implementing IGpFunction2 to also implement IGpToolBackground? Commented Sep 5, 2013 at 16:11
  • @KirkKuykendall I added a small code fragment I found in my email to the answer, hopefully that explains what you're after?
    – KHibma
    Commented Sep 5, 2013 at 17:22
  • Thanks! I suppose if I have a legacy class that doesn't implement the interface that it's assumed it can be run in background? Commented Sep 5, 2013 at 17:25
  • 1
    You got it. If we could go back in time, there would be an argument to have done it the other way (foreground only, unless you specifically allow for the BG). But this is today, and this is what we got. :)
    – KHibma
    Commented Sep 5, 2013 at 18:02
  • 1
    My co-worker just made me aware of this topic, which says you need to re-compile, so it may just be lucky that it works in DT. resources.arcgis.com/en/help/arcobjects-net/conceptualhelp/#/…
    – KHibma
    Commented Sep 6, 2013 at 17:12
0

Background Processing is 64Bit; ArcMap/ArcCatalog are 32Bit and heavily COM/DCOM dependent. You are trying to create a tool that bridges these. Your best answer is is to stay centered on the ArcMap/ArcCatalog and not use the background tools; these are the direction/libraries ESRI is writing the software to use going forward but as you are supporting legacy applications you need to keep you eye on that scope.

You will really want to look at what you are writing in the long run; the new generation of ESRI software is going to be 64Bit only; and will not support backward components. While ESRI says ArcMap/ArcCatalog are not going away these will only function in the machines 32bit emulator; not utilizing the full capabilities of modern hardware.

You will find in the next year you really should look to the next generation very seriously as the WOW process in Windows actually is a huge performance hit.

3
  • 1
    Just to be picky on details, background processing is only 64bit if you've installed the 64bit background processing product. If you've only installed Desktop, background processing is indeed 32bit. When working with 32/64bit and Managed code, you'll need to build Any CPU and register with both products. If you're working in the C++ world you'll need to build DLLs for both products (bits)
    – KHibma
    Commented Sep 5, 2013 at 17:12
  • Yes, good point. The 32bit does have some background processing compared to the full tool they call Background Geoprocessing.
    – D.E.Wright
    Commented Sep 5, 2013 at 17:53
  • Thanks I have tried to support 64bit and have built for any CPU (it's .net). I was just trying to remove a variable for the question, as far as I can see if it works in foreground it should work in 32bit background Commented Sep 5, 2013 at 19:26

Not the answer you're looking for? Browse other questions tagged or ask your own question.