Forum |  HardWare.fr | News | Articles | PC | Prix | S'identifier | S'inscrire | Aide | Shop Recherche
1185 connectés 

 


 Mot :   Pseudo :  
  Aller à la page :
 
 Page :   1  2  3  4  5  ..  46  47  48  49  50  51
Auteur Sujet :

[Topic unique] .Net @ Prog

n°2304669
OrcusZ
Pro AMD
Posté le 16-08-2017 à 15:37:48  profilanswer
 

Reprise du message précédent :
En parlant de l'Update 3, sur VS Community lorsque j'utilise le Snippet "CTRL + ," j'ai la consommation mémoire qui se met à augmenter indéfiniment...
 
Vous pourriez me dire si chez vous cela fonctionne correctement.


---------------
Made you your own sentence without believing that of the others...
mood
Publicité
Posté le 16-08-2017 à 15:37:48  profilanswer
 

n°2304670
TotalRecal​l
Posté le 16-08-2017 à 16:11:03  profilanswer
 

Ca fait quoi Ctrl , ? [:vizera]
Chez moi ça ouvre Navigate to, mais je ne sais même pas si ça vient de VS ou Resharper [:vizera]²

 

Concernant VS2017 Update 3 faut que je reboote avant de pouvoir te répondre :D.

Message cité 1 fois
Message édité par TotalRecall le 16-08-2017 à 16:11:32

---------------
Réalisation amplis classe D / T      Topic .Net - C# @ Prog
n°2304671
OrcusZ
Pro AMD
Posté le 16-08-2017 à 16:18:27  profilanswer
 

TotalRecall a écrit :

Ca fait quoi Ctrl , ? [:vizera]  
Chez moi ça ouvre Navigate to, mais je ne sais même pas si ça vient de VS ou Resharper [:vizera]²  
 
Concernant VS2017 Update 3 faut que je reboote avant de pouvoir te répondre :D.


 
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.
 


---------------
Made you your own sentence without believing that of the others...
n°2304687
Implosion ​du Sord
Fesseur de chameaux
Posté le 16-08-2017 à 19:08:42  profilanswer
 

OrcusZ a écrit :

En parlant de l'Update 3, sur VS Community lorsque j'utilise le Snippet "CTRL + ," j'ai la consommation mémoire qui se met à augmenter indéfiniment...

 

Vous pourriez me dire si chez vous cela fonctionne correctement.


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


---------------
Away from keyboard, close to your breast
n°2304703
OrcusZ
Pro AMD
Posté le 17-08-2017 à 09:14:38  profilanswer
 

Implosion du Sord a écrit :


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.


---------------
Made you your own sentence without believing that of the others...
n°2304704
TotalRecal​l
Posté le 17-08-2017 à 09:29:46  profilanswer
 

OrcusZ a écrit :


 
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.
 


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 :p


---------------
Réalisation amplis classe D / T      Topic .Net - C# @ Prog
n°2304982
ov3rflow
Overrage
Posté le 28-08-2017 à 13:42:30  profilanswer
 

TotalRecall a écrit :

Update 3 pour VS2017 dispo !
https://www.visualstudio.com/en-us/ [...] 3.26730.03
Beaucoup de choses en lien avec l'accessibilité mais bien entendu pas que ça. La change list est bien longue, peut être enfin la version qui me convaincra de passer de VS2015 à 2017, pour l'instant c'était pas fameux :o


 
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

n°2305024
OrcusZ
Pro AMD
Posté le 29-08-2017 à 13:06:58  profilanswer
 

ov3rflow a écrit :


 
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  :D


---------------
Made you your own sentence without believing that of the others...
n°2305125
TotalRecal​l
Posté le 31-08-2017 à 15:21:31  profilanswer
 

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\ :heink:
 
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 :fouyaya:


---------------
Réalisation amplis classe D / T      Topic .Net - C# @ Prog
n°2305199
dav-master
Posté le 02-09-2017 à 11:38:41  profilanswer
 

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 ?


Message édité par dav-master le 02-09-2017 à 11:39:03
mood
Publicité
Posté le 02-09-2017 à 11:38:41  profilanswer
 

n°2305208
TotalRecal​l
Posté le 02-09-2017 à 16:40:04  profilanswer
 

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.


---------------
Réalisation amplis classe D / T      Topic .Net - C# @ Prog
n°2305785
Implosion ​du Sord
Fesseur de chameaux
Posté le 19-09-2017 à 01:00:47  profilanswer
 

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 ?


---------------
Away from keyboard, close to your breast
n°2305804
TotalRecal​l
Posté le 19-09-2017 à 15:27:44  profilanswer
 

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 :o) : j'ai l'impression que ces c****** de Jetbrains recommencent à prendre leurs utilisateurs pour des cobayes de leur bouse en version alpha :mad:. 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 [:hardbox]


Message édité par TotalRecall le 19-09-2017 à 15:28:10

---------------
Réalisation amplis classe D / T      Topic .Net - C# @ Prog
n°2305809
Implosion ​du Sord
Fesseur de chameaux
Posté le 19-09-2017 à 15:57:43  profilanswer
 

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


Message édité par Implosion du Sord le 19-09-2017 à 15:59:11

---------------
Away from keyboard, close to your breast
n°2305810
TotalRecal​l
Posté le 19-09-2017 à 16:11:31  profilanswer
 

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 [:autobot] [:makokotte]


Message édité par TotalRecall le 19-09-2017 à 16:14:24

---------------
Réalisation amplis classe D / T      Topic .Net - C# @ Prog
n°2305814
rottendan
GT : RottenFleshDan
Posté le 19-09-2017 à 17:04:37  profilanswer
 

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

n°2306057
TotalRecal​l
Posté le 25-09-2017 à 16:46:39  profilanswer
 

https://blog.jetbrains.com/dotnet/2 [...] -2017-2-1/
Les blaireaux  [:mixag]  
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.
[:buggy]  
[:vyse]  


---------------
Réalisation amplis classe D / T      Topic .Net - C# @ Prog
n°2306063
Implosion ​du Sord
Fesseur de chameaux
Posté le 25-09-2017 à 20:52:38  profilanswer
 

Implosion du Sord a écrit :

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 ?


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'  [:eduard khil:1]
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  [:the geddons]


---------------
Away from keyboard, close to your breast
n°2306064
zywiec
Posté le 25-09-2017 à 20:59:17  profilanswer
 

Je ne savais pas non plus :D

n°2306068
TotalRecal​l
Posté le 26-09-2017 à 09:09:42  profilanswer
 

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 :

Code :
  1. string message = null;
  2.             try
  3.             {
  4.                 try
  5.                 {
  6.                     try
  7.                     {
  8.                         try
  9.                         {
  10.                             var z = 0;
  11.                             int i = 1 / z;
  12.                         }
  13.                         catch (Exception ex)
  14.                         {
  15.                             throw new Exception("1", ex);
  16.                         }
  17.                     }
  18.                     catch (Exception ex)
  19.                     {
  20.                         throw new Exception("2", ex);
  21.                     }
  22.                 }
  23.                 catch (Exception ex)
  24.                 {
  25.                     throw new Exception("3", ex);
  26.                 }
  27.             }
  28.             catch (Exception ex)
  29.             {
  30.                 message = ex.ToString();
  31.             }
  32.             Console.WriteLine(message);
 

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.


Message édité par TotalRecall le 26-09-2017 à 09:24:34

---------------
Réalisation amplis classe D / T      Topic .Net - C# @ Prog
n°2306232
Implosion ​du Sord
Fesseur de chameaux
Posté le 30-09-2017 à 20:15:17  profilanswer
 

NHibernate dans un contexte asynchrone : [:mister mystere]


---------------
Away from keyboard, close to your breast
n°2306234
TotalRecal​l
Posté le 30-09-2017 à 20:26:46  profilanswer
 
n°2306236
Implosion ​du Sord
Fesseur de chameaux
Posté le 30-09-2017 à 20:36:30  profilanswer
 

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


Message édité par Implosion du Sord le 30-09-2017 à 20:37:20

---------------
Away from keyboard, close to your breast
n°2306238
TotalRecal​l
Posté le 30-09-2017 à 20:40:56  profilanswer
 

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 ?


---------------
Réalisation amplis classe D / T      Topic .Net - C# @ Prog
n°2306239
Implosion ​du Sord
Fesseur de chameaux
Posté le 30-09-2017 à 20:48:13  profilanswer
 

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 )

Message cité 1 fois
Message édité par Implosion du Sord le 30-09-2017 à 20:50:35

---------------
Away from keyboard, close to your breast
n°2306240
TotalRecal​l
Posté le 30-09-2017 à 20:54:16  profilanswer
 

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 ?


---------------
Réalisation amplis classe D / T      Topic .Net - C# @ Prog
n°2306241
Implosion ​du Sord
Fesseur de chameaux
Posté le 30-09-2017 à 21:00:55  profilanswer
 

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)


---------------
Away from keyboard, close to your breast
n°2306242
Implosion ​du Sord
Fesseur de chameaux
Posté le 30-09-2017 à 21:02:32  profilanswer
 

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à :o

Message cité 1 fois
Message édité par Implosion du Sord le 30-09-2017 à 21:05:14

---------------
Away from keyboard, close to your breast
n°2306243
TotalRecal​l
Posté le 30-09-2017 à 21:03:51  profilanswer
 

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 ?


Message édité par TotalRecall le 30-09-2017 à 21:06:37

---------------
Réalisation amplis classe D / T      Topic .Net - C# @ Prog
n°2306244
TotalRecal​l
Posté le 30-09-2017 à 21:05:33  profilanswer
 

Implosion du Sord a écrit :

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)


 

Implosion du Sord a écrit :

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


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 ? :/


---------------
Réalisation amplis classe D / T      Topic .Net - C# @ Prog
n°2306245
Implosion ​du Sord
Fesseur de chameaux
Posté le 30-09-2017 à 21:09:35  profilanswer
 

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  [:tinostar]  

 

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


Message édité par Implosion du Sord le 30-09-2017 à 21:33:27

---------------
Away from keyboard, close to your breast
n°2306249
TotalRecal​l
Posté le 30-09-2017 à 22:28:30  profilanswer
 

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 :o. 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.


Message édité par TotalRecall le 30-09-2017 à 22:29:28

---------------
Réalisation amplis classe D / T      Topic .Net - C# @ Prog
n°2306250
Implosion ​du Sord
Fesseur de chameaux
Posté le 30-09-2017 à 23:02:39  profilanswer
 

Citation :

In order to use EF Core 2.0 or any other .NET Standard 2.0 library with a .NET platforms besides .NET Core 2.0 (e.g. with .NET Framework 4.6.1 or greater) you will need a version of NuGet that is aware of the .NET Standard 2.0 and its compatible frameworks. Here are a few ways you can obtain this:

 

Install Visual Studio 2017 version 15.3
If you are using Visual Studio 2015, download and upgrade NuGet client to version 3.6.0


Mais je conseille pas :o


Message édité par Implosion du Sord le 30-09-2017 à 23:02:58

---------------
Away from keyboard, close to your breast
n°2306275
ov3rflow
Overrage
Posté le 02-10-2017 à 13:31:31  profilanswer
 

Implosion du Sord a écrit :

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 )

 

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  :D

 


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  [:klemton] ?

 

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.

 

 

 


Message cité 1 fois
Message édité par ov3rflow le 02-10-2017 à 13:31:56
n°2306277
Implosion ​du Sord
Fesseur de chameaux
Posté le 02-10-2017 à 15:19:29  profilanswer
 

ov3rflow a écrit :

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 ?


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.


---------------
Away from keyboard, close to your breast
n°2306278
TotalRecal​l
Posté le 02-10-2017 à 15:23:11  profilanswer
 

Implosion du Sord a écrit :


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).


[:do not want]


---------------
Réalisation amplis classe D / T      Topic .Net - C# @ Prog
n°2306279
ov3rflow
Overrage
Posté le 02-10-2017 à 17:59:45  profilanswer
 

Implosion du Sord a écrit :


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).
 


 
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 ?
 

Implosion du Sord a écrit :


 
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.


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

n°2306282
Implosion ​du Sord
Fesseur de chameaux
Posté le 02-10-2017 à 21:26:04  profilanswer
 

ov3rflow a écrit :

 

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 ?

 



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.

 
ov3rflow a écrit :

 

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


I'm in charge :o
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 :o

 

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


---------------
Away from keyboard, close to your breast
n°2306292
ov3rflow
Overrage
Posté le 03-10-2017 à 11:46:31  profilanswer
 

:jap:  
 

n°2306519
TotalRecal​l
Posté le 10-10-2017 à 17:40:32  profilanswer
 

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


---------------
Réalisation amplis classe D / T      Topic .Net - C# @ Prog
n°2306738
TotalRecal​l
Posté le 16-10-2017 à 16:33:56  profilanswer
 

TotalRecall a écrit :

https://blog.jetbrains.com/dotnet/2 [...] -2017-2-1/
Les blaireaux  [:mixag]  
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.
[:buggy]  
[:vyse]  


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


---------------
Réalisation amplis classe D / T      Topic .Net - C# @ Prog
mood
Publicité
Posté le   profilanswer
 

 Page :   1  2  3  4  5  ..  46  47  48  49  50  51

Aller à :
Ajouter une réponse
 

Sujets relatifs
service web REST en VB.NET HeySpreadRequete Access avec paramètres, éxécutée en VB .Net
impersonalisation sous ASP.NET[Topic Unique] les blagues pourries de harko et florentg
Generation d'un GIF en ASP.NETAppeler un service web .NET sécurisé en Java
Prog Visual Basic "periodicité"[Oracle] Temps d'execution de requete tres long par rapport au .NET
[VB.NET] Lister des imprimantes réseauxFusion de résultats de requêtes dans une unique Table
Plus de sujets relatifs à : [Topic unique] .Net @ Prog



Copyright © 1997-2016 Hardware.fr SARL (Signaler un contenu illicite) / Groupe LDLC / Shop HFR