Les techdays 2010 étaient pour moi l’occasion de revenir sur Paris et revoir pas mal de monde. Pas mal d’anciens collègues sympathiques qu’il fait bon retrouver :-).

Revenir sur Paris en effet, car je suis parti il y a 7 mois m’installer en Bretagne dans un cadre idéal, à Vannes. Pas mal de choses ont changé depuis, mais ce n’est pas l’objet de ce billet.

Ces techdays sont également pour moi un retour au blog. Voici ce que j’ai vu durant les sessions de ces presque 3 jours (je suis arrivé sur Paris le lundi à 16h00)

1er jour

SharePoint 2010 à votre service : les services d'application dans SharePoint 2010

A l’issu de la session j’ai eu le sentiment que les services d'applications (qui devraient être nommés services applicatifs comme le suggère Patrick Guimonet) étaient sémantiquement proches des jobs SharePoint 2007. On y apprend qu'ils offrent néanmoins :

• Une plus grande souplesse sur la répartition de charge et sur l'association à des applications web spécifiques (déjà possible dans la version 2007, mais plus lourds à gérer)
• Une interface résolument orientée "Service" à l'aide d'un système de proxy exposant le service à d'autres environnement et d'autres fermes SharePoint via du WCF.

Bien évidemment, ils remontent dans la hiérarchie du modèle objet, puisqu’ils sont des SPService à part entière.

Ils sont naturellement administrables via du PowerShell.

Dommage toutefois, car cette session abordait trop d'aspects pour permettre d’aborder convenablement les services SharePoint et être à la hauteur de ce que j'attendais.

2ème jour

Dynamics NAV 2009

Petite immersion dans le monde de l'ERP avec une présentation de Dynamics NAV 2009 et d'une entreprise de menuiserie servant de cas d'étude pour les besoins des démonstrations. Au passage, le speaker glisse un jeu de mots bienvenu sur l'activité de l'entreprise qui réalise des fenêtres, qui en est à la version 7 (la fenêtre s'ouvre plus vite) et qui la décline dans des modèles professionnel, familial et intégral. Un ton posé et clair pour une session menée par Isabelle Saint Martin (Chef de produit Microsoft Dynamics) en collaboration avec deux speakers dont j'avoue ne pas avoir noté le nom.

La démo présente le produit ainsi qu'un site web, un windows mobile et des outils Office mettant en œuvre un scenario de mobilité, l'intégration de données métiers (mesures, prix, photos du chantier, etc) et du reporting . Côté technique, énormément de choses ont été réalisées à l'aide de services Web WCF exposés par NAV 2009.

Afficher l'album en entier

Au final, j'ai eu le sentiment d'une solution bien ficelée, utile, et bien loin de certaines usines à gaz… bref, une approche pragmatique et donc vraiment adaptée au monde des PME.

ASP.Net WebForms 4.0

Vient ensuite la session d'Aurélien VERLA sur ASP.Net WebForms 4.0 en amphithéâtre… ce qui ne semble pas avoir intimidé le speaker qui, seul, est parvenu à garder un ton dynamique et présenter pas mal de choses intéressantes une heure durant. Des nouveautés sur la gestion des fichiers de config, sur l'HTML généré par les WebForms, sur des aspects de performance, sur les contrôles ainsi que des trucs et astuces. Bref, une session à voir pour rester à jour sur les WebForms dès que les webcasts seront disponibles.

Comment inclure la sécurité dans vos appels d'offre ?

Eric MITTELETTE et Philippe BERAUD (qu’on voit sur les photos) ont présenté la session "Comment inclure la sécurité dans vos appels d'offre ?". Pas de nouveautés technologiques dans cette session mais une sensibilisation à la sécurité à travers des points que j'ai pu revoir ou découvrir. Des notions incontournables et qui restent pourtant boudées par le programme des écoles informatiques. Les speakers ont présenté comment intégrer la sécurité dans les projets et ont notamment insisté sur l'importance de la modélisation des menaces. Ils ont également donnée énormément de liens, notamment vers la documentation des SDL, vers la liste des failles les plus fréquentes, et vers les outils de modélisation.

Afficher l'album en entier

Là encore, vous pourrez retrouver tout ça sur le webcast.

Business Connectivity Services

La dernière session de la journée s'est révélée être celle que j'ai le plus apprécié des TechDays. Julien CHOMARAT et Gaëtan Bouveret ont présenté une session très intéractive et pleine de démos sur les Business Connectivity Services de SharePoint. Pour faire simple, la version 2010 de SharePoint apporte avec sa brique Composite une solution puissante pour intégrer très facilement de l'applicatif dans les sites… et tout ça dès SharePoint Foundation.

Pour être franc, je n'ai pris pas beaucoup de notes durant cette session tellement je suivais le jeu d'acteur des deux speakers (mais quand même une photo de chacun d’eux). Si vous vous intéressez à SharePoint, ne faites surtout pas l'impasse sur le webcast de cette session !

Jour 3

KeyNote

Le seul Keynote auquel j'ai assisté durant ces trois jours a présenté les évolutions des langages de programmation et les recherches faites pour les rendre encore plus simple, accessibles à des enfants et à des non informaticiens. De plus en plus de visuel, de moins en moins de code… et surtout de moins en moins d'erreurs.

Une vision du futur proche avec les Natural User Interface et une belle démo sur la table Surface permettant à une équipe de travail de répartir des tâches listées dans Team Foundation Server. Le projet Natal était aussi de la partie pour le plaisir des yeux… et ce sera visiblement pour cette année.

Une petite déception pour ma part en ce qui concerne les avancées présentées sur la recherche car elles relèvent plus de l’agrégation intelligente que de l’assistance à la recherche… bref, toujours basée sur le même standard de recherche par mot clé. Je rêve du jour ou des systèmes intelligents apprendront à connaitre les utilisateurs pour adapter leur recherche :-)

Enfin, sachez que vous pouvez dès à présent retrouver ce keynote (ainsi que ceux des jours 1 et 2) en vidéo : http://blogs.technet.com/mstechdays/archive/2010/02/11/techdays-2010-revivez-la-conf-rence-pl-ni-re-du-troisi-me-jour-en-vid-o.aspx

SharePoint WorkSpace 2010

Fabrice BARBIN a présenté la session SharePoint WorkSpace 2010, successeur de Groove. Deux axes pour cette présentation : côté "Groove" ou on retrouve les fonctionnalités déjà présentes dans la version précédente et côté SharePoint avec le côté client Offline de SharePoint.

Dans le nouveautés on retrouve une interface uniformisée avec le reste de la gamme Office (offrant entres autres un ruban sur la partie supérieure), une meilleure intégration avec le reste des outils Office et des améliorations côté mécanismes d'authentification.

Fabrice a présenté l'aspect Client SharePoint au cours d'une démo intégrant les Businesss Connectivity Services : il a notamment inséré des données dans une base SQL Server à partir d'une liste externe et de l'interface Groove.

Administration de SharePoint 2010

Patrick GUIMONET et Benoit HAMET ont animé la session "Administration de SharePoint 2010" au cours de laquelle on découvre pas mal de choses intéressantes, notamment :

• La possibilité de retrouver au sein d'un site les permissions spécifiques (les éléments pour lesquelles l'héritage des droits a été désactivé) et les permissions associées à un utilisateur donné (ce qu'il peut voir au sein du site).
• Un developper DashBoard qui, lorsqu'il est activé, affiche la trace d'exécution de la page. Dans le même esprit, chaque message d'erreur se voit affecter un identifiant de correlation qui permettra de retrouver plus facilement les messages d'erreurs dans les logs. Bref, de quoi faciliter le debugging de nos devs SharePoint et identifier les problèmes de performance.
• Un Best Practice Analyzer omniprésent sur l'administration centrale : il affiche des messages pour guider les administrateurs lorsque des éléments ne sont pas configurés au mieux ou lorsque des dysfonctionnement surviennent.

Afficher l'album en entier

Enfin, Patrick nous a fait une démo à base de PowerShell et de Cmdlets SharePoint et a publié les slides et les scripts de sa présentation sur son blog.

SharePoint Online et gouvernance

Emmanuel BERGERAT et Damien CARO ont animé la session "SharePoint Online et gouvernance" sur la dernière tranche horaire des TechDays.

Après un rappel général sur l'offre Online de Microsoft et sur l'intérêt du Software + Service, les deux speakers ont présenté l'interface. Peu de nouveautés sur la première partie puisqu'elle concernait la version actuelle basée sur SharePoint 2007. Plus sur la seconde en revanche, avec une vidéo de la vNext de SharePoint Online basée sur SharePoint 2010. Les fonctionnalités y sont visiblement plus nombreuses : identification avec LiveID, solutions SandBox voire Full Trust (non confirmé pour le moment).

Voilà pour les sessions. Pour conclure ce billet je voudrais remercier toutes les personnes avec lesquelles j’ai pu passer du temps durant ces trois jours, et notamment la personne qui m’a hébérgé…

Intégrer les outils clients Office avec un extranet SharePoint est un besoin récurent qui trouve malheureusement peu de solutions. L’équipe SharePoint a récemment annoncé sur son blog une solution côté client qui ne pourra cependant pas satisfaire tout le monde.

Pour m’être intéressé à cette intégration à plusieurs reprises, j’ai souhaité présenter quelles étaient précisément les raisons de la limitation et comment les contourner. Et c’est au travers de mon article sorti ce matin sur TechHeadBrothers que vous trouverez tout ça.

A noter au passage : vous pourrez retrouver une solution similaire sur le projet CodePlex CKS. Bonne lecture !

Annoncé il y a deux jours sur le blog de l’équpe Groove, la prochaine version de Groove portera le nom de SharePoint Workspace 2010 !

Information qui dépasse le strict cadre du nom de produit, car bien qu’aucun détail précis ne soit communiqué il est vraisemblable que Groove prenne une dimension tout autre.

En effet, outil collaboratif décentralisé par excellence, Groove est annoncé comme étant client de la solution collaborative centralisée MS par excellence (à savoir SharePoint). Bref, une affaire à suivre de près pour la prochaine version !

Suite du post d’hier ou j’indiquais que l’installation du SP2 sur une VPC m’avait posé quelques soucis, j’ai poursuivi mes test et j’ai pu déceler d’autres logs que ceux référencés par l’assistant. Ces logs comportaient entres autres ces quelques lignes :

[SPManager] [ERROR] [4/29/2009 10:53:18 PM]: ReflexiveUpgrade [SPServer Name=office12-server Parent=SPFarm Name=SharePoint_Config] failed.
[SPManager] [ERROR] [4/29/2009 10:53:18 PM]: The system cannot find the path specified.

[SPManager] [ERROR] [4/29/2009 10:53:18 PM]:    at System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail)
   at System.DirectoryServices.DirectoryEntry.Bind()
   at System.DirectoryServices.DirectoryEntry.get_AdsObject()
   at System.DirectoryServices.PropertyValueCollection.PopulateList()
   at System.DirectoryServices.PropertyValueCollection..ctor(DirectoryEntry entry, String propertyName)
   at System.DirectoryServices.PropertyCollection.get_Item(String propertyName)
   at Microsoft.SharePoint.Administration.SPIisApplicationPool.get_PeriodicRestartMemory()
   at Microsoft.SharePoint.Administration.SPProvisioningAssistant.EnableMemoryBasedAppPoolRecycling(SPIisApplicationPool local)
   at Microsoft.SharePoint.Administration.SPProvisioningAssistant.EnableMemoryBasedAppPoolRecycling(String applicationPoolId)
   at Microsoft.SharePoint.Upgrade.EnableMemoryBasedAppPoolRecycling.Upgrade()
   at Microsoft.SharePoint.Upgrade.SPActionSequence.Upgrade()
[SPManager] [ERROR] [4/29/2009 10:53:18 PM]: Action 3.1.3.0 of Microsoft.SharePoint.Upgrade.SPIisWebSiteWssSequence failed.
[SPManager] [ERROR] [4/29/2009 10:53:18 PM]:    at Microsoft.SharePoint.Upgrade.SPActionSequence.Upgrade()
   at Microsoft.SharePoint.Upgrade.SPManager.Upgrade(Object o, Boolean bRecurse)
   at Microsoft.SharePoint.Upgrade.SPManager.ReflexiveUpgrade(Object o, Boolean bRecurse)
   at Microsoft.SharePoint.Upgrade.SPManager.Upgrade(Object o, Boolean bRecurse)
   at Microsoft.SharePoint.Administration.SPPersistedUpgradableObject.Upgrade(Boolean recursively)
   at Microsoft.SharePoint.Upgrade.SPManager.ReflexiveUpgrade(Object o, Boolean bRecurse)
   at Microsoft.SharePoint.Upgrade.SPManager.Upgrade(Object o, Boolean bRecurse)
   at Microsoft.SharePoint.Administration.SPPersistedUpgradableObject.Upgrade(Boolean recursively)
   at Microsoft.SharePoint.Upgrade.SPManager.ReflexiveUpgrade(Object o, Boolean bRecurse)
   at Microsoft.SharePoint.Upgrade.SPManager.Upgrade(Object o, Boolean bRecurse)
   at Microsoft.SharePoint.Administration.SPPersistedUpgradableObject.Upgrade(Boolean recursively)
   at Microsoft.SharePoint.Upgrade.SPManager.ReflexiveUpgrade(Object o, Boolean bRecurse)
   at Microsoft.SharePoint.Upgrade.SPManager.Upgrade(Object o, Boolean bRecurse)
   at Microsoft.SharePoint.Administration.SPPersistedUpgradableObject.Upgrade(Boolean recursively)
   at Microsoft.SharePoint.Upgrade.SPManager.ReflexiveUpgrade(Object o, Boolean bRecurse)

Vous pourrez entres autres noter les erreurs "The System cannot find the path specified” et “Action 3.1.3.0 of Microsoft.SharePoint.Upgrade.SPIisWebSiteWssSequence failed.”

Si SPIisWebSiteWssSequence ne me parle pas nécessairement, la classe SPIisWebSite correspond à ce que j’ai manipulé récemment et dont j’ai commencé à parler sur ce post : Gestion des Applications Web SharePoint et sites IIS : Best Practices. Bref, j’ai rapidement compris que l’erreur venait d’un problème au niveau de mon site IIS . L’erreur "The System cannot find the path specified” n’indique pas la véritable erreur, puisque le chemin IIS existe bien. Il n’empêche, la VPC sur laquelle j’ai tenté la migration était celle que j’avais utilisé aux TechDays, et pour laquelle j’avais fais quelques modifications en dur (comme pour les entêtes d’hote par exemple).

Bref, je n’ai pas respecté mes propres recommandations (sur une VPC de démo, hum, y’a pas mort d’homme non plus)…

J’ai finalement supprimé les sites IIS concernés avant de les “re-provisonner” proprement : au final, la mise à jour MOSS SP2 + Language Pack s’est bien passée :-)

J’enfonce donc encore un peu le clou  pour souligner l’importance de modifier les paramètres SharePoint depuis l’API et non depuis les éléments autour.

Je viens tout juste de tenter une installation du SP2 de SharePoint fraîchement sorti. Vous trouverez les liens pour télécharger les Office Server Service Packs sur le blog de David.

Préalablement à l’installation de ces Service Packs, il vous faudra installer ceux de Windows SharePoint Services :

• Les SP2 WSS : http://www.microsoft.com/downloads/details.aspx?displaylang=fr&FamilyID=79bada82-c13f-44c1-bdc1-d0447337051b 
• Le Language Pack SP2 x86 : http://www.microsoft.com/downloads/details.aspx?displaylang=fr&FamilyID=085e5ac8-58f6-4cf9-8012-33b95ee36c0f
• Le Language Pack SP2 x64 : http://www.microsoft.com/downloads/details.aspx?FamilyId=2C2B6CAF-B46D-45EB-AC4D-DEAAA48C3A2C

Vous retrouverez une également une version SlipStream de WSS :

• La version d’installation x86 avec le SP2 : http://www.microsoft.com/downloads/details.aspx?displaylang=fr&FamilyID=ef93e453-75f1-45df-8c6f-4565e8549c2a
• La version d’installation x64 avec le SP2 : http://www.microsoft.com/downloads/details.aspx?displaylang=fr&FamilyID=2c2b6caf-b46d-45eb-ac4d-deaaa48c3a2c

Mais avant toute chose, pensez à sauvegarder vos données. Ce n’est pas une recommandation spécifique : c’est à faire systématiquement avant une mise à jour. Je vous recommande également de (re)lire la page du Technet Deploy software updates for Windows SharePoint Services 3.0 avant de précéder à la mise à jour.

Enfin, notez pour l’avenir qu’il est de bon ton de garder une version d’installation SP2+ Ready avec vous en réutilisant l’astuce que j’avais relayé sur la création de version SlipStream. SP2+ car cette astuce vous permettra d’incorporez les éventuelles KB intermédiaires. Personnellement, je m’en sers chez mes clients de façon à garder une version slipstream en phase avec ce qu’ils ont en production.

Ma VM n’ayant pas aimé la mise à jour, je vous ferai un retour sur l’installation un peu plus tard.

Une des choses que j’aime avec SharePoint, c’est de voir que la frontière exploitation/développeurs est souvent moins marquée qu’ailleurs.

Moins marquée parce que SharePoint fait appel à tellement de systèmes différents qu’un développeur ne pourra pas s’en sortir bien longtemps sans s’intéresser à des problématiques un peu plus connotée infrastructure/système/réseau qu’à son habitude.

Moins marquée également car les admins se mettent à s’intéresser au monde du développement. Et j’insiste sur ce point, car je l’ai vu plusieurs fois : les admins veillent de plus en plus souvent aux fuites mémoire et sont aussi souvent conscient que des Best Practices de développement (l’appel au Dispose) peuvent les réduire considérablement. Mieux que ça : j’en ai vu se mettre à coder, dans Visual Studio (chose plutôt rare), ou via PowerShell  (chose déjà bien plus courante).

Bref, la frontière se réduit par endroit et c’est une très bonne chose. Il n’empêche… certaines vielles habitudes persistent de chaque côté et impliquent des difficultés d’administration et/ou des dysfonctionnement dont je viens parler ici.

Problèmes concrets :

La souplesse de SharePoint fait qu’une batterie de serveurs peut s’élargir facilement, pour mieux tenir la charge par exemple, ou encore pour assurer une continuité de service. Lorsqu’un nouveau serveur est ajouté à la batterie de serveurs, SharePoint réalise automatiquement un certain nombre d’opérations sur le nouveau serveur :

• Création des applications pools
• Création des sites IIS
• Déploiement des fichiers de solution contenus dans le magasin de solutions SharePoint (fichiers dans le répertoire 12, déploiement dans le GAC/BIN, …)
• Mise à jour des fichiers web.config en fonction des modifications gérées par SharePoint (SafeControls, SPWebConfigModification, …)

Bref, en théorie un site est opérationnel dès que le serveur est rattaché à la batterie de serveurs. En pratique, ce mécanisme est très souvent insuffisant car les développeurs et/ou les administrateurs ont introduit des changements à faire manuellement : le mécanisme automatique de SharePoint ne les réalise donc pas… et c’est le drame !

Quelques exemples de problèmes vécus :

• Ajout manuel de paramètres dans le fichier web.config :

Les développeurs ont ajouté manuellement des paramètres dans le fichier web.config. Une ConnectionString par exemple, ou encore n'importe quel paramètre, référence à une ressource externe, etc. Lorsque l’utilisateur se connecte à l’Application Web SharePoint, le mécanisme de load balancing détermine quel serveur traite la demande. Dans certain cas le serveur qui répondra aura les bons paramètres… de temps en temps ce sera le serveur à qui il manque des paramètres. Dans le dernier cas, les utilisateurs ont de forte chance de tomber sur une page d’erreur.

• Déploiement manuel de WebParts / Features / Ressources.

Les développeurs ont déployés les WebParts, Features et/ou ressources en les copiant manuellement dans le répertoire 12 puis en utilisant la commande stsadm –o installfeature. Le nouveau serveur sera dépourvu de ces éléments et tout utilisateur dirigé vers ce serveur sera confronté à une page d’erreur SharePoint.

• Modification du port ou changement de host header directement depuis IIS

Qui n’a jamais voulu changer le port ou les host headers après la création d’une application Web SharePoint (pour un changement de DNS par exemple) ? Ces paramètres sont bien connus des admins qui savent les modifier depuis IIS. Lorsque cette opération est réalisée via IIS, elle reste locale. En d’autres termes, SharePoint créé automatiquement les sites IIS sur le nouveau serveur mais les modifications réalisées manuellement sur les autres serveurs ne sont pas propagées. Les utilisateurs peuvent alors tomber sur d’autres sites que ceux demandés ou sur des erreurs 404.

• Paramétrage des pools d’applications

Assez similaire aux sites IIS. Vous pouvez souhaiter les paramétrer pour prendre en compte des modifications sur les comptes de service. Dans ce cas spécifique SharePoint ne vous laissera pas faire… en tout cas pas longtemps. En effet, SharePoint changera automatiquement le compte associé au pool d’application pour lui fixer sa propre valeur. Pour les autres paramètres du pool d’application, toute modification sur IIS reste locale.

Comment éviter ces problèmes / Les Best Practices :

Le fichier Web.Config

Les développeurs ASP.Net ont l’habitude de modifier manuellement le fichier web.config d’une application web pour y ajouter des paramètres. Avec SharePoint il faut cependant privilégier un autre moyen : la classe SPWebConfigModification. J’ai cependant souvenir de propos négatifs concernant cette classe, tels que '”tout le monde sait qu’il ne faut pas l’utiliser”. Et bien pourtant si ! Les détracteurs lui reprochent de compromettre le fichier web.config. Je répond que NON. Ces personnes ont tout simplement rencontré des problèmes avec des fichiers web.config qu’elles avaient modifiés manuellement et qu’elles voulaient modifier, en plus, via la classe SPWebConfigModification. Les problèmes potentiels ne sont à imputer qu’aux modifications manuelles et pas à la classe SPWebConfigModification. Bref, passer par cette classe pour modifier le fichier web.config est un Best Practice. A chaque fois qu’un développeur fait le choix d’une modification manuelle, il induit une difficulté supplémentaire pour les admins (en cas d’ajout ou de restauration d’un serveur SharePoint) et pour les prochains développeurs (qui ne pourront plus utiliser cette classe sans avoir de problème).

Déploiement de WebParts / Features / Ressources.

Les copier/coller sont à proscrire. Utilisez des solutions SharePoint. SharePoint stocke alors vos solutions dans le magasin de solutions et sait quelles sont les opérations à rejouer pour les déployer sur de nouveaux serveurs. En outre, ce procédé évite de toucher aux éléments natifs de SharePoint (je l’ai encore vu récemment).

Modification des paramètres IIS

Ce point est un peu plus délicat. En effet, l’interface d’administration SharePoint n’offre pas la possibilité de modifier ces paramètres sans détruire puis recréer l’application Web à partir d’une base de données existante. Ce mécanisme est (trop) lourd et peu envisageable. Il existe cependant une alternative, discrète : modifier les paramètres IIS depuis le modèle objet SharePoint à l’aide de la classe SPIisSettings. Un petit exemple avec du code ajoutant un host header au site IIS :

System.Uri uri = new Uri("http://localhost");
SPWebApplication webApplication = SPWebApplication.Lookup(uri);
SPIisSettings settings = webApplication.IisSettings[SPUrlZone.Default];

SPServerBinding binding = new SPServerBinding();
binding.Port = 80;
binding.HostHeader = "gribs.virtualdomain.com";
settings.ServerBindings.Add(binding);

webApplication.IisSettings[SPUrlZone.Default] = settings;

webApplication.Update();
webApplication.Unprovision();
webApplication.Provision();

Les paramètres IIS modifiables sont nombreux. Autre exemple : inutile de modifier le fichier metabase.xml à la main pour passer en Kerberos, un simple settings.DisableKerberos = false; suffit. Idem pour modifier le répertoire du site IIS : le recours à settings.Path règle le problème.

Bref, il reste à passer ce type de code en PowerShell pour ce que soit exploitable plus facilement par des admins (hum… Fabrice ? :-))

Modification de l’Application Pool

Très similaire à IIS avec la classe SPApplicationPool.

Conclusions :

Ces Best Practices se résument facilement : il FAUT passer par les mécanismes natifs SharePoint pour toute modification impactant les déploiements. Je regrette qu'il soit cependant parfois si complexe de les mettre en pratique : pour le SPWebConfigModification, par exemple, dès lors que d’autres développeurs ont fait le choix des modifications manuelles. Pour les modifications IIS également, car il n’y a pas d’interface (ça ne sautait tarder… je suis en train d’en faire une :-)).

Il n’empêche : faire l’impasse sur ces recommandations impliquera nécessairement une difficulté d’exploitation plus importante.

Quelques nouveauté en vrac pour ce mois ci (ou presque) :

VseWSS 1.3

- La CTP de mars pour les extensions Visual Studio pour WSS 1.3 est disponible et téléchargeable ici.

Vous y retrouverez quelques améliorations par rapport à la version 1.2, dont le support du 64 bits.

J'ai lu ça sur le blog de Paul Andrew... mais ce que j'y ait décelé d'interessant surtout, c'est ce lien : SharePoint tools support in Visual Studio.

Bref, ce qui semble être un apperçu de Visual Studio 10 et de la vue d'une feature de WorkFlow !

AKS 2.0

L'Accessibility Kit for SharePoint nous arrive en version 2. Pour rappel, ce Kit a pour but d'aider à réaliser des sites respectant les WCAG 2.0 AA, c'est à dire plus accessibles. L'utilisation d'un tel kit ne rend pas pour autant les choses toutes roses, mais le principal frein à son utilisation pour nous, francophones, c'était le fait qu'il ne supportait pas notre chère langue. C'est maintenant chose faite avec la version 2.

Disponible sous licence MS-PL, il est téléchargeable sur le site d'HiSoftware. A noter qu'HiSoftware en a profité pour sortir de nouveaux composants riches pour MOSS 2007.

Cumulative Updates de février

Vous commencez certainement à connaître ces updates. Les derniers en date sont ceux de février et sont disponbiles sur le site du support Microsoft :

• pour WSS : http://support.microsoft.com/hotfix/KBHotfix.aspx?kbnum=961755
• pour MOSS : http://support.microsoft.com/hotfix/KBHotfix.aspx?kbnum=961756

Rappelez vous que vous ne devez les considérer que s'ils répondent à des problèmes que vous rencontrez.

Vous trouverez un rappel sur la manière de les appliquer sur le blog de Share Young.

Sachez enfin que je n'ai toujours pas de date pour le SP2 de SharePoint, mais bon... je mise sur le fait qu'il ne devrait pas trop tarder .

@#

Mon tout premier Summit s'achêve et déjà je regrette qu'il ait été aussi cours tellement il fut intéressant. Et ce à plusieurs niveaux.

Pour moi, c'était mon premier voyage hors d'Europe. Ca peut paraître banal pour pas mal de personnes, mais pour moi prendre l'avion plus de deux heures était une grande première (Air France, c'est pas mal du tout :-)). Voir les grandes avenues américaines, les voitures d'une autre dimension (au sens litteral, hein...), la douane aussi... Bref, j'étais vraiment impressionné par tout ça.

Le Summit : comment ça se passe ?

Côté journées, le summit fut essentiellement rythmé par les sessions :

• 7h30 : petit déjeuner
• 8h00 : départ pour le campus Microsoft
• 17h00 / 18h00 : retour à l'hotel
• 19h00 : soirée MS ou entre MVPs.

Pour ceux qui ne connaissent pas le Campus Microsoft... en quelques mots... c'est gigantesque :-) Jugez en par vous même avec Virtual Earth.

Et pour ce qui est du dialogue sur place, il fut évidemment essentiellement en anglais... ce qui s'est avéré moins évident que je ne le pensais. Mais ce qui fut rassurant pour moi, c'est que je me sentais nettement plus à l'aise au bout de trois jours (le simple fait de se poser moins de questions).

La communauté MVP

Viens ensuite ce que j'ai pu voir sur place. Un nombre très important de MVP de tous horizons. Peut être 1500, pas mal de technologies différentes du coup. Des RD aussi. Bref, un nombre impressionnant de personnes passionnées, dont énormément se connaissant déjà selon les communautés. Ca a été l'occasion de voir Steve Balmer également. L'effet dans la salle était vraiment saisissant ! Enfin et surtout (pour moi), ce fut l'occasion de rencontrer des "légendes" de la communauté SharePoint... genre Andrew Connell, Bob Fox, Ted Pattison, et tout plein d'autres géants.

Côté technique

En ce qui concerne le contenu des sessions, je ne peux évidemment pas vous en parler. Je peux en revanche vous dire que je n'ai suivi que des sessions concernant SharePoint, et que je devais systématiquement faire un choix car plusieurs se tenaient simultanément. Un rapide retour néanmoins : j'aime travailler avec SharePoint, et ce que j'ai vu m'aide à vous dire que ce n'est pas prêt de s'arrêter !

Et si vous insistez pour avoir des infos... non, je ne peux raisonnablement pas vous en donner :-) ... mais je me permet de relayer quelques infos officielles reprises du blog d'Arpan Shah :

• Visual Studio 2010 supportera les développements SharePoint “14”.
• SharePoint “14” sera uniquement 64 bits.
• La SharePoint Conference 2009 sera LA conférence ou vous devriez commencer à découvrir SharePoint “14”.
• Le SP2 de SharePoint 2007 approche. Aucune date précise, mais les rumeurs parlent de fin avril.

Le fun !

PaintBall

Pour nous, SharePointeurs, le Summit est également synonyme de PaintBall... énorme moment !

• Phil & moi... équipe de choc
• Ben Robb, Bob Fox et Andrew Connell (de gauche à droite)
• Le SpeedBall à 20, ça rocks !

Fléchettes

Et pour quelques francophones cette année, certaines soirées auront eu une certaine connotation "fléchette" (cf le post de Renaud)

En quelques mots, voilà ce qu'il y a sur les photos :

• Gaëtan ne tire pas toujours SUR la cible...
• Le GameWorks, des jeux de partout, juste en face du Sheraton Hotel.
• Quand Phil n'est pas précis, il m'en met quand même plein la tête.
• Le chiffre favori de Fabrice N'EST PAS le 18 :-).
• Renaud dit qu'il ne sait pas viser, mais il ment !
• Là, c'est moi. :-)
• Bien qu'ayant participé à quelques parties, Pierre est un couche tôt (la preuve, il n'est même pas sur les photos).

Remerciements

Cet événement était vraiment superbe ! Et j'y ai participé grace à plusieurs personnes / entités que je souhaite vraiment remercier :

• Microsoft, pour la fabueluse opportunité, l'événement en lui même et une bonne partie de la logistique
• Martine Thiphaine, MVP Lead France, pour l'organisation, les infos, les visites...
• Winwise qui m'a libéré du temps et qui a financé le voyage à Seattle.

Merci !

Nombreux sont les développeurs qui sont passés à SharePoint récemment. Beaucoup de projets, encore trop peu de développeurs SharePoint... et bien souvent les mêmes questions : "Par où commencer le développement SharePoint ?". "De quoi ais-je besoin pour développer pour SharePoint ?". Et finalement, "Qu'est ce qu'on peut faire avec SharePoint ?". Et le nombre de personnes qui se posent ces questions ne désempli pas, bien au contraire.

Si vous êtes dans ce cas, ou si vous êtes simplement sceptique quand on vous parle des technologies SharePoint, venez me voir à la session Introduction au développement SharePoint et cas pratiques des TechDays 2009. J'ai en effet l'honneur de co-animer cette session avec Master Bouveret (aka Gat) mardi, de 13h à 14h.

Voici le résumé de cette session niveau 100 :

Cette session commencera par vous présenter les bases du développement pour la plateforme SharePoint (WebParts, workflows, événements, …) ainsi que les bonnes pratiques de déploiement. Nous aborderons ensuite leur mise en application au travers de plusieurs projets communautaires innovants et largement utilisés (Podcasting Kit for SharePoint, Community Kit for SharePoint, Blueprint for SharePoint, WSPBuilder, ...)

@tout à l'heure !

Les TechDays 2009 approchent à grand pas. Ce sera l'occasion de voir et d'apprendre pas mal de choses au travers des 300 sessions et ateliers. L'occasion, aussi, de voir et de discuter avec des experts hors session sur les stands partenaires par exemple, mais aussi sur les stands Microsoft.

Si vous ne vous êtes pas déjà enregistré pour participer à cet événement gratuit, je vous invite à vous connecter au site des TechDays 2009.

Les SharePointers connaissent probablement déjà le projet Codeplex "Features" référençant de nombreuses Features SharePoint orientées Développeurs, Administrateurs et même utilisateurs. Scot Hillier a récemment mis à jour ce projet pour référencer de nouvelles Features, dont une des miennes : "Site Creation in Target Database ".

Que fait cette Feature ?

Comme son nom l'indique, cette Feature permet de choisir la base de données dans laquelle créer une nouvelle collection de sites SharePoint.

Pourquoi une telle Feature ?

Par défaut, SharePoint ajouter associe automatiquement la collection de sites créée à la base de données disponible contenant le moins de collections de site. Ce mécanisme, mêlé à celui des quotas de collections de sites, permet habituellement de contrôler la taille des bases de données lorsque le process de création de sites est industrialisé, comme lorsque le "site creation self service" est activé par exemple.

Il arrive cependant que l'on souhaite garder la maîtrise des bases de données associées aux sites SharePoint. La première demande qui m'a été faite dans ce sens visait à séparer les sites SharePoint dans un contexte multi-sites physiques (le client disposait d'antennes distantes les unes des autres et souhaitait se réserver la possibilité d'intervenir sur les bases SharePoint d'une de ses antennes sans pour autant impacter les autres). Réunir les collections de sites dans une base de données spécifique en fonction de critères métiers peut également faciliter la séparation des sites SharePoint en plusieurs Applications Web voire en plusieurs fermes SharePoint.

Bref, la seule réponse à ce besoin reposait jusqu'à présent sur l'intervention préalable d'administrateurs pour modifier les quotas de collections de sites avant la création d'une nouvelle collection.

Comment se présente cette Feature ?

Le déploiement de la Feature ajoute une Custom Action sur la console d'administration centrale "Create  site collection (with db selection)" dans la rubrique "SharePoint Site Management".

Ce lien permet d'accéder à une page d'administration similaire à la page de création de collection de sites standard, à la différence prêt qu'elle comporte une liste déroulante permettant de sélectionner la base de données de contenu.

Une Feature multilingue

Cette Feature est intégralement multilingue. Aujourd'hui, seules deux langues sont gérées, à savoir l'anglais et le français.

Comment fonctionne cette Feature ?

Cette Feature modifie le statut des bases de données pour les passer automatiquement "Offline" ou "Online" selon la sélection qui est faite, de sorte qu'une seule base de données ne puisse être choisie par SharePoint.

Quelles sont les conséquences de ce mode de fonctionnement ? Et bien tout simplement la non prise en compte des actions réalisées simultanément par un autre biais (écran de création standard, stsadm, création de collection de sites self service via un annuaire des sites, ...).  Bref, cette Feature n'est pas nécessairement compatible avec le plan de gouvernance en place sur votre plateforme SharePoint, notamment si vous avez activé la création de collections de sites en mode self service. Veuillez donc à vous assurer de ne pas être dans les cas précités avant d'utiliser cette Feature.

Où télécharger cette feature ?

A tout hasard, si vous l'avez raté : http://www.codeplex.com/features

Si l'indexation des fichiers PDF sur une plateforme SharePoint 64 bits ne pose plus de problème depuis le iFilter proposé par FoxIt, il existe désormais une autre solution proposée directement par Adobe.

L'installeur est téléchargeable ici : http://www.adobe.com/support/downloads/detail.jsp?ftpID=4025

Il est surtout interessant de noter qu'un document d'installation est disponible et qu'il indique les modifications à réaliser dans la base de registres ainsi que les redémarrages de services nécessaires.

Le document en question est disponible ici : Configuring PDF iFilter for MS Sharepoint 2007.pdf

Cette information provient du site FromTheField.

Lorsque je donne des formations sur la partie BI de SharePoint, je fais généralement un tour sur le site rapports standard du modèle portail collaboratif MOSS Entreprise. Et la dernière fois que j'ai donné cette formation, j'ai eu le droit à ce beau message d'erreur durant ma démo... pas glop !

Heureusement, seul le poste du formateur était affecté et je n'ai pas été bloqué... il n'empêche, c'est moi le formateur, et sans y passer la journée pour autant j'ai essayé de comprendre l'erreur ce jour là, mais en vain.

Le temps passe et me viens à l'idée de mettre à jour la VPC utilisée pour la formation. Je teste le site "Rapports"... aucun problème. Je lance un windows update sans faire de détail. Je teste le site "Rapports"... et blam, le message d'erreur ci dessus fais son retour. C'est louche !

Je commence l'analyse du message d'erreur. Comme on le voit ci dessus, il me faut passer en mode SQLServer ou StateServer et je suis... déjà en mode SQLServer. Ca s'annonce bien. Quelques recherches sur Internet indiquent un lien avec Reporting Services 2005. Ca m'étonne un peu, car le site "rapports" n'exploite pas Reporting Services... mais soit, je modifie le fichier web.config de reporting services pour passer le mode d' "InProc" à "SQLServer". Je teste à nouveau... et j'obtiens une erreur 404 indiquant que la page ou une de ses dépendances est manquante. Habitué à ce genre d'erreurs, je décide de me connecter au site à l'aide de SharePoint Designer histoire de voir si j'obtiens le même message d'erreur... et non, encore un autre !

Message étrange, puisque le SP1 de SharePoint Designer a été appliqué. Ma version est donc up-to-date, et fonctionne d'ailleurs très bien avec tous les autres sites que le site "Rapports".

Je tente alors une connexion à Reporting Services via le Management Studio... et voilà ce que j'obtiens :

Hum hum... quelques recherches plus tard, je pars à la recherche du WebServiceAccount nommé dans ce message... pour constater qu'il référence le compte "Network Services"... ce qui semble tout à fait normal.

Bref, j'en pers même le latin que je n'ai jamais appris ! Le temps d'en parler à un collègue qui connaît bien mieux RS que moi, de parcourir la configuration RS... de lui expliquer que mon site "Rapports" est à l'URL reports et que ce n'est pas le site reporting services mais bien mon site SharePoint... pour finalement passer sur la console IIS et comprendre que le problème est... que l'application "Reports" de reporting services est présente dans mon site SharePoint ! L'URL /reports est utilisée par mon site SharePoint ET par reporting services. Comment est-ce possible ?

Lors de l'installation, j'ai modifié le port du site et des web services reporting services pour utiliser le 90 plutôt que le 80, et j'ai gardé le 80 pour mon application web SharePoint. Et tout fonctionnait très bien jusqu'à cette mise à jour Reporting Services via Windows Update. La mise à jour à réinscrit des composant RS sur le port 80 (au lieu de rester sur le port déjà utilisé). Du coup, l'appel au sous site /Reports de mon portail SharePoint conduisait tout droit sur Reporting Services au lieu du site SharePoint prévu, le tout avec un mauvais fichier de config... Bref, j'ai résolu le problème en déplaçant les applications liées à RS sur le port 90.

Ce n'est pas une légende... laissez le "site web par défaut" tranquille... désactivez le si besoin, mais ne le modifiez pas. Pour vos autres sites, ne faites pas comme pour cette VPC, utilisez les host headers !

Le souhait de mettre en place des stratégies de gouvernance,  évoqué par certains de mes clients, et notamment sur les créations de site, m'a conduit à travailler sur les modèles de site et plus particulièrement sur leur disponibilité. Cela m'a donné une idée : présenter quels moyens permettant de filtrer les Site Templates utilisables SharePoint met à disposition. Une problématique qui trouve plusieurs réponses présentant toutes des avantages différents.

Je vous propose donc de découvrir les moyens de filtrage existant en lisant mon article sur ASP-PHP :

• Filtrer l'affichage des modèles de site dans SharePoint 2007

J'en profite pour remercier Fabrice qui m'a aidé à mettre en ligne ma première publication sur ce site.

Bonne lecture ;-)

Vous en avez peut être déjà entendu parler, la date de la Winwise Solution Conference approche à grand pas. Pour ceux qui seraient passé entre les annonces, elle se tiendra le 10 septembre 2008 au Centre de Conférences Microsoft, 148, rue de l’université dans le 7 ème arrondissement de Paris. Je vous rappelle que cet événement est ouvert à tous et entièrement gratuit.

Au programme, un keynote et 15 sessions techniques articulées autour des dernières technologies Microsoft.

Pour ma part, je co-animerai avec Pascal Laforest une session intitulée Utilisation de MOSS comme portail décisionnel. Plutôt orientée fonctionnel, cette session vous permettra de voir ce qu'il est possible de faire avec 3 aspects technologiques Microsoft récents. Pourquoi 3 ? Et bien SharePoint d'une part, toute la partie BI (Analysis Services, Reporting Services, Performance Point...) d'autre part, et... une surprise pour le troisième aspect :-) Que vous soyez à l'aise ou non avec le domaine de la BI, que vous connaissiez SharePoint de prêt, de loin, voire pas du tout, cette session vous permettra de voir ce qu'il est possible de créer en mêlant les dernières technologies Microsoft.

Je vous donne donc rendez vous le 10 septembre prochain de 10h30 à 11h30, au Centre de Conférences Microsoft. N'oubliez pas de vous inscrire au préalable sur le site de la conférence.

Le projet CodePlex SharePointOfView propose un framework pour les développeurs SharePoint. Entres autres, des classes de base pour les WebParts. Vous retrouverez la WebPartBase, déjà présentée précédemment, mais également une WebPart de transformation XSL nommée tout naturellement XSLTransformWebPart.

Pourquoi une WebPart de transformation XSL ?

Depuis SharePoint 2003 (et sur les conseils de Gat), j'utilise de très souvent la transformation XSL dans mes WebParts. Dans la version 2007, on en retrouve d'ailleurs un peu partout. La transformation XSL présente de nombreux avantages dans SharePoint :

D'une part, le XSL en lui même peut être stocké de plusieurs façons différentes :

• Directement en paramètre de la WebPart,
• Sous forme de fichier externe,
• Sous forme de fichier dans une bibliothèque SharePoint (auquel cas on bénéficie même de versionning sur le XSL).

D'autre part, les modifications demandées par le client qui veut toujours une petite adaptation après la mise en prod deviennent bien plus simples, puisqu'il suffit juste de modifier un paramètre ou un fichier. Pas d'interruption de service non plus, puisque le code ne change pas.

D'autre part, le rendu XSL peut être travaillé par une autre personne que le ou les développeurs SharePoint. Lorsque l'équipe qui travaille sur un projet commence à être de bonne taille (qui a dit plus d'une personne ?), cette possibilité de découpage peut s'avérer très utile.

XslTransformWebPart ("...and in the darkness bind them.")

La WebPart de transformation XSL permet donc de séparer le fond de la forme. Le mécanisme gérant la forme étant identique d'une WebPart à l'autre, autant le centraliser dans une seule et même WebPart. Les différences d'affichage se font en modifiant la valeur de la propriété XSL.

Côté fond, il vous suffira d'hériter de la WebPart XSLTransformWebPart puis de surcharger la méthode GetData() pour reccupérer vos données sous forme XML.

L'appel à la méthode GetData ainsi que la transformation XSL est faite depuis la méthode OnPreRender de la WebPart. L'affichage se fait quand à lui avec la méthode RenderWebPart issue de la WebPartBase, évidemment. Ce qui implique du même coup la gestion d'erreur dans la WebPart de transformation XSL. Enfin, cette WebPart est entièrement localisée, aussi bien en ce qui concerne les messages que la WebPart peut elle même afficher, qu'en ce qui concerne les propriétés de l'EditorPart. A ce jour, les ressources gérées sont l'anglais et le français.

CAMLQueryWebPart : Sample de transformation XSL

Pour illuster cette WebPart, le projet SharePointOfView.Samples met à disposition une WebPart de requête CAML héritant de la classe XSLTransformWebPart. Cette WebPart de requête CAML se contente de réaliser la requête dans la méthode GetData() d'une manière similaire au code présenté ci dessous :

protected override string GetData()
{
    SPQuery camlQuery= new SPQuery();
    camlQuery.Query = ""; // requête CAML attendue
    SPList list = SPContext.Current.Web.GetListFromUrl(ListURL);
    return list.GetItems(camlQuery).Xml;
}

Vous pourrez donc utiliser ce sample pour tester la WebPart XslTransformWebPart.

Le tout en images

Comme pour la WebPart précédente, j'ai réalisé une vidéo présentant les points essentiels de la WebPart. Je vous invite à consulter ces quelques minutes de présentation :

N'oubliez pas que le projet SharePointOfView reste ouvert à ceux qui souhaitent contribuer au projet.

Sur le papier, le déploiement de contenu de SharePoint a de quoi séduire. Malheuresement, nombreux sont ceux qui se sont heurtés à des difficultés avec le Job d'import SharePoint pendant ces déploiements. Si vous n'avez pas eu l'occasion de tester le déploiement de contenu, peut être avez vous bloqué sur la commande stsadm -o import avec des messages de même nature, du type Violation of PRIMARY KEY constraint, ou encore d'autres erreurs.

Les posts recensant les problèmes et les pièges à éviter, comme celui de Stefan Goßner, sont nombreux.

Ces problèmes ont désormais une solution Microsoft, puisqu'un KB a été récémment publié.

Je viens seulement d'en prendre connaissance grâce au blog de Joel Oleson, car ce correctif date du 20 mai.

Vour retrouverez sur le site du support Microsoft :

• La KB détaillant le rollup.
• Le formulaire de demande de hotfix.

Bref, du très très bon pour les sites nécessitant un déploiement de contenu.

PS :Si vous ne connaissez pas le Content Deployment dans SharePoint, je vous invite à consulter la partie Staging de la présentation Gestion de contenu Web que j'ai co-animé avec Gaëtan lors des TechDays 2008

Le framework SharePointOfView que Phil a récemment annoncé comporte un namespace nommé SharePointOfView.WebControls. Au menu de ce namespace, des customs controls, évidemment, et pour commencer deux WebParts.

Pourquoi des customs controls ?

Aux cours de vos développements SharePoint, combien de bouts de code avez vous copié/collé d'un contrôle existant vers un nouveau contrôle ? Combien de Try...Catch pour éviter qu'une erreur provoque un dysfonctionnement complet des pages ? Personnellement, je l'ai fait bien trop souvent. J'ai fini par me faire une WebPart de base dont mes nouvelles webparts héritent, histoire d'y insérer le code que je réutilise le plus souvent. Ont suivi d'autres WebParts que j'ajoutais à mes projets Visual Studio au fil des besoins. C'est donc très naturellement que j'ai souhaité les ajouter au framework SharePointOfView. L'idée est donc de proposer des bases de WebParts riches et génériques.

A ce jour, déjà deux WebParts ont déjà été intégrées au framework, et voici la première d'entres elles :

WebPartBase ("One WebPart to rule them all...")

L'idée de cette WebPart, c'est (essentiellement pour le moment) de permettre aux développeurs de s'affranchir de la gestion d'erreur dans leurs développements, et de la centraliser.

Trois comportements sont incorporés à cette WebPart :

• Comportement simple :

En cas d'erreur, la WebPart indique simplement qu'une erreur s'est produite. L'affichage de la page n'est pas bloqué. Au delà de l'affichage, la WebPart inscrit la StackTrace dans les fichiers de log SharePoint (à l'aide de la classe d'écriture de logs du framework SharePointOfView)

• Comportement étendu :

En plus du comportement simple, cette gestion ajoute un lien qui permet de visualiser la StackTrace. Je réfléchis à y indiquer également l'heure de l'erreur. Cette gestion n'est faite que lorsque l'utilisateur courant est administrateur de la collection de sites. On peux facilement imaginer l'utilisation qui pourrait être faite de ce fonctionnement : le responsable fonctionnel / chef de projet (administrateur de la collection de sites ici) est rapidement averti qu'une erreur se produit, réalise une simple capture d'écran et l'envoi aussitôt au(x) développeur(s).

Démonstration :

Parce qu'une petite démo vaut mieux qu'un long discours, je vous propose de regarder tout ça en images :

Fonctionnement

La WebPartBase est marquée comme abstract, et réécrit les méthodes de rendu habituelles pour y incorporer cette gestion d'erreur.

/// <summary>Base method that renders the web part.</summary>
/// <param name="writer">the output stream Html writer</param>
protected sealed override void RenderContents(HtmlTextWriter writer)
{
    try
    {
        base.EnsureChildControls();
        base.RenderContents(writer);
        RenderWebPart(writer);
    }
    catch(Exception ex)
    {
        // Rendering a simple error message instead of the WebPart and logging the real exception
        ManageError(ex).RenderControl(writer);
        SharePointOfView.Diagnostics.ULS.WriteError(ex.ToString(), "WebPartBase : RenderContents");
    }
}

Les méthodes réécrites sont marquées comme sealed de sorte à empêcher toute réécriture de ces méthodes par la suite, et donc la perte de la gestion d'erreur. Il vous faudra donc utiliser l'une des deux méthodes marquées virtual en lieu et place des traditionnelles RenderContents et CreateChildControls :

/// <summary>
/// Virtual method that replace RenderContents method, so as to ensure error handling.
/// If a failure occurs, a standard message will be shown to the users, and the error will be logged.
/// Besides, the exact exception stack trace will be displayed to the sites collection administrators.
/// </summary>
/// <param name="writer">the output stream Html writer</param>
protected virtual void RenderWebPart(HtmlTextWriter writer)
{

}

/// <summary>
/// Virtual method that replace CreateChildControls method, so as to ensure error handling.
/// If a failure occurs, a standard message will be shown to the users, and the error will be logged.
/// Besides, the exact exception stack trace will be displayed to the sites collection administrators.
/// </summary>
protected virtual void CreateWebPartControls()
{

}

Cette WebPart devrait évoluer pour localiser le message d'erreur standard. N'hésitez pas à laisser un commentaire si vous avez des remarques ou des suggestions sur cette WebPart.

Pour conclure, je vous rappelle que le projet SharePointOfView est disponible sur codeplex.