Réponse courte: D'après mon expérience, il ne devrait y avoir absolument aucun problème à développer du code basé sur .NET 3.5 pour ArcGIS 9.3 dans Visual Studio 2010 (avec le langage C # version 4), tant que vous ciblez explicitement le .NET Framework 3.5. La version du langage C # est généralement hors de propos ici.
PS: Cette réponse n'entre pas dans les différences qui existent entre le développement d'une extension ArcGIS pour les versions 9.3 et 10. (ESRI a apporté quelques modifications majeures au modèle de complément, mais je suppose que vous en êtes conscient .)
Réponse plus longue: vous devez faire la distinction entre la version du langage C # et la version Framework ciblée.
Vous pouvez considérer le .NET Framework comme étant composé de deux parties principales: le CLR (Common Language Runtime) et le BCL (Base Class Library). Le premier est la "machine virtuelle", tandis que le second est la bibliothèque de classes (contenant tous les types que vous pouvez rechercher sur MSDN).
Les cadres .NET 2 à 3.5 utilisent tous le même CLR (version 2), c'est-à-dire que l'environnement d'exécution n'a pas vraiment évolué. Mais ce qui a évolué, c'est la BCL. Si vous exécutez une application .NET 3.5 sur une machine .NET 2, le problème principal ne sera pas que le "bytecode" (CIL) sera incompatible (il ne le sera pas), mais que l'application puisse se référer et utiliser types qui n'étaient pas encore disponibles dans le .NET 2 BCL.
À présent, lorsque vous indiquez à Visual Studio 2010 de cibler le .NET Framework 3.5, il s'assurera que vous n'utiliserez pas les types BCL d'une version ultérieure du Framework. Il s'assurera également que le code généré par le compilateur C # ne nécessitera pas de fonctionnalités uniquement disponibles dans la version 4 de CLR.
La version en langage C # a très peu à voir avec tout cela. Ce que le compilateur C # fait vraiment pour prendre votre code source et le traduire dans un langage de programmation de niveau beaucoup plus bas appelé CIL (Common Intermediate Language). Certaines constructions de langage C # ne seront plus reconnaissables dans CIL: par exemple, yield returnet yield breakn'existent pas dans CIL. Ils sont simplement traduits en implémentations de l' IEnumerator<T>interface.
Pour résumer ceci: La version du langage C # devient hors de propos dès que votre code est compilé. Ce qui est important c'est ...
si la sortie CIL / "bytecode" est compatible avec le .NET Framework ciblé (si vous ciblez .NET 3.5, il sera compatible même avec .NET 2 pour les raisons mentionnées ci-dessus); et
si votre code fait référence à / utilise des types disponibles dans le framework cible.
Une exception notable (dans le sens où une construction de langage C # nécessite une version particulière du framework; c'était le dernier cas où les génériques ont été introduits IIRC) pourrait être le mot-clé C # dynamic. Il peut être compilé en code qui nécessite des types de l' System.Dynamicespace de noms, qui n'est disponible que depuis .NET 4. Mais ne vous inquiétez pas: si vous avez configuré votre projet Visual Studio 2010 pour cibler le .NET 3.5, vous devriez obtenir un erreur du compilateur si vous essayez d'utiliser des éléments qui ne sont pas disponibles ou compatibles avec cette version particulière de .NET Framework.