2012-04-16 4 views
0

J'ai un problème pour appeler le service WCF Azure à partir de bac à sable Visual Web Part Sharepoint 2010. Tous installé al ordinateur local Windows 7 64 Ultimate - Sharepoint Foundation 2010 pour développer des pièces Web et Visual Studio 2010 avec Azure SDK. Service Web démarrant dans l'émulateur Azure local, partie Web dans un ordinateur local. Quand j'utilise maître Standart « Ajouter un service de référence » à une partie web, qui génèrent app.config, puis jeter erreur:Azure WCF Service + Sharepoint 2010 Sandbox Visual Web Part = erreur

ServiceReference1.Service1Client serv = new ServiceReference1.Service1Client(); 
Label1.Text = serv.GetData(9); 

Impossible de trouver l'élément de point final par défaut qui fait référence à un contrat « ServiceReference1.IService1 » dans le ServiceModel section de configuration du client. Cela peut être dû au fait qu'aucun fichier de configuration n'a été trouvé pour votre application ou qu'aucun élément de point de terminaison correspondant à ce contrat n'a pu être trouvé dans l'élément client.

Lorsque je crée la connexion par programmation -

EndpointAddress adr = new EndpointAddress(new Uri("http://127.0.0.1:81/Service1.svc")); 
BasicHttpBinding basic = new BasicHttpBinding(); 
ChannelFactory<ServiceReference1.IService1Channel> fact = new ChannelFactory<ServiceReference1.IService1Channel>(basic, adr); 
Label1.Text = fact.CreateChannel().GetData(8); 

erreur de lancer:

Demande d'autorisation de type « System.Net.WebPermission, Système, Version = 2.0.0.0, Culture = neutral , PublicKeyToken = b77a5c561934e089 ".

app.config webpart:

<?xml version="1.0" encoding="utf-8" ?> 
<configuration> 
    <system.serviceModel> 
     <bindings> 
      <basicHttpBinding> 
       <binding name="BasicHttpBinding_IService1" /> 
      </basicHttpBinding> 
     </bindings> 
     <client> 
      <endpoint address="http://127.0.0.1:81/Service1.svc" binding="basicHttpBinding" 
       bindingConfiguration="BasicHttpBinding_IService1" contract="ServiceReference1.IService1" 
       name="BasicHttpBinding_IService1" /> 
     </client> 
    </system.serviceModel> 
</configuration> 

web.config Azure WCF Service:

<?xml version="1.0"?> 
<configuration> 
    <configSections> 
    </configSections> 
    <!-- To collect diagnostic traces, uncomment the section below or merge with existing system.diagnostics section. 
     To persist the traces to storage, update the DiagnosticsConnectionString setting with your storage credentials. 
     To avoid performance degradation, remember to disable tracing on production deployments. 
    <system.diagnostics>  
    <sharedListeners> 
     <add name="AzureLocalStorage" type="WCFServiceWebRole1.AzureLocalStorageTraceListener, WCFServiceWebRole1"/> 
    </sharedListeners> 
    <sources> 
     <source name="System.ServiceModel" switchValue="Verbose, ActivityTracing"> 
     <listeners> 
      <add name="AzureLocalStorage"/> 
     </listeners> 
     </source> 
     <source name="System.ServiceModel.MessageLogging" switchValue="Verbose"> 
     <listeners> 
      <add name="AzureLocalStorage"/> 
     </listeners> 
     </source> 
    </sources> 
    </system.diagnostics> --> 
    <system.diagnostics> 
    <trace> 
     <listeners> 
     <add type="Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener, Microsoft.WindowsAzure.Diagnostics, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" 
      name="AzureDiagnostics"> 
      <filter type="" /> 
     </add> 
     </listeners> 
    </trace> 
    </system.diagnostics> 
    <system.web> 
    <compilation debug="true" targetFramework="4.0" /> 
    </system.web> 
    <system.serviceModel> 
    <behaviors> 
     <serviceBehaviors> 
     <behavior> 
      <!-- To avoid disclosing metadata information, set the value below to false and remove the metadata endpoint above before deployment --> 
      <serviceMetadata httpGetEnabled="true"/> 
      <!-- 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="false"/> 
     </behavior> 
     </serviceBehaviors> 
    </behaviors> 
    <serviceHostingEnvironment multipleSiteBindingsEnabled="true" /> 
    </system.serviceModel> 
    <system.webServer> 
    <modules runAllManagedModulesForAllRequests="true"/> 
    </system.webServer> 
</configuration> 

post-scriptum Lorsque tout déplacé vers le déploiement de travail - Azure et Sharepoint Online - des erreurs à nouveau. Je crée une connexion par programme, car lu, que dans le sandbox solutions app.config pas déployé avec partie Web, nous devons dupliquer son code dans web.config Sharepoint 2010 - mais dans Sharepoint Online ce fichier est fermé à partir de développeurs!

Répondre

0

J'ai vérifié d'abord que vous pouvez utiliser SharePoint Designer 2010 pour créer un type de contenu externe qui consomme et écrit des données sur SQL Server, un service Windows Communication Foundation (WCF) ou un type .NET. Suivant SharePoint BCS prend en charge à la fois SOAP et OData, mais les services de données WCF prennent en charge les services OData, donc pour consommer un service de données WCF, vous avez besoin de la connectivité de base OData. Les composants WebPart d'affichage des données peuvent émettre des requêtes GET qui fonctionnent pour les flux OData. SharePoint Online Office 365 prend en charge les solutions sandbox, ce qui signifie que le code .Net/C# et les parties Web déployées en solution sont possibles, mais je ne suis pas sûr que la connexion SP Web Parts soit possible comme vous le décrivez car les solutions Sandbox ne prennent pas en charge faire des appels Web sortants.

Avez-vous vérifié la dernière pièce?

0

Vous recevez une erreur correcte de SharePoint Demande d'autorisation de type "System.Net.WebPermission, Système, Version = 2.0.0.0, Culture = neutral, PublicKeyToken = b77a5c561934e089". Ceci est dû aux restrictions Sandbox. Vous pouvez voir toutes les autorisations qui sont refusées au code sandbox à partir de l'article MSDN this. Et WebPermission avec SocketPermission qui sont dinied pour le code dans la solution de bac à sable.

Si vous souhaitez accéder à des services externes, peu importe le protocole TCP ou HTTP, vous devez passer aux solutions de confiance complètes.

Questions connexes