Discussion :

[Invité]

Bonjour,

J'ai une application developper en dotnet 1.1 et j'envisage d'effectuer une migration vers la version 3.5

Y a t il des precautions à prendre, et des piege à éviter.

Merci d'avance.

Guillaume

[Louis-Guillaume Morand]

ca dépend. tu vas juste la recompiler en 3.5 ou tu vas recoder en améliorant le code en utilisant générics, linq, et autre nouveautés?

[dev01]

Bonjour.

Les précautions à prendre concernent surtout les classes marqués Deprecated qui ont été supprimés du framework 3.5. Ensuite vu que vous venait de loin il faut faire des tests un peu poussé, vous changer de CLR ( 1.1 vers 2.0 )

[ZaaN]

Un point parmi tant d autre :

Attention aux classes qui seraient devenue obsoletes (exemple ici)

[neptune]

Sinon, il est intéressant de savoir pourquoi tu souhaites migrer. Si c'est uniquement pour dire je suis en 3.5 et plus en 1.x ca n'en vaut pas la peine. Ton application n'est pas mauvaise parce qu'elle n'est pas compilée avec la dernière version du framework .NET.

[dev01]

Sinon, il est intéressant de savoir pourquoi tu souhaites migrer. Si c'est uniquement pour dire je suis en 3.5 et plus en 1.x ca n'en vaut pas la peine. Ton application n'est pas mauvaise parce qu'elle n'est pas compilée avec la dernière version du framework .NET.

ben oui et non. Le problème n'est pas la recompilation ( quoiqu'il faudrait vérifier si le compilateur C# n'as pas subit un petit lifting et quelque amélioration sur l'optimisation ) mais bien le runtime. En effet le runtime de .NET 3.5 à été largement amélioré et est plus rapide et performant que la version 1.1.

[Invité]

En fait je suis obligé de modifier l'appli pour aujouter des fonctionnalités qui sont disponibles uniquement dans le framework 3.5.

[SaumonAgile]

ben oui et non. Le problème n'est pas la recompilation ( quoiqu'il faudrait vérifier si le compilateur C# n'as pas subit un petit lifting et quelque amélioration sur l'optimisation ) mais bien le runtime. En effet le runtime de .NET 3.5 à été largement amélioré et est plus rapide et performant que la version 1.1.

Oui le compilateur a subi un gros lifting, mais ça ne remet pas en cause la compilation d'une appli originellement en 1.1, ce sont des améliorations de performance du processus de compilation et aussi de performance du code généré.
De plus, le CLR du 1.1 par rapport à 2.0, puis 3.5 est backward compatible à 100%. Depuis le framework 1.1, chaque amélioration est une extension du CLR, mais pas une modification de l'existant.

[dev01]

Oui le compilateur a subi un gros lifting, mais ça ne remet pas en cause la compilation d'une appli originellement en 1.1, ce sont des améliorations de performance du processus de compilation et aussi de performance du code généré.

Si il y a eu modification du code généré alors il y a modification de la façon dont s'éxécute le programme au final

De plus, le CLR du 1.1 par rapport à 2.0, puis 3.5 est backward compatible à 100%. Depuis le framework 1.1, chaque amélioration est une extension du CLR, mais pas une modification de l'existant.

nop je suis pas d'accord. Le CLR a été modifié même s'il est capable de faire tourner des applications 1.1. L'exécution des applications ce fait bien sur le CLR 1.1 par défaut car compilé pour. Mais il existe une directive à mettre dans le fichier de config afin de sépcificier sur quel CLR il faut exécuter le programme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
<configuration>
  <runtime>
    <compatibilityversion major="3" minor="0"/>
  </runtime>  <startup>
    <supportedRuntime version="v3.5.7000"/>
   </startup>
</configuration>

On peux donc forcer une application 1.1 à s'éxécuter sur un runtime 3.5 et à bénéficier des améliorations

[SaumonAgile]

Si il y a eu modification du code généré alors il y a modification de la façon dont s'éxécute le programme au final

nop je suis pas d'accord. Le CLR a été modifié même s'il est capable de faire tourner des applications 1.1. L'exécution des applications ce fait bien sur le CLR 1.1 par défaut car compilé pour. Mais il existe une directive à mettre dans le fichier de config afin de sépcificier sur quel CLR il faut exécuter le programme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
<configuration>
  <runtime>
    <compatibilityversion major="3" minor="0"/>
  </runtime>  <startup>
    <supportedRuntime version="v3.5.7000"/>
   </startup>
</configuration>

On peux donc forcer une application 1.1 à s'éxécuter sur un runtime 3.5 et à bénéficier des améliorations

Honnêtement, en te lisant, je trouve que c'est simplement une autre manière de dire ce que je disais au début.

[dev01]

Honnêtement, en te lisant, je trouve que c'est simplement une autre manière de dire ce que je disais au début.

C'est mon pouvoir de persuasion qui fait ça

[souris_sonic]

Bonjour,

Je trouve votre discussion très intéressante.
Dans ma boite, on essaie de migrer une application en 3.5

Notre application est en 1.1 mais nous avons pas réussis à la recompilé en 3.5.

Notre application mélange de l'asp.net, c# et c++ managé et c++ non managé

au niveau du c++ ça coince
on ne peut pas le migrer en 3.5

pour l'instant je trouve pas encore d'info sur le sujet

j'espère que vous aurez peut être une piste

[dev01]

D'un autre coté sans la description exacte du pb, on peux pas vous aider .

Quel est le message d'erreur du compilateur ? Avez vous vérifié les classes marqué obsolètes dans le Fx 2.0 et qui ont été supprimés dans le 3.5 ?

[souris_sonic]

D'un autre coté sans la description exacte du pb, on peux pas vous aider .

Quel est le message d'erreur du compilateur ? Avez vous vérifié les classes marqué obsolètes dans le Fx 2.0 et qui ont été supprimés dans le 3.5 ?

je te remercie, je n'ai pas vérifié ça

le compilateur me donne beaucoup de fonction obsolète

pour mon code c++, en fait il faut que je trouve les bonnes fonctions de compilation pour le compiler car il mélange le code c++ , le code c, le code c++ managé
(c'est une vielle appli)

le code c++ (notre couche métier) est appelé par du code c#

on a demandé à une personne de microsoft de nous faire migrer notre code mais pour l'instant il y arrive pas

[SaumonAgile]

Il me semblait que le C++ managé n'était plus dispo après le framework 1.1 et qu'il avait été remplacé par le C++/CLI ?
Me serait-je trompé ? Suis en train de mentir effrontément ?

[dev01]

Il me semblait que le C++ managé n'était plus dispo après le framework 1.1 et qu'il avait été remplacé par le C++/CLI ?
Me serait-je trompé ? Suis en train de mentir effrontément ?

Tiens je croyais honteusement que c'était la même chose ...

si nicopyright passe par ici qu'il éclaire notre lanterne ( ô grand maitre du C++/CLI pardonnes moi mes trolls C++/CLI vs C# )

[dev01]

Après vérif effectivement c'est bien deux langages différents et le C++/CLI remplace le C++ Managé.

C'est donc normale que la couche C++ managé ne compile plus en .NET 3.5 vu qu'elle n'existe plus.

Ce que je vous recommanderais, vu les infos données, c'est penser à migrer la couche C++ managé vers du C#. Un beau peu wrapper C++/C# et le tours et joué. Le passage par le C++ managé ou le C++/CLI est à mon avis une couche pour rien. Et comme de toute façon il va falloir réécrire la partie C++ Managé en quelque chose d'autre autant l'écrire en C# directement non ?

[souris_sonic]

mille merci pour vos infos

alors là, c'est génial !!

maintenant, on va convaincre plus facilement notre chef de réécrire le c++

c'est trop génial

encore merci

le code c++ était tellement "bugué" que c'était mon rêve de le voire disparaître maintenant je sais qu'on peut vendre ça à mon chef, et je suis trop heureuse !!