Discussion :

[od.dev]

Bonjour à tous,
Question existentielle à 100 balles :

Je suis analyste-prog TRES orienté Delphi / SQL,
je ne connais du langage C# que le nom ,
Je vais prendre en charge une appli développée en Delphi (win32) qui fonctionne bien,
il est question de migrer cette appli vers .net, et on me parle du langage C#.

Les questions que je me pose :
Quels seraient les avantages de migrer une appli delphi (win32) vers C# ?
Pourquoi ne pas migrer vers Delphi.net ?
C# est-il un concurent de Delphi.net ?

Si vous pouviez m'aider à trouver des éléments de réponse, je vous en serais éternellement reconnaissant...

[meziantou]

Pourquoi ne pas migrer vers Delphi.net ?

Car le seul logiciel qui permette cela est Delphi prism. Ce qui oblige à acheter un autre logiciel en plus de visual studio. De plus si le logiciel n'est plus supporté, il faut migrer le projet dans un autre langage.
Le c# est le langage le plus utilisé avec le VB.NET, il y a donc beaucoup plus de ressources sur internet.
Le seul avantage est surement une migration plus rapide vers delphi.net

[B.AF]

Bonjour à tous,
Question existentielle à 100 balles :

Je suis analyste-prog TRES orienté Delphi / SQL,
je ne connais du langage C# que le nom ,
Je vais prendre en charge une appli développée en Delphi (win32) qui fonctionne bien,
il est question de migrer cette appli vers .net, et on me parle du langage C#.

Les questions que je me pose :
Quels seraient les avantages de migrer une appli delphi (win32) vers C# ?
Pourquoi ne pas migrer vers Delphi.net ?
C# est-il un concurent de Delphi.net ?

Si vous pouviez m'aider à trouver des éléments de réponse, je vous en serais éternellement reconnaissant...

Migrer vers C# ? Tu fais un choix 'd'avenir', par rapport à Delphi dont l'avenir semble plus être à la maintenance.

Après, si tu sais faire du pascal objet, peu de chance que tu ne maitrises pas rapidement C#. Ce sont les mêmes logiques objet.

Donc pour toi, c'est bien de travailler sur une techno qui a le vent en poupe, ca te permet de rester sur un langage objet, et tu gardes le framework .Net, sur lequel tu pourras continuer à faire du delphi le cas échéant.

[Pol63]

le delphi .net et le c# sont compilés de la meme manière, et le delphi .net doit avoir un syntaxe plus proche du delphi que le c# (il faudra surement néanmoins perdre quelques automatismes pour etre cohérent avec la POO et le framework)

[od.dev]

Car le seul logiciel qui permette cela est Delphi prism.

J'ai le BDS2006, avec Delphi, Delphi.net, C++ Builder et C#.
Pourquoi aurais-je besoin de Delphi Prism ?
C'est quoi encore ce Delphi Prism ?

[Bluedeep]

Pourquoi aurais-je besoin de Delphi Prism ?
C'est quoi encore ce Delphi Prism ?

Un plug-in Visual Studio.

Une sorte de soin palliatif pour Delphi.net afin qu'il ne souffre pas trop avant de termminer sa vie

Tiens un petit article d'un delphiste nostalgique à son sujet :

http://www.e-naxos.com/Blog/post/200...de-Delphi.aspx

[tomlev]

Pour moi le principal problème de Delphi.NET est qu'il ne permet pas de profiter des dernières évolutions de la plateforme .NET. Par exemple, je doute qu'on puisse (facilement) utiliser LINQ ou le DLR avec Delphi.NET...

[od.dev]

Oula !...
Mais alors mon C# Builder du BDS2006 devient quoi ?
Les composants (ou assemblages ?) développés dans C# Builder sont-ils compatibles dans un autre EDI, puisque développés en C# ?
Vaut-il mieux commencer à travailler dans mon C# Builder (déjà payé) ou investir dans l'EDI de MS ?

Merci pour l'article qui m'a bien (foutu les j'tons) ouvert les yeux, et je vais essayer de me procurer le livre en question (de Delphi vers C#). Même si j'ai bien compris qu'il ne s'agît pas du titre définitif.
C'est exactement ce qu'il me faut comme bâton de pèlerin.

Néanmoins, il me paraît difficile, encore à l'heure actuelle, de migrer de façon satisfaisante un progiciel métier complet de win32 vers dot net, vu la différence de richesse des offres tiers, tant payantes que gratuites.
Beaucoup de choses sont à re-développer de A à Z .
Il suffit, pour s'en convaincre, d'ouvrir un EDI win32, et un EDI dot net.

En espérant que tout ce bazars (je parle du passage de win32 à dot net) ne servira pas à rien, et qu'on ne vienne pas nous dire dans quelques années que dot net est devenu un sac à m... et qu'il faut passer à un nouveau système.
Cette réflexion est l'équivalent de la question :
Cela vaut-il le coup de migrer une grosse appli qui fonctionne bien ?
Ou encore plus exactement :
Quel version de Windows abandonnera win32 ? Win 8, 9, 10 ou jamais ?

[Pol63]

visual c# express est gratuit et permet de tout faire quand même (parfois moins pratique que les versions payantes peut être ...)

faire du win32 de nos jours ca me semble risqué quand même ... windows 7 et server 2008 supportent de moins en moins de chose (oledb est buggé par exemple (dixit microsoft))

.net a encore de longues années devant lui je pense, une machine virtuelle ca peut se faire évoluer plus facilement
et puis de toutes facon tous les langages ont une durée de vie limitée

après c'est sur que migrer une appli ca peut prendre du temps

[Graffito]

Pol63 : le delphi .net et le c# sont compilés de la meme manière, et le delphi .net doit avoir un syntaxe plus proche du Delphi que le C (il faudra surement néanmoins perdre quelques automatismes pour etre cohérent avec la POO et le framework)

+1, je confirme en tous points.

Nous avons abandonné Delphi que nous utilisions depuis 1996 pour C# il y a 3 ans sans être vraiment dépaysés.
Au final aucun regret .

[cinemania]

en fait les différences entre C# et delphi sont toutes au niveau de l'écriture, car finallement la logique est sensiblement la même.

la notion de propriétés apportée par delphi par exemple que l'on retrouve intégralement en dotnet, avec getter et setter.

De nos jours... conserver une appli qui fonctionne... c'est un peu le dialogue de sourd des banques ce qui explique qu'elles payent plus cher en maintenance applicative et tout particulièrement la maintenance payante des os vieux comme herod, qu'en développement nouveaux... ca explique aussi pourquoi ya si peu de nouveautés et améliorations du coté des banques

le changement de technologie est inévitable.
l'intérêt de dotnet c'est qu'il suit la technologie, et par conséquent il est souvent pas difficile de faire "migrer" un projet déjà sur plateforme dotnet.
j'ai faillit être recruté par une boite qui a un gros progiciel de gestion tentaculaire développé en VB6 qui a décidé de tout péter et d'y aller directement en modèle full-web en dotnet et silverlight 4.

ca n'a rien de choquant. je dirais que C# a encore de beaux jours devant lui, surtout maintenant que Microsoft développe avec (office 2007, 2010 par exemples sont développés en dotnet).

[od.dev]

la notion de propriétés apportée par delphi par exemple que l'on retrouve intégralement en dotnet, avec getter et setter.

Oui, j'ai remarqué ça avec plaisir.

De nos jours... conserver une appli qui fonctionne... c'est un peu le dialogue de sourd des banques ce qui explique qu'elles payent plus cher en maintenance applicative et tout particulièrement la maintenance payante des os vieux comme herod, qu'en développement nouveaux... ca explique aussi pourquoi ya si peu de nouveautés et améliorations du coté des banques

Ce qui me conforte dans le choix de ne pas migrer une appli qui tourne bien et qui ne coûte pas cher, voir rien, en maintenance.
Par contre, Ce qui me parait intéressant, ce serait de redévelopper certains modules sous forme de dll, comme je sais le faire en Delphi, puis d'essayer de les migrer en C#, sous forme de dll également. Il me semble avoir vu quelque part que cela ne posait pas de pb.
Ce qui me permettrait d'anticiper certaines demandes des utilisateurs qui m'obligeraient à faire appel à des ressources et des technologies dot net.

Faire "péter" une grosse appli, pourquoi pas, dans la mesure où c'est justifié.
Si c'est juste pour coller à la technologie courante, je pense que c'est une erreur.
J'ai commencé dans le développement par du cobol/Oracle sur des machines mvs... ce qui m'a vite gavé...
mais je me mets à la place des banques/assurances qui, après avoir réussi l'exploit de migrer des appli aussi fiables en win32 qu'en grand système (pourquoi ai-je envie de dire que c'est juste pas possible ? ), à qui on dirait, moins de 10 ans plus tard, que le win32 c'est de la m... et qu'il faut tout migrer vers du dot net !

[od.dev]

visual c# express est gratuit et permet de tout faire quand même (parfois moins pratique que les versions payantes peut être ...)

Merci pour l'info, je vais essayer, mais bon... s'il n'y a rien dedans...
J'ai des composants métier à re-développer, mais pour le reste, j'aimerais avoir des jolies choses déjà faites .
C'est ce que j'aimais bien chez Delphi, l'offre tiers...

[Bluedeep]

Merci pour l'info, je vais essayer, mais bon... s'il n'y a rien dedans...
J'ai des composants métier à re-développer, mais pour le reste, j'aimerais avoir des jolies choses déjà faites .
C'est ce que j'aimais bien chez Delphi, l'offre tiers...

Je ne comprends pas ta réponse : quel rapport entre IDE et offre tiers ?

[B.AF]

Faire "péter" une grosse appli, pourquoi pas, dans la mesure où c'est justifié.
Si c'est juste pour coller à la technologie courante, je pense que c'est une erreur.
J'ai commencé dans le développement par du cobol/Oracle sur des machines mvs... ce qui m'a vite gavé...
mais je me mets à la place des banques/assurances qui, après avoir réussi l'exploit de migrer des appli aussi fiables en win32 qu'en grand système (pourquoi ai-je envie de dire que c'est juste pas possible ? ), à qui on dirait, moins de 10 ans plus tard, que le win32 c'est de la m... et qu'il faut tout migrer vers du dot net !

Tu ne peux pas savoir à quel point je te rejoins. C'est pour cela que la conception est primordiale.

Dans ce cas là, par exemple, si une appli est conçue correctement en Delphi, le portage sera simple. Souvent les migrations sont mal calibrées, voir inutiles.

[od.dev]

Je ne comprends pas ta réponse : quel rapport entre IDE et offre tiers ?

Effectivement, ce n'est peut-être clair que pour un adepte Delphi.
Prenons comme exemple la version gratuite de Delphi.
Il n'est pas possible de développer des appli connectées à des bases de données. Ce qui est une restriction extrême.
Il faut donc au minimum travailler avec Delphi pro.
De plus de nombreux composants sont fournis avec les versions "Entreprise" ou "Architecte", et qui ne sont pas présents dans la version pro.
Je me demandais donc si la différence entre la version Express de Visual C# et la version pro de Visual Studio était du même ordre.
Y a-t-il des composants C# sympa et utiles dans Studio qui ne sont pas fournis avec Express ? Et si oui, est-il possible de les trouver à côté en version libre ou faut-il les acheter.
Bien entendu, j'aurai une bonne partie de la réponse à la fin du téléchargement de la version d'éval de Studio, c'est à dire dans quelques jours...

[B.AF]

Globalement oui, tu vas rester dans les mêmes logiques.
En terme de composants tiers, l'équivalent étant les librairies, il y en a suffisamment en .Net pour que tu ne sois pas dépaysé.
Au niveau IHM, les offres commerciales sont excellentes peut être même au dessus de ce qui se faisait en delphi/activex

Donc aucune inquiétude à avoir, tu ne seras pas noyé das un hell de librairie à trouver à faire cohabiter...

[Pol63]

Merci pour l'info, je vais essayer, mais bon... s'il n'y a rien dedans...
J'ai des composants métier à re-développer, mais pour le reste, j'aimerais avoir des jolies choses déjà faites .
C'est ce que j'aimais bien chez Delphi, l'offre tiers...

j'ai pas dit qu'il y avait rien dedans, niveau code on peut faire exactement la même chose
par contre les assistants de base de donnnés n'y sont pas tous, mais les assistants il vaut mieux s'en passer
source safe aussi n'est pas intégré dans les versions express (mais peut fonctionner en passant par sourcesafe, m'enfin c'est moyen)

[od.dev]

(J'ai compris ce que tu as dit. )

Pour en revenir à mon BDS 2006...
je regardais sa nouvelle version 2010, et je me rends compte que C# Builder n'existe plus !
En fait, si on retire win32, il ne reste plus rien !
A part ce truc qu'ils appellent Prism et dont on peut se demander s'il durera aussi longtemps que Delphi.net et C# Builder

Il m'apparaît maintenant clair que, quitte à apprendre un nouveau langage, la meilleure voie vers le développement dot net est le C#, et j'espère ne pas me tromper en pensant que Visual C# risque de durer plus longtemps que C# Builder.

[cinemania]

od.dev... visual C# = Microsoft
dotnet = Microsoft...

visual C# existera aussi longtemps que la plateforme dotnet existera car C# a été conçut spécifiquement pour, et que Visual Studio est l'environnement de microsoft pour développer sur du Microsoft

on ne peut certes pas prédire ce qu'il adviendra dans un futur à moyen ou long terme, mais il est évident que si microsoft a tant investi pour faire de dotnet un vrai rival et une alternative largement plus viable à java, ce n'est pas pour l'interrompre de suite.
en fait il y a fort à parier que dotnet survivra à java (n'oublions pas l'épée de damoclès au dessus de la tête de java... j'ai nommé Oracle)

c'est d'autant plus vrai que microsoft commence à développer la grande majorité de ses outils et applicatifs client sur sa plateforme, ce qui indique qu'elle à atteint le niveau de maturité minimum qu'ils souhaitaient, et que son cycle de vie est encore assez long au final.

n'oublions pas silverlight, qui est basé sur dotnet, ainsi que XNA. ce n'est pas maintenant qu'ils ont finalement mis tous les outils de développements pour leurs consoles et autres en dotnet qu'ils vont l'arrêter.

pour ce qui est de BDS 2006 à 2010... tout reste dans la logique de la boite portugaise qui a racheté Inprise qui avait racheté Borland. ce sont des incompétents chroniques qui cassent absolument tout ce qu'ils ont et rate tout ce qu'ils entreprenne...
on dirais vraiment qu'ils coulent eux même leur plateforme. comment se saborder soit même.
ils font l'inverse de la marche à suivre, ils supprime les outils pour développer sur plateforme tiers, alors qu'ils n'ont pas leur propre plateforme pour compenser et se focalise sur une plateforme qui est appelée à disparaitre.

win32 est de moins en moins supporté et le sera de moins en moins.
avec l'augmentation des ressources machines, les systèmes 32 bits ne pouvant en tirer partis, ces infrastructures sont appelées à s'éteindre dans un futur relativement proche et donc tous ceux qui ont misé intégralement sur win32 au final.

l'intérêt de miser sur une plateforme comme dotnet est aussi de passer sans heurres le changement de plateforme, car après tout, comme il a été dit, il suffit de changer la VM et le tour est joué...