Journalisation des erreurs WCF

Question

Je travaille sur un projet qui utilise des liaisons NetTcp pour parler à certains services WCF. Lorsque vous débutez, nous avons pris un mauvais exemple de la pratique d'une autre application qui a fait WCF appelle à l'aide les éléments suivants:

EntityObject sample = new ServiceProxy().GetEntity(); 

Cela fonctionnait très bien jusqu'à ce que nous avons réalisé WCF tenait sur les connexions, même si la page ASPX avait été envoyé le client (que j'ai naïvement supposé nettoierait toutes les connexions). Tandis que les connexions étaient maintenues pour ralentir les choses, ELMAH enregistrait toutes les erreurs et nous envoyait des traces complètes de la pile. Pour résoudre les problèmes de performance, nous avons changé pour ceci:

using (ServiceProxy proxy = new ServiceProxy()) 
{ 
    sample = proxy.GetEntity(); 
} 

Cela a rendu la performance rock comparativement. L'inconvénient de cette méthode est chaque fois qu'une erreur est reçue sur le proxy, la seule chose que ELMAH peut attraper est que le canal est maintenant en défaut. Nous devons ensuite explorer les logs (ceux de la WCF avec sharedListeners) pour comprendre ce qui s'est passé et si c'est une erreur de sérialisation, les chances de le trouver deviennent beaucoup plus faibles, malgré la configuration des écouteurs sur le client et le serveur. J'ai exploré l'interface IErrorHandler et je vais ajouter le support pour cela à nos services, mais je me demandais s'il y avait d'autres moyens d'obtenir des erreurs détaillées de WCF au lieu de simplement dire qu'il manquait d'informations réelles pour expliquer pourquoi fauché. Ce serait particulièrement bénéfique s'il meurt en sérialisant l'objet qu'il pourrait nous dire POURQUOI il ne pourrait pas sérialiser.

Answer 1

Je pense que si vous appelez Close() explicitement sur le proxy, et mettez cela dans un try-catch, vous obtiendrez ce que vous voulez.

Voir en particulier cet exemple:

http://msdn.microsoft.com/en-us/library/aa355056.aspx

Answer 2

Eh bien, vous pouvez dire au servive WCF pour renvoyer plus d'informations que juste « quelque chose de mal passé » en utilisant le comportement serviceDebug.

<system.serviceModel> 
    <behaviors> 
     <serviceBehaviors> 
     <behavior name="ExceptionDetails"> 
      <serviceDebug includeExceptionDetailInFaults="True" /> 
     </behavior> 
     </serviceBehaviors> 
    </behaviors> 

Ceci est correct tant qu'il s'agit d'un environnement de développement/test ou d'une application interne. Mais vraiment, l'erreur de service devrait être attrapée (et enregistrée) du côté du serveur - vous êtes sur le bon chemin avec l'interface IErrorHandler.

Le client doit gérer les exceptions côté client, telles que TimeoutException et CommunicationException pour gérer les exceptions de sécurité ou les réseaux en panne. Juste la gestion des exceptions standard .NET, vraiment.

En outre, le using() est une bonne idée en général - mais pas nécessairement ici, car vous pourriez rencontrer une exception lorsque le ServiceProxy est mis au rebut (à la fin du bloc), et cela ne sera pas détecté dans ce cas. Vous devrez peut-être utiliser un bloc try {...} catch {...} finally {...} pour vos proxys de service à la place.

Marc