Discussion :

[kilroyFR]

Pas de soucis sur sysadmin linux/Windows. Les gens qu'on embauche doivent être polyvalents.
On a fait connerie d'embaucher a une époque des experts Microsoft qui ne raisonnaient que Microsoft même si solution pas adaptée.
Finie l'époque où on avait un expert bdd un expert wcf, un expert Wpf etc.

Maintenant on a fait le choix de basculer vers des esolutions packagées ouvertes et multiplateformes (oui, Scripts Oracle déroulés sur Windows ou Linux à l'identique).
On ne réécrit pas tout puisque nos développements sont en couches (b-a-ba du devpt). Donc généralement sur nos applis Wpf/wcf le passage wcf vers webapi est très rapide. Le portage ihm l'est un peu moins mais on a un framework ihm maison qui nous permet de faire des applis 'type' rapidement.

De plus nos infrastructures sont hébergées chez les clients qui souvent (pour les plus gros) ont déjà infrastructures et admins à plein temps à occuper donc ce n'est pas un pb question budget.
La capacité à répondre. À toutes les configs demandées est un plus.
Nos développeurs maisons peuvent changer de technos et environnement et ça permet la variété dans le boulot.

[Aeson]

Pas de soucis sur sysadmin linux/Windows.

Je n'y crois pas du tout... De VRAIX sysadmin qui conaissent les 2 ? pour des app en Production ? avec de l'Oracle ? non desole je n'y crois pas.

le passage wcf vers webapi est très rapide

Le passage de SOAP a REST rapide je n'y crois pas. Mais simplement passer tes controller bien. Mais c'est pas du REST. (et je ne parle meme pas de la securité ou OAuth, OpenIDConnect et tout ca...)

ont déjà infrastructures et admins à plein temps

ah voila...

[Heliogabale]

Et bien c'est édifiant tout ces commentaires.....

Pour ma part, je considère que c'est une bonne nouvelle et une bonne chose, mais dire que c'est un oubli regrettable..... mouais

[kilroyFR]

Ben désolé mais on a des applis qui tournent dans le monde entier sur les éléments decrits que tu le crois ou pas.
Ce sont des applis qui fonctionnent en 24/7.
Sur 'petits' clients comme sur les gros l'administration et le monitoring sont réalisés soit par nos applis maison soit par des logiciels dédiés (type prtg).
Bdd Oracle a l'origine mais depuis 1 an sur sqlserver également.
Applis qui ont évolués en 10 ans au niveau technos. On profite d'un projet généralement pour migrer une seule appli vers nouvelles technos. Ça permet de faire évoluer les softs en minimisant les risques. Ça marche. On. Ne fait pas la révolution sur toutes les applis en même temps pour raison budgetaire/délais. Et ça permet d'éviter à certains devps de chercher à se faire plaisir et exploser les budgets. Pénalités fortes si les délais ne sont pas respectées donc pas de prise de risques inconsidérés.

[Aeson]

Pénalités fortes si les délais ne sont pas respectées donc pas de prise de risques inconsidérés.

Ca vas.. j'ai compris. On va en rester la..

[kilroyFR]

Passage en soap a rest c'est très facile au contraire. Webapi (même pour un newbie) est redoutablement efficace et tu prends plaisir à coder dans ce modèle. On fait du protobuf et autres 'les doigts dans le nez'.
Les concept rest sont simples et le passage d'une pensée RPC à un mode ressource se fait très bien avec de la pratique.
C'est beaucoup plus abordable que wcf où on s'arrache les cheveux pour configurer l'usine à gaz Microsoft. D.ailleurs il n'y a qu'à voir les sujets récurrents sur la config des endroits wcf pour se rendre compte de ceci.
Ça permet à certains de justifier leur poste mais c'est une complexité totalement inutile.

[Aeson]

Passage en soap a rest c'est très facile au contraire.

oui oui.. on a bien compris le genre de dev que t'es...

[RyzenOC]

excellente initiative,
depuis Windows 10 MS améliore enfin ces outils livrée avec windows de fonctionnalités bien pratique (la barre d'adresse dans regedit, le bug des 256 caractères, pouvoir mettre la console en plein écran, maintenant la couleur, paint 3D)

Manque plus qu'une nouvelle version de notepad s'inspirant de notepad++ et on sera au top.
Sinon je comprends pas vos commentaires... c'est une maj qui améliore le produit, certe elle peut être tardive, mais c'est mieux que rien je trouve.

Utilisant Windows et Linux (debian et redhat), j'ai des problèmes dans les 2 OS donc pour moi les 2 sont de la merde/sont aussi bon (comme vous voulez).
je préciserai juste que Windows à énormément gagné en qualité depuis Windows 8, le kernel est devenue très stable et l'os semble ne plus pourrir/ralentir dans le temps.

[redcurve]

humm mais qui utilise encore cmd ? Perso je fais tout en powershell

[redcurve]

Passage en soap a rest c'est très facile au contraire. Webapi (même pour un newbie) est redoutablement efficace et tu prends plaisir à coder dans ce modèle. On fait du protobuf et autres 'les doigts dans le nez'.
Les concept rest sont simples et le passage d'une pensée RPC à un mode ressource se fait très bien avec de la pratique.
C'est beaucoup plus abordable que wcf où on s'arrache les cheveux pour configurer l'usine à gaz Microsoft. D.ailleurs il n'y a qu'à voir les sujets récurrents sur la config des endroits wcf pour se rendre compte de ceci.
Ça permet à certains de justifier leur poste mais c'est une complexité totalement inutile.

WCF n'est pas extrêmement compliqué simplement il faut lire la doc avant de se lancer dans du paramétrage hasardeux bref se former quoi. REST permet d'aller plus vite car il n'y a pas besoin de réfléchir.

En outre REST et SOAP ne sont pas forcément interchangeable suivant les contraintes du projet ou le métier du client.

[redcurve]

non j'ai dis RDP... quand tu pourra faire du RemoteDesktop depuis Linux vers du windows en SSH fait moi signe

Humm non en fait RDP est un protocole extrêmement puissant, le souci vient des primitives graphique sur les ptf style linux & co car c'est tout un gros bordel dégueulasse, et surtout le fait du X est une vraie merde. Du coup ils sont coincés sur des technos primitives comme VNC ou ils prennent en gros des images ce qui se passe sur le poste distant. Ce qui amène a des aberrations dégueulasse comme celle que je vois chez mon client, car il n'y a pas de notion de session ce truc étant une appli de screenshot du coup ils ont du caser un soft degueu qui balance des keystroke pour garder les sessions actives

[redcurve]

Il y a 15 ans les solutions desktop sous Windows ça passait mais l'aspect non multi plateforme fait que dans la majorité des cas soit tu es passe client léger soit des solutions type Qt. Perso on s'est planté royalement avec SL/Wpf parce qu'on ne voulait pas passer sur client léger (demande client pourtant). On a change notre fusil d'épaule et heureusement car plus personne ne nous demande de client desktop. Ou alors c'est pour faire de l'outillage rien de plus. Qui en 2017 peut encore commencer des projets sur environnements mono techno ou technos mortes (SL/Wpf) ?
Curieux de connaître la typologie de clients auxquels tu es confronté. Ça fait 15 ans que je n'ai pas vu d'appels d'offres avec des applis desktop. Pourtant je travaille pour des grands comptes (SNCF, Xerox, etc).

Alors Silverlight n'a jamais été là pour durer, ce sous ensemble de WPF était uniquement là pour apporter des possibilités non disponibles sur html 4.1 . Une fois html 5 sortie elle a été abandonnée comme prévu depuis la version 1.0 .

WPF, n'est pas mort du tout il continu sont évolution tranquillement, la prochaine étape sera la fusion des deux implémentations de WPF celle de microsoft et celle de xamarin. En outre, le langage WPF n'est qu'un langage de sérialisation d'interface vectorielle. La communauté libre n'a jamais été capable de poindre quoique ce soit de valable dans le domaine ... sauf en se basant sur wpf lol.

Cette année nous avons une évolution majeure de WPF qui arrive avec WPF core, l'ajout d'un système de sérialisation indépendant de la plateforme va permettre de faire tourner wpf sur windows, linux, etc.

Se lancer dans un projet Winform par exemple est du suicide, toute la techno (une flat api en fait), est deprecated depuis plusieurs années.

[kilroyFR]

C'est beau de rêver avec Wpf. Enfin on a donné et je vois mal la communauté de développeurs revenir dessus vu que Microsoft les ignore.
Depuis 2012 plus rien de concret (à part conneries du genre support hdpi et autres). 2006-2012.
Qd je pense les nuits que j'y ai passe pour tout réapprendre from scratch pour des applis mono plateformes. Quel gâchis.

[redcurve]

C'est beau de rêver avec Wpf. Enfin on a donné et je vois mal la communauté de développeurs revenir dessus vu que Microsoft les ignore.
Depuis 2012 plus rien de concret (à part conneries du genre support hdpi et autres). 2006-2012.
Qd je pense les nuits que j'y ai passe pour tout réapprendre from scratch pour des applis mono plateformes. Quel gâchis.

Perso j'ai eu a réapprendre de 0 ... tu dois confondre avec la sous implémentation spécifique silverlight et comme tu n'as pas pris la peine de lire complètement la doc de la v1 bah tu n'étais pas ou courant qu'une fois html5/ecma script 6 ok SL allait sauter mdr. Je trouve ça assez comique tu ne peux t'en prendre qu'à toi même.

[Aeson]

C'est beau de rêver avec Wpf

le XAML utilisé est toujours en grande partie utilisé par UWP et Xamarin. Donc t'a rien perdu a apprendre Xaml.

Maintenant si t'as absolument besoin de multi-platform tu fais du Html. Mais question perf et productivité c'est pas du tout la meme chose. En Xaml sous windows t'aura du natif avec de meilleurs perf et une meilleurs productivité.

Et croire que ton site fonctionera direct sur tout les browser est utopique

Sinon t'attend Xamarin et WPF Core (en Xaml) qui tournera en natif sur Windows, Mac, Linux, Android,....

[kilroyFR]

Aucun soucis on a su s'adapter seulement comme pas mal de dev on est vigilant maintenant sur tout ce que produit MS. Effectivement on considère qu'ils essaient des choses. SL à été abandonné suite abandon des plugins (flash et autres) dans les navigateurs .
Commercialement MS à vendu du rêve en faisant croire au client semi lourd ou semi léger. En fait c'était juste pour occuper le terrain. D'où la vigilance désormais. On ne saute pas sur aspnet core tant que ça n'est pas stable.
Différencier webapi et mvc était déjà un errement de MS car ça n'a aucun sens techniquement (pourquoi 2 apis pour renvoyer du HTML ou du json/XML).
Le cahier des charges aspnet core est déjà plus cohérent mais tout ça pour ça au final !
Empirique.
Enfin je vois qu'en 2017 ce ne sont pas forcément les plus vieux les plus fermes au changement. Accrochez vous bien a vôtre
rocher wpf et on en reparlera dans quelques années (MFC même si vous voulez).

[Aeson]

Accrochez vous bien a vôtre rocher wpf et on en reparlera dans quelques années

ok. Explique moi comment tu justifie la ré-écriture d'une application WPF/WCF en HTML/WebApi ? C'est quoi les avantages pour le business ?

[Aeson]

pourquoi 2 apis pour renvoyer du HTML U du json/XM

C'est toujours 2 api differentes en asp.net core. Elles sont seulement toutes les 2 dans un namespace commun. Tu dois toujours ajouter .AddMvc() dans ton pipeline Asp.Net Core si tu veus utiliser Razor et les tables de routage MVC. C'est donc bien 2 api differentes...

[kilroyFR]

ok. Explique moi comment tu justifie la ré-écriture d'une application WPF/WCF en HTML/WebApi ? C'est quoi les avantages pour le business ?

Pas une reecriture, un portage. C'est bien different. La partie logique metier n'est pas reecrite.
Nos clients veulent des APIs ouvertes, du REST/JSON pour les interfaces avec applis mobiles notamment.
WCF+REST ca existe mais c'est un montage tordu de plus dans ce couteau suisse qu'est WPF.
Comment on le justifie ? par les couts de maintenance/devpt pour les nouveaux developpeurs.
SOAP est lourd et delaissé de plus en plus donc aucun interet de rester sur WCF.
Plus facile a un dev (meme moyen) de coder des API Rest directement que de se former a WCF et essayer de faire du REST. Oui c'est faisable mais a quel prix ! (au prix de trucs et astuces a gogo).
Meme l'equipe WebAPI chez microsoft a preferée choisir ASPNetMVC au lieu de WCF pour l'hebergement des WS services dans IIS.

[kilroyFR]

C'est toujours 2 api differentes en asp.net core. Elles sont seulement toutes les 2 dans un namespace commun. Tu dois toujours ajouter .AddMvc() dans ton pipeline Asp.Net Core si tu veus utiliser Razor et les tables de routage MVC. C'est donc bien 2 api differentes...

2 apis unifiées (avec des astuces pour permettre la portabilité - merci MS) = au final 1 type de projet et pas 2 comme maintenant.