Versión de C # para ArcObjects 9.3

10

¿Puedo usar C # 4.0 con el marco de destino establecido en .NET 3.5 para desarrollar una extensión para ArcMap 9.3? ¿O tiene que ser C # 3.0 o anterior?

arcobjects arcmap c# .net Mike Rogers
fuente
Si el framework de destino 3.5 está utilizando C # 2.0 con extensiones. ArcEngine 10 necesita apuntar a .NET 3.5 para que te pierdas algunos extras 4.0. Quería usar un control de calendario wpf en mi aplicación, pero no pude porque es 4.0. Así que tuve que usar el winforms uno.
patrick
Estaba usando C # 4.0 para desarrollar una extensión para ArcMap 10 con el marco de destino establecido en 3.5, así que me preguntaba si sería compatible con versiones anteriores mientras el marco permaneciera 3.5. ¿Debo cambiar mi extensión ArcMap 10 a C # 2.0 para que se pueda volver a compilar con ArcMap 9 sin tener que hacer muchas ediciones de código? ¿C # 3.0 funcionará con ArcMap 9?
Mike Rogers

Respuestas:

13

Respuesta corta: en mi experiencia, no debería haber ningún problema para desarrollar código basado en .NET 3.5 para ArcGIS 9.3 en Visual Studio 2010 (con lenguaje C # versión 4), siempre y cuando se dirija explícitamente a .NET Framework 3.5. La versión del lenguaje C # es principalmente irrelevante aquí.

PD: Esta respuesta no entra en las diferencias que existen entre el desarrollo de una extensión ArcGIS para las versiones 9.3 y 10. (ESRI ha realizado bastantes cambios importantes en el modelo de complemento, pero supongo que está al tanto de eso .)

Respuesta más larga: debe distinguir entre la versión del lenguaje C # y la versión de Framework específica.

Puede pensar que .NET Framework se compone de dos partes principales: CLR (Common Language Runtime) y BCL (Base Class Library). La primera es la "máquina virtual", mientras que la segunda es la biblioteca de clases (que contiene todos los tipos que puede buscar en MSDN).

.NET Frameworks 2 hasta 3.5 todos usan el mismo CLR (versión 2), es decir, el entorno de ejecución realmente no ha evolucionado. Lo que ha evolucionado, sin embargo, es el BCL. Si está ejecutando una aplicación .NET 3.5 en una máquina .NET 2, el problema principal no será que el "bytecode" (CIL) sea incompatible (no lo hará), sino que la aplicación podría hacer referencia y usar tipos que aún no estaban disponibles en .NET 2 BCL.

Ahora, cuando le dice a Visual Studio 2010 que apunte a .NET Framework 3.5, se asegurará de que no usará tipos BCL de ninguna versión posterior de Framework. También se asegurará de que el código generado por el compilador de C # no requiera características solo disponibles en la versión 4 de CLR.

La versión del lenguaje C # tiene muy poco que ver con todo esto. Lo que realmente hace el compilador de C # es tomar su código fuente y traducirlo a un lenguaje de programación de nivel mucho más bajo llamado CIL (lenguaje intermedio común). Ciertas construcciones de lenguaje C # ya no serán reconocibles en CIL: por ejemplo, yield returny yield breakno existen en CIL. Simplemente se traducen a implementaciones de la IEnumerator<T>interfaz.

Para resumir esto: la versión del lenguaje C # se vuelve irrelevante tan pronto como se compila su código. Lo que es importante es ...

  • si la salida CIL / "bytecode" es compatible con .NET Framework específico (si apunta a .NET 3.5, será compatible incluso con .NET 2 por los motivos mencionados anteriormente); y

  • si su código hace referencia / utiliza los tipos que están disponibles en el marco de destino.

Una excepción notable (en el sentido de que una construcción de lenguaje C # requiere una versión particular del marco; este fue el último caso cuando se introdujeron los genéricos IIRC) podría ser la palabra clave C # dynamic. Puede compilarse en un código que requiere tipos del System.Dynamicespacio de nombres, que solo está disponible desde .NET 4. Pero no se preocupe: si ha configurado su proyecto de Visual Studio 2010 para apuntar a .NET 3.5, debería obtener un error del compilador si está tratando de usar cosas que no están disponibles o que no son compatibles con esa versión particular de .NET Framework.

stakx
fuente
1
@SeaJunk, esto no es del todo correcto. Incluso si puede no haber una extensión del SDK de ESRI para ArcGIS 9.3 / VS2010, esto no le impedirá hacer referencia a los ensamblados de ArcGIS y comenzar a escribir código. Es decir, todavía es posible usar ese IDE, solo que más incómodo. También podría haber algo más de trabajo manual (registrar componentes, etc.) pero, de nuevo, es factible AFAIK.
stakx
Sí, lo siento, solo busqué eso :)
SeaJunk
Proporcionó una buena explicación, pero las relaciones son un poco más complejas, ya que las características de los tres (CLR, BCL y C #) están fuertemente influenciadas entre sí.
Petr Krebs
Como nota al margen, también hay algunos datos divertidos muy interesantes sobre la evolución de CLR y C #. Por ejemplo, la covarianza y la contravarianza en los parámetros de tipo genérico se introdujeron en CLR 2.0, pero no fue hasta C # 4 cuando comenzó a ser compatible con el lenguaje. Otro, por cierto, un gran ejemplo de su punto: LINQ, introducido en C # 3, se basa en métodos de extensión, que se pueden simular en C # 2 con el uso de System.Runtime.CompilerServices.ExtensionAttribute.
Petr Krebs
1
El blog de Eric Lippert ( blogs.msdn.com/b/ericlippert ) es un recurso maravilloso en varios rincones oscuros de .NET / C # y las decisiones detrás de su diseño.
Petr Krebs