Type de contenu text / xml; charset = utf-8 n’était pas supporté par le service

J’ai un problème avec un service WCF. J’ai une application console et je dois consumr le service sans utiliser app.config, j’ai donc dû définir le sharepoint terminaison, etc. par code. J’ai une référence de service au svc, mais je ne peux pas utiliser le app.config. Voici mon code:

BasicHttpBinding binding = new BasicHttpBinding(); EndpointAddress address = new EndpointAddress("http://localhost:8731/WcfServicio/MiServicio"); MiServicioClient svc = new MiServicioClient(binding, address); object ob = svc.PaisesObtener(); 

À la dernière ligne lorsque je fais svc.PaisesObtener() j’obtiens l’erreur:

 Content Type text/xml; charset=utf-8 was not supported by service http://localhost:8731/WcfServicio/MiServicio. The client and service bindings may be mismatched. 

Le premier hit de Google dit:

Il s’agit généralement d’une incohérence dans les liaisons client / serveur, où la version du message du service utilise SOAP 1.2 (qui attend application / soap + xml) et la version du client utilise SOAP 1.1 (qui envoie text / xml). WSHttpBinding utilise SOAP 1.2, BasicHttpBinding utilise SOAP 1.1.

Il semble généralement être un wsHttpBinding d’un côté et un basicHttpBinding de l’autre.

N’oubliez pas de vérifier également le code associé aux liaisons. Donc, si vous avez écrit:

 BasicHttpBinding binding = new BasicHttpBinding(); 

Assurez-vous que tous vos fichiers app.config contiennent

  

pas le

  

ou alors.

J’ai vu ce comportement aujourd’hui quand le

     

était absent du web.config. Le fichier service.svc était là et a été servi. Il a fallu du temps pour se rendre compte que le problème n’était pas dans la configuration de liaison elle-même …

J’ai vu ce problème aujourd’hui en essayant de créer un proxy de service WCF, à la fois en utilisant VS2010 et svcutil.

Tout ce que je fais est avec basicHttpBinding (donc pas de problème avec wsHttpBinding ).

Pour la première fois dans ma mémoire, MSDN m’a fourni la solution, à l’adresse suivante: Comment: publier des métadonnées pour un service à l’aide d’un fichier de configuration . La ligne que je devais changer était à l’intérieur de l’élément de comportement à l’intérieur de l’élément de comportement du service MEX dans mon fichier de service app.config. Je l’ai changé de

 <serviceMetadata httpGetEnabled="true"/> to <serviceMetadata httpGetEnabled="true" policyVersion="Policy15"/> 

et comme par magie l’erreur a disparu et j’ai pu créer le proxy du service. Notez qu’il existe une entrée MSDN correspondante pour utiliser du code au lieu d’un fichier de configuration: Comment: publier des métadonnées pour un service utilisant du code.

(Bien sûr, Policy15 – comment aurais-je pu oublier cela ???)

Encore un “gotcha”: mon service doit exposer 3 terminaux différents, chacun supportant un contrat différent. Pour chaque proxy que je devais construire, je devais commenter les 2 autres points de terminaison, sinon svcutil se plaindrait de ne pas pouvoir résoudre l’adresse URL de base.

J’étais confronté au même problème lors de l’utilisation de Channel Factory. En fait, il était dû à un contrat erroné spécifié dans le noeud final.

Pour quiconque atterrit ici en cherchant:

type de contenu ‘application / json; charset = utf-8 ‘n’était pas le type attendu’ text / xml; charset = utf-8

ou un sous-ensemble de cette erreur:

Une erreur similaire a été provoquée dans mon cas par la création et l’exécution d’un service sans atsortingbuts appropriés. J’ai reçu ce message d’erreur lorsque j’ai essayé de mettre à jour la référence de service dans mon application cliente. Il a été résolu lorsque j’ai correctement appliqué les [DataContract] et [DataMember] à mes classes personnalisées.

Cela serait très probablement applicable si votre service a été configuré et fonctionne, puis il est cassé après que vous l’ayez édité.

Je faisais également face au même problème récemment. après avoir lutté quelques heures, finalement une solution est sortie en ajoutant

 Factory="System.ServiceModel.Activation.WebServiceHostFactory" to your SVC markup file. eg ServiceHost Language="C#" Debug="true" Service="QuiznetOnline.Web.UI.WebServices.LogService" Factory="System.ServiceModel.Activation.WebServiceHostFactory" 

et maintenant vous pouvez comstackr et exécuter votre application avec succès.

Encore une fois, j’insiste sur le fait que l’espace de noms, le nom svc et le contrat doivent être correctement spécifiés dans le fichier web.config:

     

Exemple:

    

(Tags non pertinents dans ces échantillons)

Dans mon cas, je devais spécifier messageEncoding à Mtom dans app.config de l’application cliente comme ceci:

                 

Mon client et mon serveur utilisent tous deux basicHttpBinding. J’espère que cela aide les autres 🙂