Centre de développement Sharepoint 2010
Sharepoint 2010 - MSDN
Tutoriels Sharepoint 2010 sur areaprog
Developper Top 10 Resource Center | Sharepoint
Cet article est le dernier d’une série de 3 (je ne compte pas le bonus qui est pour les curieux !):
Je vous recommande vivement de lire le premier article qui définit le besoin et introduit les concepts qui seront mis en place pour arriver à nos fins.
A ce stade, et grâce au deuxième article, nous avons configuré une WebApp Sharepoint avec les Claims en FBA et NTLM pour que les sites soient accessibles aussi bien à partir d’une application Silverlight pour Windows Phone 7 que directement à partir d’un navigateur qui utilise les credentials de la session.
Il nous reste à coder l’application Silverlight qui dans notre exemple nous permettra d’afficher une liste. Dans cet article, vous trouverez une assemblie à télécharger que vous pourrez réutiliser dans vos projets, qui vous aidera à mettre en place la phase d’authentification en un minimum de temps et de code.
Je souhaite afficher une simple liste qui se trouve sur mon site Sharepoint. Comme on ne change pas une équipe qui gagne, je reste sur l’exemple de ma liste des vins.
Un petit avant goût avant/après:
Ma liste dans Sharepoint :
Ma liste sur Windows Phone 7 dans un contrôle Panorama
La dernière partie qui affiche la liste sous la forme d’un contrôle Panorama peut tout à fait être suivie indépendamment que les données proviennent de Sharepoint.
Pour développer une application pour Windows Phone 7, il faut installer le kit de développement pour Windows Phone 7. Ce kit est gratuit et contient entre autres une version Express de Visual Studio, Blend 4 pour WP7 ainsi qu’un émulateur qui vous permet de tester vos applications.
Démarrez Visual Studio en mode administrateur.
Créez un nouveau projet Silverlight pour Windows Phone 7 et choisissez-lui un petit nom (ici SPListOnWP7).
Par défaut, Visual Studio crée une page xaml appelée MainPage. Dans notre cas, nous allons utiliser un contrôle Panorama pour page principale. Nous allons donc nous baser sur une page Panorama par défaut, plutôt que la MainPage déjà créée.
Vous aurez peut-être remarqué qu’il existe un type de projet Panorama : je ne l’ai pas choisi car il est + loin de l’ergonomie finale que nous souhaitons obtenir. C’est malgré tout un choix tout à fait pertinent pour créer une application basée sur une page de type Panorama.
Supprimez le fichier MainPage.xaml de votre projet. Puis ajoutez un nouvel élément “Panorama Page” à votre projet que vous appellerez MainPage, pour remplacer l’ancien:
C’est dans le code behind de la page principale MainPage.xaml.cs que nous accèderons à nos listes Sharepoint.
Dans les exemples et démos de ce blog, vous trouverez souvent du code métier ou d’accès aux données dans le code-behind d’une page xaml. Ce genre d’écriture n’est pas recommandé car il mélange les couches Vue/Métier/Accès aux données. Malgré tout, il est pratiqué pour la démo, pour montrer le minimum de code qui ne cible pas directement le sujet de l’article. En mode projet, je vous recommande d’utiliser le pattern MVVM dont vous trouverez un exemple ici, dans un article dédié à ce sujet. Spécifiquement pour Windows Phone, vous pouvez utiliser le toolkit MVVM Light qui prend en charge la problématique de navigation. Je ne m’étends pas plus sur le sujet dans ce post...mais j’y reviendrai bientôt dans un prochain article.
Avec Sharepoint 2010, s’offrent 2 nouveaux moyens d’accéder à Sharepoint à partir d’un client Silverlight. L’une ou l’autre des possibilités serait un choix pertinent:
Il n’y a pas une mais plusieurs raisons au fait que cela coince.
La solution la plus simple est d’utiliser les Web Services (.asmx) qui existaient déjà dans Sharepoint 2007. Il faudra commencer par utiliser le service Web d’authentification de Sharepoint pour récupérer un jeton (CookieContainer) qui sera ensuite passé en paramètre dans dans les requêtes du modèle objet de Sharepoint.
Pour simplifier l’appel au service Web d’authentification de Sharepoint, je vous propose d’utiliser une assemblie (que je mets en pièce jointe) qui va se charger de nous authentifier auprès du service Authentication.asmx de notre site et qui nous renvoie le CookieContainer que l’on réinjectera dans les requêtes sur le modèle objet de Sharepoint.
Pour ne pas alourdir ce post (et ne pas embêter les lecteurs qui s’en fichent ), j’ai déporté l’explication de ce projet dans la 4ème partie de cet article. J’y explique le fonctionnement de ce projet ainsi que l’utilisation de Rx framework qui nous permet ici de simplifier l’appel asynchrone à des services web.
Téléchargez cette assemblie :
et référencez-là dans le projet SPListOnSP7 :
Ouvrez le fichier MainPage.xaml.cs et ajoutez la référence au namespace de SPProxyForWP7. Puis instanciez la classe Context qui va nous permettre de nous authentifier en passant en paramètres:
Vous obtenez ce code:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Net;
using System.Windows;
using System.Windows.Controls;
using System.Windows.Documents;
using System.Windows.Input;
using System.Windows.Media;
using System.Windows.Media.Animation;
using System.Windows.Shapes;
using Microsoft.Phone.Controls;
using SPProxyLibForWP7;
namespace SPListOnWP7
{
public partial class MainPage : PhoneApplicationPage
Context ctx = new Context(
@"http://stephe-msft:16483", // URL du site
"stephe", // Id User FBA
"xxxxxx"); // Password User FBA
// Constructor
public MainPage()
InitializeComponent();
}
A présent, nous allons déclencher l’authentification en appelant Authenticate dans le constructeur de la page et en passant 2 delegates qui correspondent respectivement au code à exécuter sur une authentification réussie, et sur erreur. Remarquez que sur une authentification réussie, on récupère un CookieContainer en paramètre du delegate.
_ctx.Authenticate(OnAuthenticated, OnError);
void OnAuthenticated(CookieContainer cc)
void OnError(Exception e)
A ce stade, l’authentification est déjà opérationnelle ! Pour le vérifier, placez un point d’arrêt dans votre méthode OnAuthenticated. Démarrez votre application (F5), vous devriez tomber sur votre point d’arrêt.
Le CookieContainer sera vu comme un jeton d’authentification et sera réinjecté dans mes requêtes aux listes à travers les Web Services de Sharepoint (Lists.asmx). Nous allons à présent utiliser le service web Lists.asmx pour récupérer les items de notre liste des vins.
Cliquez sur “Add Service Reference” pour votre projet SPListOnWP7:
Ajoutez une référence au service lists.asmx en suffixant l’adresse de votre site par /_vti_bin/lists.asmx et cliquez Go.
Cette opération va nous permettre d’avoir accès un ensemble de classes proxy qui nous aideront à appeler facilement les services web pour accéder aux listes de notre site. Modifiez le nom du namespace pour qu’il soit plus explicite, ici : SPWebServices. Cliquez Ok.
Votre service a été ajouté au projet, ainsi qu’un fichier ServiceReferences.ClientConfig.
Le fichier ServiceReferences.ClientConfig contient la configuration des endpoints et bindings utilisés pour appeler les services web. Pour utiliser le CookieContainer dans les requêtes, il faut ajouter l’attribut suivant sur la configuration du binding:
enableHttpCookieContainer="true"
Voici votre fichier modifié :
<configuration>
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="ListsSoap" enableHttpCookieContainer="true" maxBufferSize="2147483647" maxReceivedMessageSize="2147483647">
<security mode="None" />
</binding>
</basicHttpBinding>
</bindings>
<client>
<endpoint address="http://stephe-msft:16483/_vti_bin/lists.asmx"
binding="basicHttpBinding" bindingConfiguration="ListsSoap"
contract="SPWebServices.ListsSoap" name="ListsSoap" />
</client>
</system.serviceModel>
</configuration>
Repassons à présent côté code dans le fichier MainPage.xaml.cs et ajoutez la référence au namespace du service :
using SPListOnWP7.SPWebServices;
Dans la callback OnAuthenticated, écrivons le code nous permettant de récupérer les items de la liste des vins.
En plus détaillé:
On instancie la classe proxy cliente du service lists.asmx. On injecte le CookieContainer dans la classe cliente. En Silverlight, toutes les opérations d’appel à des services web se font en asynchrone, c’est pourquoi on associe une callback à l’événement de fin récupération des items de la liste. L’appel à GetListsItemsAsync déclenche la récupération des éléments de la liste.
ListsSoapClient lists = new ListsSoapClient();
lists.CookieContainer = cc;
lists.GetListItemsCompleted += new EventHandler<GetListItemsCompletedEventArgs>(lists_GetListItemsCompleted);
lists.GetListItemsAsync(
"Wines", //List Name
String.Empty, //View Name
null, //query
null, //view fields
null, //row limit
null, //query options
null); //webID
void lists_GetListItemsCompleted(object sender, GetListItemsCompletedEventArgs e)
A ce stade, vous pouvez positionner un point d’arrêt dans votre méthode
Vous devriez y tomber si vous démarrez l’application en mode debug (F5).
A présent, nous allons parser le flux en retour pour en extraire les items et les projeter dans un ensemble d’éléments fortement typés.
Pour cela, nous commençons par créer une classe qui représente un élément de la liste des vins, à savoir son nom et le nombre de bouteilles qui restent dans ma cave. Cette classe nous permettra d’accéder aux différentes informations (titre, nb bouteilles) en relatif dans le binding dans la page xaml.
public class WineElem { public string Title { get; set; } public int BottlesCount { get; set; } public override string ToString() { return Title; } }
Parsons à présent le flux et effectuons la projection:
IEnumerable<XElement> rows = e.Result.Descendants(XName.Get("row", "#RowsetSchema"));
IEnumerable<WineElem> wines = from element in rows
select new WineElem
Title = (string)element.Attribute("ows_LinkTitle"),
BottlesCount = (int)double.Parse(element.Attribute("ows_Count").Value)
};
Tout est prêt à présent pour raccorder notre collection wines à la source de données d’un contrôle Silverlight WP7.
Notre liste sera représentée par un contrôle typique de l’ergonomie Windows Phone 7: le contrôle Panorama.
Chaque élément de la liste sera représenté par une bouteille (une image wine.png):
Ajoutez ce fichier à votre projet, ainsi que l’image suivante qui servira de fond d’écran pour l’application (fondVins.png):
Modifiez les propriétés de ce fichier dans Visuel Studio pour qu’ils soient déployés correctement:
Vous pouvez télécharger ces images directement ici :
Ouvrez votre fichier MainPage.xaml. Vous y trouverez le code type pour l’utilisation d’un contrôle Panorama, à savoir:
<!--LayoutRoot contains the root grid where all other page content is placed-->
<Grid x:Name="LayoutRoot">
<controls:Panorama Title="my application">
<!--Panorama item one-->
<controls:PanoramaItem Header="item1">
<Grid/>
</controls:PanoramaItem>
<!--Panorama item two-->
<controls:PanoramaItem Header="item2">
</controls:Panorama>
</Grid>
Modifiez le titre en remplaçant
par
<controls:Panorama Title="Ma Cave A Vins">
Nommez le contrôle PanoWinesList, puis supprimez les 2 items déclarés “en dur” : nous allons utiliser la propriété ItemsSource pour renseigner dynamiquement la source de données du contrôle Panorama.
<controls:Panorama x:Name="PanoWinesList" Title="Ma Cave A Vins" ItemsSource="{Binding}">
En affectant ItemsSource à {Binding}, on définit que la source de données est relative à la propriété DataContext que l’on va initaliser dans le code-behind. Rouvrez le fichier MainPage.xaml.cs et ajoutez la dernière ligne à la méthode :
PanoWinesList.DataContext = wines;
Ainsi, dans le contrôle Panorama, chaque élément sera rattaché à une instance de WineElem.
A présent, nous allons définir la représentation d’un item de la liste des vins. Nous utiliserons pour cela 3 éléments graphiques différents:
Pour cela, nous allons modifier la propriété ItemTemplate du contrôle Panorama, qui définit le représentation d���un élément :
<controls:Panorama.ItemTemplate>
<DataTemplate>
<Grid>
<Image Source="wine.png" Canvas.Top="100" Width="300" Height="400" HorizontalAlignment="Center" VerticalAlignment="Center" />
<TextBlock Text="{Binding BottlesCount}" HorizontalAlignment="Center" VerticalAlignment="Center" FontSize="48"></TextBlock>
</DataTemplate>
</controls:Panorama.ItemTemplate>
Nous avons choisi une grille comme conteneur de nos éléments. Par défaut les éléments contenus dans la grille s’affichent en haut à gauche, donc nous centrerons tous les contrôles.
Reprenons l’explication élément par élément :
On ajoute également une image de fond sur la grille principale, ce qui nous amène au code complet suivant:
<phone:PhoneApplicationPage
x:Class="SPListOnWP7.MainPage"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:phone="clr-namespace:Microsoft.Phone.Controls;assembly=Microsoft.Phone"
xmlns:shell="clr-namespace:Microsoft.Phone.Shell;assembly=Microsoft.Phone"
xmlns:controls="clr-namespace:Microsoft.Phone.Controls;assembly=Microsoft.Phone.Controls"
xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
mc:Ignorable="d" d:DesignWidth="480" d:DesignHeight="800"
FontFamily="{StaticResource PhoneFontFamilyNormal}"
FontSize="{StaticResource PhoneFontSizeNormal}"
Foreground="{StaticResource PhoneForegroundBrush}"
SupportedOrientations="Portrait" Orientation="Portrait"
shell:SystemTray.IsVisible="False">
<Image Source="fondVins.png" HorizontalAlignment="Stretch" VerticalAlignment="Top"></Image>
<!--Panorama-based applications should not show an ApplicationBar-->
</phone:PhoneApplicationPage>
Ca y est, votre application fonctionne !
Vous pouvez la démarrer en obtiendrez le résultat suivant, en vous déplaçant de page en page :
Dans cet article, nous avons vu comment créer une nouvelle application Silverlight pour Windows Phone 7. Nous avons accédé aux listes d’un site Sharepoint en nous authentifiant en mode forms grâce aux Web Services (.asmx) de Sharepoint, en utilisant l’astuce du CookieContainer. Nous avons également affiché une liste dans un contrôle typique WP7 : le Panorama.
Pour les plus curieux, rendez-vous avec le Bonus : l’utilisation de Reactive Framework pour simplifier l’appel asynchrone à des services web. Nous nous baserons sur le code de l’assemblie fournie en téléchargement un peu plus haut dans cet article.
Cet article est le second d’une série de 3:
Cette deuxième partie est consacrée à la configuration de Sharepoint pour permettre une authentification Forms Based avec les claims. En effet, une application Silverlight devra s’authentifier à Sharepoint en Forms. Or, Sharepoint permet l’authentification Forms Based uniquement à travers les Claims.
N’hésitez pas à lire ce post qui explique simplement le fonctionnement des Claims et les mécanismes d’authentification en général dans Sharepoint 2010.
Il y a 2 grandes parties dans ce post:
[Vous pouvez sauter les étapes 1 et 2 si vous créez une nouvelle WebApp]
Cette étape va nous permettre d’identifier la WebApp à traiter, et de vérifier s’il faut la faire évoluer en mode Claims pour supporter l’authentification FBA.
Lancez la console d’administration de Sharepoint :
Allez dans Site Actions/Site Settings :
Puis dans Application Management à partir du menu de gauche, choisissez Manage Web Applications :
Sélectionnez la Web App qui héberge la collection de sites à laquelle vous souhaitez accéder depuis un Windows Phone 7 (la colonne URL devrait vous permettre de l’identifier facilement), puis cliquez sur “Authentication Providers” dans le bandeau:
Cliquez sur Default pour voir la configuration du mode d’authentification de votre Web App :
Si vous voyez “Windows” apparaitre en tant que provider c’est qu’il faut convertir votre WebApp pour utiliser les claims.
La procédure de conversion ne peut s’effectuer qu’en Power Shell.
Lancez le management shell en mode administrateur:
Tapez le script suivant, en spécifiant l’URL de votre WebApp (ex : “http://stephe-msft:16483”) et votre identifiant d’administrateur (ex: “EUROPE\stephe”) :
$WebAppName = "http:// yourWebAppUrl"$account = "yourDomain\yourUser"$wa = get-SPWebApplication $WebAppNameSet-SPwebApplication $wa -AuthenticationProvider (New-SPAuthenticationProvider) -Zone Default
$wa = get-SPWebApplication $WebAppName$account = (New-SPClaimsPrincipal -identity $account -identitytype 1).ToEncodedString()
$zp = $wa.ZonePolicies("Default")$p = $zp.Add($account,"PSPolicy")$fc=$wa.PolicyRoles.GetSpecialRole("FullControl")$p.PolicyRoleBindings.Add($fc)$wa.Update()
$wa = get-SPWebApplication $WebAppName$wa.MigrateUsers($true)
A ce stade, vous disposez d’une WebApp en mode Claims.
Rejouez la séquence de l’étape 1. dans la console d’administration, pour vous retrouver devant le menu “Authentication Providers” de la WebApp qui doit à présent afficher un provider de type Claims :
Cliquez sur Default pour éditer les paramètres d’authentification, et activez :
Cliquez Save en base de l’écran
Nous allons modifier 3 fichiers de configuration pour y définir le provider “admembers”.
Pour cela, il faut passer par le Gestionnaire de Services IIS que vous pouvez lancer en tapant “iis” dans l’intitulé de commande du menu démarrer.
Les fichiers de configurations se trouvent respectivement dans les répertoires associés aux 3 éléments encadrés, qui sont accessibles en faisant un click droit sur l’élément, puis “Explorer”.
Dans notre exemple ma WebApp est “Sharepoint – 16483”.
Editez le fichier web.config avec notepad, un quelconque éditeur xml ou même Visual Studio. Recherchez la section suivante dans le fichier :
<membership defaultProvider="i"> <providers> <add name="i" type="Microsoft.SharePoint.Administration.Claims.SPClaimsAuthMembershipProvider, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" /> </providers> </membership>
<add name="admembers" type="System.Web.Security.ActiveDirectoryMembershipProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" connectionStringName="adconn" enableSearchMethods="true" attributeMapUsername="sAMAccountName" />
<membership defaultProvider="i"> <providers> <add name="i" type="Microsoft.SharePoint.Administration.Claims.SPClaimsAuthMembershipProvider, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" /> <add name="admembers" type="System.Web.Security.ActiveDirectoryMembershipProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" connectionStringName="adconn" enableSearchMethods="true" attributeMapUsername="sAMAccountName" /> </providers></membership>
<connectionStrings> <add name="adconn" connectionString="LDAP://europe.corp.microsoft.com/DC=europe,DC=corp,DC=microsoft,DC=com" /></connectionStrings>
...</Sharepoint> <connectionStrings> <add name="adconn" connectionString="LDAP://europe.corp.microsoft.com/DC=europe,DC=corp,DC=microsoft,DC=com" /> </connectionStrings> <system.web> <securityPolicy> <trustLevel name="WSS_Medium" policyFile="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\config\wss_mediumtrust.config" />...
<membership defaultProvider="admembers"> <providers> <add name="admembers" type="System.Web.Security.ActiveDirectoryMembershipProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" connectionStringName="adconn" enableSearchMethods="true" attributeMapUsername="sAMAccountName" /> </providers> </membership>
<connectionStrings> <add name="adconn" connectionString="LDAP://europe.corp.microsoft.com/DC=europe,DC=corp,DC=microsoft,DC=com"/> </connectionStrings> <system.web> <membership defaultProvider="admembers"> <providers> <add name="admembers" type="System.Web.Security.ActiveDirectoryMembershipProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" connectionStringName="adconn" enableSearchMethods="true" attributeMapUsername="sAMAccountName" /> </providers> </membership> </system.web>
Dans l’administation centrale de Sharepoint, placez-vous sur la page de configuration des WebApp (suivez l’étape 1. si vous souhaitez être guidés) :
Sélectionnez votre WebApp et dans le bandeau cliquez sur “User Policy”. Seuls les utilisateurs NTLM sont présents dans la policy, nous allons y ajouter ceux qui sont autorisés à se connecter en FBA. Cliquez sur “Add Users”.
Puis Next
Dans la section Users, cliquez sur l’annuaire pour rechercher des utilisateurs:
Dans mon cas, j’autorise tous les membres du provider LDAP admembers à avoir le contrôle total. Vous pouvez être plus restrictif en choisissant certains comptes de l’AD, mais il faut les rechercher dans la section “Forms Auth” et non pas “Active Directory” pour qu’ils soient associés à l’authentification FBA.
Cliquez Ok.
Cochez les permissions adéquates (Full Control dans mon cas) et cliquez sur Finish.
Vous pouvez à présent vous connecter à votre site Sharepoint avec 2 modes d’authentification différents, mais tous deux basés sur le même Active Directory:
D’une part, vos utilisateurs peuvent toujours accéder au site comme auparavant, à partir d’un navigateur en utilisant les credentials de la session(authentification NTLM). Evidemment, ils peuvent également utiliser l’authentification Forms Based dans le navigateur s’ils le souhaitent et si vous leur en avez donné les autorisations. Dans ce cas, ne préfixez pas l’identifiant par le nom de domaine lorsque vous saisissez les credentials (ex : “stephe” et non pas “EUROPE\stephe”).
D’autre part, vos applications Windows Phone 7 accèderont à Sharepoint en passant par l’authentification Forms Based.
En fait, le plus dur est fait. Vous pouvez maintenant vous attaquer à l’application Windows Phone 7 :
Accéder à Sharepoint dans une application Silverlight pour Windows Phone 7 (3/3) : Côté client Silverlight pour WP7
L’idée est simple, la mettre en pratique, un peu moins (en tout cas pour l’instant).
Cet article est destiné à un public de développeurs qui n’est pas forcément à l’aise avec la console d’administration ou tout ce qui relève des possibilités de configuration de Sharepoint…ou à des Sharepointers qui pourront peut-être passer directement à la partie Développement.
L’article est scindé en 3 parties :
Je suis donc partie d’un contexte de la vraie vie :
Vous l’aurez compris, si j’en suis à vous parler du mode d’authentification, c’est qu’il ne suffit pas d’utiliser un client OData ou le Client Side Object Model pour accéder à votre Sharepoint depuis Windows Phone 7.
Je me suis librement inspirée du post de Paul Stubbs pour arriver à mes fins. Cette article va un peu plus loin et vulgarise également davantage ce qui touche à la configuration de Sharepoint.
Mon téléphone n’est pas dans le domaine (puisque je n’y ai pas ouvert de session comme je l’aurais fait sur mon PC)
-> C’est à mon application Silverlight de s’authentifier en renseignant “manuellement” un nom d’utilisateur et un mot de passe. Pour cela, je vais devoir activer un deuxième mode d’authentification dans ma WebApp : l’authentification par formulaire (Form Based Authentication).
-> Il faut trouver une manière de renseigner ces credentials Forms dans notre application : nous utiliserons le service Web SOAP d’authentification de Sharepoint, en récupérant le cookie et en le réinjectant dans les requêtes au service SOAP de listes, qui seront ainsi reconnues comme authentifiées.
Configurer le mode d’authentification FBA : utiliser mon AD existant comme un provider d’identité, pour que les credentials passés en mode FBA soient vérifiés dans mon annuaire d’entreprise (comme c’est le cas pour mon authentification NTLM)
On peut résumer cela avec le schéma suivant qui montre les séquences des 2 scenarii d’authentification, selon que l’on se place côté PC ou côté Windows Phone 7:
Voici la séquence des opérations à réaliser sous forme de schéma:
Et commençons par configurer Sharepoint dans la seconde partie de l’article:
Accéder à Sharepoint dans une application Silverlight pour Windows Phone 7 (2/3) : Côté Sharepoint