Que signifie réellement cibler un framework et comment optimiser la compatibilité?
Salutations à tous,
Cela m'a confondu depuis que j'ai commencé à coder en C #. Mon objectif est de créer un assemblage qui s'exécutera sur le dernier framework .NET de l'utilisateur, quel qu'il soit. Je ne veux pas exiger l'installation de .NET 4, mais je veux l'utiliser si l'utilisateur l'a, et plus important encore, je veux qu'il fonctionne quand même si l'utilisateur a seulement .NET 4 et rien au dessous de. Je commence à penser que ce n'est même pas possible.
Je ne comprends pas vraiment ce que je sélectionne lorsque je change de "Framework cible" dans Visual Studio. Est-ce que cela signifie "sera compatible avec cette version et plus"? Ou "sera compatible uniquement avec cette version"? Il semble que ce soit la dernière jusqu'à présent. mes tests dans les machines virtuelles montrent que les assemblys ciblés .NET 4 échouent sans .NET 4 et que les assemblys ciblés .NET 3.5 échouent sans .NET 3.5. N'y a-t-il aucun moyen de régler cela afin que je puisse obtenir une compatibilité maximale?
MISE À JOUR: Pour clarifier, j'ai un programme qui cible .NET 2. Les affiches ici semblent indiquer qu'il devrait être chargé avec .NET 4. Mais dans un environnement avec seulement .NET 4 et rien avant, il ne se charge pas.
UPDATE2: OK, compris, mais c'est beaucoup plus complexe que ce que les affiches semblent penser. J'ouvre une question différente pour discuter des subtilités, mais la version courte est que vous avez besoin d'un app.config avec <supportedRuntime version="v4.0" /> pour pouvoir exécuter des assemblys non .NET 4 sur .NET 4. Ils ne se chargeront pas sans. il.
Les frameworks sont conçus pour être compatibles avec les versions antérieures. Si vous avez un programme écrit en .NET 2.0, vous pouvez l'exécuter dans le runtime 4.0, car aucun des frameworks n'a jamais supprimé les fonctionnalités d'une version précédente (c'est pourquoi nous avons toujours des collections non génériques comme ArrayList, même si ils sont déconseillés au profit des collections génériques). Cependant, l'inverse n'est pas nécessairement vrai; une application 4.0 n'est pas garantie pour fonctionner en 2.0, car elle PEUT tirer parti des nouvelles fonctionnalités du nouveau moteur d'exécution qui ne sont pas disponibles dans les versions précédentes. Dans tous les cas, si vous souhaitez que votre application tente de s'exécuter sur des versions d'exécution non ciblées, vous devez l'indiquer dans le fichier app.config à l'aide d'éléments SupportedRuntime.
Pour répondre à votre question spécifique, vous pouvez faire ce que vous voulez avec la procédure de base suivante:
Développez votre application pour cibler la version du framework EARLIEST que vous souhaitez prendre en charge. Cela désactivera l'accès aux nouvelles fonctionnalités des exécutions plus récentes (telles que Linq dans 3.5 et le typage dynamique dans 4.0), garantissant ainsi que votre application n'exigera aucune fonctionnalité qui ne puisse être fournie par aucune des exécutions prises en charge.
Spécifiez les infrastructures acceptables pour votre application à l'aide de l'élément SupportedRuntime dans votre fichier app.config. Cela indiquera au code natif qui initialise le moteur d'exécution dans lequel votre application s'exécutera que si elle ne trouve pas la version ciblée, toutes les autres sont acceptables. Je pense que le comportement consiste à rechercher d'abord le framework ciblé, et s'il n'est pas disponible, il devrait utiliser le dernier runtime pris en charge.
.NET est compatible avec les versions antérieures. Cela signifie que si vous sélectionnez .NET Framework 2.0 comme infrastructure cible, il fonctionnera sous les versions 2.0, 3.0, 3.5 et 4.0 installées. Mais si vous sélectionnez, par exemple, la version 4.0 comme infrastructure cible, il ne fonctionnera que si la version 4.0 est installée.
Je crois ceci est supposé être quelle que soit la version que vous choisissez et plus. Ainsi, si vous ciblez le cadre 2.0, cela devrait fonctionner si le client dispose de cadres 2.0, 3.0, 3.5 ou 4.0 installés.
Vous sélectionnez également des fonctionnalités linguistiques lorsque vous sélectionnez cette option. Par conséquent, je ne vois absolument pas comment vous pourriez utiliser les fonctionnalités du framework 4.0 à l'aide d'un framework de ciblage d'applications 2.0. Même le chargement dynamique d'assemblys ne fonctionne pas, essayez de charger une dll compilée en 4.0 à partir d'une application 2.0, elle ne vous le permettra pas.
Voici comment fonctionne le ciblage: Si vous ciblez .NET 3.5, il ne s'exécutera pas si l'utilisateur ne dispose pas de .NET 3.5. Il fonctionnera si l'utilisateur a une version plus récente.
Pour une compatibilité maximale, choisissez .NET 2.0, il fonctionnera même sur .NET 3.5, 4.0 et ainsi de suite.
Cependant, vous pourriez perdre de nouvelles fonctionnalités de .NET telles que LINQ, etc.
http://msdn.Microsoft.com/en-us/library/bb398197(VS.100).aspx
Puis-je quand même cibler .NET Framework 2.0 dans VisualStudio 2010?