Reprise du message précédent :
J'ai utilisé CLR Profiler, mais pas facile à faire fonctionnement de façon pertinente. Le profiler intégré à VS 2013 (Premium/Ultimate) est pas mal pour des trucs basiques..

C'est vendu par la même boîte (jetbrains) et R# est leur produit phare, mais dotTrace est un soft à part entière, pas un plugin (même si il y a une certaine intégration à R# juste pour améliorer l'ergonomie)

Pour VS le surcout de ces versions ne se justifie pas pour moi donc j'écarte d'emblée cette option . CLR Profiler c'est plus orienté profiling mémoire que performances si je me souviens bien. Je n'ai pas précisé mais tous les softs que je mentionne sont des profilers de performances.

Oui en effet c'est orienté profiling mémoire, mais ça permet d'identifier des problèmes de créations d'objets en boucles et donc des lenteurs (j'ai eu un cas de GC qui consommait toutes les ressources car trop d'objets étaient créés dans des boucles dégueulasses)

Il y a des gens qui s'amusent avec VS 2015 ? La CTP 5 est sortie mi janvier : http://www.visualstudio.com/en-us/news/vs2015-vs.aspx

Hello,
Vous connaissez de bonnes extensions pour Visual Studio OU resparper pour améliorer le support des JS ?

Je cherche surtout un truc qui permette de naviguer rapidement entre les classes et les méthodes, sous la forme d'un treeview ou alors exactement comme la barre de navigation qu'on a dans n'importe quelle classe en c#.

Je me tape la maintenance d'une appli où il y a des JS de plusieurs milliers de lignes et naviguer là dedans c'est l'horreur vu que tout ce que j'ai c'est le Ctrl+F.

Merci

ReSharper 6 le fait, si je dis pas de connerie. En tout cas j'avais pas trop de souci pour me balader dans du source JS quand j'en avais besoin dans ma dernière mission (je ne l'ai pas là, donc je peux pas te dire).

Ah ouais, je viens de trouver où c'est planqué. Il faut activer la fenêtre "File structure" de R#. J'avais déjà essayé mais c'était vide avant donc je croyais que ça ne fonctionnait pas pour le JS, mais si...
Je me disais aussi, c'est curieux que ça n'existe pas
Merci

Ne faites jamais confiance à un intégrateur système qui vous dit que les <customErrors> de votre appli web sont bien à "On" sur votre serveur de production, même en lui ayant donné la forme exacte et en lui demandant de vérifier deux fois.

Si elles sont juste à "on" (notez la minuscule), c'est comme si elles étaient à Off : l'erreur de syntaxe n'est pas vue à l'init de l'appli, mais dès qu'une erreur est levée, car c'est apparemment là qu'a lieu le premier accès.
Du coup la lecture de la section customErrors déclenche elle même une erreur (pour avertir du fait que la section est mal formatée) et c'est traité par une erreur serveur .

Ce qui m'est venu à l'esprit en te lisant :

Le genre de conneries ou tu peux y passer des heures à trouver la cause.

Ouais, surtout quand t'as pas le fichier sous les yeux. Du coup j'étais parti sur d'autres pistes, genre le form authentication qui parait t-il peut interférer avec les custom errors ou une erreur levée sur ma page d'erreur elle même (qui n'est pas du tout statique).

Sondage sur les solutions d'intégration continue :
https://polldaddy.com/poll/8635275/
Et vous ?

Note : le sondage vient de redgate (reflector, etc), d'où une forte prévalence des solutions orientées .Net plutôt que généralistes.

J'ai voté "Cruise Control" et "Team Foundation Build" (une large préférence pour le CCNet)

'tain, j'utilise rien de tout ça, je sais même pas à quoi ça sert

Perso j'ai utilisé Teamcity.  
Ca manque un peu de métrique et tout ça mais côté IC ça fait plutôt bien son taf, et ça s'installe/administre très simplement, sans truc payant ni environnement lourd à mettre en oeuvre.
 
TFS j'ai des clients qui s'en servent mais c'est une usine à gaz pour moi, à petite échelle tu passes plus de temps à comprendre et résoudre les merdes diverses que ce que tu gagnes en productivité.  
Après sur de gros projets avec des gens dédiés à l'administration du bouzin c'est une autre histoire et ça doit avoir des qualités vu qu'il y a des gens qui s'en servent .
 
Comme solution généraliste Jenkins (ex hudson) est pas mal, puissant et compatible avec plein de choses. Par contre (java oblige) c'est un agglomérat de plein de trucs qui ne s'aiment pas toujours entre eux .
 
Je ne me souviens plus si j'ai déjà essayé CCNet, je connais de nom mais si je m'en suis déjà servi ça ne m'a pas marqué en tout cas .

Non sérieusement tu développes dans quel contexte ?

Déjà testé Hudson, c'était un peu casse pied à mettre en place pour .NET.
Pour java ça tournait pas trop mal.
Mais mon chef trouvait ça inutile et qu'on avait passé trop de temps dessus.
 
De nos jours on a toujours pas de solution d'intégration continue  
Là où je rigole moins, c'est que j'ai un collègue qui ne sait pas commiter correctement, et du coup quand on récupère les sources, la plupart du temps ça ne compile plus  
Mais sinon ça sert à rien  
 
Bref. Vivement notre nouvelle machine de build que je colle un vrai outil d'intégration continue qui va bien.
Et si y a la possibilité de baffer celui qui commit comme un sagouin, c'est encore mieux.

CCNet, il faut faire du script, beaucoup (généralement écris en NAnt). C'est ultra flexible, facile à appréhender. Par conter pour les très très gros projet en intégration continue complète et complexe, au bout d'un moment on sature et il faut quelque chose de plus user-friendly.

TFS c'est la vraie usine à gaz.
Dans mon ancienne mission, on utilisait CCNet couplé à TFS pour la partie Work-Item / Source Control

T'es développeur web ? ( )

Je produis des DLL, utilisées dans un ordonanceur de jobs (solution développée en interne) tout simplement Pour développer et tester mes applis, j'ai fais tout simplement une ConsoleApplication qui utilise la DLL. Pas d'interface Pas de Web ni de WPF

Alors ce type d'outils est d'autant plus pertinent pour toi !
Tu fais des tests ? (des vrais, j'entends , unitaires/intégration)

Pas assez comme beaucoup, j'utilise juste les classes de test intégrées à VS.

Si tu as un projet de test unitaire avec une couverture de code décente c'est déjà pas mal !

Moi j'ai le bonheur d'avoir repris une application de >500 000 lignes de codes avec exactement 0 tests unitaires .

Pour faire court une solution d'intégration continue ça te sert par exemple à :
- Compiler à chaque nouveau commit, comme ça si un développeur archive un truc foireux ou oublie un fichier on n'attend pas le lendemain pour le découvrir, ce qui est pratique surtout si le mec s'apprête justement à partir en congé pour 15j en emportant le pc portable sur lequel il développe.
- Executer tes tests à chaque fois qu'un commit a lieu, comme ça si un commit pète un test tu ne mets pas 15j à t'en rendre compte
- Surveiller les métriques liées au code : les trucs abstraits comme le couplage, sloc, la complexité cyclomatique, mais aussi la couverture par les TUs, etc.
- Générer et stocker tes builds, donc mieux maitriser tes releases.
- La génération peut aussi appliquer un scénario complexe et répétitif, chiant à faire la main (du genre sélectionner le bon profil, générer X, retirer Y,  ajouter Z, faire un setup avec tout ça...). Et rien que pour ça tu peux me croire ça vaut le coup, surtout quand tu bosses avec une CP qui trouve toujours un truc à ajouter ici ou là et qu'il faut refaire toute la procédure alors que tu viens de finir pour la troisième fois de la journée.

Comme toutes ces opérations ont lieu sur un serveur dédié tu ne perds pas de temps à les réaliser sur ton post local.

Je vais me pencher sérieusement là dessus. La raison c'est qu'on travaille en relativement petite équipe avec des outils archaïque pour le versioning.

Genre ? Sourcesafe ? Winzip ( ) ?

T'es pas loin. VSS mais on migre vers ... RTC.
Attention, je suis pas dans une PME hein, près de 80 000 collaborateurs et presque 30 millions de clients

Ho putain Visual Source Safe.
J'ai découvert ça que j'étais en stage, quelle horreur ce truc  
 
Même là où je bosse (petite PME) on n'utilise pas ça (on est sous SVN, perso je préférerai passer sous GIT mais bon.)

Putain, malgré que le projet System.Data.SQLite ait des années et que l'EF en soit à la version 6, faire fonctionner ça ensemble c'est une belle galère (problèmes bizarre de designer, code généré incomplet, références et fichiers de confs moisis...).
J'ai mis des jours avant d'arriver à faire mon premier insert, ça fonctionne enfin, mais du coup j'hésite à utiliser le truc sur de la prod.

Certains s'en servent ?

 
J'ai arrêté SQLite, trop de galère avec les version 32bits/64bits... et trop de truc qui sont pas gérés correctement avec EF

Ok je suis pas le seul alors. Sur Internet ils ont l'air de dire que ça passe tranquille.

Maintenant faut que je comprenne pourquoi j'ai des perfs immondes (1s / insert )

edit : en fait c'est le premier accès qui est super mou, après ça va à peu près.

+1 sur tout. Super fan de TeamCity, léger et pratique. TFS c'est horrible, enfin les conditions dans lesquelles je l'ai utilisé étaient pas top non plus donc ça a pas dû aider à me donner une image positive Mais bon, franchement pas convaincu face à TeamCity.
Idem pour Hudson/Jenkins, utilisé dans un cadre Java, pas mal mais un peu lourdaud et chiant à configurer de ce que j'en ai entendu dire (pas moi qui l'ai fait).

J'ai pas mal utilisé SQLite, sympa pour des protos, mais je me vois mal le faire en prod. C'est dans quel cadre ?
Pour les perfs y a des astuces aussi un peu (typiquement l'utilisation de requêtes paramétrées si tu l'attaques en direct ; je sais pas avec EF 6) mais sinon ça déroule bien.

"Prod" dans le sens "non expérimental", c'est pour une appli client lourd qui doit stocker pas mal de petites infos.
SQLite me parait une très bonne solution, c'est le support EF6 vraiment décevant qui m'a surpris vu les galères que c'est à faire fonctionner rien que sur mon poste de dév, alors que je pensais qu'en installant juste quelques bricoles par nuget + les libs pour le designer ça irait tout seul.

Ouais non, la gestion des binaires et autres dépendances c'est vraiment le point noir du truc

Y'a des gens ici qu'on deja implementer/utiliser un state Pattern ou State Machine pour une application web (MVC + EF)
 
Sur le projet au boulot j'ai pour idee de tracker le changement d'etat qu'un user fait sur une entity, de maniere a controller le fait qu'il puisse pas faire ceci, avant cela etc...
 
D'habitude je fais a l'arrache, dans la business logic de chaque action je check les differents cas et fait en fonction.
 
Mais j'ai l'envie de faire ca de maniere plus jolie, ca me permettrais de controller les actions a l'execution mais egalement afficher ou cacher des boutons en fonction de l'Etat courant
 
Je suis tomber sur la librairie stateless https://github.com/nblumhardt/stateless (par le mec qui a cree Autofac)
 
Ca a l'air de marcher plutot bien sur une appli console, mais porter ca sur une grosse appli MVC + EF database first je m'y essaye mais j'ai l'impression de pas savoir ou je vais
 

Très bonne question . Malheureusement moi (comme toi sans doute) j'ai toujours fait des bricolages localisés et spécifiques, donc pas trop de conseils à donner pour généraliser ça sur un modèle d'archi .

Tu devrais en dire plus sur les scénarios à couvrir. Et comme on est en web dis nous également si tu dois t'attendre à des soucis de concurrence multi utilisateur (dans ce cas tu devras peut être gérer aussi un système de lock sur tes entités)

La question est très intéressante, j'espère que tu partageras tes trouvailles, bon courage !

C'est pas un Workflow qu'il te faudrait mettre en place ? (yype Microsoft Workflow Foundation)

Personnellement j'essaie de gérer au maximum ces contraintes directement sur la BDD.
Après, j'ai une classe de DAO de base qui relance la transaction 3x uniquement quand la connexion met du temps et quand il y a un verrou.
Le scope de la transaction est géré par la classe business au dessus.
Pour le cas des check constraints je travaille avec le code sqlnumber et le message. C'est pas portable sur d'autre sgbdr mais j'ai rien trouvé de plus propre et de plus intègre que de gérer uniquement via la BDD.
Tu as tellement de façon de contourner les règles métier en application Web..

Il y a bien une idée de workflow dans la gestion d'état mais par contre je ne pense pas que WF puisse aider .
edit, pour développer : à moins que ça ne se soit bien enrichi WF n'est pas trop "interactif" ni orienté gestion d'états, il me semble que le but c'est plus de pousser un certain nombre de trucs en entrée et d'exécuter en one shot une série d'actions selon un scénario (d'où l'idée de workflow).

Je viens de voir que j'ai répondu un peu à côté de la plaque. Sorry, j'ai encore le décalage horaire dans la gueule