“EndPoint Pas Trouvé d'erreur” avec WCF service déployé sur site SharePoint 2010

J'essaie d'utiliser le autocompleteextender de la ajaxcontroltoolkit dans un de mes sharepoint des solutions (ce qui nécessite une version plus ancienne de la bibliothèque depuis toutes les dernières nécessitent l' .NET Framework 4.0) et malheureusement Je ne peux pas utiliser une page de méthode dans un UserControl, seulement dans une page réelle. Donc je suis parti avec une seule option qui consiste à utiliser une méthode à partir d'un service web réelle. Le problème est que je n'arrive pas à comprendre comment déployer correctement le service et configurer le web.config. Lorsque j'essaie d'afficher les informations de métadonnées dans le navigateur j'obtiens un message d'erreur disant "point de terminaison n'est pas trouvé". Cependant, lorsque j'essaie d'entrer l'URL avec le nom de la méthode est ajouté à l'URL il trouve effectivement ET exécute la méthode renvoyer des données JSON -ce qui signifie évidemment qu'il peut trouver mon service. Aussi, je peux utiliser jQuery pour faire appel à mon service et de renvoyer les données JSON -mais je ne veux pas utiliser jQuery pour ce projet et qu'il est plutôt juste garder tout pur C#.

Ce que je veux savoir, c'est pourquoi je ne peux pas obtenir le "joli informations de métadonnées" pour afficher dans le navigateur donc, je reçois le "chaud au cœur" et permettre la découverte du service par les autres applications de la façon dont il devrait être en train de travailler?

Je triple vérifié le web.config et j'ai à la fois le metadataExchange d'extrémité ainsi que celui qui fait référence à mon service tous les deux entrés et j'ai httpGetEnabled la valeur "true". J'ai essayé de courir svcutil /t:les métadonnées et l'a signalé à mon service, mais je reçois plusieurs erreurs, la première à me dire qu'il ne peut pas obtenir les métadonnées, la seconde que les Métadonnées contient une référence qui ne peut pas être résolu et que le troisième est un HTTP GET Erreur qui dit que le document HTML ne contient pas de service Web de découverte de l'information. Même si j'ai mon svc fichier dans le même ISAPI répertoire que le OOTB SharePoint services et permet de générer les fichiers XSD pour ces services, mais pas pour le mien.

Voici ce que mon site web actuel.fichier de configuration ressemble à...

<?xml version="1.0"?>
 <configuration>
  <system.web>
   <compilation debug="true" />
    <identity impersonate="true"/>
  </system.web>
 <system.serviceModel>
 <!-- we need this to enable session -->
 <client>
 </client>
 <serviceHostingEnvironment aspNetCompatibilityEnabled="true" />
 <behaviors>
  <endpointBehaviors>
  </endpointBehaviors>
  <serviceBehaviors>
    <behavior name="metadataSupportBehavior">
      <!-- To avoid disclosing metadata information, set the value below to false and remove the metadata endpoint above before deployment -->
      <serviceMetadata httpGetEnabled="true" httpGetUrl="http://myserver/sites/mysitecollection/_vti_bin/WebServices/MyService.svc" policyVersion="Policy15"/>
      <!-- To receive exception details in faults for debugging purposes, set the value below to true.  Set to false before deployment to avoid disclosing exception information -->
      <serviceDebug includeExceptionDetailInFaults="true"/>
      <serviceAuthorization impersonateCallerForAllOperations="false"/>
      <serviceCredentials>
        <windowsAuthentication includeWindowsGroups="true" />
      </serviceCredentials>
    </behavior>
    <behavior name="defaultBehavior">
      <serviceDebug includeExceptionDetailInFaults="true" />
      <serviceMetadata httpGetEnabled="true" />
    </behavior>
  </serviceBehaviors>
</behaviors>
<bindings>
</bindings>
<services>
  <service behaviorConfiguration="metadataSupportBehavior" name="Sample.WebServices.MyService">
    <clear />
    <endpoint address="" binding="basicHttpBinding" contract="Sample.WebServices.IMyService">
    </endpoint>
    <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange">
      <identity>
        <certificateReference storeName="My" storeLocation="LocalMachine"
          x509FindType="FindBySubjectDistinguishedName" />
      </identity>
    </endpoint>
    <host>
      <baseAddresses>
        <add baseAddress="http://myserver/sites/mysitecollection/_vti_bin/WebServices/MyService.svc" />
      </baseAddresses>
    </host>
  </service>
</services>

Je suis à une perte réelle ici. Toutes les pensées?

Merci d'avance!!!

Mise à JOUR #1: OK, je presque ai eu de travail. Je veux dire que je "techniquement" l'a fait, mais seulement dans le navigateur et avec quelques mises en garde.

La première chose que je fis fut d'ajouter le code suivant à mon site web.fichier de configuration:

  <endpointBehaviors>
    <behavior name="webBehavior">
      <webHttp />
    </behavior>
  </endpointBehaviors>

Puis mis à jour mon point de terminaison de service afin d'inclure une référence à la nouvelle configuration de la sorte:

    <endpoint address="" binding="webHttpBinding" contract="Sample.WebServices.IMyService" behaviorConfiguration="webBehavior">
      <identity>
        <dns value="localhost" />
      </identity>
    </endpoint>

J'ai aussi changé la liaison basicHttpBinding à webHttpBinding.

Maintenant pour les mises en garde...

1. Je peux l'obtenir pour fonctionner pleinement et de retourner une réponse XML dans le navigateur, mais SEULEMENT si je lance le service en mode debug, ce qui signifie qu'il est hébergé dans Visual Studio et pas de IIS, donc il ne compte pas vraiment.

2. Quand je ne suis pas d'exécuter le service en mode debug, j'ai une erreur qui dit quelque chose à l'effet de "L'exception message est" la Valeur ne peut pas être null. Nom du paramètre: "de source".

Après avoir marché à travers mon code dans le débogueur je vois la véritable erreur qui est:

Demande de l'autorisation de type 'IBM.Les données.DB2.DB2Permission, IBM.Les données.DB2, Version=9.0.0.2, Culture=neutral, PublicKeyToken=7c307b91aa13d208' a échoué.

Qui en anglais veut dire que je suis en train de charger une version 32 Bits de l'IBM.Les données.DB2 DLL dans mon site SharePoint qui malheureusement ne permet 64-Bit assemblées.

Donc, ma première réaction est: "Ah Ah!" ce qui devrait être simple droit? Je veux dire, j'ai besoin de trouver une version 64 bits de la DLL ou il suffit de configurer le Pool d'Applications que mon site SharePoint dans IIS utilise pour permettre 32bit assemblées pour être chargé et tout devrait fonctionner tout seul! Ne suis-je pas intelligent? Mais PAS dit SharePoint! Non seulement suis-je ne te laisserais pas faire aucune de ces choses* mais je vais l'afficher entièrement votre batterie de serveurs SharePoint inutilisable pour tenter de mettre en œuvre de tels ridicule que des solutions!!!

Alors maintenant, quand j'essaie d'accéder à une ressource dans ma batterie de serveurs SharePoint, je suis accueillie avec cette.

[NullReferenceException: Object reference not set to an instance of an object.]
   Microsoft.Office.Server.Administration.UserProfileApplicationProxy.get_ApplicationProperties() +134
   Microsoft.Office.Server.Administration.UserProfileApplicationProxy.get_PartitionIDs() +44
   Microsoft.Office.Server.Administration.UserProfileApplicationProxy.IsAvailable(SPServiceContext serviceContext) +329
   Microsoft.Office.Server.WebControls.MyLinksRibbon.get_PortalAvailable() +44
   Microsoft.Office.Server.WebControls.MyLinksRibbon.EnsureMySiteUrls() +60
   Microsoft.Office.Server.WebControls.MyLinksRibbon.get_PortalMySiteUrlAvailable() +15
   Microsoft.Office.Server.WebControls.MyLinksRibbon.OnLoad(EventArgs e) +91
   System.Web.UI.Control.LoadRecursive() +65
   System.Web.UI.Control.LoadRecursive() +190
   System.Web.UI.Control.LoadRecursive() +190
   System.Web.UI.Control.LoadRecursive() +190
   System.Web.UI.Control.LoadRecursive() +190
   System.Web.UI.Control.LoadRecursive() +190
   System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +2427

Même si je annuler toutes mes modifications à IIS, l'Application de la Piscine, les Dll, redémarrer IIS, redémarrer mon serveur etc. rien ne fonctionne. Je suis juste totalement vissé.

De bons moments.

*Eh bien, pour être juste SharePoint n'avait rien à voir avec le 64 Bits IBM pilote étant pas disponibles, mais je vais supposer que, même si il y en avait un que je pourrais techically utilisation de SharePoint serait de trouver un moyen de me punir pour essayer d'obtenir le travail fait.

Mise à JOUR #2: OK, j'ai fixé tout le "site SharePoint pas de travail". Fondamentalement, les Pools d'Applications en cours d'utilisation pour tous SharePoint sites connexes semblait avoir changé pour activer les applications 32 Bits, y compris les SecurityTokenServiceApplication (bravo au mec plus à cette site pour non seulement avoir le même problème, mais également l'affichage de la solution). Maintenant, même si je ne me souviens pas précisément de définir la valeur true pour chaque SharePoint des Applications liées à la Piscine, je suis prêt à jouer le jeu et dire que peut-être dans un acte de désespoir de cause, j'ai peut-être tout simplement dit d'enfer avec elle et a commencé à imprudemment modification des paramètres de configuration. Vous le savez, parce que c'est juste ce qu'aux développeurs chevronnés faire.

De toute façon...

Maintenant mon site web Administration Centrale est de nouveau opérationnel, mais la UserProfileApplication service est encore bancale et je suis toujours enclin à penser que mon SecurityTokenServiceApplication service est toujours sur le fritz depuis, je reçois un message d'erreur (détails cachés bien sûr, depuis le web.la config est configuré pour le faire) m'indiquant que "Le serveur n'a pas pu traiter la demande en raison d'une erreur interne".

De détails à suivre...

Mise à JOUR #3: OK, j'ai tout retour à l'état initial de travail de la forme. J'ai confirmé que le simple fait de l'activation des applications 32 Bits pour un Pool d'Applications utilisées par SharePoint ressources effectivement mises à jour de tous les autres à emboîter le pas. Je le sais pour un fait parce que j'positivement de ne pas modifier cette valeur pour CHAQUE liés à SharePoint Pool d'Applications de moi-même. Je m'en étais souvenu passer par quelque chose comme ça. Il s'avère que l'ensemble de ces Pools d'Applications avec le funky la recherche "GUID" comme de noms que le Web SharePoint utilisation des Services ont également été mis à jour afin de permettre des applications 32 Bits pour exécuter ce qui est ce qui a causé mon environnement à aller tout tordu.

En plus, j'ai obtenu mon SecurityTokenService pour afficher les métadonnées dans le navigateur correctement en suivant les suggestions fournies ici. Même si elles ressemblent un peu à un "hack", ils sont petits et réversible hacks, donc je suis partie.

En bref, vous modifiez les fichiers de configuration pour chacun des services, comme:

1. Dans le spStsActAsBinding liaison renommer httpTransport httpsTransport.
2. Ajouter allowInsecureTransport=”true” et enableUnsecuredResponse=”true” pour la liaison de sécurité.
3. Assurez-vous de définir seulement 1 configuration de liaison (par exemple dans le Service de Profil, vous trouverez 2 configuration de liaison pour le même service pour http et https, protocole).

Après avoir fait tout cela, vous devriez être en mesure d'obtenir le "chaud métadonnées floue" que je vais essayer d'obtenir la coutume service WCF, je travaille sur.

Alors maintenant, j'ai juste besoin de revenir à la fixation de mon problème initial qui était d'obtenir la version 32 Bits de l'IBM.Les données.DB2 DLL pour travailler avec SharePoint 2010. La seule chose que je n'ai pas encore essayé à la création d'un IIS service hébergé qui fonctionne ENTIÈREMENT indépendant de SharePoint. En faisant cela me permettrait de créer un Pool d'Applications qui PEUT exécuter des applications 32 Bits sans causer de SharePoint pour flip-je l'espère.

Mise à JOUR #4: OK, alors tout d'abord je vais vous dire d'ignorer mes conseils ci-dessus à propos de déconner avec le SecurityTokenService. Assurer que vous obtenez le "chaud métadonnées floue" avec les changements, mais alors vous aurez probablement la cause de votre site SharePoint à briser.

De toute façon...j'ai maintenant créé un site qui est totalement indépendante de SharePoint qui utilise son propre Pool d'Applications qui est configuré pour autoriser les applications 32 Bits alors que, techniquement, doit prendre soin de tous mes problèmes. Eh bien, quand j'essaie de taper du texte dans ma zone de texte, il n'est pas "saisie semi-automatique", mais il y a l'activité du réseau qui se passe parce que je le vois dans un violon. La partie étrange, c'est que ça n'arrive qu'une fois. Ce qui signifie, si j'ai frappé la touche retour arrière et retaper quelque chose d'autre, pas d'appels supplémentaires sont faits pour le service web. Je dois recharger la page pour tester de nouveau. Le message d'erreur que je reçois quand il fait appel à la méthode est "405 method not Allowed". Maintenant, mon interface de la méthode de signature utilise WebInvoke avec la Méthode de la propriété est définie sur "GET" qui comme je l'ai dit devrait fonctionner correctement et a dans le passé lors de la prise de REPOS appels qui retournent des données JSON, que maintenant il ne fonctionne pas. Oh, dans le navigateur web il fonctionne et je vois merveilleux résultats XML retourné à partir de la méthode. Mais quand j'essaie d'utiliser le AutoCompleteExtender dans mon SharePoint UserControl pour appeler la méthode (ou à l'aide de n'importe quel autre client que ce soit), il n'a pas. J'ai essayé d'utiliser le WebGet() attribut, mais alors rien n'est retourné dans le navigateur web. Je crois que j'ai un 415 erreur.

Mise à JOUR #5: j'ai trouvé un autre post où certains gars semble avoir exactement le même problème que je rencontre maintenant, la seule différence est que je ne peux pas obtenir la saisie semi-automatique de travailler, même si j'ai le webservice dans le même projet. J'ai aussi essayé les suggestions qui ont été faites à son poste et qu'ils n'ont pas de travail non plus. Voici une lien à la poste pour ceux qui sont intéressés.

OriginalL'auteur Ami Schreiber | 2013-03-01