C'est juste à titre informatif, avant de passer à l'action.
Y a t'il des problèmes particuliers lorsque l'on convertit un projet de 2003 .net 1.1 en 2005 ?
Si oui lesquels.
Ou peut etre que le bébé accouche sans douleur ?
 
Merci.

Cela dépends du projet. Et surtout du respect des normes .NET de base.
 
En gros, si ton projet est de type application Console ou Winform, sans trucs tordus (Cross Threading & co), c'est succés assuré dans 99% des cas.
 
En Web, c'est un petit peu plus délicat, mais cela fonctionne tout de même assez bien.
 

Bein c'est du web et y a rien de torturé dedans, sauf que la solution comporte une dizaine de projet, et que l'on a plusieurs projets web, mais un seul possède le web.config, de plus un de ces projets fonctionne avec de l'asp et celui ci est la racine de tout.

pour le web, y'a quand même un truc important : la moitié du code (tout ce qui se trouve dans le designer) n'existe plus en 2.0 par défaut.
 
je sais pas ce qu'il se passe lorsque tu upgrade un projet. le risque, c'est que tout ce que tu as modifié dans cette page soit perdu.

je risquerai de perdre le code des pages ? je n'ai pas bien compris.
Ou tu parles de méthodes genre OnPreRender ... ?

Ce qui se trouve dans ta page "Mapage.Designer.cs", puisque ce fichier par défaut n'existe pas en .NET 2.0

je suis peut etre une grosse buse , mais je vois pas ce que c'est, je jetterai unoeil demain .

Ben...
J'ai un doute. Ou alors c'est tout intégré dans ta page CS.
 
Mais en gros, en ASP.NET 1.1, quand tu crée un contrôle <asp:textbox id="montxt" runat=server".../> t'as aussi dans ton code C# la ligne "protected TextBox montxt;" qui doit être présent quelque part.
 
Et t'as un Initialize() qui va définir à quoi ça ressemble dans une région "designer".
 
En ASP.NET 2.0, c'est très largement simplifié, puisque ce code est implicite. Du coup, si t'as du code dans cette partie de ta feuille, ça risque fortement de disparaitre.
 
Mais bon, en soit c'est pas très gênant, juste que ça va demander à passer du temps sur chaque page pour vérifier que ce qui a sauté, tu l'as bien réécrit ailleurs.
 
Il faut savoir aussi qu'un certain nombre de namespace on été complètement repensés (System.Collection, System.Web et System.Net sont trois bons exemples) et tu vas certainement avoir de gros problèmes si tu les utilisait.
 
Par exemple, le type ArrayList n'existe plus. Tu vas avantageusement pouvoir le remplacer par un List<T>, mais ça demande du boulot tout de même. Et ne pas oublier que nombre de propriétés/méthodes de classes existantes sont passées déprécated, et parfois ne compilent carrément pas. C'est notamment le cas dans le namespace System.Net, où 100% des classes ont été réécrites.

, et tout ca l'utilitaire de conversion le fait .
 
oui je vois ce que tu veux dire alors parlant du code qui pourrait sauter, par contre, tout ce qui est systeme.net collection ... oui c'est utilisé, et l'application existante est plutot énorme .
 
Si changé un ArrayList part un List<T> peut se faire sans souci car le List<T> reprend toutes les méthodes de l'arraylist alors bon, je passerai du temps a corriger les erreurs de compiles.
D'un autre cote nous avons plusieurs projets, au sein de la solution, alors on devrait pouvoir les passer au fur et a mesure en 2005, mais vu que nous n'avons aucune procédure de test unitaire capable de tester l'ensemble de l'appli, ca promet d'etre une sévère galère .
 
Merci .

Le souci d'un ArrayList, c'est que ça stocke des "object", donc tu peux mélanger les types.
Un List<T> en revanche, tu définit le type T à utiliser à la création, et il refusera de stocker autrechose.
Mais bon, pour les cas où t'es obligé de mélager des petits pois et des carottes, t'as toujours le Array, qui remplace le ListArray, mais qu'il est déconseillé d'utiliser (les List<T> ) sont bien plus performant, et leur typage fort permet de détecter au plus tôt des bugs de fonctionnement.

Sinon, je ne suis pas sûr que migrer les projets existants soit une très bonne idée.
 
Je vous conseille de passer à .NET 2.0 (voir le 3.0 ou 3.5 puisque VS 2008 va sortir d'ici très peu de temps maintenant) à l'occasion d'une nouvelle version ou d'ajouts de briques logicielles à un projet existant : rien n'empêche une DLL écrite en .NET 2.0 de travailler avec un EXE en .NET 1.1 par exemple.
 
Personnellement, j'ai des projets écrits en .NET 1.1 et en 2.0 sur les mêmes serveurs, et qui coopèrent entre eux sans problème. Quand j'ai vu que je passerais vraissemblement autant de temps à migrer qu'à redévelopper, j'ai préféré faire ni l'un ni l'autre

merci, mais c'est un projet web, donc des DLL en 1.1, peuvent elles travailler avec des DLL en 2.0 ou 3 ou 3.5 ? et inversement, sur le meme serveur ?

Tu *devrais* pouvoir les utiliser si tu les utilise comme des références dans ton projet.
Ceci dit, je n'ai jamais fait le test, donc je ne peux pas l'affirmer. Le mieux c'est de faire un test. Tu dwl Visual Studio 2005 Express, tu crées un projet DLL, et tu tentes d'utiliser la DLL depuis un site écrit en 1.1 et inversement.

ok je vois, et les using devraient aussi fonctionner de la meme maniere j'imagine.
En tous cas merci, ca me donne des pistes, ici je suis en 1.1 et j'essais de pousser au max pour que les pseudo boss pousse la prod a passer en 2.0 et supérieur, donc si des projets arrivent a passer en 2.0 ou plus, la limitation ne sera plus que la volonté des boss de faire plier la production .

En tout cas, même si c'est chiant ensuite (obligé d'avoir deux PC par dev -moi j'ai un XP installé dans un Virtual PC pour .NET 1.1- puisque VS2005 ne fais pas de 1.1) le mieux c'est de rester en 1.1 pour ce qui existe déjà, mais faire les nouveaux développements autant que possible en 2.0 ou plus.
 
A noter qu'avec VS 2008, tu peux faire en même temps du 2.0, 3.0 et 3.5 -1.1 je sais plus- donc passer de 1.1 à 2.0 ou 3.0 n'est pas un problème, puisque de toute façon vous ne serez pas embêtés avec VS 2008 contrairement.

on developpe actuellement un projet, mais qui n'est pas un projet web ou winform c'est surtout une sorte des classes métiers, donc déjà si l'on peut convertir cela et l'utiliser dans les autres projets ca sera un gros progrès.