web-dev-qa-db-fra.com

Impossible de déboguer un message de service WCF

J'ai une solution Visual Studio 2008 avec un service WCF et un client.

Lorsque j'exécute mon client et appelle une méthode de mon service, un message indiquant «Impossible de déboguer automatiquement 'Home.Service' s'affiche. La procédure distante n'a pas pu être déboguée. Cela indique généralement que le débogage n'a pas été activé sur le serveur. "

J'ai cherché sur Google et j'ai essayé ce qui suit.

<system.web>
   <compilation debug="true" />
</system.web>

a été ajouté dans app.config sur le client et le serveur.

Je me suis également assuré que le projet est compilé en mode débogage.

Quoi d'autre pourrait être à l'origine de ce message?

Edit: Ajout de plus d'informations en fonction des questions de feedback

  • Il utilise wsHttpBinding

  • J'ai mis

    <serviceDebug includeExceptionDetailInFaults="true"/>

  • J'utilise

    var service = new HomeReference.HomeServiceClient();
service.ClientCredentials.Windows.ClientCredential = CredentialCache.DefaultNetworkCredentials;

Malheureusement, l'erreur apparaît la première fois que j'appelle une méthode sur mon service. Je peux fermer la boîte de message et l'application continue de fonctionner. Toutes les exceptions levées sur le serveur ne sont cependant pas propagées au client (je suppose que cela devrait?)

visual-studio-2008wcf
31
Frode Lillerud

Dans mon cas, le problème s'est avéré être une incompatibilité entre les paramètres de sécurité sur le client et le serveur. J'utilisais une liaison personnalisée comme celle-ci:

<customBinding>
    <binding name="AuthorisedBinaryHttpsBinding" receiveTimeout="00:03:00" sendTimeout="00:03:00">
      <!-- this next element caused the problem: -->
      <security authenticationMode="UserNameOverTransport">
      </security>
      <binaryMessageEncoding>
        <readerQuotas maxDepth="100" maxStringContentLength="1000000"
          maxArrayLength="655360000" />
      </binaryMessageEncoding>
      <httpsTransport />
    </binding>
  </customBinding>

Lorsque j'ai supprimé l'élément de sécurité que j'ai souligné ci-dessus, le problème lié au message "Impossible de déboguer automatiquement" a disparu. 

Pour résoudre le problème, j’ai d’abord activé le traçage WCF . Cela m'a montré que WCF lançait un MessageSecurityException : 

Le processeur de sécurité n'a pas pu trouver Un en-tête de sécurité dans le message. Cela Peut être dû au fait que le message est une Faute non sécurisée ou à un décalage Contraignant entre les Parties en communication. Cela peut Se produire si le service est configuré pour la sécurité Et que le client n'utilise pas la sécurité .

Cela m'a amené à regarder les paramètres de liaison du côté client. Il s'est avéré que je n'avais pas ajouté l'élément de sécurité requis à ma liaison personnalisée. Comme je le faisais avec le code, j'avais besoin de ce qui suit (notez la 3ème ligne):

  var binding = new CustomBinding(
      binaryEncoding,
      SecurityBindingElement.CreateUserNameOverTransportBindingElement(),
      new HttpsTransportBindingElement { MaxReceivedMessageSize = MaxMessageSize, });

En ce qui concerne la raison pour laquelle Visual Studio a affiché cette erreur, je n'en ai aucune idée - cela me semble être un bogue.

13
Samuel Jack

Je me suis battu avec cette même erreur pendant plus d'une heure et voici que j'ai redémarré VS2008 et que cela s'est réglé comme par magie. Essayez car cela pourrait vous faire gagner du temps.

39
Exist

La connexion automatique à un service présente les limitations suivantes:

  • Le service doit faire partie de la solution Visual Studio que vous déboguez.

  • Le service doit être hébergé. Il peut s'agir d'un projet de site Web (système de fichiers et HTTP), d'un projet d'application Web (système de fichiers et HTTP) ou d'un projet de bibliothèque de services WCF. Les projets de bibliothèque de services WCF peuvent être des bibliothèques de services ou des bibliothèques de services de flux de travail.

  • Le service doit être appelé à partir d'un client WCF.

  • Le débogage doit être activé avec le code suivant dans le fichier app.config ou Web.config:

    <system.web>
  <compilation debug="true" />
</system.web>

Voir Limitations sur le débogage WCF

De plus, si les deux projets (client et service) font partie de la même solution mais s'exécutent dans des processus différents (par exemple, si vous utilisez votre serveur IISlocal pour le développement et exécutez votre application Web à l'aide de pool d’applications différent que le service consommé), vous devrez peut-être activer " Plusieurs projets de démarrage " pour la solution (sur Propriétés de la solution -> Projet de démarrage) afin que le débogueur puisse s’attacher à tous les deux. 

Pour éviter que la fenêtre du navigateur de services ne s'affiche chaque fois que vous déboguez, vous pouvez définir "Action de démarrage" (sur les propriétés du projet de service) sur "Ne pas ouvrir une page. Attendez la demande de l'application externe".

Ceci est une expérience personnelle et peut aider les autres.

8
Jorge Garcia

L'autre raison pour laquelle vous pourriez voir cette erreur (et je crois que c'est le cas pour moi) est si vous utilisez Windows 64 bits. Apparemment, Visual Studio ne prend pas en charge le débogueur x64.

Vous pouvez contourner ce problème en modifiant la cible de la plate-forme pour l'application consommatrice:

Propriétés du projet -> Construire -> Changer "Cible de la plateforme" en "x86".

Malheureusement, cela ne fonctionnera pas pour moi car j'essaie de l'exécuter dans AppFabric de développement Windows Azure, ce qui semble nécessiter tout pour fonctionner en mode 64 bits!

6
Dave

J'ai aussi le même problème. J'ai changé dans les fichiers de configuration client et service comme

Le débogage de la compilation est défini sur true.

Cela a fonctionné pour moi.

1
sriram

J'ai eu le même problème dans Visual Studio 2017. Après avoir supprimé le dossier .vs caché à la racine du dossier de la solution, j'ai pu à nouveau déboguer.

0
Bobmonga

As-tu essayé

    <serviceBehaviors>

  <serviceDebug includeExceptionDetailInFaults="true"/>
            </behavior>
        </serviceBehaviors>

À des fins de débogage?

Edit: tant pis, je pense avoir mal compris la question

0
kd7

Dans mon cas, le problème s'est avéré être quelque chose de complètement différent. J'avais changé le nom d'une opération sur le service Web et oublié de mettre à jour le client. Pour une raison quelconque, l'erreur "Impossible de déboguer automatiquement ...".

0
T.J.Kjaer

Dans votre service Web web.config, assurez-vous que le débogage de la compilation est défini sur true. Cela devrait résoudre votre problème!

0
joseph

J'ai eu un problème similaire, dû au fait que l'authentification Windows n'était pas activée sur le répertoire IIS site/virtual.

Avez-vous essayé de définir le mode d'authentification sur Intégré au lieu de Anonyme? http://msdn.Microsoft.com/en-us/library/x8a5axew(VS.80).aspx

0
mundeep

Il se peut également que le même numéro de port soit utilisé dans IISExpress et IIS. Si vous développez une application WCF dans Visual Studio et IISExpress, puis installez la même application sur votre IIS local, assurez-vous de ne pas utiliser le même numéro de port dans IIS et IISExpress. L'utilisation du même numéro de port entraînera ce message d'erreur.

0
GunnarS