Reprise du message précédent :
.NET 2.1 ???

Net core    
 
J'ai eu l’occasion de tester avec un SPA Angular la version 2.0 et 2.1 preview.  
Rien à voir, temps de compilation améliorer, structure du code beaucoup mieux pensé...
 
Je vais surement migrer deux application qui utilise la version 2.0.6, je vous tiendrais au courant si vous le souhaiter ( surtout s'il y a de la casse   )

T'as pas traîné
Une autre excellente raison de ne pas s'exiler a Paris, en plus des tarifs et des parisiens

+10000 à mon humble avis...
 
Sinon, faudrait vraiment que j'y mette, à .NET Core

Je me dis la même chose. La portabilité je m'en tape mais niveau perfs ça a l'air de carburer encore plus.  
 
Mais j'ai mon petit framework maison que j'utilise dans tous mes projets et y a pas moyen de migrer ça en pur .Net Core.
Par contre ça vaudrait vraiment le coup que je me fasse un projet entier Core MVC qui tourne sur du .Net FW classique, une bonne façon d'attaquer le truc sans tout mettre à la poubelle.  
Me manque juste une idée de projet, ou la motivation de porter un truc existant

Resharper 2018.1.2 out !
Quand je dis que chez Jetbrains ils prennent leurs utilisateurs pour des bêta testeurs, maintenant ils en font même une blague : https://blog.jetbrains.com/dotnet/2 [...] x-bug-fix/

A vous, copains développeurs .NET, quelle est votre avis sur ça :
https://www.clubic.com/mag/diaporam [...] ute-87214/  
 

 
Plutôt "meh" ?
Vous pensez qu'à terme Microsoft va finir par sortir la gestion de code source de TFS pour pousser à utiliser Git ?

Qu'on s'en fout un peu. Ca fait un moment que MS fait copain-copain avec Git, 3 ans que je bosse avec un Git intégré autour de TFS, donc que derrière ils achètent Github c'est pas déconnant.
 
Sur le côté "OMG MS a acheté Github, c'est la fin du monde" je trouve ça très limité comme réflexion. Ce tweet résume assez bien le problème : https://twitter.com/andrestaltz/sta [...] 1712955392

Je suis 100% d'accord avec toi.
 
Moi je m'inquiète juste pour mes petites habitudes au boulot, sous TFS depuis toujours.

Bin pour moi, faut pas trop s'accrocher à ses petites habitudes en dev/IT
Ensuite, sur le sujet Git/TFS, ba le plugin Git dans TFS a une approche très similaire à TFS donc ça déroute pas tant que ça. L'achat de Github c'est de la plomberie, pour le dev au quotidien je vois pas trop ce que ça peut changer.

Ben chez nous TFS fait partie intégrante de nos méthodes de travail.
On a articulé pas mal de nos process de livraison (et donc de gestion de projet, formation interne, communication...) sur nos branches TFS et nos chiffrements en tiennent compte.
 
Sans aller jusqu'au serveur de build (on est une toute petite boite où l'IT est clairement pas une priorité....), je suis un peu frileux à l'idée de devoir passer une période de migration / adaptation

Mais à aucun moment il n'est dit qu'ils allaient remplacer TFS par autre chose (quoi d'ailleurs ?). MS a juste racheté Github, probablement pour la base utilisateurs/la partie "social", pas pour remplacer TFS

Ethiquement, dans le monde informatique j'ai bcp moins de soucis avec Microsoft que Apple, Oracle ou nVidia.
En lisant l'info vendredi je me suis dit que les défenseurs de l'opensource et contempteurs en tous genres de MS allaient bien gueuler et j'en rigolais d'avance, perso je m'en tamponne.
Et si ça peut aider à subir moins de TFS () et plus de Git en entreprise j'approuve. Si ça soutient encore plus MS dans son incursion dans le monde de l'open source amorcée il y a quelques années j'approuve aussi.

 
D'où ma question adressée à ceux qui connaissent un peu mieux le sujet que moi : comment le sentez-vous ? est-ce que c'est le moment de lancer un projet de 20j pour se former et migrer vers un Git, ou est-ce que je peux rassurer mon DG, lui dire qu'on garde TFS encore quelques années ?

Alors attention, on parle de quoi ? TFS en tant que solution complète (ex : TFS 2015, 2017 et maintenant VSTS) avec bug tracking, usine de build, déploiement, etc... ? Ou TFS uniquement pour le versioning ?
Nan parce que dans le dernier cas je saurais pas dire, la dernière fois que j'y ai touché stait en 2012

Formez-vous sur Git quoi qu'il arrive. A titre perso, à titre pro, j'en sais rien, mais mettez-vous-y. C'est présent chez tous les clients que j'ai vus depuis 2012, ça a pris une ampleur monstre et il y a des concepts à bien comprendre. Franchement, c'est limite un must-have dans le CV aujourd'hui.
Pour bien commencer, un tuto super sympa et interactif : https://learngitbranching.js.org/ Au pire des cas, vous vous prenez 1h deux ou trois fois par semaine avec les collègues, vous jouez avec ce site et en route.
 
Maintenant, note bien que c'est pas le rachat de Github par MS qui devrait motiver ce choix, mais purement et simplement l'envie de pas trop être décalés dans votre métier

Merci pour toutes ces infos

Clair que Git aujourd'hui c'est incontournable. Et savoir à quoi correspondent les trucs autour (Gitlab, etc) pour ne pas avoir l'air à la ramasse si on t'en parle.

Git est le mode de fonctionnement par défaut lors du Setup de TFS et ceci depuis quelques années
Maintenant presque partout c'est Git qui est utilisé. C'est assez simple a appréhender et je vous recommande de vous y mettre si vous ne connaissez pas.
 
La gestion de branche qui est souvent appliquée est Gitflow: https://danielkummer.github.io/git- [...] index.html
Mais vous trouverez des gestions de branche plus simplifiées pour les petits projets (à la gitlab ou github)

On va pas lancer le débat mais pour moi le feature branching c'est l'horreur Moins y a de branche "long-lived" moins y a de chance de foirade. Là on galère avec 3 branches (1 dev, 1 prod, 1 release), on voudrait passer à 2 mais faudrait automatiser pas mal de tests hors TU pour que le release manager ne nous casse pas les c... euh pieds
 
Pour moi le modèle idéal c'est le trunk based, mais faut une bonne discipline dans l'équipe.

Dans de grosses équipes (>>6 dev), le trunk based est impossible à gérer je trouve  

Pareil, je suis contre la multiplication des branches.
Déjà à partir de 3, c'est galère quand on commence à bosser sur l'une mais qu'on veut pas impacter une autre, et on commence à diverger assez rapidement.

Quand je suis arrivé ici, le développeur en place avait une approche différente : une seule branche, mais des itérations par shelve / réservation.
Il avait ainsi une branche iso prod pour ses hotfixs et livraisons, et à chaque fois qu'il bossait sur un projet / évol, il aboutissait à un shelve qu'il ne livrait que sur les environnements de test/qualif.
Quand la recette était concluante, il archivait ses modifs (donc la dernière version de son shelve) sur le tronc commun, et il poussait en prod.

Inutile de dire que quand je suis arrive, ça a duré 2 semaines avant qu'on crée de belles branches indépendantes et proprement séparées

Après, créer des branches à chaque version, c'est pas très relevant non plus... Qui va franchement aller remonter 8~9 ans de code pour l'exécuter ou le livrer (puisque pour la consultation seule, le versionning de TFS le fait déjà naturellement)

EDIT : Mais sinon, clairement au quotidien, avoir une seule branche de développement et une de prod, on sent bien qu'il manque un endroit où placer son support versus son développement à long terme (= projets d'évol).
Du coup, pour moi, je dirai que l'idéal, c'est 3 : dev / main (+hot fixs) / prod (qui sert de référentiel de livraison).

Mais en écrivant, je ne peux m'empêcher de constater que ça dépend très fortement des impératifs imposés par le client au final (nombre d'environnements, complexité des environnements, chiffrages/certificats à mettre en place, SI articulés autour....)

Ouais, mais imagine le merdier avec les branches et les merges...

 
Les merges et les conflits, je suis désolé si on bosse sur des choses propres et bien architecturées découplées (ASP .NET MVC, par exemple, ou MVVM en applications lourdes), on minimise déjà pas mal. Charge après au chef de projet de pas faire bosser 5 gus sur CustomerController.cs en même temps quoi... Sinon c'est que le découplage est pas bon
 
Sinon, on se pose tous ensemble, le vendredi, une petite heure et on résoud les conflits ensemble

Ca fait des années que je bosse seul (ou quasi) sur les projets dont j'ai la charge, ça fait remonter des souvenirs assez désagréables ces histoires de branching sauvage et de merges .

Ah ouais non, le jour où le chef de projet interviendra pour dire qui bosse sur quelle classe parce qu'on a des soucis de résolution de conflits, je reste pas dans la mission

Entre 30 et 100 commits par jour. Une 20ene de PR par jour. Aucun soucis.

master = release courante
feature/xxxx-* = chaque dev est associé a un ticket
release/rc* = constitution des release candidate a partir de master + feature/ validées (via des pull request sous TFS, par le release manager en lien avec le chef de projet)
integration = merge de l'ensemble des feature systematique

Apres on ajoute la notion de tag dès qu'on est sur les rc, et on merge vers master quand ca part en prod

Après tout dépend de l'equipe projet. Il y a un lead dev par projet, un lead tech qui chapote, et de la formation à git pour ceux qui ne maîtrisent pas.

 
Tout pareil : 8 equipes de dev

Ca c'est tellement chiant. Soit tu merges régulièrement, auquel cas tu passes ton temps à valider des PR (si c'est 1 seule personne qui est release manager, je trouve que c'est pire) ou demander/attendre qu'on te valide la tienne, soit tu merges toutes les X semaines auquel cas c'est open bar des conflits.

Tout le monde valide les PR vers integration, qui servent a la revue de code.

Le release manager ne fait qu'assembler la RC, aide a les qualifier, et planifier/preparer les déploiements.

Et oui, on mere'ge souvent, plusieurs fois par jour. On est même capable au besoin de faire plusieurs release dans la semaine (qui partent en prod), alors que l'on est sur des applications extrêmement sensibles (systemes de paiement)

Bonjour bonjour,  
Je sais pas trop si je suis au bon endroit, mais depuis 10 jours (date de la MAJ W10) je rencontre un problème plutot génant, sans trouver de solutions qui me convienne.
 
J'ai des solutions stockées sur un partage réseau.
L'execution de certaines "fonctionnalités" (accès webservice, mails etc...) se mettent en erreurs (un argument invalide a été fournis).
 
Si je copie la solution en local, pas de soucis.  
 
D'après mes recherches, ca proviendrait des droits/privilèges du framework. Mais je ne vois pas comment changer cela.
A savoir qu'on a plusieurs postes qui se sont mis a déconner, et d'autres non, alors qu'il semble qu'on ai tous eu la MAJ Windows 10.
 
Si vous avez des idées, je suis preneur.
 
Infos complémentaires : nous utilisons VS2010 et 2013, framework 3.5 et 4, c'est tout pareil.

Pour moi, exécuter un programme depuis une UNC ça déclenche forcément des alertes de sécurité, et à juste titre d'ailleurs. Rien à voir avec les updates Windows, .Net, VS ou autre, ça a toujours été comme ça et c'est très bien.
 
Questions :  
- C'est pas clair, c'est quoi que tu as sur le réseau : le .sln et les sources que tu fais tourner depuis VS, des EXE, du Web (WS hosté dans IIS, etc) ?
- C'est quoi cet environnement bizarre et dégueulasse où on fait tourner des trucs depuis des emplacements sur le réseau ?
 
Tip :
- En montant l'UNC comme un disque virtuel il y a peut être moyen de faire sauter une partie des sécurité. Mais ça reste dégueulasse .

Je n'ose croire que c'est lié au """"versioning"""" en mode share réseau

J'ai pas osé le suggérer parce que je préfère continuer de vivre dans un monde où ce genre de choses n'existe pas .

Ca a peut être toujours été comme cela, mais avant la dernière MAJ, je ne rencontrai pas ces soucis. Elle a peut être juste rétablie des règles de sécurités.  
De plus, tous nos postes ne sont pas touchés, c'est surtout ca qui me chagrine.
 

 
"On a toujours fait comme ça"

 
On lui a peut être imposé  

Personnellement je n'ai jamais eu de formation en ce qui concerne .net, et ma formation de base était plutôt légère (BTS info de gestion) donc les bonnes pratiques en ce qui concerne la sécurité, le déploiement me sont inconnues.
Je suis pas contre l'évolution, et faudra qu'on y passe, mais faire changer 15 ans d'habitude, c'est pas évident.

A un moment tu proposes, tu mets en place des trucs, etc...
Autant y a des trucs qui sont difficiles à changer, mais des outils du quotidien genre bosser un .sln partagé avec probablement 0 versioning, faut mettre un place les bases et les montrer aux copains.
On avait fait ça y a 10 ans avec 2 collègues, on avait du versioning mais les binaires de prod étaient compilés sur nos machines depuis Visual Studio... ba on a mis un petit TeamCity en place avec 1 machine qui faisait agent de build, on a montré le truc, on nous a filé un PC dans un coin qui est devenu notre serveur de build, etc...

Je sais pas, faut faire preuve d'initiative un peu. On est (souvent) des ingés, payés (souvent) comme tels, alors se résigner quand on a pas les bases, c'est pas super pro je trouve.

EDIT : ouais ba OK, t'as appris sur le tas, mais si t'as pas les bases bin faut aussi les chercher. Je veux pas t'engueuler ou quoi, je pige bien qu'il y a un historique, mais si tu sens qu'il te manque des bases faut pas hésiter à chercher et secouer un peu le cocotier. Les mauvaises pratiques qui sont là depuis 15 ans, c'est peut-être difficile de les changer mais c'est pas en se fondant dedans sans rien dire que ça va bouger Sans parler de l'impact sur ta carrière.

Vais pouvoir allez chouiner dans le bureau de mon DSI pour avoir une formation digne de ce nom alors  
 
L'autoformation c'est bien, mais ça a ces limites. Et si tu ne connais pas les bonnes pratiques, c'est difficile de dire ce qui est mauvais.  

Du coup on peut en parler ici en gentleman sans juger les gens    
 
Toujours intéressant de voir que pour certains des choses sont indispensable, alors que pour d'autre c'est une perte de temps