C’est annoncé sur le blog de l’équipe Microsoft Update: Le SP2 sera disponible sur Microsoft Update fin du mois. On peut donc s’attendre à le voir en téléchargement quelques jours plus tôt. Il ne nous reste plus qu’à attendre tranquillement et patiemment qu’il soit disponible…

Source: http://blogs.technet.com/mu/archive/2009/04/14/service-pack-2-for-2007-microsoft-office-system-due-april-28th.aspx

Il arrive que l’on se retrouve face à un objet dont le type ne fait pas partie des assemblies référencées. Mais dès lors, comment savoir quelle assembly doit être ajoutées aux références pour en permettre l’utilisation, par exemple ? La solution est simple mais peu connue ou tout du moins utilisée:

Il suffit, une fois que l’on a une référence sur l’objet, d’utiliser la fenêtre Quick Watch sur cet objet et d’indiquer GetType().Assembly.Location à la suite du nom de l’objet.

Il ne vous reste plus qu’à référencer l’assembly indiquée.

Il y a quelques semaines la rumeur sur la gratuité de SharePoint Designer a fait son apparition sur le net. C’est désormais officiel, il est possible voire même encouragé de télécharger cet outil.

On y verra une très bonne chose… Tout du moins si vous le mettez à disposition de vos utilisateurs de manière structurée et réfléchie, histoire d’éviter des interventions sur des sites customisés de manière hasardeuse.

Pour le téléchargement, rendez-vous ici: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=baa3ad86-bfc1-4bd4-9812-d9e710d44f42

Le Central Administration, tous les administrateurs SharePoint connaissent. Les développeurs devraient également être au courant de ce que renferme cette interface même ce n’est pas toujours le cas. Selon les développements, il est rapidement nécessaire de configurer des scopes de recherche et d’exposer des méta données de content types. Dans ce cas, quoi doit s’occuper de cette configuration?

Au delà, de la discussion habituelle sur les rôles des uns et des autres, voyons comment il est possible de permettre à un utilisateur de réaliser des opérations liées à la recherche.

Pour pouvoir configurer le search et ajouter de nouvelles propriétés (scopes, rules, ...), il est nécessaire à la personne d'avoir un accès Read sur le Shared Service concerné: http://servername:port/ssp/admin/_layouts/user.aspx.

(Source: http://technet.microsoft.com/en-us/library/cc262918.aspx)

Toute personne (que ce soit en donnant les droits directement ou au travers d’un groupe) recevant les droits Read a ainsi accès à l'écran suivant:

Comme on le voit, beaucoup de liens sont présents sur cette page mais la majorité de ceux-ci nous mènent vers des pages auxquelles on a pas accès.
Ainsi, avec le droit Read, la liste des pages auxquelles on a accès sont:

• Trusted My Site host locations
• Published links to Office client applications
• Search settings

Les deux premières pages sont accessibles uniquement en read, il n'est donc pas possible de faire des modifications sur les valeurs contenues dans cette page.

Au niveau du Quick Launch, le lien Back to Central Administration et Shared Services Administration sont également innaccessibles.
Reste donc le Search Settings (http://servername:port/ssp/admin/_layouts/searchsspsettings.aspx) qui est accessible par les personnes ayant un droit read sur le shared service.

Au travers de cet écran, il est ainsi possible d’avoir accès à toutes les propriétés du search.

Il arrive qu’une erreur 403 survienne à la suite de ces opérations. Ainsi, il est préférable d’exécuter la commande attrib –s c:\windows\tasks en ligne de commande. Cette commande permet de modifier l’attribut Système du répertoire des tâches planifiées. Rassurez-vous, nous remettrons cet attribut dès que nous le pourrons.

Une fois cette dernière opération effectuée, il reste à faire un clic droit sur le répertoire c:\Windows\Tasks et vérifiez que WSS_WPG a un accès en lecture et en écriture.

Comme prévu, nous allons remettre l’attribut système au répertoire des tâches planifiées en indiquant la commande suivante: attrib +s c:\windows\tasks.

Vérifiez par ailleurs que WSS_WPG et votre compte fonctionnel ont les droits sur le composant OSearch (pour plus de détails sur la manière de faire, rendez-vous au post SharePoint: Quand les Service Packs nous créent des soucis... On les résoud!).

Internet Explorer 8 est disponible en version finale.

D’apparence, il y a peu de changements mais cette nouvelle version comporte toute une série de nouveautés. Parmi les plus visibles, on peut noter des performances accrues, un support CSS amélioré et bien d’autres choses comme la notion de suggestions. Retrouvez la liste complète des nouveautés à l’adresse http://www.microsoft.com/presspass/newsroom/windows/factsheets/IE8FS.mspx

Pour les développeurs, on notera tout de même la présence d’un outil permettant de faire du debugging.

Téléchargez Internet Explorer à l’adresse: http://www.microsoft.com/ie8

Lorsque vous développez des applications accessibles depuis un browser, il est conseillé de vérifier cette application à l’aide de différents navigateurs. Nous voici donc parti pour l’installation de Firefox, de Chrome et tout autre navigateur que l’on souhaite tester.

Reste cependant le problème des versions… Chez un client, on retrouve en standard 2 (voire 3) versions de Internet Explorer. Installer plusieurs Internet Explorer n’est malheureusement pas aisé sur un même poste de travail.

Concernant Internet Explorer et ses versions, un outil très utile est disponible en téléchargement libre: IETester.

IETester is a free WebBrowser that allows you to have the rendering and javascript engines of IE8 RC1, IE7 IE 6 and IE5.5 on Vista and XP, as well as the installed IE in the same process.
New in v0.3 : IE8 RC1, zoom feature and a lot of corrections and improvements !

Pour le télécharger, rendez-vous à l’adresse http://www.my-debugbar.com/wiki/IETester/HomePage

Bon tests!

Après avoir exécuté la commande

stsadm –o blockedfilelist –extension .exe –delete

vous recevez un Operation Successful. Parfait! Vous pouvez désormais faire l’upload de fichiers .exe dans votre SharePoint. Mais SharePoint vous refuse à nouveau l’upload de votre fichier. Bizarre non vu que l’opération s’est correctement terminée?

En fait non… l’instance de SharePoint pour laquelle vous avez autorisé l’upload de fichiers .exe est celle du Central Administration et non pas celle prévue pour stocker les données.

Il suffit donc d’indiquer l’url du site root de votre instance en paramètre à la commande:

stsadm –o blockedfilelist –extension .exe –delete –url http://servername

Tout développeur SharePoint est rapidement confronté au développement de web parts, d’event handlers ou encore de workflows. Malheureusement, quand les choses ne vont pas bien, peu savent comment s’y prendre pour débugger et ainsi analyser et corriger le code pouvant poser des soucis. Tous les développeurs sont passées par cette période où les choses sont floues et plus cette période est courte, mieux l’on se porte généralement.

Voici donc un mini guide concernant le débugging d’event handler.

Nous ne reviendrons pas sur l’utilisation des event handlers ni sur le déploiement de ceux-ci. Pour un rappel de ce qu’est un event handler, je vous renvoie sur le site MSDN. La partie qui nous intéresse au niveau des event handlers est qu’ils sont déployés soit dans le répertoire bin de SharePoint, soit dans le Global Assembly Cache (GAC) et chargé dynamiquement par SharePoint lorsque cela est nécessaire.

Outils pour gérer les event handlers

Plusieurs outils sont disponibles sur l’Internet et la majorité de ceux-ci sont gratuits. Personnellement, j’en recommande deux. SP RAD Studio, disponible à la mi-mars et Event handler Explorer en téléchargement libre à l’adresse Event Handler Explorer.

Pourquoi utiliser un tel outil? Tout simplement pour vérifier que l’event handler est bel et bien attaché à la liste ou la librairie de documents souhaitée.

Bien que cela s’avère très simple d’utilisation, voici un petit tour rapide de l’outil:

A l’ouverture du programme, tout est vide. il vous faudra indiquer l’adresse du site collection sur lequel vous souhaitez travailler.

Une fois l’adresse indiquée, vous pouvez naviguer au sein de ce site collection jusqu’à la liste ou la librairie de documents souhaitée.

Une fois sur cette liste, cliquez sur Event Handlers. Si des event handlers sont effectivement attachés à cette liste, ceux-ci sont listées sous ce noeud.

En sélectionnant un event handler, vous obtenez plus d’informations dans la partie droite de l’outil.

Il est également possible d’ajouter ou de supprimer des event handlers par ce biais.

Utilisation des logs de SharePoint

Toute erreur non gérée dans un event handler est logguée dans le fichier de log de SharePoint. L’ensemble des fichiers (il y a, par défaut, un fichier par demi-heure d’exécution de SharePoint) sont situés dans le répertoire c:\Program Files\Common Files\Microsoft Shared\web server extensions\12\LOGS si vous avez installé le SharePoint avec les paramètres par défaut.

Une recherche sur le nom complet de la classe, par exemple, Societe.SharePoint.Application.EventHandlers.NomEventHandler au travers des fichiers permettra rapidement de voir si une erreur est survenue ou non. Une erreur de ce genre prend la forme suivante:

02/25/2009 21:14:39.61 w3wp.exe (0x0C04)                       0x04DC Windows SharePoint Services   General                                8e0c                Critical   Event manager error: Could not load file or assembly 'Societe.SharePoint.Application.EventHandlers.NomEventHandler, Version=1.0.0.0, Culture=neutral, PublicKeyToken=9f4da00116c38ec5' or one of its dependencies. The system cannot find the file specified.            

Notez que, avec Microsoft Office SharePoint Server 2007, vous pouvez écrire directement dans ces logs. Pour cela, il vous faudra référencer la DLL Microsoft.Office.Server.dll dans le répertoire C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\ISAPI\. Ensuite, dans votre code, indiquez l’instruction suivante: Microsoft.Office.Server.Diagnostics.PortalLog.LogString(“votre texte”);

Débugging avec Visual Studio

SharePoint utilise plusieurs processus pour fonctionner. L’un d’entre eux est en charge de gérer le rendu des pages web dans le navigateur. Pour être précis, ce processus est utilisé par toutes les applications ASP.NET, comme c’est le cas pour SharePoint. Ainsi, si on souhaite voir ce qu’il se passe dans notre code durant le chargement et l’exécution de celui-ci, il faudra s’attacher au processus w3wp.exe.

Il se peut que plusieurs instances du processus tournent en parallèle. Pas de souci, vous pouvez attacher votre débuggeur simultanéement à plusieurs processus ou instances de processus. Pour cela, rendez-vous dans Visual Studio. Dans le menu Debug, sélectionner Attach to a process…

Sélectionnez ensuite les instances de w3wp.exe en maintenant la touche CTRL enfoncée. Si vous tentez de vous attacher au process juste après un IISRESET, celui-ci sera manquant. Ainsi, il vous sera nécessaire d’appeler, dans votre browser, un site SharePoint afin que le processus soit démarré.

Vous avez désormais attaché votre debugger à votre event handler. Il suffit donc de placer des points d’arrêts et de réaliser du pas à pas. Profitez bien de toutes les fonctionnalités offertes par Visual Studio (Debugging in Visual Studio).

Ce n'est pas une astuce mais juste un rappel. Modifier un hyperlien est simple mais la syntaxe peut être déroutante.

item["mon_champs"].Value = "http://monserveur.com, le titre de mon lien";

Je sais que cela servira à certaines personnes ;-)

Lors du démarrage de Virtual PC sous Vista, vous recevez le message suivant

Suite à cela, j'ai entendu dire que Virtual PC 2007 n'était pas compatible avec Vista. C'est faux.

Vous n'êtes certainement pas sans savoir que Vista utilise l'UAC (User Account Control), ce qui empêche entre autres à un logiciel d'accéder aux fichiers du file system sans lui donner explicitement des droits. Ainsi, il est nécessaire de donner ces droits à Virtual PC pour qu'il puisse accéder aux fichiers qui lui sont nécessaires.

Pour cela, il suffit de faire un clic droit sur l'icône de Virtual PC, sélectionner Propriétés et de se rendre dans l'onglet Compatibilité. Cochez l'option Exécuter ce programme en tant qu'administrateur.

Et voilà, rien de plus simple :)

23 parcours thématiques, 300 conférences techniques, plus de 140 partenaires experts Microsoft autour de 5 grands thèmes :

• Découvertes
  Windows 7, Windows Azure, SaaS, Cloud Computing…
• Architecture et Développement
  Windows Live, SOA, Visual Studio, .NET, Silverlight, Design, Biztalk…
• Infrastructure et socle applicatif de l'entreprise numérique
  SQL Server, Windows Server, Virtualisation, Microsoft Desktop Optimization Pack, High Performance Computing, Small Business Server, Enterprise Business Server, Sécurité, ERP…
• Efficacité individuelle et collective
  Poste de travail, Communications Unifiées, Recherche en entreprise, Microsoft PerformancePoint, SharePoint, Office Communications Server, CRM…
• Enjeux
  Sécurité, Interopérabilité, Accessibilité, Education, Recherche, Programme de licences...

Site officiel: http://www.microsoft.com/france/mstechdays/

Inscriptions: http://galilee.microsoft.fr/TechDays2009/Default.aspx

Lors d'un appel au Web Service Lists.asmx et plus exactement à la méthode GetListItems, il est souvent nécessaire de passer des paramètres de types XML. Ces paramètres sont mal interprétés, rendant ainsi l'utilisation du Web Service difficile voire impossible.

Les paramètres XML sont indiqués dans InfoPath sous la forme d'une chaîne de caractères (ceci dit de l'XML, ce n'est jamais que des caractères qui respectent des règles prédéfinies).

C'est cette chaîne qui, une fois encodée pour être envoyée, n'est plus compréhensible par le Web Service.

Une fois le problème repéré, des tests montrent que l'appel du Web Service depuis une application .NET se fait sans aucun souci. Sur base de ces informations, une solution s'offre à nous: utiliser un Web Service (écrit en .NET) que l'on déploie au sein de SharePoint afin de générer le message à envoyer de manière correcte.

    <WebMethod()> _
    Public Function GetListItems(ByVal listName As String, ByVal viewID As String, ByVal query As String, ByVal viewFields As String, ByVal rowLimit As String, ByVal queryOptions As String, ByVal webID As String) As XmlNode
        Dim service As SharePointListsWS.Lists = GetWebServiceInstance(webID)

        Dim queryElement As XmlNode = CreateNode("Query", query)
        Dim viewFieldsElement As XmlNode = CreateNode("ViewFields", viewFields)
        Dim queryOptionsElement As XmlNode = CreateNode("QueryOptions", queryOptions)

        Return service.GetListItems(listName, viewID, queryElement, viewFieldsElement, rowLimit, queryOptionsElement, webID)

    End Function

    Private Function GetWebServiceInstance(ByVal webID As String) As SharePointListsWS.Lists
        Dim service As New SharePointListsWS.Lists
        service.Credentials = System.Net.CredentialCache.DefaultCredentials

        service.Url = SPContext.Current.Web.Url + "/_vti_bin/Lists.asmx"

        Return service
    End Function

    Private Function CreateNode(ByVal name As String, ByVal innerXml As String)
        Dim document As New XmlDocument
        Dim node As XmlNode = document.CreateElement(name)
        node.InnerXml = innerXml
        Return node
    End Function

Ce Web Service, après avoir générer du XML valide et compréhensible, passe les paramètres au Web Service Lists.asmx qui, cette fois, pourra interpréter les paramètres en entrée. Les valeurs retournées par celui-ci sont quant à elle directement renvoyées vers le client appelant.

Ce qu'il vous faut donc savoir pour réaliser ce Web Service intermédiaire:

• Comment écrire un Web Service;
• Comment permettre de l'intégrer dans SharePoint;
• Comment le déployer dans SharePoint.

Il existe de nombreux articles discutant de chacun des points. Pour simplifier la vie aux personnes qui ne souhaitent pas trop de temps, je vous joins un fichier zippé comprenant l'ensemble des fichiers nécessaires pour installer un tel Web Service: Téléchargement

La procédure se résume donc par:

• Dézippez le fichier;
• Appuyez sur install.bat.

Attention! La version actuelle de ce package fait que le fichier spdisco.aspx existant sur le serveur est remplacé par celui présent dans le package. Il est par ailleurs supprimé lors d'un retract de la solution. Faites un backup préalablement.

Cette question m'est revenue plusieurs fois déjà. Ainsi, je prends quelques minutes pour mettre la réponse par écrit.

Dans l'historique d'un workflow, vous retrouvez des valeurs "System Account" à chaque ligne.

Cette information est ainsi peu utile et il serait bien plus intéressant d'indiquer l'utilisateur qui a provoqué une action de laquelle résulte l'élément présent dans l'historique.

Pour cela, voici rapidement la procédure:

• Dans le code de votre workflow, si vous n'avez pas suivi l'un des différents articles du net, rajoutez la première ligne (afin de récupérer l'élément courant) du code ci-dessous en global ainsi que la seconde ligne (qui serait la variable dans laquelle on stocke l'ID du user courant de type entier) dans tous les cas:

VB:

Public workflowProperties As New Microsoft.SharePoint.Workflow.SPWorkflowActivationProperties ()
Public CurrentUserId As Integer = -1

C#:

public Microsoft.SharePoint.Workflow.SPWorkflowActivationProperties workflowProperties = 
      new Microsoft.SharePoint.Workflow.SPWorkflowActivationProperties ();
public int CurrentUserId = -1;

• Si ce n'est déjà fait, ajoutez une activité Code avant l'activité LogToHistoryListActivity. Dans cette activité, ajoutez les lignes suivantes qui permettent de récupérer l'ID de l'utilisateur au sein de SharePoint:

VB:

CurrentUserId = workflowProperties.Item("Editor").ToString().Substring( _
       0, workflowProperties.Item("Editor").ToString().IndexOf(";#"))

C#:

CurrentUserId = workflowProperties.Item("Editor").ToString().Substring(
       0, workflowProperties.Item("Editor").ToString().IndexOf(";#"));

• Les activités d'un Workflow sont constituées d'un ensemble de propriétés qu'il est possible (voire nécessaire) de spécifier. C'est également le cas pour la LogToHistoryListActivity. Au delà des propriétés explicites telles que HistoryDescription que vous avez certainement déjà remplis (sans quoi, il serait dur d'avoir des logs...), il existe la propriété UserId. C'est cette propriété qui indique l'utilisateur à afficher dans l'historique. Elle requiert une valeur entière qui correspond à ... vous l'aurez compris, la valeur que nous avons récupéré dans le point précédent. Ainsi, il ne reste plus qu'à cliquer sur le bouton "..." et de sélectionner la variable :

• Dernière étape: déployez votre workflow et vérifiez! Désormais l'utilisateur affiché est bien le bon

Alors qu'il y a un an presque jour pour jour je vous annonçais la venue du SP1 de Vista, voici désormais le SP2 en beta!

Comme pour son prédécesseur, il corrige certes quelques bugs, failles de sécurité et autres incohérences qui persisteraient après le SP1 mais il ajoute de nouvelles fonctionnalités / possibilités.

Pour le télécharger, il vous faudra attendre le:

• 2 décembre pour les abonnés MSDN et Technet;
• 4 décembre en téléchargement publique sur MSDN et Technet.

Les nouveautés les plus importantes de ce Service Pack:

• Support de types d'hardware émergeants:
• Support du Bluethoot 2.1;
• Possibilité d'enregistrer des données sur des supports Blue-Ray;
• ...;
• Amélioration de l'administration;
• Amélioration des performances:
• Windows Search 4 qui améliore les performances d'indexation et améliore la qualité des résultats;
• Diminution des ressources nécessaires pour les gadgets de la toolbar;
• Hyper-V.

Des améliorations concernant la compatibilité entre des logiciels tels que ZoneAlarm et Vista sont présentes. Par ailleurs, Microsoft annonce que toute application qu'il n'y aura pas de régression de la compatibilité lors du passage au SP2 (heureusement ceci dit...).

On notera aussi qu'un outil pour nettoyer les fichiers devenus obsolètes après l'installation du SP2 est fourni.

N'hésitez pas à poster vos feedbacks à ce sujet et n'oubliez pas, il s'agit d'une version beta, il n'est pas conseillé de l'installation pour une installation en "production".

Alors que l'envoi de fichier via WebDAV (c'est-à-dire à l'aide de la vue Explorateur) se passe efficacement, l'envoi de fichiers via l'interface web dans SharePoint s'avère très lent?

Si vous disposez d'Internet Explorer 6 sur les pcs depuis lesquels l'upload est lent, ne cherchez plus le pourquoi! Si ce n'est pas le cas, il s'agit juste d'une piste à suivre.

La cause est simple: Internet Explorer 6 utilise une clé de registre qui indique la taille du buffer à utiliser pour l'envoi des fichiers. La taille par défaut pose problème dès lors que vous faites l'upload d'un fichier de plus de 2Mo. Après quelques secondes, l'upload semble s'arrêter (et pour preuve, vous pouvez monitorer la charge réseau au travers de l'information "Total Bytes/sec") et un timeout intervient dès lors.

Internet Explorer 7 ne souffre pas de ce paramètre puisque la valeur de la clé s'est vue modifiée.

Vous trouverez la procédure pour mettre à jour le paramètre: http://support.microsoft.com/kb/329781/en-us