Le service WCF Azure utilise le service WCF Azure

Question

J'ai actuellement une solution avec un service WCF Azure et un projet Windows Phone 7. Je peux exécuter la structure de développement localement et parcourir l'url (http://127.0.0.1:81/API/V1.svc) de mon service amende. Lorsque j'ajouterai une référence de service à partir de l'application Windows Phone, je découvrirai le service, mais lorsque j'essaierai d'afficher les méthodes sur le service, j'obtiendrai l'erreur "Impossible de lancer ASP.NET Development Server car le port '50149' est utilisation." Si je clique sur OK, je reçois "Une erreur est survenue lors du téléchargement des métadonnées à partir de l'adresse. Veuillez vérifier que vous avez entré une adresse valide."

Je ne comprends pas pourquoi il découvre sur le port 50149 depuis que je passe en revue à sur le port 81 mais j'ai essayé d'utiliser le port 81 lors de l'ajout du service et je suis

Il y avait un téléchargement d'erreur « http : // localhost: 81/API/V1.svc '. Impossible de se connecter au serveur distant Aucune connexion n'a pu être établie car la machine cible l'a refusée 127.0.0.1:81 Les métadonnées contiennent une référence qui ne peut pas être résolue: 'http: // localhost: 81/API/V1.svc '. Aucun point de terminaison n'écoutait http://localhost:81/API/V1.svc pouvant accepter le message. Ceci est souvent causé par une adresse incorrecte ou une action SOAP. Voir InnerException, si présent, pour plus de détails. Impossible de se connecter au serveur distant Aucune connexion n'a pu être établie car la machine cible l'a refusée 127.0.0.1:81 Si le service est défini dans la solution actuelle, essayez de créer la solution et ajoutez à nouveau la référence de service.

Voici mon modèle de service section

<system.serviceModel> 
    <services> 
    <service name="DocDemon.API.V1"> 
     <endpoint name="basicHttpBinding" binding="basicHttpBinding" contract="DocDemon.API.IV1" /> 
    </service> 
    </services> 
    <behaviors> 
    <serviceBehaviors> 
    <behavior name=""> 
    <serviceMetadata httpGetEnabled="true" /> 
    <serviceDebug includeExceptionDetailInFaults="false" /> 
    </behavior> 
    </serviceBehaviors> 
    </behaviors> 
    <serviceHostingEnvironment multipleSiteBindingsEnabled="true" /> 
    <bindings> 

    </bindings> 
</system.serviceModel> 

Ai-je besoin de définir et de point final ici?

Cela a-t-il quelque chose à voir avec le projet WP7 et le WCF Azure étant dans la même solution? (Dois-je exécuter le WCF lorsque j'essaie d'ajouter une référence de service à partir de l'application WP7?)

Answer 1

J'ai déplacé l'application WP7 dans sa propre solution, puis elle a pu détecter le service Web correctement lorsque cette application était en cours d'exécution dans le DevFabric local. L'application WP7 était juste incapable de le trouver quand ils étaient dans la même solution.

Answer 2

Avez-vous regardé les exemples WCF Azure known issues dans la bibliothèque de codes MSDN? Il y a une subtilité autour des métadonnées et un changement de comportement nécessaire. Espérons que cela aide.

Answer 3

Dans mon WCF en cours d'exécution dans Azure configurer points d'extrémité en deux endroits (mon exemple définit un point de terminaison ssl sur le port 443):

1ère fois dans web.config pour définir les contrats de points finaux:

<system.serviceModel> 
    <services> 
     <service 
      behaviorConfiguration="CustomValidationBehavior" 
      name="ServiceName"> 

      <endpoint 
           binding="wsHttpBinding" 
           bindingConfiguration="MembershipBinding" 
           name="bindingName         contract="InterfaceName" /> 

Ensuite, vous devez également vous assurer que Azure expose votre service à travers ses propres critères d'évaluation dans ServiceDefinition.csdef:

<InputEndpoints> 
    <InputEndpoint name="HttpsIn" protocol="https" port="443" certificate="CertName" /> 
</InputEndpoints> 

Answer 4

vous ne pouvez pas utiliser une référence à ce port si ne fonctionne pas, aucune métadonnée ne sera trouvée. Je dirais que déplacer votre projet de serveur vers IIS au lieu de Casini puisque c'est là qu'il se déroulera sur la plate-forme Azure. J'ai eu quelques problèmes de lecture avec Azure et Casini qui ne se sont pas produits sur IIS.