Quel .NET Framework et C # Version devrais-je cibler avec ma bibliothèque de classe?

Je le garderais à 2,0 que vous devez utiliser des fonctionnalités 3.0 ou 3.5.

Personnellement, je ciblerais .NET 2.0. Cela signifie, entre autres choses:

• pas de méthodes d'extension (il y a une solution de contournement)

• pas de linq

• Vous pouvez utiliser des expressions Lambda

• Vous pouvez utiliser le mot-clé "var"

  La chose est, vous pouvez utiliser des fonctionnalités de langue C # 3.x (le sucre syntaxique dite), mais vous ne pouvez pas utiliser de bibliothèques cible C # 3.x (System.core pour en nommer un, inclut des méthodes d'extension et LINQ).

  Je n'essaierais pas de supporter c # 1.x, car il est très différent de c # 2.x et plus élevé. En outre, je m'attends à ce que la plupart des gens qui utiliseraient votre bibliothèque sont des personnes qui construisent de nouvelles choses qui ne seraient pas dans leurs bons esprits utilisent C # 1.x; -)

Si je devais commencer un nouveau projet, j'utiliserais toujours le plus récent runtime! Si 3.5 est disponible, pourquoi aurais-je besoin de démarrer un projet en 2.0, ou 1.0 à moins que je ne savais qu'il y a quelque chose de sérieusement mal avec la nouvelle version? Les nouvelles versions signifient la fixation de vieux bugs et l'ajout de nouvelles fonctionnalités, c'est bien.

En ce qui concerne la mise à niveau de l'ancien projet vers une nouvelle version, vous devez prendre en compte vos gains et pertes. Si sa valeur en vaut, mettez-la, sinon de rester avec l'ancienne version.

Faites attention à soigner car de nouveaux outils pourraient ne pas prendre en charge les anciennes versions. Bien que ce ne soit pas le cas avec 2010 car il prendra en charge toute la version jusqu'à 2.0.

Essayez ceci:

Commutateur Mode de ciblage sur Framework 2.0 (suppression du système.Core référence).

S'il ne compile pas, essayez d'ajouter une référence à Linqbridge.dll :

Sinon, vous devriez cibler 3.5;)

Je vote pour la réponse d'Erik van Brakel. De plus, je voudrais suggérer que si vous souhaitez prendre en charge 3.5 fonctionnalités telles que LINQ et les méthodes d'extension, vous pouvez créer une bibliothèque supplémentaire, disons

mylibrary.dll

mylibrary.linq.dll

Utilisant donc la même approche que MS DID (quand ils ont quitté la version System.dll 2.0 mais ajouté toutes les nouvelles fonctionnalités dans System.Core.dll)

Je ciblerais la version 2.0 avec la bibliothèque contenant les fonctions principales et ajoutez une bibliothèque supplémentaire ciblant 3.5 pour ajouter des méthodes d'extension en fonction de votre bibliothèque principale.

De mon point de vue, si vous voulez un large éventail d'utilisateurs, vous devez le faire avec les premières versions, 1.1 sera bien, car il fonctionnera sur n'importe quelle machine a une nouvelle version.

Cela dépend de ce que la DLL est pour. Si cela dispose d'une logique C # générique que vous souhaitez mettre à la disposition des autres, alors .NET 2.0 est probablement votre meilleur choix. Toutefois, si cela a quelque chose à voir avec les fonctionnalités plus récentes dans .net, comme WPF, EF, WCF, Silverlight, ECT, alors il devra être dans la version de .NET qui prend en charge cette fonctionnalité particulière.

Personnellement, je dirais que je l'écrirais dans .NET 3.5 Seulement parce que faire le saut de .NET2.0 à .NET3.5 est assez indolore car il n'y a pas beaucoup de modifications de rupture contrairement au saut de .net1.x à .net2 .0. :)

Je ne pense pas que personne utilise .NET 1.1 plus. Donc, à moins que vous ne souhaitiez vraiment utiliser 3.5 Caractéristiques 2.0 devrait être bien. De plus, si vous avez le contrôle de qui va réellement utiliser votre bibliothèque, alors cela dépend aussi de eux. S'ils ont le dernier cadre, vous pouvez utiliser cela.

Nous ciblons plusieurs versions d'exécution simultanément (.NET 1.1, .NET 2.0 et .NET 3.5) pour certains produits.

Nous gérons cela de plusieurs manières: p>

• Solution séparée et fichiers de projet et pour chacun des .NET 1.1, 2.0 et 3.5 SP1, mais référençant les mêmes fichiers source. li> ul>

  EG: P>

  #if DEBUG_VERBOSE
    Logging.Log("Web service Called with parameters: param = " + param);
    Logging.Log("Web service Response: " + response); 
    Logging.Log("Current Cache Size (bytes): " + cache.TotalBytes); 
    // etc. 
  #endif 
  

  • définissant net_x_x code> symboles dans chacune des solutions p> li>

  • pour le code spécifique .NET Framework, nous utilisons des instructions de préprocesseur telles que ceci: p> li> ul> xxx pré>

    Pour clarification, les lignes ci-dessus commençant par # sont des commandes de préprocesseur. Lorsque vous compilez une solution, le compilateur C # (CSC) pré-traite les fichiers source. Si vous avez une instruction #IFDEF code>, SCC évaluera pour déterminer si ce symbole est défini - et dans l'affirmative, inclure les lignes dans ce segment lors de la compilation du projet. p>

    C'est un moyen de marquer le code pour compiler dans certaines conditions - nous l'utilisons également pour inclure des informations de débogage plus intensives dans des constructions de débogage verbeuse spécifiques, comme: P>

    public void SomeMethod(int param)
    {
    #ifdef NET_1_1
     // Need to use Helper to Get Foo under .NET 1.1
      Foo foo = Helper.GetFooByParam(param);
    #elseif NET_2_0 || NET_3_5
     // .NET 2.0 and above can use preferred  method. 
      var foo =  new Foo { Prop = param }; 
      foo.LoadByParam();  
    #endif 
      foo.Bar();
    }
    
    #ifdef NET_3_5
    // A method that is only available under .NET 3.5 
    public int[] GetWithFilter(Func Filter)
    { 
      // some code here
    }
    #endif 
    

    • Nous avons ensuite des scripts nant qui automatisent la production d'une version pour chaque version .NET. Nous contrôlons tout cela via TeamCity, mais nous pouvons également déclencher les scripts nant manuellement. Li> ul>

      Cela rend les choses plus compliquées, nous avons donc seulement tendance à le faire là où nous devons maintenir une instance legacy 1.1 ou 2.0 (par exemple, où un client ne peut pas / ne pas mettre à niveau). P>

      J'imagine que lorsque .NET 4.0 roule autour, nous ferons la même chose et il suffit d'ajouter un symbole net_4_0. p> p>

combiné à utiliser une approche comme celle mentionnée par Will Hughes, si vous souhaitez que l'accès / option utilise des fonctionnalités plus récentes lorsqu'il est disponible, lors du développement actif, utilisez le dernier cadre. Lorsqu'il est prêt à commencer à faire des candidats à la libération, défini sur le cadre le plus bas, puis lorsque les problèmes arrivent, heurtent régulièrement la version-cadre et / ou utilisent l'approche #Ifdef pour travailler.

Cette solution fonctionne assez bien. Je viens de configurer deux projets différents avec une "propriétés du projet-> bâtiments-> symboles de compilation conditionnelle" et utilisée dans le code comme ceci: xxx