Reprise du message précédent :
Bah c'est pas magique c'est sur mais c'est comme tout faut se former dessus...

Perso je viens de finir une migration TFS (2015) vers Azure DevOps (anciennement Visual Studio Team Services), bon ba si vous avez le cas un jour, préférez la méthode "on fait un snapshot de base et on migre tout d'un coup"

 
C'est marrant, c'est l'option que j'aurais choisi de base le snapshot    

Pareil, mais quelqu'un d'autre a dit non pour moi sans me demander ²

Pourtant TFS a toujours été un bonheur de simplicité à déployer et administrer, et le guide de migration ne fait que 60 pages, c'est étonnant que ça puisse présenter des difficultés.
https://www.microsoft.com/en-us/dow [...] x?id=54274
 
 

Ah moi je suis plutôt content des dernières mises à jours d'Azure Devops.
 
Et pareil pour azure, j'utilise régulièrement jamais eu un soucis. Bon par contre je me suis paluché pas mal de documentation avant de passer à l'acte  

Bin ici ça va faire 1h que l'instance est down, donc je vous laisse imaginer l'état d'esprit

Ahah, c'est partout pareil. Presque 3 ans que j'utilise jamais un bug et la que c'est open boom ça crashe  

C'est ça Chu sur la mgration depuis 1 mois, RAS, j'officialise vendredi pour le reste de l'équipe et là bim, 1h que c'est en vrac

Pour ceux qui veulent avoir la Roadmap de Visual Studio :  
 
https://docs.microsoft.com/fr-fr/vi [...] 18-roadmap

Y'en a qui passent ou ont passé des certifs microsoft ?
 
Y'a plus vraiment de certif à jour niveau DEV non ?

Il me semble qu'il y en a des "nouvelles" en SQL2014/SQL2016, mais côté .NET, j'ai l'impression que ça a pas évolué depuis un bail
 
Par exemple, je ne suis pas sûr qu'il y en ait pour .NET Core ni même UWP

 
Bah AZ-200/AZ-201.
Sinon toujours le MCPD App Builder mais il y aura comme pour les autres certifs une transition vers leur "role based certifications". Donc faudra s'attendre surement à un rôle ".Net Developer" j'imagine ou un truc du genre.
 
Les différents chemins as of Septembre 2018 : http://download.microsoft.com/down [...] _24_18.pdf

Les gars, j'aimerai mettre en place de l'envoi de mail dans une petite appli .NET maison (monitoring).
Je vais utiliser au plus simple MailMessage et SmtpClient.
 
Questions :
- je suis chez Orange (Fibre Jet, grand public), donc je suppose que je dois utiliser le SMTP d'Orange pour l'envoi ?
- si vous savez comme ça marche chez eux : je dois demander des credentials spécifiques ? Je ne trouve pas le mot de passe de ma boite @orange.fr ? SSL (port 465) ou pas (port 25) ?
- pour l'@ expéditeur, je peux mettre un truc genre "monitoDiB@toto.com" ou il faut impérativement que ce soit la même adresse que le login SMTP "blablabal@orange.fr" ?
 
La destination ça sera un random compte Gmail/Outlook que je consulte sur mon téléphone
 
Merci d'avance

Fais un test en powershell avec Send-MailMessage tu auras tout de suite la réponse.
Ca dépend des fournisseurs après, et à l'époque, Orange te laissait envoyer sans auth depuis son réseau. Ca a probablement changé depuis.

D'ac, merci ! Bonne idée pour le test !

Il faut trouver les infos de SMTP pour ton fournisseur. Généralement ils communiquent dessus sur leur propre site ou ça se trouve chez des tiers, genre https://serversmtp.com/fr/serveur-smtp-orange/
A condition que ça soit à jour.
 
Attention aussi que sur ton compte l'option POP / IMAP / SMTP soit bien activé, par défaut ça l'est de moins en moins (vieux protocole, failles de sécurité potentielle, tout ça). La solution (totalement naze) forcée par les fournisseurs est donc d'obliger les gens à utiliser uniquement leur webmail, ou une appli propriétaire, qui sont dans les deux cas généralement lents, buggés, et bourrés de publicités indésirables.

Salut,
 
J'ai envie de faire une petite appli C# WPF pour apprendre et j'aimerai la faire bien. En suivant des patterns, une archi un peu règle de l'art etc.
A la base je suis sysadmins, donc suis plutôt powershell et compagnie et qd je code c'est qq fonctions mais sinon c'est tout dans le main.cs .
 
Du coup pour partir sur des bonnes bases que me conseillez vous ? A priori faudrait faire du MVVM. J'utilise un framework spécifique genre MVVMLight ? Je peux suivre le cours sur pluralsight si besoin .

Franchement, avant de faire du MVVM, fais du code behind classique et découpe bien tes fonctionnalités / composants en classe pour commencer (Separation of Concern)
Tu auras déjà pas mal à faire.
Ensuite fais du IoC et du DI.

Apprends ensuite à bien gérer tes évènements en provenance de la vue, et commence à jouer avec le binding et les command.

Seulement là tu pourras commencer à jouer avec du MVVM. Car crois moi c'est vite le bordel, et t'as vite fait d'avoir des fuites de mémoire partout si tu fais pas un minimum gaffe.

Après, les frameworks ont du évoluer un peu depuis, mais se lancer dedans sans avoir déjà fait du dev en WPF c'est couillu.

Tu peux déjà faire du MVVM "natif" histoire de comprendre le principe, tu pourras toujours ajouter après des surcouches ou des composants particuliers.
Mais si l'appli est petite et que tu débutes, tu risques de trouver l'approche MVVM un peu usine à gaz pour pas beaucoup de valeur ajoutée.

Vous avez des bonnes ressources pour apprendre tout ça ?

 
Wabon ? Comment-est ce possible ? (je fais quasiment pas de wpf)

 
 
Merci  

Je viens de voir qu'on a posté en même temps hier, mais franchement je suis de ton avis : le MVVM c'est bien lourd à mettre en place. Donc *si* c'est pas un impératif pour l'appli visée effectivement j'aurais tendance à donner le même conseil que toi.
Quand tu viens du système déjà rien que Visual Studio + C# + XAML + je suppose EF et cie ça fait déjà un paquet de trucs à assimiler sans s'emmerder avec des design patterns pensés pour des applications mammouths maintenues par de grosses équipes.

Pour les ressources je pense qu'un bon bouquin sur WPF + MVVM ça devrait bien aider dans ton cas. Sachant que ça n'a pas bougé des masses ces dernières années, même un bouquin de genre 2012 ferait déjà l'affaire.

 
 
Je vais faire un audit d'application monolithique avec une forte dette technique. Le but étant ensuite de trouver un plan de migration vers une appli plus moderne.
 
Habituellement, j'utilise pas d'outil, je fais du reverse engineering en regardant le code, et en faisant des tests. J'ai rarement besoin d'outil d’analyse de perf, car les bottleneck s'identifient assez rapidement.
 
Vous, si ça vous arrive, vous utilisez des outils ?
 
Je vais ptet passer le tout aussi à SonarQube.

Les outils ont le bon côté de fournir des métriques, donc des trucs factuels et présentables à des managers. Si tu fournis des bons indicateurs comme la complexité cyclomatique ou les dépendances, c'est pas mal mais gaffe à ne pas tout prendre au pied de la lettre (objectifs chiffrés de couverture de code par exemple). Mais faut pas se baser dessus uniquement, la maintenabilité du code c'est aussi (et surtout) la lisibilité, la courbe d'apprentissage, etc... et ça, bon, perso je le ferais en rentrant dans le code comme tu dis.
 
Comme outils, y a évidemment Sonar mais aussi NDepend par exemple. T'as aussi Visual Studio qui fournit un outil d'analyse de code (mais uniquement dans la version Pro je crois).

Désolé pour la réponse tardive.
Déjà en WPF (pas que, mais ce sont les plus évidentes) tu as des références dites fortes de façon très implicite.
Les événements par exemple, le fait de s'y abonner implique une référence forte avec celui qui s'y abonne.
Ainsi, tant que la désinscription n'est pas faite, l'objet en question ne peut être relâché en mémoire.
 
Il y a des façons d'éviter ça (notamment avec des objets WeakReference de mémoire).
Avec le MVVM, tu fais énormément de DI avec une notion de portée que tu peux également gérer.
Donc tu dois bien maîtriser le cycle de vie de tes instances et les relations avec celles-ci, sinon elles ne seront jamais relâchées.

Le problème avec le WPF propre (comprendre MVVM + moteur d'injection de dépendance) selon moi, c'est qu'on passe plus de temps à copier/coller des patterns et remplir les trous (membres d'interface, abonnements/désabonnements à évènements, constructeurs...) qu'à développer l'UI ou coder "l'intelligence" du programme...
 
Pour ça, je trouve que le Winforms se prête mieux à une appli simple, à 2 ou 3 écrans max, et avec des délais courts.
 
Par contre en effet, les possibilités sont vachement plus poussées, et pour du client lourd, on peut faire des choses vraiment impressionnantes en WPF, en bossant en équipe
 
Pour résumer (peut être un peu bêtement, et d'après ma petite expérience à moi) :
- WPF : pour bosser à plusieurs, design poussé, nécessite un architecte et une équipe plutôt Agile
- Winforms : pour travailler à 1 ou 2 personnes (simultanément disons), sans design bien poussé, se prend vite en main, pour des applis plus légères

Winform c'est un peu has been quand même pour un nouveau projet sur plateforme récente avec un minimum d'exigences.
J'aurais plutôt fait exactement le même raisonnement que toi mais avec :
- WPF + code behind + binding à l'arrache (genre un objet public sur le code behind) pour la version simple.
- WPF avec MVVM et tout ce qui va avec pour un gros projet en équipe [etc].
 
Winform c'est parfait pour du prototypage express, ou une appli modeste où t'es sûr qu'on ne va pas te demander d'intégrer des composants visuels chiadés (c'est surtout ça la contrainte).
Sachant que c'est parfaitement possible aussi d'écrire du code dégueulasse en winform, donc le fait de prendre ça au lieu de WPF ne te préserve de rien .

Ah ptin j'avais même pas pensé au WPF "de base" avec le code dans le xaml.cs en effet

A l'époque j'avais fait du MVVM et j'avais également été voir du côté de Reactive Extension pour WPF.
J'ai trouvé qu'un mix des deux étaient vraiment intéressant, parce que d'un côté on avait toute la partie découpage, séparation, réutilisation, et de l'autre, toute la partie UI/UX qui était grandement amélioré.
 
Je sais pas si c'est toujours le cas aujourd'hui.
Chose rigolote, pour ceux qui ont déjà fait de l'Angular2, c'est très proche comme façon de faire.

C'est ça que j'entendais dans mon post plus haut par "WPF natif". Surtout si le but est de se former, ça serait dommage de faire du winform alors que c'est carrément différent.

Oui en effet, ça me parait le plus "simple" pour démarrer

 
J'ai la même vision.  
Un outil pour mesurer la complexité cyclomatique ?
 

Pour l'audit, perso j'utilise les outils d'architecture (Resharper, Visual Paradigm, NDepend, VS...) pour me faire une idée du découpage projet et des classes.
Plus des indicateurs chiffrés (complexité cyclomatique, nombre de warnings à la compilation , ratio commentaire / SLOC, etc). Certains sont intégrés à VS si t'as la licence suffisante, sinon faut taper à l'extérieur. Si tu as un serveur de build sous la main la plupart des infos sont dispos à coups de plugins.
Si t'as accès au repository, l'historique des commits et du nombre de contributeurs peut t'apporter des infos.
L'ancienneté des technos utilisée et leur obsolescence est aussi un paramètre à prendre en compte.

Ensuite y a beaucoup de trucs qui ne peuvent se voir que par le code.
Et surtout tout ça en discutant avec ceux qui l'ont écrit ou enduré ; l'informatique c'est aussi une aventure humaine.

Par exemple j'ai fait récemment un audit sur une appli de 15 ans d'âge, avec un historique bien lourd : base en ASP.Net Webforms VB *sans code behind* qui fleurait bon l'ASP tout court, puis apparition de code behind, puis de class libraries en VB, puis d'autres en C# (mais le tout sans presque jamais penser Objet), puis tentative de réécrire les couches intermédiaires de l'appli en C# il y a moins de 2 ans. Tests unitaires imaginaires, avec environ 0,5% de couverture de code .
C'est un carnage, à part quelques morceaux par endroits tout était bon à jeter, même le code de moins de 2 ans tellement le truc a été mal encadré.
Y a des trucs dont tu peux avoir l'intuition en regardant le code, mais l'historique par ceux qui ont vraiment vécu le truc est encore plus instructif, donc c'est un aspect à ne pas négliger.

Bin ceux que je cite (y compris VS)

 
Mouarf j'avais jamais fais gaffe que c'était dans sonarqube  

 
Quelqu’un ici a mis en place cqrs / évent sourcing dans un projet?

Non, mais c'est quelque chose de très complexe, donc fais vraiment gaffe avant de partir sur ce genre d'archi.