Le multi-targeting de Visual Studio et les Services Packs

Bonjour,

Aujourd'hui je voudrais parler de Visual Studio 2008, du multi-targeting et des Services Packs du Framework .NET.

Comme vous le savez sûrement, Visual Studio 2008 vous permet de choisir une version cible du Framework .NET pour vos projets.
Ceci vous permet donc de développer des projets pour les Frameworks 2.0, 3.0 ou 3.5 à l'aide d'un même outil.

Cependant il pourrait être intéressant de savoir lors de vos développements si vous utilisez une classe, un type ou une méthode apporté(e) par un Service Pack du Framework .NET cible, et qui n'était donc pas présente dans la version RTM du Framework en question.

A première vue, on pourrait se demander pourquoi car il va de soi que tout bon développeur s'assure bien évidemment qu'il va déployer son application sur des machines ayant la même version du Framework .NET, avec le même Service Pack que la plateforme de développement.

Toutefois, cela se complique un peu avec le Framework .NET 3.5 Service Pack 1 qui installe le Service Pack 2 du Framework .NET 2.0.

En effet, ce Service Pack 2 n'est pas installable seul (pour le moment en tous cas, affaire à suivre...), il ne s'installe que par l'installation du SP1 du Framework .NET 3.5.

Voici au passage un rappel de là où nous en sommes des versions de Visual Studio et de CLR.

Imaginons alors une équipe de développement qui souhaite utiliser Visual Studio 2008 SP1 pour continuer à créer des applications .NET 2.0 SP1, car son parc de machines clientes n'est équipé que du Framework .NET 2.0 SP1, et que la migration vers le Framework .NET 3.5 SP1 n'est pas à l'ordre du jour.
Cette équipe risque alors de développer en utilisant des nouvelles fonctionnalités du Framework .NET SP2, alors que le parc ciblé n'en est qu'au SP1.
Si les développeurs utilisent une classe, un type ou une méthode apportée par le Service Pack 2, vous imaginez bien que des problèmes vont vite faire surface.

J'espère que vous m'avez suivi jusque là, sinon relisez le passage précédent au calme :o)

Afin d'éviter donc d'utiliser des fonctionnalités apportées par un Service Pack donné, vous pouvez utiliser l’outil d’analyse de code (Code Analysis).
Cet outil contient une règle afin de vous prévenir si vous utilisez une fonctionnalité qui ne sera pas présente sur les postes cibles car le niveau de service pack est différent. Plus précisément cette règle vous indiquera si vous utilisez une fonctionnalité apportée par un Service Pack du Framework .NET, par rapport au Framework .NET cible de votre projet.

Il faut pour cela activer une règle dans l’onglet Code Analysis des propriétés de votre projet, cette règle n’est disponible que pour les versions Visual Studio Team Development et Visual Studio Team Suite.

Si vous n'avez pas une de ces versions de Visual Studio, alors vous pouvez obtenir la même option avec l'outil FxCop.

L'analyse de votre application via Code Analysis ou FxCop lèvera alors un avertissement si vous utilisez une fonctionnalité apportée par un Service Pack des Framework 2.0, 3.0 ou 3.5.

L'article suivant de David Kean explique précisément comment utiliser ces outils, avec pleins de screenshots pour configurer tout ça : https://davesbox.com/archive/2008/08/25/new-for-visual-studio-2008-sp1-and-fxcop-1-36-multi-targeting-rule.aspx. Merci à lui pour cette synthèse.

A bientôt,
Aurélien

Comments

• Anonymous
  December 22, 2008
  With the advent of .NET Release pace, I often encounter customers lost with .NET Framework version issues
• Anonymous
  January 06, 2009
  Bonjour, Dans un article précédent intitulé “ Le multi-targeting de Visual Studio et les Services Packs