Take the 2-minute tour ×
Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. It's 100% free, no registration required.

I am using several ESRI .NET DLLs in some custom Python scripts. For example ESRI.ArcGIS.Geodatabase.dll

On my development machine these DLLs are in the C:\Program Files (x86)\ArcGIS\DeveloperKit10.0\DotNet folder.

Now I wish to deploy the scripts to another machine. However unless the user has the ArcObjects SDK for .NET installed these DLLs are missing from their machine.

Even worse, requesting that the user install the SDK, means they also need to install Visual Studio, which is a 600MB download (for the free Express version). If they don't have Visual Studio the ESRI installer won't continue.

So should these DLLs be bundled up with the scripts (which may cause compatibility issues if service packs are added), or is there an easier deployment method?

Update:

The .NET DLLs are now installed by default in version 10 of ArcGIS. They are placed in the GAC (Global Assembly Cache). You can see them in Windows Explorer (in Windows 7) in C:\Windows\assembly (not really a folder, but you can view what is in the GAC). Looking at the assembly properties indicates the DLL should be in a folder such as C:\Windows\assembly\GAC_32\ESRI.ArcGIS.System\10.0.0.0__8fc3cc631e44ad86\ESRI.ArcGIS.System.dll but this file does not seem to exist.

Python for .NET seems to now require you use the full name when adding a reference to these DLLs. Looking at its sourcecode it looks like it previously used LoadWithPartialName so you before you could use the code below. This now returns a FileNotFound exception.

import clr
clr.AddReference("ESRI.ArcGIS.System")
from ESRI.ArcGIS.System import *

Now it seems you need to use the following:

import clr
clr.AddReference("ESRI.ArcGIS.System, Version=10.0.0.0, Culture=neutral, PublicKeyToken=8fc3cc631e44ad86")
from ESRI.ArcGIS.System import *
share|improve this question
add comment

4 Answers

up vote 3 down vote accepted

You do not need to deploy ArcObjects DLLs at all. They are installed in the GAC, which is true for both classic .NET assemblies as well as ArcObjects PIAs.

share|improve this answer
1  
Are the PIAs installed in the GAC when you install ArcGIS Desktop 10? Or only when you install the SDK? I guess .NET add-ins wouldn't work without them so it must be when Desktop is installed. Confusing because of how they handled it in 9.3 -- you had to install it with ".NET Support" to get the PIAs. –  blah238 Dec 20 '11 at 23:59
1  
Yes, at 10, they are always installed with ArcGIS Desktop without any need specify them during installation. –  Petr Krebs Dec 21 '11 at 9:37
1  
SDK installs additional set of the same assemblies into its own directory so that they can be more conveniently referenced in Visual Studio. At runtime though, your code typically loads the GAC-installed assemblies, unless you explicitly override this behavior in the application .NET configuration file, e.g. ArcMap.exe.config. –  Petr Krebs Dec 21 '11 at 9:42
    
Thanks Petr. After looking through the Python for .Net docs, the assemblies in the GAC should be available to load into Python, however I can't seem to access them still - I will look into it further and update when I've found out why. –  geographika Dec 21 '11 at 16:28
add comment

In 9.x, you could install ArcGIS with .NET support which IIRC included the .NET PIAs, however in 10.0 you have to install the SDK: http://support.esri.com/en/knowledgebase/techarticles/detail/34178 -- See @Petr's answer, the .NET PIAs are installed into the GAC when you install ArcGIS Desktop 10.

According to this page, Visual Studio is not required to install the ArcObjects 10 SDK -- but that's NOT correct as the installer refuses to continue without a supported VS IDE installed.

If you use comtypes you could use the COM OLBs instead of the .NET PIAs. Of course you would still have to install comtypes or deploy it with your script (not sure how but I think it can be done), but it would eliminate the .NET assembly dependency.

See also related questions:

share|improve this answer
    
It states in there: ArcGIS Desktop, ArcGIS Engine Runtime or ArcGIS Server is required to develop with the ArcObjects SDK. You also have to have the Microsoft .NET Framework 3.5 SP1 installed. SO if the development is done, you dont need the VS I guess, but you still need to deploy the SDK –  Hairy Dec 14 '11 at 11:44
    
The mix of .NET and Python is working perfectly, so I'm loathe to move to comtypes. Unfortunately the SDK installer refuses to continue unless VS is on the machine. –  geographika Dec 14 '11 at 11:52
    
@geographika you cannot install the SDK without VS on the machine. A way aound this, if you have bought the SDK, is to create a 'dummy' app and migrate the dlls within the dummy app, then deploy it to the server, so they are registered. Then utilise them like that. –  Hairy Dec 15 '11 at 7:49
    
Confirmed. ArcGIS documentation states it is not required in certain pages. But the SDK installer WILL NOT GO THROUGH without Visual Studio 2008 Express, or Visual Studio 2010 premium/ult/test/professional. –  Dexter Aug 17 '12 at 18:34
add comment

You cannot bundle up the dll's as it is against your licensing agreement and they've recently got very sniffy about it. You either need to install AGS 10 .NET, or ArcObjects 10 .NET SDK, and, obviously, Visual Studio.

We've just had our own issues around the very same issue. We had deployed a .NET toolbox on an AGS 10 Java server, with the dlls wrapped up. Worked a treat, until we were told it breached our licencing agreement and we'd have to buy the other components or face the consequences.

It kind of stinks, but hey ho. Means 2 AGS 10 licenses for them, so someones happy...

share|improve this answer
    
Thanks for the answer. To clarify the user has a licensed copy of ArcGIS desktop on their machine, but not the SDK or Visual Studio. Is there no option to install the DLLs without a 600MB Visual Studio download which will never be used? –  geographika Dec 14 '11 at 9:40
    
apparently not. I believe it changed lately. You are not allowed to deploy the dlls at all, not even slightly; the installation of the app you build, cannot contain the dlls –  Hairy Dec 14 '11 at 11:43
    
There's a difference between deploying the runtime dll's required to run ArcGIS (bin/gac) and the interop assemblies required to develop .net customizations for it (dotnet dir). Contact Esri for clarification on what you can and cant deploy in this case. –  SeaJunk Dec 14 '11 at 20:57
    
If you build an AO .NET application, you have to have the relevant dlls, bundled with it at deployment, if there is no ArcObjects .NET SDK on the deployment server, you simply have to, in order to get it to execute. It is against your licensing conditions to bundle the dlls. Period. I know this, as fact, as we have come across it and are now having to migrate the .NET services, to Java services, so we can run them, within the licensing framework, on our ArcGIS 10 for Java server instance –  Hairy Dec 15 '11 at 7:47
    
@Hairy; no you don't need to bundle/deploy the DLLs with your code. If you build your extension correctly you code will function with the GAC installed DLLs from your ESRI installed software and you should not have any problems. They key is using the DLLs to reference properly, like having your web/app.config file reference the GAC version instead of a local build copy of the appropriate libraries. –  D.E.Wright Dec 18 '11 at 21:24
show 2 more comments

Why not use the ArcGIS Engine Runtime? It's the runtime for standalone ArcGIS/ArcObjects applications. If your not using any Desktop UI stuff in your scripts it should work?

share|improve this answer
    
This is a license violation as well, if you are using the DLLs without a UI in a 'Service' type of application then you must be license AGS Server. I had previously asked ESRI about using a Engine to deploy a application but since the overall APP was a Sevice I needed to license AGS, not Engine. –  D.E.Wright Dec 18 '11 at 21:20
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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