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.