Quel est l’impact de l’installation du .NET Framework 3.0/3.5 pour les applications .NET 1.1 & 2.0?



Comme je vois souvent passer cette question, je vous propose de la couvrir rapidement. Tout d'abord, jetez un œil à cette image qui résume les dépendances entre les briques .NET successives:


 netfx versions


Pour faire simple, .NET 1.0 fut remplacé intégralement par .NET 1.1 au niveau fonctionnel qui fut lui-même remplacé intégralement par .NET 2.0.


 


Conséquence : une application écrite en 1.1 est par défaut impactée par l’installation du Framework 2.0. En effet, par défaut à nouveau, une application .NET va tenter d’utiliser la dernière version du Framework. Logiquement, tout est censé bien se passer. En cas de problème de compatibilité, on peut forcer son application 1.1 à n’utiliser que le .NETFx 1.1 via un fichier app.config. Mais c’est une opération manuelle, application par application.


 


Cette histoire était vraie jusqu’au .NETFx 2.0. A partir du .NETFx 2.0, nous avons figé la brique de base à ce niveau de fonctionnalités. Les nouveaux Framework « se contenteront » alors d’enrichir la brique de base avec des nouveaux services. .NETFx 3.0 apportant principalement WPF (graphique), WCF (communication) et Worflow Foundation. .NETFx 3.5 apporte principalement LINQ.


 


Du coup, l’installation du .NETFx 3.0 (basé sur .NETFx 2.0) n’aura aucune incidence sur une application conçue pour tourner en .NETFx 2.0. Cette application n’aura tout simplement aucune conscience de l’existence de ces nouveaux services. Cela sera donc totalement transparent pour elle.


 


Par contre, l'installation du .NETFx 3.0 entraine forcément l'installation dans la foulée du .NETFx 2.0 sur lequel il est basé. Ainsi, de manière indirecte, l'installation du .NETFx 3.0 peut avoir un effet sur les machines où uniquement le .NETFx 1.1 était installé. En effet, suite à l'installation du .NETFx 3.0, les applications écrites en 1.1 basculeront alors sur le 2.0.


 


Pour terminer, voici un lien vers les « breaking changes »  au runtime, c'est-à-dire les éventuels problèmes générés lorsque l’on fait tourner une application 1.1 sur le framework 2.0/3.x : http://msdn2.microsoft.com/en-us/netframework/aa497239.aspx avec plus de détails ici : http://msdn2.microsoft.com/en-us/netframework/aa570326.aspx


Les chances de tomber sur de tels problèmes sont minces, mais si c’est le cas, il est alors possible de forcer une application spécifique à utiliser le runtime de son choix via le fichier app.config.


-= David =-

Comments (2)

  1. Oriane says:

    Bonjour,

    je lis que les "briques de base sont figées" et je me demande logiquement pourquoi le framework 3.5 SP1 Beta installe le framework 2.0 SP2.

    Cordialement

  2. Bonjour,

    Merci pour votre commentaire. En fait, lorsque je parlais de briques de base figées, je parlais en terme de fonctionnalités. Le Framework 2.0 évoluera naturellement à travers les mises à jour de sécurité et des bugs trouvés via hotfixes et service packs.

    Dans ce cas précis, le .NET 3.5 SP1 beta se permet de mettre à jour le .NET 2.0 pour bénéficier des dernières mises à jour en terme de correctifs de bugs.

    Cordialement,

    David

Skip to main content