Reprise du message précédent :

 
La version classique c'est un "Go To" ( je suppose que c'est la même chose que "Navigate To" ), ça te permet de naviguer vers du code en fonction de différent snippet ( rechercher de fichier, membre d'une classe, allez à la ligne... ).
 
3 fois que je l'utilise par réflexe aujourd'hui, 3 fois que le ventilateur de mon PC s'emballe et quand j'ouvre le Gestionnaire de Tâche, je vois la consommation mémoire de VS 2017 grimper en flèche, la première fois que j'ai remarquer j'étais à 1.5Go.
 

J'avais ce soucis avec la version précédente deja par moment

 
Ok. c'est quand même assez chiant    
 
Mais j'ai l'impression que ça dépend des projets ouvert. Je verrais bien.

Chez moi avec VS 2017 en anglais + R# ça ouvre le "Recent files" de R#.  
Pas réussi à trouver l'équivalent VS à Go to dans le menu Window. Donc je ne peux pas te dire

 
Pareil, pour le moment je suis resté sur 2015.
 
Bon en tout cas pas toujours prêt à me mettre sur .NET Core.
 
Même si du coup asp.net core à l'air bien

 
Perso je suis pas sur d'utiliser Visual Studio pour du .Net Core. J'aime bien VS Code  

Hier mon compilo et mon IDE se sont mis à dérailler sur un assembly spécifique en me disant qu'il ne trouvait pas telle classe que je venais justement de déplacer, ou à l'inverse qu'elle existait en double, plus des vautrages aléatoires du designer, etc.
J'ai passé 30 minutes à tenter de vider les différents caches, relancer VS, virer les suo/csproj.user (sans trop d'espoir)...
 
Pour au final constater à l'instant que cette saloperie d'assembly s'est mise je ne sais comment à référencer une version compilée d'elle même sortie de dans C:\Temp\vs6FF9.tmp\Release\
 
Outre que je me demande bien comment ça a pu arriver, je n'aurai pas été contre au moins un petit warning à la compil, parce qu'a priori une assembly qui référence un truc qui porte le même nom que ce qu'elle génère elle même, on peut s'attendre à ce que ça pose quelques soucis

Petite question ...
 
Je suis développeur Aspnet  principalement autour d'un socle mvc5 DbFirst & Fw 4.6
 
Je brasse des applications avec beaucoup beaucoup  de data &  formulaires ect ect, en gros des applications "métier" type intranet dans le secteur bancaire
 
Le DbFirst m'offre une rapidité de développement importante avec la génération automatique des controllers , la souplesse syntaxique de Razor ect ect  
 
Seulement,  je remarque  que certains utilise AngularJs avec Mvc5 et je me pose la question , de la pertinence de venir coupler ces derniers
 
 - D'un point de vue rapidité de dev je suis forcement plus lent , puisqu'il s'agit de réécrire l’intégralité du controller et la vue associée ?

C'est quoi l'intérêt que tu vois à Angular dans ton cas ?
La grosse différence se passera côté client, ça dépend de tes contraintes au niveau UI, etc.
Si tes formulaires ont une ergonomie et des perfs qui te conviennent en l'état, t'as pas forcément besoin de faire du Angular, etc.

Mettre à plat des Exception dans un logger, c'est toujours galère si on veut être assez exhaustif (logger, les inner exception, logger les messages d'erreur HTTP des HttpRequestException, ....)
Je n'ai pas trouvé de NuGet qui permet de faire ça bien. Des idées ?

Tu veux le logger complet ou juste la gestion des exceptions ?
Personnellement je suis un adepte de NLog. La gestion des exceptions est bien foutue et il y a un package spécial web.

Bon, sinon, coup de gueule du jour (je râle pas assez, c'est mauvais ) : j'ai l'impression que ces c****** de Jetbrains recommencent à prendre leurs utilisateurs pour des cobayes de leur bouse en version alpha . Une fois sur deux l'autocompletion m'affiche le même truc en autant d'exemple que je tape de touche, et il me rajoute des caractères redondants en fin de ligne sortis de nulle part (le classique c'est " );". Manifestement leur nouveau modèle de licence bien chiant ça ne les pousse pas à dévéroler leur truc

On utilise Log4net, mais ça gère mal les aggregateException par exemple.
Avec certain type d'exception, il y a des choses vraiment intéressantes à logguer... je cherche un moyen de mettre tout ça "à plat"

Sinon, jamais compris l’engouement pour les outils Jetbrains

Ah ouais les AggregateException c'est quand même un cas bien spécial, sans parler du bordel autour (en fonction de comment se passent tes tâches parfois certains trucs ne sont pas appelés du tout même en cas de vautrage interne, etc). Je trouve ça génial la TPL mais honnêtement des années après je ne suis toujours pas à l'aise avec.
A mon avis faut pas compter sur une lib toute faite pour gérer ça en 3 coups de cuillères à pot.

edit : et moi je kiffe Resharper et je ne me vois plus bosser sans, mais ça me pète les couilles leur manie d'introduire régulièrement des régressions complètement débiles d'une version à l'autre alors que d'après le Changelog ils n'ont même pas touché à la partie qui foire

+1 pour Resharper et leur IDE pour Java est vachment bien aussi

https://blog.jetbrains.com/dotnet/2 [...] -2017-2-1/
Les blaireaux    
Ils te sortent une release corrective qui corrige quelques trucs que personne n'a remarqué, mais à en croire les commentaires ils ne corrigent pas LE bug défonceur de code qui rend R# abominable à utiliser depuis la version précédente et sur lequel tout le monde râle.
 
 

Mais pourquoi ce n'est qu'aujourd'hui que je remarque que Exception.ToString() fait super bien le taf pour afficher correctement le contenu de l'exception et la stack ?? Et qu'on a été une 10ene à découvrir cette magie cet aprèm'  
Faut que je test avec les AggregateException...

Dans ma mémoire le ToString n'était pas surchargé sur les Exception... et ça se trouve c'est géré depuis .Net 4.0 voir 3.5  

Je ne savais pas non plus

Ah non, même en .Net 2 le ToString() a toujours permis de récupérer sous une forme pratique Message, Stack trace, InnerException, etc.
En 1.x je ne saurais l'affirmer par contre.
Je pensais que t'avais besoin d'un truc plus fin, genre pour contrôler la hiérarchie de InnerExceptions, etc.
Pour les AggregateException je ne sais plus ce que fait un simple appel à ToString() mais pour moi t'es de toute façon sensé faire un truc intelligent en passant par Flatten, Handle, etc.

edit : je viens de faire le test à l'arrache avec trois try/catch imbriqués dans un main :

En .Net 2.0 ça donne :

System.Exception: 3 ---> System.Exception: 2 ---> System.Exception: 1 ---> System.DivideByZeroException: Attempted to divide by zero.
   at ConsoleApplication1.Program.Main(String[] args) in c:\Temp\ConsoleApplication1\ConsoleApplication1\Program.cs:line 21
   --- End of inner exception stack trace ---
   at ConsoleApplication1.Program.Main(String[] args) in c:\Temp\ConsoleApplication1\ConsoleApplication1\Program.cs:line 45
   --- End of inner exception stack trace ---
   at ConsoleApplication1.Program.Main(String[] args) in c:\Temp\ConsoleApplication1\ConsoleApplication1\Program.cs:line 45
   --- End of inner exception stack trace ---
   at ConsoleApplication1.Program.Main(String[] args) in c:\Temp\ConsoleApplication1\ConsoleApplication1\Program.cs:line 45
 

Et en 4.6.2 :

   System.Exception: 3 ---> System.Exception: 2 ---> System.Exception: 1 ---> System.DivideByZeroException: Attempted to divide by zero.
   at ConsoleApplication1.Program.Main(String[] args) in c:\Temp\ConsoleApplication1\ConsoleApplication1\Program.cs:line 21
   --- End of inner exception stack trace ---
   at ConsoleApplication1.Program.Main(String[] args) in c:\Temp\ConsoleApplication1\ConsoleApplication1\Program.cs:line 25
   --- End of inner exception stack trace ---
   at ConsoleApplication1.Program.Main(String[] args) in c:\Temp\ConsoleApplication1\ConsoleApplication1\Program.cs:line 30
   --- End of inner exception stack trace ---
   at ConsoleApplication1.Program.Main(String[] args) in c:\Temp\ConsoleApplication1\ConsoleApplication1\Program.cs:line 35

Donc ça déplie bien le type d'exception, le message, les inner exceptions. Par contre assez curieusement la version .Net 2.0 se foire sur les numéros de lignes.

NHibernate dans un contexte asynchrone :

FYP

Jamais eu de soucis avant, mais là je suis totalement bloqué et dans une merde pas possible...
Je me demande si demain je vais pas tout swticher sur autre chose, mais je ne sais pas quoi

Perso ça fait pas mal d'années que j'ai abandonné NHibernate et les autres ORM que l'EF.  
A part en terme de perfs je ne vois pas quel intérêt NH peut encore avoir (sauf en legacy bien sûr), et encore il parait que l'EF Core a rattrapé et dépassé NH en termes de perfs.
 
Mais bref, concrètement c'est quoi le souci ? C'est quoi qui est asynchrone dans le bordel et pourquoi ça pose un souci ?

Là NH c'est de l'héritage historique. Avant EF Core, il n'y avait pas photo : NH était bien devant. Passer à EF Core n'est pas vraiment envisageable sur ce projet, mais Dapper pourrait l'être (mais ça me gonfle de refaire tous les mappings)

Je suis dans une WebAPI qui communique avec une autre API pour faire de la synchro. En asynchronisme top-down, mon thread de début de traitement n'est pas le même que mon thread de fin de traitement (changement de thread id après les call HTTP, merci async/await) => impossible de récupérer ma session NHibernate, mon context est perdu, en créer un nouveau est également impossible. Supprimer l'asynchronisme, et je me retrouve en deadlock ( https://blog.stephencleary.com/2012 [...] -code.html )

Ah je vois, et je comprend le côté NHibernate.  
 
Vu que je boycotte le machin je ne sais pas/plus du tout comment fonctionne le système de sessions et comment le partager entre threads (en supposant même que ça soit thread safe, c'est peut être foireux par design !).  
 
Tu ne peux pas t'en sortir en utilisant un injecteur de dépendances avec une gestion du cycle de vie ? Y a pas un bordel du genre SessionFactory dans NH ou qqch comme ça qui pourrait se tweaker pour ton cas ?

Le soucis est que ce qui se passe dans la SessionFactory est très opaque. J'ai bien ma session, je peux l'observer, mais je ne peux pas l'utiliser dans un autre thread que celui dans laquelle elle a été créé. J'ai horreur de ce genre de framework où tout est opaque (ça vaut pour les frameworks de DI)

Sur le papier, il semble que je dois pouvoir m'en sortir en bidouillant la surcharge de SessionFactory, mais ça ne donne rien (GetCurrentSession() me jette). On est à deux à bosser dessus depuis mardi, je déprime là

A part ça, il y a des utilisateurs de Teamcity (outil d'intégration continue gratuit de Jetbrains) ici ?

Je l'ai installé il y a trois jours sur mon serveur de dév, et j'ai remarqué un truc désagréable depuis : même quand TC ne branle absolument rien (0 commit, 0 build), j'ai en moyenne 2Go d'écriture disque par jour.
Mais l'espace disque utilisé lui ne varie absolument pas (<0,1%) et aucun log ou autre suspect.
C'est sur un SSD donc j'ai l'indicateur SMART qui va bien pour voir le volume d'écritures, ça monte de façon très linéaire depuis que j'ai installé TC. C'est con parce qu'à part ça, il est pas mal.
C'est du java, donc le truc bouffe en permanence plus de 500Mo de RAM et il doit y avoir des trucs totalement mystérieux et inutiles qui tournent...

Je vais créer un ticket chez JB mais je me demandais si certains avaient vu ça ?

Ah ouais, pas marrant. J'imagine que vous avez déjà lu tout ce qui se raconte sur NH et le multi threading, mais peut être que qqun qui bosse avec passera ici.
Je dirai juste que peut être que si l'accès à la session est bloquée hors thread initiateur c'est justement parce que le truc n'est pas du tout thread safe par conception ?

Demain je vais quand même essayer de remonter une archi similaire à ce qu'on à mais avec EF Core... mais j'ai peur du temps de dev pour la migration... et peur des potentiels problèmes qu'on va se taper.
Avec NH, l'avantage c'est qu'on à une très grosse maitrise / expérience du produit.

Je suis en totale panique ce weekend    

EDIT : ok, un projet 4.6.2 vide avec juste les nuget d'EFCore, et plus rien ne compile   (vs2015, watmilles trucs à installer du coup)
Le .Net, ça devient de plus en plus comme le Java

Euuuh mais pour faire du Core 2.0 il ne faut pas avoir en target netcoreapp2.0 (ou à la limite Standard) plutôt que .Net 4.6/4.7 ??
Il faut aussi avoir l'update 3 de vs2015 je pense.
Et oui, effectivement, c'est le bordel . Gageons que d'ici deux ans il n'y aura plus toutes les lourdeurs liés à ce schisme tardif de notre vénéré FW.

Mais je conseille pas

Bon je vais surement dire des conneries, mais le fait de balancer des idées, même bidon te fera peut être trouver une solution  

Je suppose que tu as configuré Nhibernate pour qu'il construise automatiquement un contexte a chaque requête http ?

Tu peux pas instancier un autre thread qui serait en charge de l'instanciation du context et des appels Nhibernate, et communiquer ensuite via pipe ou autre entre ton thread de départ et d'arrivée ?

Remarque ça sera ptet le même problème, tu pourrais pas créer un contexte nhibernate dans le nouveau thread   ?

Peut être que Nhibernate te laisse pas créer un autre contexte car sa factory considère que tu en as déjà instancié un pour cette requête http ? Du coup depuis in thread vide, sans contexte, peut être que tu pourras en instancier un.

Je pense que c'est exactement le soucis, que l'on soit en mode "call" ou "web". Il faut qu'on réécrive notre propre factory. Un collègue est en train d'expérimenter ça.
 
Le soucis est que je ne veux pas créer un autre contexte, car j'ai de la logique métier a continuer de traiter dans un bloc cohérent avant et après avoir changé de thread.
 
Je suis en train de récupérer le code d'un collègue sur un autre projet, il a réalisé un ORM minimaliste qui s'inspire de Dapper en encore beaucoup plus simple (c'est un wrapper à ADO au final, supportant le mapping d'objets).
 
On est en train de supprimer NHibernate dans de plus en plus de projets. Une très grande partie de notre logique métier est en directement écrite en SQL. Dès que l'on manipule des listes d'objets : procédure stockées obligatoires chez nous.

 
Si je comprend bien tu as le soucis que pour une seule méthode spécifique de ton API ? Car sinon tu peux faire une verrue juste pour ça, en utilisant du bon vieux ADO.NET. Au moins le temps de repenser ça, ou d'explorer a tête reposé la possibilité d'instanciation de contexte sur NHibernate.
 
Il faut peut être que tu instancie une autre factory NHibernate avec paramètres différents ?
 

 
C'est votre direction technique qui impose les procédures ?

On s'est donné jusqu'à demain midi pour trouver. La solution de backup court terme sera un switch vers du direct ADO.NET. Notre soucis est localisé dans une couche de synchro entre deux API.

On réécrit une factory là, qui supporte la connexion a de multiples bases de données et du pure asynchrone.

I'm in charge
Nous avons de très grosses contraintes de performance, et nous manipulons une masse de données assez monstrueuse générant une quantité d'I/O inimaginable

NH ne sert au final que pour manipuler des trucs superficiels et objets unitairement, et accessoirement nous donner accès à une connexion ADO facilement.

Hello,  
S'il y a des gens inspirés parmi vous : http://forum.hardware.fr/hfr/Progr [...] 6254_1.htm
Merci

Apparemment ils ont compris
https://blog.jetbrains.com/dotnet/2 [...] -2017-2-2/
Espérons que cette release soit la bonne.

Merci de l'info

Damned, ils ont modifié un truc dans la dernière update de VS2017 (15.4 ?), dorénavant, CTRL+CLIC sur un objet, une classe, une propriété, une énum etc... provoque une navigation vers sa définition -___-
 
Adieu le CTRL+CLIC+C / CTRL+V pour copier/coller rapidement tout un mot :-(