Quelle est la meilleure façon de cibler plusieurs versions de la .NET framework?

Je suis en train de construire une bibliothèque de classe et je vais déployer un package NuGet, ce qui me permet de choisir différentes assemblées être ajoutés comme des références basées sur l' .NET framework version du projet, il est ajouté. C'est une fonctionnalité très intéressante, mais ce que je me pose est de savoir si il est possible d'avoir un seul projet de bibliothèque de classes, et de le construire à l'encontre de plusieurs versions de la .NET framework?

Je préfère éviter d'avoir:

MyLibrary40.dll et MyLibrary45.dll

si possible, parce que les deux projets auraient à partager beaucoup de code. La version 4.5 offrira async fonctions, qui est de 4,5 fonctionnalité.

Personne ne sait quelle est la meilleure approche pour ce qui est? Puis-je utiliser plusieurs configurations de build? Ou dois-je aller en bas de l'autre projet de route?

Si je travaillais en C++, je serais probablement utiliser plusieurs configurations et #if blocs autour les fonctions qui ne sont pris en charge dans une configuration, mais j'ai peur que cela conduirait à m'avoir deux assemblées du même nom, qui font des choses différentes.

Merci d'avance!

Si vous souhaitez cibler les différentes versions, dans une assemblée?
c'est la meilleure façon d'obtenir BadImageException 🙂
Mais, j'ai trouvé un travail autour de la compilation, vous pouvez regarder les liens que j'ai mis dans ma question, ils peuvent vous aider dans votre voyage - stackoverflow.com/questions/15549011/...
Je veux avoir un fichier de projet, mais être en mesure de produire deux assemblées, l'une qui prend en charge .NET 4.0 et un que soutient .NET 4.5 et ajoute quelques async fonctions sans avoir à créer des projets distincts..
J'ai demandé à ce aussi, non stricte de la réponse a été donnée, peut-être que vous aurez de meilleures réponses que j'ai eu, ce que vous avez besoin est le gestionnaire de configuration.. stackoverflow.com/questions/15321757/...
cela peut aider aussi stackoverflow.com/questions/5006397/...
Je crois que vous aurez des problèmes si vous essayez de compiler le code en tant 4.0, qui a 4.5 mots-clés / les appels de méthode qui n'existent pas.
vous pouvez le faire, en suivant les liens que j'ai fournis, MAIS ce n'est pas sûr, une fois que vous en bas de l'exécution, il va avoir une mauvaise image d'exception ou de toute autre exception lors de l'appel de l'4.5 fonctionnement
Mon point est qu'il n'a même pas de compiler si vous essayez d'utiliser le même projet pour plusieurs assemblées. Si vous essayez de compiler le programme suivant avec 4.0 - il échouera. la classe Program { static void main(string[] args) { DoStuff(); } private static async void DoStuff() { int mavaleur = attendent GetStuff(); } private static async Task<int> GetStuff() { attendent Tâche.Delay(5000); return 0; } }
Si vous compilez à la version supérieure, puis essayez de la redirection convenu il va exploser au moment de l'exécution. Ma recommandation serait d'avoir plusieurs projets ou de ne pas utiliser le 4.5 caractéristiques.
Merci à tous pour les commentaires, je suis allé avec la solution ci-dessous!
C'est ce que la compilation conditionnelle devrait être utilisé pour.

InformationsquelleAutor Dave Kerr | 2013-07-17

.net c#visual-studio-2012

37

Vous aurez au moins besoin d'un VisualStudio Solution avec 2 projets (un pour .net 4 et un pour .net 4.5).

Ajouter tous les codefiles à l' .net 4-projet et dans l'autre projet que vous ajoutez le code des fichiers en tant que lien (utiliser "Add Existing Item..."-Dialogue et a choisi Add as link)

Vous pouvez maintenant ajouter tous les codes et toutes les classes pour .NET 4.5 à votre 4.5-projet.

De plus, vous devez définir vos propres commutateurs du compilateur (symboles de compilation conditionnelle) pour vos projets. Comme NET4 pour votre .net 4-projet et NET4.5 votre .net 4.5-projet)

Vous réglez les commutateurs dans les paramètres du projet en vertu de Build->Général>Compilation Conditionnelle Commutateurs

Dans votre code, vous pouvez utiliser les commutateurs comme suit pour générer du code .NET 4 ou .NET 4.5
```
#if NET4
  //code only for .NET 4
#endif

//code for all framework versions.

#if NET45
  //code only for .NET 4.5
#endif
```
- Merci beaucoup, c'est en effet la façon dont je suis allé. J'ai un .NET Framework 4.5 Bibliothèque de Classe appelé 'JsonClient" et il a toutes les fonctionnalités. L' .NET 4.0 version est appelée "JsonClientLite" et comprend exactement le même code, mais au lieu d'utiliser la compilation conditionnelle, j'ai un fichier distinct pour chaque classe avec des méthodes Asynchrones (j'ai donc JsonClient.cs à la fois, JsonClientAsync.cs seulement dans le principal) - je utiliser des raccourcis pour les fichiers dans le .NET 4.0, comme vous l'avez décrit. Je suis heureux avec la façon dont cela fonctionne, il semble un moyen propre à faire - je vous remercie beaucoup pour votre réponse!
- J'ai écrit github.com/CADbloke/CodeLinker pour résoudre ce - qu'il remplit un nouveau projet avec des éléments à partir d'un projet existant.
InformationsquelleAutor Jehof
15

Une approche simple consiste à ajouter un autre .csproj fichier dans le même dossier, et de le configurer pour construire un cadre de référence différent de la version. Cela évite d'avoir à ajouter des liens vers des fichiers, comme les deux projets sont essentiellement vues au cours de la même structure de dossier.

Dire que vous avez la structure:
```
- MyLibrary\
  - MyLibrary.sln
  - MyLibrary\
    - MyLibrary.csproj
    - Program.cs
```
Double MyLibrary.csproj dans le même dossier et modifier pour modifier un peu les choses:
- <ProjectGuid> juste faire un nouveau GUID pour cette valeur de l'élément de
- <TargetFrameworkVersion> spécifier la version alternative ici, par exemple: v4.5 ou v3.5
- <OutputPath> (pour Debug et Release) définir un chemin d'accès unique, comme bin\Debug\net45 et bin\Debug\net45, pour permettre la sortie de chaque projet à la fin dans un emplacement unique
Vous devez également ajouter un nouvel élément à la non-conditionnelle <PropertyGroup> élément, de sorte que les deux projets n'entrent pas en collision dans le obj dossier pendant des constructions parallèles. C'est important, et protège contre bizarre condition de course de bugs.
```
<PropertyGroup>
  <BaseIntermediateOutputPath>obj\net45\</BaseIntermediateOutputPath>
```
Enfin, ajouter ce nouveau projet à votre solution existante.

Cette approche fonctionne main dans la main avec la définition de la compilation commutateurs comme NET35 et NET45, et à l'aide de #if NET35 /#endif directives.

Deux projets open source qui utilisent cette technique sont MetadataExtractor et NetMQ. Vous pouvez les consulter dans le cas où vous frappez la difficulté.
- Est la réponse par @DrewNoakes encore du chemin à faire si vous utilisez Visual Studio 2015? Ou y at-il de meilleures façons de faire cela de nos jours? Je me demandais
- - Je l'utiliser dans Visual Studio 2015. Cependant, une fois la xproj/projet.json trucs terres, qui va probablement être une meilleure façon de cibler de multiples plates-formes.
- Merci pour la réponse rapide... je vais garder cela à l'esprit.
- "Double MyLibrary.csproj dans le même dossier": cela sonne étrangement comme si toutes les modifications (ajout de fichiers) à un .csproj fichier devra être fait manuellement dans l'autre, ainsi (?), ce qui sonne comme un plutôt enclin à l'erreur d'approche.
- yep, ce n'est pas parfait. Si vous avez de la chance, un projet échouera à construire. Sinon vous risquez de manquer d'un fichier. Cependant, dans certains cas, vous devrez peut-être vous fournir une cale de classe pour quelque chose qui est absente dans une version cible. Si vous connaissez une meilleure solution, je suis preneuse.
- Si vous ajoutez des fichiers à l'aide de la accepté de répondre à vous encore faudra penser à le lien de l'une des autres projets.
- C'est en quelque sorte corriger, mais je ne serais probablement toujours préférable d'exclure de la contenu du fichier déclarer la cale de la classe par le biais de la compilation conditionnelle plutôt que de différents fichiers de projet pour les différentes versions cibles.
- En effet, l'on a accepté la réponse ne fournit aucun avantage à cet égard.
- Si votre projet utilise les packages NuGet pour les dépendances cela provoque un conflit avec les packages.fichier de configuration (puisqu'il contient une référence à la version de votre projet, des besoins, et il ne peut pas avoir un autre nom en plus de " packages.config'). Je ne peux pas dire si ce sera la cause de tous les problèmes, mais parce que d'un package NuGet restauration va toujours tirer vers le bas toutes les versions disponibles.
InformationsquelleAutor Drew Noakes
5

Une vieille question, je sais, et ce n'était pas une réponse appropriée à l'époque... mais maintenant, il est possible d'utiliser un Projet Partagé, qui est logiquement le même que l'ajout d'un projet en tant que lien plutôt que chaque fichier individuellement.
- Bonne idée, mais il a beaucoup de limites, la plus évidente étant votre bibliothèque de classe ne peut pas référence à quelque chose qui n'est pas aussi un Projet Partagé. Ce qui est logique, je suppose, mais jusqu'à ce que chaque package NuGet est un Projet Partagé, probablement pas utile dans la plupart des circonstances.
- Hmm, pas sûr de ce que vous réfère ici. Je peux créer une bibliothèque partagée Une et une bibliothèque de classe B qui fait référence à Un et Newtonsoft package NuGet. Je peux ensuite écrire le code à l'intérieur d'Un qui utilise par exemple JObject. Cela est vrai dans VS2015 ainsi que VS2017
InformationsquelleAutor Stephen Drew

Vous devez vous connecter pour publier un commentaire.