Comment s'assurer que vous ne recevez pas l'exception WCF Faulted state ?

Question

J'obtiens cette exception :

L'objet de communication, System.ServiceModel.Channels.ServiceChannel, ne peut pas être utilisé pour la communication car il est dans l'état Faulted.

Le service WCF utilise le wsHttpBinding par défaut. J'utilise WCF de la manière suivante partout où je l'utilise :

using (var proxy = new CAGDashboardServiceClient())
{
    proxy.Open();
    var result = proxy.GetSiteForRegion(ddlRegions.SelectedValue);
    ddlSites.DataSource = result;
    ddlSites.DataBind();
    proxy.Close();
}

La ligne d'erreur indiquée dans le message semble se trouver après le dernier proxy.close. Je ne suis pas sûr de ce qui se passe. Je lance le service à partir de Visual Studio 08.

Voici les informations de la trace :

The communication object, System.ServiceModel.Channels.ServiceChannel, cannot be used for communication because it is in the Faulted state.

Server stack trace: 
  at System.ServiceModel.Channels.CommunicationObject.Close(TimeSpan timeout)

Exception rethrown at [0]: 
  at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
  at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
  at System.ServiceModel.ICommunicationObject.Close(TimeSpan timeout)
  at System.ServiceModel.ClientBase`1.System.ServiceModel.ICommunicationObject.Close(TimeSpan timeout)
  at System.ServiceModel.ClientBase`1.Close()
  at System.ServiceModel.ClientBase`1.System.IDisposable.Dispose()
  at CAGDashboard.UserControls.ucVolunteerCRUDGrid.ddlRegions_SelectedIndexChanged(Object sender, EventArgs e) in C:\Documents and Settings\rballalx\My Documents\Visual Studio 2008\Projects\DashboardCAG\CAGDashboard\UserControls\ucVolunteerCRUDGrid.ascx.cs:line 81
  at System.Web.UI.WebControls.ListControl.OnSelectedIndexChanged(EventArgs e)
  at System.Web.UI.WebControls.DropDownList.RaisePostDataChangedEvent()
  at System.Web.UI.WebControls.DropDownList.System.Web.UI.IPostBackDataHandler.RaisePostDataChangedEvent()
  at System.Web.UI.Page.RaiseChangedEvents()
  at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

Answer 1

Vous devriez éviter de mettre les proxies clients dans using blocs.

Answer 2

---

Mise à jour :

Ce site La réponse liée décrit une manière plus propre et plus simple de faire la même chose avec la syntaxe C#.

---

Poste original

C'est la façon recommandée par Microsoft de traiter les appels de clients WCF :

Pour plus de détails, voir : Exceptions attendues

try
{
    ...
    double result = client.Add(value1, value2);
    ...
    client.Close();
}
catch (TimeoutException exception)
{
    Console.WriteLine("Got {0}", exception.GetType());
    client.Abort();
}
catch (CommunicationException exception)
{
    Console.WriteLine("Got {0}", exception.GetType());
    client.Abort();
}

Informations complémentaires

Tant de gens semblent poser cette question sur WCF que Microsoft a même créé un échantillon dédié pour démontrer comment traiter les exceptions :

c : \WF_WCF_Samples\WCF\Basic\Client\ExpectedExceptions\CS\client

Téléchargez l'échantillon : C# ou VB

Considérant qu'il y a tellement de problèmes impliquant la déclaration d'utilisation , Discussions internes (animées ?) y fils sur cette question, je ne vais pas perdre mon temps à essayer de devenir un cow-boy du code et à trouver une méthode plus propre. Je vais juste le sucer, et mettre en application les clients de WCF cette manière verbeuse (pourtant fiable) pour mes applications de serveur.

Answer 3

Si le mode de transfert est Tampon alors assurez-vous que les valeurs de MaxReceivedMessageSize y MaxBufferSize est même . Je viens de résoudre le problème de l'état défectueux de cette façon après m'être débattu avec lui pendant des heures et j'ai pensé le poster ici si cela peut aider quelqu'un.

Answer 4

Cette erreur peut également être causée par l'absence de méthodes marquées avec l'attribut OperationContract. C'est le problème que j'ai rencontré lorsque j'ai créé un nouveau service et que je l'ai testé pendant un long moment.

Answer 5

Comme dans la réponse de Ryan Rodemoyer, j'ai découvert que lorsque l'UriTemplate du contrat n'est pas valide, vous pouvez obtenir cette erreur. Dans mon cas, j'utilisais deux fois le même paramètre. Par exemple :

/Root/{Name}/{Name}