Version C # pour ArcObjects 9.3

10

Puis-je utiliser C # 4.0 avec le framework cible défini sur .NET 3.5 pour développer une extension pour ArcMap 9.3? Ou doit-il être C # 3.0 ou antérieur?

Mike Rogers
la source
Si le framework cible 3.5, vous utilisez C # 2.0 avec des extensions. ArcEngine 10 doit cibler .NET 3.5 pour que vous passiez à côté de quelques goodies 4.0. Je voulais utiliser un contrôle de calendrier wpf dans mon application, mais je ne pouvais pas parce que c'était 4.0. J'ai donc dû utiliser celui des winforms.
patrick
J'utilisais C # 4.0 pour développer une extension pour ArcMap 10 avec le cadre cible défini sur 3.5, donc je me demandais s'il serait rétrocompatible tant que le cadre restait 3.5. Dois-je changer mon extension ArcMap 10 en C # 2.0 afin qu'elle puisse être recompilée avec ArcMap 9 sans avoir à effectuer de nombreuses modifications de code? C # 3.0 fonctionnera-t-il avec ArcMap 9?
Mike Rogers

Réponses:

13

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.

stakx
la source
1
@SeaJunk, ce n'est pas tout à fait correct. Même s'il n'y a pas d'extension SDK ESRI pour ArcGIS 9.3 / VS2010, cela ne vous empêchera pas de référencer des assemblages ArcGIS et de commencer à écrire du code. Autrement dit, il est toujours possible d'utiliser cet IDE, mais plus inconfortable. Il pourrait également y avoir un peu plus de travail manuel impliqué (enregistrement des composants, etc.) mais encore une fois, c'est faisable AFAIK.
stakx
Oui, désolé, je viens de regarder ça :)
SeaJunk
Vous avez fourni une bonne explication, mais les relations sont un peu plus complexes, car les caractéristiques des trois (CLR, BCL et C #) sont fortement influencées les unes par les autres.
Petr Krebs
En passant, il y a aussi quelques faits amusants très intéressants sur l'évolution de CLR et C #. Par exemple, la covariance et la contravariance sur les paramètres de type générique ont été introduites dans CLR 2.0, mais ce n'est qu'en C # 4 qu'elle a commencé à être prise en charge par le langage. Un autre, accessoirement un excellent exemple de votre point: LINQ, introduit en C # 3, repose sur des méthodes d'extension, qui peuvent être simulées en C # 2 avec l'utilisation de System.Runtime.CompilerServices.ExtensionAttribute.
Petr Krebs
1
Le blog d'Eric Lippert ( blogs.msdn.com/b/ericlippert ) est une merveilleuse ressource sur divers coins sombres de .NET / C # et les décisions derrière leur conception.
Petr Krebs