J'ai un problème avec un service WCF. J'ai une application console et je dois utiliser le service sans utiliser app.config. J'ai donc dû définir le point de terminaison, etc. à l'aide d'un code. J'ai une référence de service à la svc, mais je ne peux pas utiliser 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()
, le message d'erreur suivant s'affiche:
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:
c'est généralement une incompatibilité dans les liaisons client/serveur, où la version du message dans le service utilise SOAP 1.2 (qui attend application/soap + xml) et la version dans le client utilise SOAP 1.1 (qui envoie text/xml). WSHttpBinding utilise SOAP 1.2, BasicHttpBinding utilise SOAP 1.1.
Cela semble généralement être un wsHttpBinding d'un côté et un basicHttpBinding de l'autre.
Ne pas oublier de vérifier le code lié aux liaisons aussi. Donc si vous avez écrit:
BasicHttpBinding binding = new BasicHttpBinding();
Assurez-vous que tous vos app.config
fichiers contient
<endpoint address="..."
binding="basicHttpBinding" ...
pas le
<endpoint address="..."
binding="wsHttpBinding" ...
ou alors.
J'ai vu ce comportement aujourd'hui quand le
<service name="A.B.C.D" behaviorConfiguration="returnFaults">
<endpoint contract="A.B.C.ID" binding="basicHttpBinding" address=""/>
</service>
était absent du web.config. Le service.svc
Le fichier était là et a été servi. Il a fallu un certain temps pour comprendre que le problème n'était pas dans la configuration de la liaison elle-même ...
J'ai constaté ce problème aujourd'hui en essayant de créer un proxy de service WCF, utilisant à la fois VS2010 et svcutil.
Tout ce que je fais est avec basicHttpBinding
(donc aucun problème avec wsHttpBinding
).
Pour la première fois de mon souvenir, MSDN m'a effectivement fourni la solution, sur le lien suivant: Procédure: publier des métadonnées pour un service à l'aide d'un fichier de configuration . La ligne que je devais modifier se trouvait à l'intérieur de l'élément behavior de l'élément de comportement du service MEX dans mon fichier app.config de service. Je l'ai changé de
<serviceMetadata httpGetEnabled="true"/>
to
<serviceMetadata httpGetEnabled="true" policyVersion="Policy15"/>
et comme par magie l'erreur est partie et j'ai pu créer le proxy de service. Notez qu'il existe une entrée MSDN correspondante pour utiliser du code à la place d'un fichier de configuration: Procédure: publier des métadonnées pour un service à l'aide de code.
(Bien sûr, Policy15 - comment aurais-je pu oublier cela ???)
Encore un "gotcha": mon service doit exposer 3 terminaux différents, chacun prenant en charge un contrat différent. Pour chaque proxy que je devais créer, je devais commenter les 2 autres points de terminaison, sinon svcutil se plaindrait de l'impossibilité de résoudre l'adresse URL de base.
J'étais confronté au même problème lors de l'utilisation de Channel Factory. c'était en fait dû au mauvais contrat 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; jeu de caractères = utf-8
ou un sous-ensemble de cette erreur:
Une erreur similaire a été causée dans mon cas par la construction et l’exécution d’un service sans attributs 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 client. Cela a été résolu quand j'ai correctement appliqué [DataContract]
et [DataMember]
attributs à mes classes personnalisées.
Cela s’appliquerait fort probablement si votre service était configuré et fonctionnait, puis s’était rompu après l’avoir modifié.
Encore une fois, je souligne que l’espace de nom, le nom svc et le contrat doivent être correctement spécifiés dans le fichier web.config:
<service name="NAMESPACE.SvcFileName">
<endpoint contract="NAMESPACE.IContractName" />
</service>
Exemple:
<service name="MyNameSpace.FileService">
<endpoint contract="MyNameSpace.IFileService" />
</service>
(Balises non pertinentes omises dans ces exemples)
Dans mon cas, je devais spécifier messageEncoding à Mtom in app.config de l'application cliente comme ça:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<startup>
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.6.1" />
</startup>
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="IntegrationServiceSoap" messageEncoding="Mtom"/>
</basicHttpBinding>
</bindings>
<client>
<endpoint address="http://localhost:29495/IntegrationService.asmx"
binding="basicHttpBinding" bindingConfiguration="IntegrationServiceSoap"
contract="IntegrationService.IntegrationServiceSoap" name="IntegrationServiceSoap" />
</client>
</system.serviceModel>
</configuration>
Mon client et mon serveur utilisent basicHttpBinding. J'espère que cela aide les autres :)
Je faisais également face au même problème récemment. après avoir lutté quelques heures, enfin une solution est apparue en plus de
Factory="System.ServiceModel.Activation.WebServiceHostFactory"
to your SVC markup file. e.g.
ServiceHost Language="C#" Debug="true" Service="QuiznetOnline.Web.UI.WebServices.LogService"
Factory="System.ServiceModel.Activation.WebServiceHostFactory"
et maintenant vous pouvez compiler et exécuter votre application avec succès.