Implementar archivos DLL de ArcObject .NET

8

Estoy usando varias DLL de ESRI .NET en algunos scripts de Python personalizados. Por ejemplo ESRI.ArcGIS.Geodatabase.dll

En mi máquina de desarrollo, estas DLL se encuentran en la carpeta C: \ Archivos de programa (x86) \ ArcGIS \ DeveloperKit10.0 \ DotNet .

Ahora deseo implementar los scripts en otra máquina. Sin embargo, a menos que el usuario tenga instalado ArcObjects SDK for .NET, estas DLL faltan en su máquina.

Peor aún, solicitar que el usuario instale el SDK significa que también necesita instalar Visual Studio, que es una descarga de 600 MB (para la versión Express gratuita). Si no tienen Visual Studio, el instalador de ESRI no continuará.

Entonces, ¿deberían estas DLL estar agrupadas con los scripts (que pueden causar problemas de compatibilidad si se agregan paquetes de servicio), o hay un método de implementación más fácil?

Actualización :

Las DLL de .NET ahora están instaladas por defecto en la versión 10 de ArcGIS. Se colocan en el GAC (Caché de la Asamblea Global). Puede verlos en el Explorador de Windows (en Windows 7) en C:\Windows\assembly(no es realmente una carpeta, pero puede ver lo que está en el GAC). Mirar las propiedades del ensamblaje indica que la DLL debe estar en una carpeta como, C:\Windows\assembly\GAC_32\ESRI.ArcGIS.System\10.0.0.0__8fc3cc631e44ad86\ESRI.ArcGIS.System.dllpero este archivo no parece existir.

Python para .NET parece requerir ahora que use el nombre completo al agregar una referencia a estas DLL. Mirando su código fuente, parece que anteriormente usó LoadWithPartialName para que antes pueda usar el código a continuación. Esto ahora devuelve una excepción FileNotFound.

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

Ahora parece que necesita usar lo siguiente:

import clr
clr.AddReference("ESRI.ArcGIS.System, Version=10.0.0.0, Culture=neutral, PublicKeyToken=8fc3cc631e44ad86")
from ESRI.ArcGIS.System import *
arcobjects installation geographika
fuente

Respuestas:

3

No necesita implementar las DLL de ArcObjects en absoluto. Se instalan en el GAC, lo cual es cierto tanto para los ensamblados clásicos de .NET como para los PIA de ArcObjects.

Petr Krebs
fuente
1
¿Se instalan los PIA en el GAC cuando instala ArcGIS Desktop 10? ¿O solo cuando instalas el SDK? Supongo que los complementos .NET no funcionarían sin ellos, por lo que debe serlo cuando se instala Desktop. Confuso debido a cómo lo manejaron en 9.3: tuvo que instalarlo con ".NET Support" para obtener los PIA.
blah238
1
Sí, a las 10, siempre se instalan con ArcGIS Desktop sin necesidad de especificarlos durante la instalación.
Petr Krebs
1
SDK instala un conjunto adicional de los mismos ensamblados en su propio directorio para que se pueda hacer referencia a ellos de manera más conveniente en Visual Studio. Sin embargo, en tiempo de ejecución, su código generalmente carga los ensamblajes instalados en GAC, a menos que anule explícitamente este comportamiento en el archivo de configuración .NET de la aplicación, por ejemplo, ArcMap.exe.config.
Petr Krebs
Gracias petr. Después de buscar en Python documentos .Net, los ensamblajes en el GAC deberían estar disponibles para cargarse en Python, sin embargo, parece que todavía no puedo acceder a ellos; lo investigaré más y actualizaré cuando descubra por qué.
geographika
4

En 9.x, podría instalar ArcGIS con soporte .NET, que IIRC incluía .NET PIA, sin embargo , en 10.0 debe instalar el SDK: http://support.esri.com/en/knowledgebase/techarticles/detail/34178 - Consulte la respuesta de @ Petr , los PIA de .NET se instalan en el GAC cuando instala ArcGIS Desktop 10 .

De acuerdo con esta página , Visual Studio no necesita instalar ArcObjects 10 SDK, pero eso NO es correcto ya que el instalador se niega a continuar sin un VS IDE compatible instalado.

Si usa comtypes , podría usar los OLB COM en lugar de los PIA .NET. Por supuesto, aún tendría que instalar comtypes o implementarlo con su script (no estoy seguro de cómo hacerlo, pero creo que se puede hacer), pero eliminaría la dependencia del ensamblado .NET.

Ver también preguntas relacionadas:

blah238
fuente
Establece allí: ArcGIS Desktop, ArcGIS Engine Runtime o ArcGIS Server es necesario para desarrollar con ArcObjects SDK. También debe tener instalado Microsoft .NET Framework 3.5 SP1. Entonces, si el desarrollo está hecho, no necesita el VS, supongo, pero aún necesita implementar el SDK
Hairy
La combinación de .NET y Python está funcionando perfectamente, por lo que detesta pasar a los tipos. Lamentablemente, el instalador del SDK se niega a continuar a menos que VS esté en la máquina.
geographika
@geographika no puede instalar el SDK sin VS en la máquina. Una forma de resolver esto, si ha comprado el SDK, es crear una aplicación 'ficticia' y migrar los dlls dentro de la aplicación ficticia, luego implementarla en el servidor, para que estén registrados. Entonces utilízalos así.
Peludo
Confirmado. La documentación de ArcGIS indica que no se requiere en ciertas páginas. Pero el instalador del SDK NO PASARÁ sin Visual Studio 2008 Express o Visual Studio 2010 premium / ult / test / professional.
Dexter
3

No puede agrupar los archivos dll, ya que va en contra de su acuerdo de licencia y recientemente se pusieron muy nerviosos al respecto. Necesita instalar AGS 10 .NET o ArcObjects 10 .NET SDK y, obviamente, Visual Studio.

Acabamos de tener nuestros propios problemas en torno al mismo problema. Habíamos desplegado una caja de herramientas .NET en un servidor Java AGS 10, con los dlls cerrados. Funcionó de maravilla, hasta que nos dijeron que violaba nuestro acuerdo de licencia y que tendríamos que comprar los otros componentes o enfrentar las consecuencias.

Apesta, pero oye, ho. Significa 2 licencias AGS 10 para ellos, así que alguien feliz ...

Peludo
fuente
Gracias por la respuesta. Para aclarar, el usuario tiene una copia con licencia del escritorio de ArcGIS en su máquina, pero no el SDK o Visual Studio. ¿No hay ninguna opción para instalar las DLL sin una descarga de Visual Studio de 600 MB que nunca se utilizará?
geographika
aparentemente no. Creo que ha cambiado últimamente. No está permitido desplegar los dlls en absoluto, ni siquiera un poco; la instalación de la aplicación que creas, no puede contener los dlls
Hairy
Hay una diferencia entre implementar los dll de tiempo de ejecución necesarios para ejecutar ArcGIS (bin / gac) y los ensamblados de interoperabilidad necesarios para desarrollar personalizaciones de .net para ellos (directorio dotnet). Póngase en contacto con Esri para obtener aclaraciones sobre lo que puede y no puede implementar en este caso.
SeaJunk
Si crea una aplicación AO .NET, debe tener los dlls relevantes, incluidos en la implementación, si no hay ArcObjects .NET SDK en el servidor de implementación, simplemente tiene que hacerlo para que se ejecute. Va en contra de sus condiciones de licencia agrupar los dlls. Período. Sé esto, de hecho, ya que lo hemos encontrado y ahora tenemos que migrar los servicios .NET a los servicios Java, para que podamos ejecutarlos, dentro del marco de licencias, en nuestra instancia de servidor ArcGIS 10 para Java
Hairy
@Peludo; no, no necesita agrupar / implementar las DLL con su código. Si construye su extensión correctamente, su código funcionará con las DLL instaladas por GAC desde su software ESRI instalado y no debería tener ningún problema. La clave es usar las DLL para hacer referencia correctamente, como hacer que su archivo web / app.config haga referencia a la versión de GAC en lugar de una copia de compilación local de las bibliotecas apropiadas.
DEWright
0

¿Por qué no usar ArcGIS Engine Runtime ? Es el tiempo de ejecución para las aplicaciones independientes de ArcGIS / ArcObjects. Si no está utilizando ningún elemento de la IU de escritorio en sus scripts, ¿debería funcionar?

MathiasWestin
fuente
Esto también es una infracción de licencia, si está utilizando las DLL sin una interfaz de usuario en un tipo de aplicación de 'Servicio', entonces debe tener una licencia de AGS Server. Anteriormente le había preguntado a ESRI sobre el uso de un motor para implementar una aplicación, pero como la aplicación general era un servicio, necesitaba licenciar AGS, no motor.
DEWright