Discussion :

[od.dev]

visual C# = Microsoft

Oui, mais C# = langage et Visual C# = outil de développement
Ce qui n'est pas la même chose.
En plus tu cites l'excellent exemple de java qui est forcément appelé à disparaître à cause de dot net.

Rien n'empêche de penser que MS ne va pas abandonner l'outil Visual C# et sortir un nouvel outil de développement dot net.
Et même, qu'est ce qui nous empêche d'imaginer que MS ne va inventer une nouvelle plateforme "Dash++ Ultimate" de mes c..., qui optimisera l'excellente
logique architecturale de dot net, rendant celle-ci tout aussi obsolète que win32 ?
La question n'est pas de savoir si ce qu'ils ont fait est bien, mais bien de savoir si ce qu'ils vont faire ne sera pas nettement mieux.

En fait la Vrai Question est : Combien de temps reste-il à vivre à win32 ?

En fonction de la réponse, on commence à investir dans dot net, ou on continu à amortir ou à engranger avec win32 en attendant la nouvelle plateforme "Dash++ Ultimate" de mes c...

D'accord pour Inprise et autres Code Gear qui semblent plutôt mal Embarcadero dans le monde du développement...
Il s'agît en fait de sociétés écran financées en sous-main par MS pour couler Delphi .
Du coup, on ne peut pas honnêtement les traiter d'incompétents.

[od.dev]

Une précision toute fois :
La problématique dont je parle est bien de migrer une application existante et qui ne pose pas de problème majeur de fonctionnement.

Encore que le développement d'une nouvelle appli en win32 peut se poser, tant la différence de richesses des ressources est importante entre les deux plateformes.
La clé étant, encore une fois, la réponse à la question de la durée de vie de win32.
Même si certaines fonctionnalités posent d'ors et déjà pb, comme il a déjà été dit. Facile de remplacer ces modules nécessitant certaines technologies par des modules dot net.

[cinemania]

od.dev pas forcément facile de remplacer les modules.

pour que ce soit facile il faut que l'applicatif d'origine ait été pensé pour être massivement modularisable.
ensuite faut mixer les technologies... ce genre de compétences ne pousse pas sur les cocotiers, et rien ne dit que tes successeurs puissent ne serait ce que les acquerirs.
en effet le seul moyen de mixer les technologies aujourd'hui c'est soit le socle est écrit en C# et tu utilise le P/Invoke sur les DLL écrite en natif... soit tu envisage C++/CLI et là par contre, on est plus tout à fait à la portée d'un développeur Delphi, mais bien d'un développeur C++, qui est autrement plus complexe.

quand on parle de vie d'un produit, il faut toujours penser aussi à l'obsolescence des plateformes ce que peu de personnes font.
j'ai vu des boites qui il y a encore 2 ans ont lancé une appli en win32 et aujourd'hui... se sont dit qu'il était temps de passer à quelque chose de plus "évolutif"... 2 ans... c'est ridicule.

si tu ne migre pas la totalité de l'appli, tot ou tard elle sera donc morte, et ce ne sera pas plus tard quand ce sera devenue une usine à gaz parce que yaura tellement de parties en win32 et en on sait pas quoi qu'il faudra envisager la refonte.
soit on l'envisage direct et on sort les marteaux les burins et les grands travaux commencent, soit l'application est appelée à etre arreté sur les 3/5 ans et on s'en fou.

en plus le portage ne pose pas de grosse difficulté, et c'est peut être l'occasion d'envisager quelques retouches à divers endroits, retouches structurelles permettant une plus grande modularité ou évolutivité, maintenant que vous allez vers une plateforme qui permet cela.

pour ce qui est de visual C# et de C# effectivement ce sont bien l'ide et le langage, mais les deux sont de microsoft...
actuellement sous windows on peut pas vraiment dire que Visual Studio ait une réelle concurrence pour développer en dotnet...
je vois un peu mal l'intérêt de microsoft d'arreter pour refaire la même chose
à ce compte là ils le refondent mdr
et je vois encore moins l'intérêt de microsoft d'arreter VS pour un tiers genre SharpDevelop ou Eclypse développé en java et qui par conséquent risque de mourir comme le langage dans un futur proche s'ils n'envisage pas de le porter vers autre chose.
le fait que désormais il y ait blend n'est pas une gageur à VS bien loin de là, mais bien un outil pour compléter plus adapté à la fonction de designer, pour ceux qui veulent vraiment séparer les métiers.

tu crois quand même pas que Microsoft va s'amuser à arrêter de faire du VS alors qu'une édition Team System de VS2008 il y a encore 1 an se négociait environ 11400€ (0€ pour les MSDN certes mais bon)...

[binoo]

En plus tu cites l'excellent exemple de java qui est forcément appelé à disparaître à cause de dot net.

Sans vouloir faire de hors sujet (mais quand même un petit peu), dotnet ne sera pas responsable d'une éventuelle fin de java. En tout cas, rien (ou pas grand chose) ne le laisse penser actuellement.
Certes Oracle est en train de faire de la m****, mais il faut rappeler que google utilise java (android) et je me dis (vite fait, comme ça ) que java n'est pas forcément près de tomber à l'eau...


Sinon pour ton choix de migration, est-ce que ton application dispose d'une interface graphique ?
Si c'est le cas, alors, dotnet te proposera de nouvelles perspectives non négligeables (avec WPF : interfaces vectorielles, animations, ...) qui attireront davantage les nouveaux acheteurs potentiels de ton produit.

[od.dev]

od.dev pas forcément facile de remplacer les modules.

pour que ce soit facile il faut que l'applicatif d'origine ait été pensé pour être massivement modularisable.

C'est de toute façon ainsi que je conçois le développement.

ensuite faut mixer les technologies...

Ote-moi d'un doute :
il est bien possible d'appeler une dll win32 avec une appli dot net et vis versa ?
Je pense naïvement que, dans la mesure où les 2 cohabitent dans windows, cela ne pose pas de pb.

Ouh lala j'ai peur... non !

tu crois quand même pas que Microsoft va s'amuser à arrêter de faire du VS alors qu'une édition Team System de VS2008 il y a encore 1 an se négociait environ 11400€ (0€ pour les MSDN certes mais bon)...

Ne répète pas ce que je te dis :
je suis persuadé qu'il sont fous.
A partir de là, ils sont capables de tout.

[od.dev]

Sans vouloir faire de hors sujet (mais quand même un petit peu), dotnet ne sera pas responsable d'une éventuelle fin de java. En tout cas, rien (ou pas grand chose) ne le laisse penser actuellement.
Certes Oracle est en train de faire de la m****, mais il faut rappeler que google utilise java (android) et je me dis (vite fait, comme ça ) que java n'est pas forcément près de tomber à l'eau...

Alors là, je crois qu'on peut discuter un peu de tout ce que je crois avoir compris dans ma grande naïveté.

1)
Je suis développeur win32 depuis win32, j'ai vu la naissance de "Java Power" en tant que spectateur puisque je n'en ai jamais eu besoin.
A l'époque, je voyais le monde connu ainsi :
win32 d'un côté, et html pour tout ce qui était internet.
(si tu as connu cette époque, tu te rappelles sûrement de l'abonnement à payer tous les mois pour accéder au 7 ou 8 sites sans intérêt existants en faisant gaffe à la note de tél.)
Question : comment faire la même chose sur des sites que sur des PC, en clair : comment intégrer des appli "PC like" dans un site internet :
d'où naissance de Java, applets java, java bean...
2)
Si j'ai bien compris, mais là j'ai de sérieux doutes, dot net a été créé pour fédérer tous les peuples de la planète PC, et (ou peut-être son successeur ?) rendre transparente la frontière entre PC et internet via les web services (qui, je sais, concernent tous les langages et plateformes).
C'est à dire qu'avec une seule architecture de développement on peut (pourra ?) développer une appli dont on ne se demandera plus si elle est locale ou à destination d'internet, elle sera tout simplement PC.
D'où la mort annoncée de Java aussi sûrement que celle de win32 et des langages archaïques dont il s'abreuve.
N'y a-il pas un J# ? Preuve de la panique de java qui s'agite dans les sables mouvants ?
Dot net et son langage dédié C# seraient donc l'anglais de la planète PC.
A la limite pourquoi pas ?

Sinon pour ton choix de migration, est-ce que ton application dispose d'une interface graphique ?
Si c'est le cas, alors, dotnet te proposera de nouvelles perspectives non négligeables (avec WPF : interfaces vectorielles, animations, ...) qui attireront davantage les nouveaux acheteurs potentiels de ton produit.

Il s'agît d'une interface métier MDI standard.
J'ai peut-être tord de l'imaginer identique après et avant la migration.
Pour être clair, mon but serait de migrer l'appli de Delphi Win32 vers C# dot net en toute transparence au niveau interface graphique, c'est à dire, sans que le client ne s'en rende compte.
Mais je pense de moins en moins que cela puisse être possible.

[Pol63]

y a un peu des mélanges dans tout ca (je vais peut etre en remélanger un peu plus ^^)

déjà en .net on peut appeler des dll COM et des api win32 et des dll .net peuvent avoir une exposition COM

ensuite il me semble qu'à l'époque d'avant .net microsoft proposait vb6 et visual c++, les 2 ayant un runtime ; vb6 pouvait etre compilé en P-Code (donc réellement compilé à l'exécution)

ensuite ils ont réléchis pour gagner des part de marché contre java et ont fait la plateforme .net, qui est basée sur un framework (boite à outils plus que géante) et une compilation à chaque exécution
du coup ca leur permet d'avoir juste un compileur (jit) à écrire pour chaque os je pense ; pour le développeur rien à se préoccuper de spécial
une appli développée sur visual studio 2002 peut être migrée vers vs 2010 sans soucis (en sans trop de soucis)

donc .net avance et je ne vois pas pour quelle raison ils l'arrêteraient, .net étant un genre de middleware entre le développeur et les OS microsoft qui permet des optimisations spécifiques à la machine (mono permet l'exécution d'un exe .net fx2 sur linux)

quand à html vs win32, ca subsistait encore pas mal, asp.net étant un genre de php
depuis wpf (xaml + un langage .net au choix) on peut faire des applications pour navigateur come on fait un .exe wpf
et il y a aussi silverlight, genre de wpf pour navigateur pouvant être sorti du navigateur (concurrent de flash en théorie) (silverlight fonctionnant au passage sur plusieurs navigateurs et même mac OS)

[tomlev]

Ote-moi d'un doute :
il est bien possible d'appeler une dll win32 avec une appli dot net et vis versa ?

Appeler Win32 à partir de .NET, ça se fait assez bien. Le contraire, c'est une autre paire de manche... en général ça se fait via des interfaces COM, y a peut-être d'autres moyens mais je les connais pas

Si j'ai bien compris, mais là j'ai de sérieux doutes, dot net a été créé pour fédérer tous les peuples de la planète PC, et (ou peut-être son successeur ?) rendre transparente la frontière entre PC et internet via les web services (qui, je sais, concernent tous les langages et plateformes).

Mouais, ça c'est un peu du blabla commercial... en pratique, tu as effectivement une plateforme commune (le .NET Framework et le CLR), mais les technos pour le web (ASP.NET, Silverlight) et pour les applis Windows (Windows Forms, WPF) sont différentes

C'est à dire qu'avec une seule architecture de développement on peut (pourra ?) développer une appli dont on ne se demandera plus si elle est locale ou à destination d'internet, elle sera tout simplement PC.

Non, tu ne pourras pas faire une appli qui soit à la fois locale et web (sauf peut-être avec Silverlight, mais c'est un peu limité)

D'où la mort annoncée de Java aussi sûrement que celle de win32 et des langages archaïques dont il s'abreuve.

Java est loin d'être mort, mais il est en perte de vitesse par rapport à .NET, du moins c'est mon impression. Mais il ne faut pas oublier que .NET est limité à l'univers Windows (l'utilisation de Mono, l'implémentation open-source de .NET qui peut fonctionner sous Linux ou Mac, reste encore assez marginale)

N'y a-il pas un J# ? Preuve de la panique de java qui s'agite dans les sables mouvants ?

Ca a existé, mais c'est plus ou moins mort (en tous cas ce n'est plus supporté)

Dot net et son langage dédié C# seraient donc l'anglais de la planète PC.

Si on veut... du moins sous Windows. Mais y a encore pas mal de monde qui développe en Win32...

Il s'agît d'une interface métier MDI standard.

Les interfaces MDI, c'est un peu passé de mode... la tendance est plutôt au TDI (tabbed document interface)

[od.dev]

Merci beaucoup pour ces précisions

Non, tu ne pourras pas faire une appli qui soit à la fois locale et web (sauf peut-être avec Silverlight, mais c'est un peu limité)

Euh... quelle partie de ton anatomie serais-tu prêt à couper s'il s'avérait que ce sera possible sur la prochaine plateforme du maître des lieux. Qui nous expliquera que dot net est une grosse m... etc...

Java est loin d'être mort, mais il est en perte de vitesse par rapport à .NET, du moins c'est mon impression. Mais il ne faut pas oublier que .NET est limité à l'univers Windows (l'utilisation de Mono, l'implémentation open-source de .NET qui peut fonctionner sous Linux ou Mac, reste encore assez marginale)

Ok, en fait Java n'est pas mort, la question est : combien de temps va-t-il agoniser ?

Si on veut... du moins sous Windows. Mais y a encore pas mal de monde qui développe en Win32...

Pareil : quelle différence y-a-t-il entre mort et agonie ? Si ce n'est une perte de temps ?

Les interfaces MDI, c'est un peu passé de mode... la tendance est plutôt au TDI (tabbed document interface)

Ah, voilà qui m'intéresse, je vais m'en renseigner. Cela dit ma problématique principale est de migrer une appli pérenne vers une plateforme pérenne.

[Graffito]

Ok, en fait Java n'est pas mort, la question est : combien de temps va-t-il agoniser ?

Aussi longtemps que C++
Je partirai à la retraite et il bougera encore

Les interfaces MDI, c'est un peu passé de mode... la tendance est plutôt au TDI (tabbed document interface)
Ah, voilà qui m'intéresse, je vais m'en renseigner. Cela dit ma problématique principale est de migrer une appli pérenne vers une plateforme pérenne.

Regarde cette discussion qui propose une méthode TDI avec onglets détachables combinant ainsi TDI et MDI :
Les formes "détachables" sont, soit bien rangées dans leur TabControl (TDI), soit détachées ce qui permet de voir plusieurs formes en même temps (MDI).
http://www.developpez.net/forums/d31...i/lavenir-mdi/

Bien qu'il s'agisse d'un forum Delphi, il expose une solution développée en C#.
J'ai mis une demo et du source C# au message 34 de cette discussion.

[od.dev]

Les interfaces MDI, c'est un peu passé de mode... la tendance est plutôt au TDI (tabbed document interface)

Regarde cette discussion qui propose une méthode TDI avec onglets détachables combinant ainsi TDI et MDI :
Les formes "détachables" sont, soit bien rangées dans leur TabControl (TDI), soit détachées ce qui permet de voir plusieurs formes en même temps (MDI).
http://www.developpez.net/forums/d31...i/lavenir-mdi/

Ouai ben, effectivement, c'est bien une histoire de mode , parce que je ne vois pas bien l'intérêt de remplacer le concept MDI par ce concept, si ce n'est pour coller à la mode...

[binoo]

Ouai ben, effectivement, c'est bien une histoire de mode , parce que je ne vois pas bien l'intérêt de remplacer le concept MDI par ce concept, si ce n'est pour coller à la mode...

Oui pas de fonctionnalité majeure apportée (voire pas de nouvelle fonctionnalité tout court). Juste de l'ergonomie.
Beaucoup utilise se principe (navigateur web, messageries, outils de développement, ...), l'utilisateur est à l'aise avec ce principe.

[od.dev]

Ok.

Personnellement, j'utilise une rangée de boutons anciennement "OutLook like" à gauche,
et je développe chacune des appli de façon indépendante.
Je ne les transforme en fille qu'au moment où l'utilisateur les sollicite.
Bien entendu, chacune de ces fiches filles sont incorporées dans le projet pour la compil de l'appli, mais au lancement de celle-ci, les filles ne sont pas visibles comme dans un projet mdi par défaut.
Ce qui me permet de donner l'allure que je veux à l'appli, et même pourquoi pas remplacer les boutons par des onglets.
Mais je pense que beaucoup font comme cela...

[cinemania]

il ne faut pas oublier l'ergonomie od.dev... c'est un facteur important.

C'est même ce facteur qui a fait qu'un applicatif de ma société a remporté le marché, face à des concurrents nettement mieux implantés et plus anciens sur le secteur... certes il était moins complet, mais son ergonomie...
il n'y avait pas photo.

C'est pourquoi, la mode est importante y compris dans le développement des applications, car il faut suivre ce à quoi les utilisateurs sont habitués ou se qu'ils sont susceptibles de plébisciter et d'aimer... les gouts et les couleurs en sommes.

Tu peux toujours rester en Windows Forms qui est l'équivalence UI des win32, mais tu peux envisager de passer progressivement à WPF, vu que toute façon vous migrez.

Quand je pensais à la mort de java, je ne sous entendais pas qu'il serait enterré par dotnet, mais bien par Oracle lui même... qui commence déjà a creuser le trou... mais c'est une autre histoire.

Graffito... Contrairement à ce que tu semble penser, C++ n'agonise pas du tout, et cela ne risque pas de changer avec l'avènement prochain (même si ca commence à faire long) de la spécification 2 de C++.
Il est encore, et sera encore fortement utilisé dans l'industrie du développement, et d'ailleurs C/C++ est fortement utilisé dans les univers embarqués au même titre que des langages fonctionnels.
Le fait que tu n'en entende pas tellement parlé, c'est surtout que c'est, je dirais, plus un marché pour initié qu'autre chose...
En revanche il y a plus de chance que Java et Dotnet soient enterrés quand tu prendra ta retraite, que C et C++.

Pour revenir à ce qui est des appels...
Comme l'a si bien dit tomlev, appeler du code win32 depuis dotnet, c'est assez simple... pour cela on a plusieurs mécaniques bien huilées à dispositions... le P/Invoke... C'est l'artillerie lourde, et le COM Interop.
C'est facile, accessible, ça marche plutôt bien.

Pour ce qui est de l'opération inverse, invoquer du code C# dans du code Win32... alors là c'est plus du tout la même histoire et les mécaniques ne sont clairement plus les mêmes.
La première déjà énoncée et qui marche dans l'autre sens, les interfaces COM.
C'est pour toujours ce qu'il faut et ca ne permet pas de couvrir les autres cas.
Pour le reste, il faut mettre la main dans le camboui, s'acheter 2 ou 3 semi remorques de prosac et d'aspro, et commencer à développer en C++/CLI en mixant les deux mondes... comment ? en hostant la CLR dans une application win32... On peut le faire autrement qu'en C++/CLI mais là c'est vraiment qu'on a un grain, et qu'on aime se faire mordre.
Donc il y a un interopérabilité de dotnet vers natif, voulue par microsoft, c'est dans l'objectif... l'inverse ne faisant pas vraiment parti des objectifs... c'est plus tout à fait aussi drôle.

[od.dev]

vu que toute façon vous migrez.

J'en suis de moins en moins sûr puisque, si j'en crois ceux qui crient le plus fort, win32 est loin d'être supplanté par dot net.
Je penche de plus en plus vers la solution du status quo.

l'inverse ne faisant pas vraiment parti des objectifs... c'est plus tout à fait aussi drôle.

C'est bien dommage, parce que cela aurait permis de s'y intéresser progressivement et donc plus volontiers et de façon plus systématique.

[Graffito]

Cinémania:
Graffito... Contrairement à ce que tu semble penser, C++ n'agonise pas du tout,

C'était juste un euphemisme : je comparais l'agonie future (improbable) de Java avec celle (inexistante) de C++ . Comme toi je pense que (malgré bien des défauts) C++ est encore bien vivace et qu'il conservera encore des parts de marchés significatives dans l'avenir .

[cinemania]

od.dev... ba disons que le win32 n'est pas mort certes, mais reste à voir s'il ne sera pas remplacé... car les plateformes 32 sont balayés au fur et à mesure par le x64 et les compilations en 64bits...

les langages comme C++ sont des langages... ils ne sont pas limités à la plateforme...
si demain win32 s'effondre et est remplacé par autre chose sans aller jusque dotnet... et bien ... tu codera toujours en C++ mais plus avec win32...

comme je l'ai déjà dit, reste à voir... à quelle étape du cycle de vie ton produit se situe... à partir de là, il peut être envisageable ou non de porter le produit.

dotnet a plus de chance de rester que win32 car win32 devra être remplacé et que tôt ou tard Microsoft en aura marre de la compatibilité descendante, à ce moment là. Comme dotnet est indépendant de la plateforme pour le développeur... ca ne change rien.
Quand ce moment arrivera, ceux qui voudrons continuer à tourner sur des applications péhistériques (lol), devront continuer à tourner sur des systèmes antiques... et cela risque de ne pas forcément être très bien vu par les clients finaux.

Maintenant tu peux décider de maintenir le statut quo pour l'instant... mais dans l'absolu, à quoi bon attendre...

[od.dev]

Parce que, contrairement à des idées reçues, mes clients ne sont pas sensibles aux effets de mode. Bien au contraire, c'est un plus, pour eux, de continuer à travailler sur une appli qu'ils maîtrisent et dont ils connaissent les défauts et le calendrier de résolution de ceux-ci.
Même les nouveaux clients sont très rassurés de voir qu'on leur propose une appli robuste qui a fait ses preuves et qui a une "histoire" et non le dernier truc à la mode (Il faut dire que l'effet Vista y est pour quelque chose).
La seule info complémentaire qu'il me manquait pour répondre à leurs inquiétudes (et aux miennes), c'est la pérennité de la plateforme. Car, bien entendu, ils ont entendu dire que dot net win32.
Je pense donc pouvoir les rassurer avec les arguments des développeurs non dot net.

[Guulh]

On parle de pérennité comme si .Net étant le dernier joujou à la mode. Mais ça fait quand même dix ans que ça traîne...

[od.dev]

What ?

La pérennité de dot net n'est pas en question.