Edgar Maucourant - Consultant / formateur SharePoint

SP2010 : Assistant de configuration ? Pas besoin j'suis un pro ! A moins que...

Edgar — Thu, 04 Feb 2010 16:18:00 +0100

Bonjour à tous,

Si vous êtes comme moi et que vous aimez bien vous passer d'assistant pour mettre en place les choses vous-même, vous serez sûrement confronté à un problème avec l'installation de SharePoint Server 2010.

En effet une fois l'installation de SharePoint terminée (elle ressemble comme deux gouttes d'eau à celle de MOSS 2007), il reste encore à paramètrer la ferme, et là c'est plus du tout pareil qu'en version 2007. Heureusement Microsoft a mis en place un nouvel assistant (rien à voir avec l'assistant de configuration lancé pour créer la ferme qui existe toujours d'ailleurs). Cet assistant vous aidera à paramétrer et déployer les services d'applications dans votre ferme.

Sauf que moi je voulais les déployer à la main pour bien comprendre chacun d'eux et leur dépendance, et là c'est le drame... (ouais j'aime bien l"effet mélodramatique pour encourager à lire la suite...)

Non en fait ce n'est pas si dramatique, mais il existe 2 services d'applications que vous ne pourrez pas créer sans passer par l'assistant ou Powershell : le service d'état temporaire et le service du registre d'applications.

Le premier est tout simplement le service de gestion de sessions utilisé entre autre par InfoPath Form Services ou Visio Services, cette application ne fonctionnera pas si ce service n'est pas créé et démarré. Le second semble lié à la prise en charge des applications BDC 2007 (je dis "semble" car je n'ai pas testé ce qu'il fait...).

Si vous n'avez pas utilisé l'assistant de configuration dès le départ, vous avez deux solutions, relancer l'assistant de configuration et cocher les deux services à installer (les services d'applications existants ne seront pas modifiés), utiliser PowerShell avec la commande new-SPStateServiceApplication (comme indiqué dans les alertes du système d'Analyse).

Pour plus d'infos sur la démarche : http://technet.microsoft.com/fr-fr/library/ee704548(office.14).aspx (en français !)

En espérant que cela vous permettent de ne pas trop chercher

Bon code à tous ! Edgar

Limite des 2000 éléments à qui s'applique-t-elle ? [MAJ : 03/02/2010]

Edgar — Mon, 30 Nov 2009 11:55:00 +0100

Bonjour à tous,

MAJ du 3 Février 2010 : je reviens sur la conclusion de cet article qui est en partie erronée.

Pour les utilisateurs finaux, il est important de garder dans tous les cas des vues (affichages) dont le nombre total d'éléments (toutes pages confondues) soit inférieur à 2000 éléments (environ ça peut être un peu plus ou un peut moins).

En effet ce que ne montre pas le test ci-dessous c'est que lorsque beaucoup d'utilisateurs exécutent des affichages renvoyant plus de 2000 éléments au total, le serveur pourrait être très rapidement surchargé même si chaque page ne renvoit que 100 éléments. La gestion d'un nombre maximum d'éléments par page (paging) permet de reduire cette surcharge mais ne l'annule pas. Dans les résultats ci-dessous dès que l'on dépasse 500 éléments par page les performances se réduisent essentiellement à cause du temps de transfert des informations du serveur vers le navigateur et du temps nécessaire au navigateur pour interpreter et mettre en page ces informations. Cependant la surchage sur le serveur est importante à partir du moment où l'on dépasse cette fameuse limite des 2000 éléments, essentiellement à cause de contraintes sur les bases de données SQL Server (pour les amateurs de données techniques lire cet article : http://sharepoint.microsoft.com/blogs/GetThePoint/Lists/Posts/Post.aspx?ID=162)

Il existe donc que deux solutions, mettre moins de 2000 éléments par niveau (racine, dossiers, sous-dossiers,...) ou utiliser des vues avec des filtres renvoyant moins de 2000 éléments (moins efficace que la répartition par dossiers mais permet d'améliorer les performances tout de même).

Dans le deuxième cas, il est important de noter que la première colonne utilisée pour le filtre doit être indexée pour améliorer les performances (les indexes sur les autres colonnes ne sont pas pris en compte lors de la requête). Il est important également de noter que si vous utilisez un filtre à plusieurs colonnes, seuls le nombre d'éléments renvoyés par le filtre sur la première colonne est important. Ainsi si je créé un affichage utilisant un filtre du type "Service égale à DRH ET Créé par égale à Jean Dupont" si la colonne Service contient plus de 2000 éléments avec la valeur DRH, le filtre ne sera pas efficace même si le résultat final (les deux filtres associés) renvoit moins de 2000 éléments !

Comme quoi la gestion des performances est un sujet complexe, j'espère que cet éclaircissement vous sera utile lors de la gestion de grandes listes

Pour plus d'infos : http://office.microsoft.com/en-us/sharepointtechnology/HA101736671033.aspx (article en anglais, je n'ai pas trouvé malheureusement d'équivalent en français).

Fin de la MAJ

On entend régulièrement (y compris de ma part) que les listes SharePoint ont une limite de performance aux alentours de 2000 éléments (a visto de naz...), ce qui est vrai, mais depuis quelques temps déjà je me demandais dans quelle mesure cette perte de performance s'appliquait. En effet la plupart des articles que j'ai lu parlent d'une perte de performance à partir de 2000 éléments par conteneur (dossier) ou par vue, mais ce dernier terme n'est pas clair pour moi.

Une vue peut afficher 2000 éléments au total mais répartis par page de 100 éléments (le défaut), dans ce cas est-ce le nombre d'élément par page ou pour la vue globale dont il faut tenir compte ?

De plus à qui s'applique cette consigne ? Aux utilisateurs finaux ? Aux développeurs ? Aux deux ?

Afin d'avoir enfin la réponse à ces questions j'ai testé différents cas et j'ai calculé les temps d'affichage des pages (oui je sais je suis dans ma phase statistiques en ce moment...). Je me suis donc contenté de tester la partie utilisateurs finaux, car des articles pour les développeurs ont déjà été écrit (un lien vers l'un deux est donné en fin d'article).

Le protocole de test

J'ai créé un site dans lequel j'ai ajouté une liste générique contenant 4 colonnes : Title (1 seule ligne de texte), LinkedValue (Lookup lié à une liste contenant 3 valeurs), Choice (Colonne type choix à 3 valeurs), et LongText (Multiple ligne de texte).
J'ai ensuite créé une application console qui m'a permis d'ajouter des éléments hétérogènes dans la liste (nombre aléatoire pour la valeur liée, le choix, et caractères aléatoires pour le texte long).
Enfin j'ai testé dans l'interface de SharePoint l'affichage d'une page contenant plus ou moins d'éléments, dans une liste contenant elle aussi plus ou moins d'éléments :p

Note : les temps affichés ne sont pas à la seconde près c'est l'ordre de grandeur qui importe ici.

Note 2 : J'ai testé sur une liste mais à priori les résultats sur les Bibliothèque de documents devraient être les mêmes (des amateurs pour le test ?)

Les résultats

Nb E Tot = Nombre d'éléments total dans la liste
Nb E Page = Nombre d'éléments affichés dans la page
Temps = Temps moyen d'affichage de la page

Nb E Tot	Nb E Page	Temps
100	100	< 1s
200	100	< 1s
500	100	< 1s
500	500	< 2 s
1000	100	1s
1000	1000	4s
2000	100	1s
2000	1000	4s
2000	2000	8/9 s
3000	100	1s
3000	1000	5s
3000	2000	8/9 s

Nb E Tot	Nb E Page	Temps
10000	100	1s
10000	1000	5s
10000	2000	8/9 s
10000	4000	16/17s
10000	10000*	52s
50000	100	1s
50000	2000	8/9 s
50000	10000*	52s
50000	20000**	106s
50000	50000***	> 250s****

* : Sur mon IE 7 une fois les résultats affichés l'interface a mis quelques secondes à répondre aux clics.
** : Sur mon IE 7 l'interface est devenue très lente, plusieurs secondes entre 1 clic et le déclenchement de l'action
*** : sur mon IE 7 l'interface est carrément devenue inutilisable, plusieurs dizaines de secondes pour sortir de la page, les autres IE répondaient normalement.
|-> Tout ces comportements sont sûrement dû au JavaScript dans la page...
**** : J'ai arrêté le chrono le temps n'étant de toute façon plus acceptable depuis longtemps.

Mon analyse

On voit clairement que peu importe le nombre d'éléments dans la liste si le nombre d'éléments dans la page reste faible (< 500) les performances sont bonnes. Par contre plus on augmente le nombre d'éléments dans la page et plus on voit un temps de chargement conséquent. Ce qui est tout à fait normal car il faut plus de temps pour générer le code, pour l'envoyer au navigateur, et à celui-ci pour interpréter le code.

A noter que ces temps ne le montrent pas, mais durant l'affichage le CPU est à 100% ! Sauf pour les affichages de moins de 2 secondes où il oscille entre 30% et 60% mais pendant un pic de quelques millisecondes seulement. Ceci signifie que des affichages de plusieurs secondes sur une liste pourraient facilement mettre un serveur à genoux s'ils sont déclenchés par plusieurs utilisateurs sur différentes listes en même temps !

Résultat : si vous suspecter une utilisation importante de votre (ou vos) sites SharePoint, gardez des temps inférieurs à 1 seconde pour les pages de vues.

Bon alors ?

Cette limite des 2000 éléments n'est à priori pas valable pour les utilisateurs finaux, car on voit déjà clairement des limites à partir de plus de 500 éléments par page. Par contre elle concerne bien les développeurs qui devront en tenir compte pour leurs applications.

Mon conseil est donc le suivant :

Pour les utilisateurs fonctionnels, ne pas utiliser de vues affichant plus de 500 éléments par page et vos performances seront toujours optimales.
Pour les développeurs, suivre les recommandations de Microsoft sur le sujet et notamment bien lire l'article suivant : Working with large lists in Office SharePoint Server 2007 complété par l'article suivant de Reza Alirezaei :http://blogs.devhorizon.com/reza/?p=790

Bon code à tous !

Forum de discussion attention aux pièces jointes orphelines... (Application CodePlex inside...) MAJ 02/12/09

Edgar — Sun, 29 Nov 2009 17:59:00 +0100

Bonjour à tous,

EDIT 02/12/2009 : La CU d'Octobre semble régler ce problème, cependant je n'ai pas encore testé ce patch, et je ne sais pas si une fois appliqué cela supprime toutes les pièces jointes orphelines existantes ou si cela permet juste de ne plus en créer, pour plus d'infos : http://support.microsoft.com/kb/975002/en-us (3ème puce)

En travaillant sur un projet pour Alti (www.alti.fr, un peu de pub ça ne fait jamais de mal...), je me suis rendu compte que lorsque l'on supprime un sujet de discussion dans un forum sur un site SharePoint, les pièces jointes associées à ce sujet ne sont pas supprimées ! Elles deviennent des pièces jointes orphelines, et il n'est pas plus possible de les supprimer par l'interface utilisateur ou le modèle objet.

Bon soyons honnêtes, ces pièces jointes orphelines ne pose aucun problème tant que vous n'essayez pas d'exporter votre site en utilisant la commande export de STSADM ou l'API de migration de contenu. Si c'est le cas, vous risquez d'obtenir le message suivant :

FatalError: Cette contrainte ne peut pas être activée, car toutes les valeurs n'ont pas de valeurs parentes correspondantes. à System.Data.ConstraintCollection.AddForeignKeyConstraint (ForeignKeyConstraint constraint) à System.Data.ConstraintCollection.Add(Constraint constraint, Boolean addUniqueWhenAddingForeign) à System.Data.DataRelationCollection.DataSetRelationCollection .AddCore(DataRelation relation) à System.Data.DataRelationCollection.Add(DataRelation relation) à System.Data.DataRelationCollection.Add(String name, DataColumn parentColumn, DataColumn childColumn) à Microsoft.SharePoint.Deployment.FileObjectHelper. GetNextBatch() à Microsoft.SharePoint.Deployment.ObjectHelper. RetrieveDataFromDatabase(ExportObject exportObject) à Microsoft.SharePoint.Deployment.FileObjectHelper. RetrieveData(ExportObject exportObject) à Microsoft.SharePoint.Deployment.ExportObjectManager. GetObjectData(ExportObject exportObject) à Microsoft.SharePoint.Deployment.ExportObjectManager. MoveNext() à Microsoft.SharePoint.Deployment.ExportObjectManager. ExportObjectEnumerator.MoveNext() à Microsoft.SharePoint.Deployment.SPExport.SerializeObjects() à Microsoft.SharePoint.Deployment.SPExport.Run()

En anglais ça donne ça :

FatalError: This constraint cannot be enabled as not all values have corresponding parent values. at System.Data.ConstraintCollection.Add(Constraint constraint, Boolean addUniqueWhenAddingForeign) at System.Data.DataRelationCollection.DataSetRelationCollection .AddCore(DataRelation relation) at System.Data.DataRelationCollection.Add(DataRelation relation) at System.Data.DataRelationCollection.Add(String name, DataColumn[] parentColumns, DataColumn[] childColumns) at Microsoft.SharePoint.Deployment.ListItemObjectHelper. GetNextBatch() at Microsoft.SharePoint.Deployment.ObjectHelper. RetrieveDataFromDatabase(ExportObject exportObject) at Microsoft.SharePoint.Deployment.ListItemObjectHelper. RetrieveData(ExportObject exportObject) at Microsoft.SharePoint.Deployment.ExportObjectManager. GetObjectData(ExportObject exportObject) at Microsoft.SharePoint.Deployment.ExportObjectManager. MoveNext() at Microsoft.SharePoint.Deployment.ExportObjectManager. ExportObjectEnumerator.MoveNext() at Microsoft.SharePoint.Deployment.SPExport.SerializeObjects() at Microsoft.SharePoint.Deployment.SPExport.Run()

Pas mieux...

Pour que votre export se déroule sans accroc (et qu'Hannibal Smith soit content), il vous faut supprimer toutes ces pièces jointes orphelines.

- Oui mais, il a pas dit qu'on pouvait plus y faire référence ni par l'interface, ni par le modèle objet ?

Si, si il l'a dit, mais il nous reste toujours...

Tada ! La base de données SharePoint !

"Oh noooooooooon" s'écrient déjà certains qui voient leur garantie et leur support Microsoft s'envoler... Oui c'est vrai, c'est une procédure qui à priori n'est pas supportée par Microsoft, mais faute de mieux on s'en satisfait. Et puis si c'est bien fait c'est pas visible :p Non plus sérieusement j'ai ouvert un ticket à ce sujet mais je n'ai pas encore eu de retour intéressant.

Bon Ok, comment on fait alors ?

Voici tout d'abord un message d'avertissement : La procédure qui suit n'est pas supportée par Microsoft ! Vous utilisez les informations fournies ci-dessous à vos risques et périls.

Pour ceux que ça ne rebute pas, voici la procédure : j'aurais pu vous fournir les requêtes SQL à utiliser mais j'ai fait mieux (enfin je crois), j'ai créé une application WinForm qui va traquer et supprimer (optionnel) les pièces jointes orphelines pour vous ! C'est pas bon ça ? :p

L'application vous permet même de choisir ce que vous souhaitez analyser, depuis toutes les WebApplications, jusqu'à une simple liste en passant par une collection de site ou un site en particulier. Elle est pas belle la vie ? (toute ressemblance avec une pub de Jambon est fortuite...).

Ok, elle est où ton application ?

Dispo sur CodePlex (avec l'aimable autorisation d'Alti) : http://sporphansanalyzer.codeplex.com

Elle est écrite en anglais, car je pense qu'elle pourrait servir à plein de gens (oui je sais c'est prétentieux..), mais que ceux qui sont hermétique à l'anglais se rassurent c'est très simple à comprendre. On choisi ce que l'on veut analyser, on clique sur "Analyze", on attend et voilà ! Si des pièces jointes orphelines sont trouvées un message s'affichera, vous pourrez alors relancer le traitement en cochant la case "remove orphaned attachments" pour supprimer ces éléments automatiquement.

L'application est à faire tourner directement sur un serveur hébergeant SharePoint.

En attendant un patch de Microsoft (on espère), cela vous permettra au moins d'exporter vos sites.

Bon code à tous !

USB2 vs SSD sur eSata, le match pour les consultants ! (MAJ : 19/11/2009)

Edgar — Wed, 04 Nov 2009 21:59:00 +0100

Bonjour à tous,

Mise à jour du 19/11/2009 : à la demande générale de Guillaume (comment ça une personne c'est pas général ?), j'ai ajouté à la fin de l'article une section sur les test avec HDTune...

Cela fait pas mal de temps que je n'ai pas bloggué, mais comme beaucoup j'ai eu fort à faire. J'aurais pu blogger sur la SharePoint Conference 2009 de Las Vegas mais d'autres l'ont fait mieux que moi (Hi Renaud, Hi Nicolas !), non cette fois-ci si je prends ma plume (enfin mon clavier) c'est pour vous parler du SSD...

Je ne sais pas vous, mais moi les tests qui vous affichent des perfs en Mo/s ou sur des outils qui simulent des copies, des transferts, des utilisations de ci ou de ça, ça ne me parle pas beaucoup. Moi j'aime bien avoir du concret et savoir exactement comment cela fonctionne avec mes outils à moi (oui oui double possession). J'ai cherché des tests sur le SSD avec des machines virtuelles, mais je n'en ai pas trouvé, j'ai donc décidé de vous faire part de mes propres informations.

En conséquence, voici le match, que dis-je, le combat du siècle entre un disque USB2 Externe, un SSD interne et un SSD Externe ! (Bon OK c'est un peu théâtrale pour un test mais on se refait pas...)

Bonjour à tous,

Mais tout d'abord...

Késako le SSD ?

Geeks en tous genres, adeptes des actualités 3 ans avant tout le monde, passez votre chemin ! Pour les autres, le SSD (Solid Storage Disk) représente la nouvelle génération de disques durs, non plus avec des plateaux qui tournent mais avec de la mémoire style carte flash / clé usb (ce n'est pas tout à fait pareil quand même). L'avantage de ce type de disques est d'offrir des performances très élevées (250Mo/s en lecture et 90 Mo/s en écriture dixit la boite de mon disque), pas de pièces mobiles donc moins de risques de pannes, pas de bruit et une consommation énergétique en générale moindre. En contre partie ils sont pour le moment très chers : de 99 à 700 € suivant les capacités qui oscillent entre 32 Go (oui oui vous avez bien lu 32) et 256 Go pour les plus généreux. Mais c'est une technologie jeune et les capacités et prix iront en augmentant pour l'une et en descendant pour l'autre (espérons seulement que ce soit dans cet ordre :p).

Oui mais alors SSD ou pas SSD ?

Le gros souci avec le SSD en ce moment c'est de savoir si ça vaut le coup ou pas, si réellement on va le sentir passer mais qu'après on pourra fanfaronner avec des "perfs de ouf" ou alors si on passera pour le geek de service qui a dépensé une fortune pour acheter le dernier truc "hyper ultra super top moumoute over the top of the performances" mais qui en réalité tourne juste 10% plus vite que le reste...

Pour nous consultants, les performances c'est important (vous trouvez pas que ça fait pub pour mousse à raser ?). On passe notre temps à créer des machines virtuelles, à les détruire, à en recréer d'autres, à les copier d'un disque à l'autre en permanence. Il arrive même très souvent que l'on fasse tourner plus d'une machine virtuelle en même temps, et là c'est souvent le drame ! Un clic et on peut aller se chercher un café...

Alors quitte à passer pour le Geek de service je me suis acheté un nouveau portable avec SSD. Un Dell Latitude équipé d'un SSD de 64 Go. Ca fait pas beaucoup ! Je voulais jouer à celui qui à la plus grosse... capacité, mais il fallait attendre presque 2 mois pour un disque de 256 Go. J'ai donc opté pour ce disque de 64 Go, tout en jurant aux cieux et à qui voulait l'entendre (z'étaient pas nombreux d'ailleurs) qu'un jour quand je serais grand j'achèterai en plus un SSD Externe.

Et ce jour est arrivé ! Ce sont les larmes pleins de yeux (ou le contraire) que je suis arrivé à la caisse tout tremblant tenant le saint graal entre mes mains : un SSD Intel x25 de 160 Go ! Et pour l'habiller je me suis servi d'un boitier Akasa Intégral 2,5" en eSata, ben oui parce que mettre un SSD dans un boitier externe en USB2 ce n'est pas bien, cette interface étant limitée en terme de débit.

C'est donc après quelques minutes passées en caisse (Et nous pouvons tous remercier Guillaume sans qui je n'aurais pas ce disque : Merci Guillaume !), que je suis retourné tout fiévreux... à mon travail et que j'ai du attendre le soir pour tester la bête (pfff pas idée d'inventer le boulot...).

(Bon Ok il est bien sympa à nous raconter sa vie lui mais on s'en moque, nous ce qu'on veut c'est le test !!!)

OK ok, ça vient...

L'environnement de test

Les tests ont été réalisés sur mon portable DELL Latitude E6400 avec un T9600, 8Go de RAM et Windows Server 2008 R2. Les tests consistent en une copie de machines virtuelles Hyper-V (le VHD) de 20,1 Go entre les différents disques, puis une fois les fichiers copiés, je démarre les machines à tour de rôle depuis chaque disque et je calcule : le temps de démarrage, le temps d'ouverture de l'administration centrale de SharePoint, le temps d'ouverture de Visual Studio 2008, quelques opérations d'installations et de créations diverses, la mise en veille et la sortie de veille de la machine virtuelle et enfin l'extinction de la machine virtuelle.

Les disques testés

Un Lacie USB2 250 Go je suppose que le disque tourne en 5400 trs/min
SSD Interne Samsung 64 Go (fourni avec le portable)
SSD Externe Intel X-25 160 Go dans boitier Akasa Integral eSata

Les résultats de copies

Enfin voici les résultats, tout t'abord la copie :

Disque de départ	Lacie USB2
Disque d'arrivé	SSD Interne
Utilisation de la mémoire	Monte de 1,30Go à 1,7Go puis au bout d'une minute se stabilise autour de 1,55Go
Utilisation du CPU	Stable à 12-25% avec des pics à 30%
Temps de copie annoncé	10 Minutes
Temps de copie réel	11 Minutes 37 secondes
Taux de transfert	29,53 Mo/s

Disque de départ	Lacie USB2
Disque d'arrivé	SSD Externe
Utilisation de la mémoire	Monte de 1,32Go à 1,65Go puis reste stable
Utilisation du CPU	Stable à 12-25% avec des pics à 30%
Temps de copie annoncé	11 Minutes
Temps de copie réel	10 Minutes 34 secondes
Taux de transfert	32,46 Mo/s

Les performances semblent similaires sur les deux disques avec un léger avantage pour le SSD Externe, on peut noter une utilisation de la mémoire et CPU assez basse.

Disque de départ	SSD Interne
Disque d'arrivé	SSD Externe
Utilisation de la mémoire	Monte de 1,29Go à 5,6Go !!! puis descend progressivement tout au long de la copie jusqu'à 1,96Go. Une fois la copie terminée la mémoire revient à 1,32Go
Utilisation du CPU	Environ 35/50% pendant la montée en charge de la mémoire (environ 1minute) puis 12-25% avec des pics à 35/40%
Temps de copie annoncé	4 Minutes
Temps de copie réel	4 Minutes 08 secondes
Taux de transfert	82,99 Mo/s

Là les choses changent un peu, on voit déjà une utilisation de la mémoire beaucoup plus intensive, ce qui laisse supposer que sur une machine avec moins de mémoire la copie aurait peut-être été plus lente. L'utilisation du CPU est elle aussi en hausse avec des pics plus nombreux. Est-ce dû au SSD ou au port eSata ? Aucune idée. Enfin par contre le temp de copie est tout bonnement hallucinant ! Deux fois et demie moindre qu'avec l'USB2 ! Et encore on parlait d'une copie USB2 -> SSD, je n'ai pas fait le test en USB2 -> USB2 mais il y a fort à parier que le temps serait plus long. Lors d'un autre test de copie d'une VM de SSD à SSD je suis même monté à des taux annoncés sur la copie à 200Mo/s !

Les résultats pour les applications

Passons maintenant à l'utilisation des disques, vous trouverez ci-dessous un ensemble de graphiques permettant de se rendre compte des performances de chaque disque, les temps sont indiqués en secondes et les moins élevés sont meilleurs.

De premiers résultats encourageant ! Le démarrage de la machine virtuelle prend presque moitié moins de temps sur le SSD Externe. Cela dit la machine étant issue d'un Hyper-V de Windows Server 2008 et que mon portable étant en Windows Server 2008 R2 la machine nécessitait de réinstaller les services d'intégration et de lui ré-attribuer une adresse IP valide pour accélérer encore le démarrage (voir test plus bas).

Alors là la différence est tout bonnement hallucinante, il a fallut 4 fois moins de temps sur les SSD interne pour ouvrir l'administration centrale que sur le disque USB2 ! Le SSD externe apporte même encore un petit boost à ce résultat.

Là aussi le résultat est sans appel, l'impression de rapidité est vraiment très impressionante, et cela semble le cas avec toutes les ouvertures d'applications.

Ce test était juste pour valider que l'installation d'une application bénéficiait elle aussi de l'utilisation d'un disque SSD et le résultat est concluant...

Le démarrage de la même machine virtuelle une fois les services d'intégration installés et l'adresse IP correctement attribuée. Le résultat est un peu moins contrasté mais montre toujours une différence de performance importante en faveur du SSD

Afin de ne pas faire que des tests sur des ouvertures d'applications, je me suis lancé dans la création d'une application Web, activité qui ne devrait pas trop faire travailler le disque. Et même si l'on voit un gain de performance en faveur du SSD celui-ci est tout de même moins important qu'avec les activités faisant une grande utilisation du disque dur.

Là encore la création d'une collection de site ne fait pas trop travailler le disque dur, on voit donc logiquement une différence entre les disques qui est plus réduite.

Un résultat intéressant, car l'ouverture du site de haut niveau nécessite la compilation des différentes DLL et l'on voit logiquement un résultat en faveur des SSD (au coude à coude, si tant est qu'un disque dur ait un coude O_o).

La mise en veille de la machine virtuelle utilisant intensément le disque dur, on voit ici une nette avance des disques durs SSD par rapport à l'USB2. Cependant j'avoue que je pensais cette différence plus importante, une chose est sûre, lorsque l'on attend que la machine virtuelle se mette en veille cette différence de temps nous paraît colossale :). A noter que dans ce cas les machines virtuelles étaient intégralement contenues sur leur disque, c'est à dire que la mémoire virtuelle a été enregistrée sur le disque amovible. En général je laisse plutôt les fichiers de config et la mémoire virtuelle sur le disque interne et le VHD sur les disques externes, un autre test plus loin permet de voir le résultat avec cette configuration.

Là également la sortie de la veille pour la machine virtuelle utilise intensément le disque, on voit donc un gain jusqu'à x3 pour le SSD, ce qui confirme l'avance des SSD (ça en devient presque lassant :p)

Ceci est un résultat intéressant, il s'agit d'éteindre complètement le système virtuel en utilisant le bouton "démarrer" :). Et on se rend compte que la différence n'est pas énorme entre les disques et que le SSD interne s'en tire mieux que le SSD Externe, mystère mystère

Là aussi un résultat intéressant correspondant à une variante d'un test précédent, cette fois-ci les machines sont mises en veille mais avec leur fichier de config et mémoire virtuelle sur le disque dur interne (SSD) et on voit que la différence n'est pas énorme (normal c'est le SSD Interne qui fait tout le travail) mais surtout qu'elle est en faveur de l'USB2... Je n'ai pas testé le CPU pendant le processus mais lors des copies de disque à disque le CPU était plus sollicité pour un disque SSD, ceci expliquant peut-être cela...

Et avec HDTune ? (pour les amateurs de chiffres...)

Ci-dessous deux capture d'écran montrant les performances des disque SSD interne et externe testées avec HDTune

D'abord avec le SSD Interne (Samsung)

Et avec le SSD Externe (Intel)

On voit très clairement que le SSD Externe est plus stable dans le débit que l'interne (normal il y a moins d'applications qui font appel à ce disque), par contre les taux de transfert me paraissent très étonnants. Les disques SSD Intel étant en général plus rapides que les autres (et les tests sur les applications ayant montré que le SSD Externe était plus rapide), je pense que la méthode utilisée par HDTune pour le transfert de copie n'est pas optimisée... Toujours est-il que ça décoiffe quand même de telles performances :p

Et le boitier externe dans tout ça ? Kékivo ?

Le boitier externe est bien, très bien même mais comme il fallait que je lui trouve des défauts, voici en vrac ce que je peux dire de mal sur lui… (gniark gniark).

La led n'indique pas l'activité du disque, et comme celui-ci ne fait aucun bruit on ne sait pas si ça travail ou pas... (mais l'alimentation est bien indiquée par une led donc ça va)
les cables fournis sont assez longs (environ 50 cm), ce qui est appréciable lorsque l'on veut mettre le disque loin du portable, par contre si on pose le disque à côté de l'ordinateur on se retrouve avec un sacré plat de spaghetti !
le boitier est plus gros (long) qu'un USB2 classique (mais il peut contenir tous les types de disques 2,5")

Sinon à part ça il a un style du tonnerre et il est livré avec une petite sacoche en simili cuir trouée au bon endroit pour utiliser le boitier sans le sortir ! En plus la connectique fournie est très bien (cable eSata, USB2 données, USB double pour alimentation).

Alors ? SSD ou pas SSD ? (Bis)

Pour moi le choix est déjà fait puisque j'ai le SSD Mais si je devais vous donner un conseil se serait : si vous avez les moyens, foncez ! Le gain de performance et le confort induit par l'utilisation d'un SSD est plus qu'appréciable et vous donnera vraiment l'impression de travailler plus vite... Je ne conçois plus de m'en passer, mais reste qu'à 430 € le disque + le boitier externe ça fait un peu bobo au baba...

Sur ce, bon code à tous !

SharePoint, nom interne, nom d'affichage et URL

Edgar — Sun, 26 Apr 2009 18:03:00 +0200

Bonjour à tous,

Cette fois encore je vais écrire une série de posts qui traitent d'un sujet commun mais que je préfère écrire en plusieurs fois pour rendre la lecture plus simple. Chaque post traitant d'une partie du sujet indépendante des autres.

Ce premier post traitera des noms intenes, des noms d'affichages et des URLs dans SharePoint, le second traitera de quelques limites fixées de l'outil SharePoint sur ces éléments (et il arrivera bientôt).

SharePoint est un progiciel, et qui dit progiciel dit paramétrage à outrance. Le progiciel étant la volonté d’avoir un outil à la fois très générique pour s’adapter au plus grand nombre et tout en même temps assez spécifique (vertical dit-on dans le métier) pour permettre une mise en œuvre rapide (vous sentez le paradoxe ?). De plus dans la globalisation du travail à laquelle nous faisons face, SharePoint se devait d’être multilingue.

"Jusque-là aucun problème ?" me direz-vous.

Et bien si, ceci est un problème car développer et paramètrer un environnement entièrement polymorphe (dont les noms et champs peuvent changer tout le temps) n’est pas du tout envisageable. Or un progiciel a besoin d'être polymorphe pour réellement s'adapter au métier et à l'organisation des clients.

D’un autre côté, fixer le nom des champs pour l’intégralité de l’application n’est pas envisageable non plus !

Imaginez : créer une colonne dont le nom serait fixé à l’avance et que vous ne pourriez pas changer, type : data1, data2, data3,… Bonjour l'horreur pour la mise en oeuvre...

Alors que faire ?

Recourir aux noms internes pardi ! Ainsi beaucoup d'éléments dans SharePoint possèdent un nom interne (qui ne varie pas) et un nom d’affichage qui lui peut varier à tout moment. Certains éléments comme les sites ou les listes possèdent eux plutôt une URL (qui fait office de nom interne) et un nom d'affichage.

Ainsi à présent nous avons un champ interne dont le nom ne varie pas (et donc auquel nous pouvons faire référence sans risque) et un nom d'affichage qui peut varier et s'adapter au contexte, à la langue, au grés et envies de l'utilisateur...

"Tout ça c’est bien beau", me direz-vous, "mais encore une fois beaucoup de texte et toujours pas de problème à l'horizon..."

Et encore une fois votre optimiste fait chaud au coeur mais vous conduira droit à votre perte (de cheveux dans ce cas...). Car le soucis c’est que SharePoint vous a masqué (légèrement) qu’un tel nom interne existait !!! Et surtout qu'il ne supportait pas les caractères spéciaux et espaces !

(Sentez-vous la tension monter maintenant ?)

Disgression 1 : Bon, soyons honnête, l’apprentissage de SharePoint n’est pas forcément des plus aisé, et si au départ on parlait de champs internes et de noms d'affichage certains se jetteraient par les fenêtres. C'est pourquoi souvent cette notion est passée sous silence. Cependant c'est très important de bien comprendre le fonctionnement de ces noms comme nous allons le voir à présent.

Donc comme je le disais, un des premier soucis auquel on peut être confronté avec ce nom interne c'est qu'il n'accepte pas les caractères spéciaux ni les espaces, et qu'il les remplace donc par des équivalents.

Ainsi :

"espace" devient _x0020_
"é" devient _x00e9_
"è" deivent _x00e8_
"'" (apostrophe) devient _x0027_
...

Ce qui rend la lecture un peu fastidieuse car le champ : "Interlocuteur demandé" devient "Interlocuteur_x0020_demand_x00e9_"

De plus lorsque ce nom doit être affiché dans une URL, le sous-tiret bas (underscore : _) est remplacé par des %5f et devient donc : "Interlocuteur%5fx0020%5fdemand%5f00e9%5f", ce qui est franchement illisible...

Pire ces remplacements allongent la taille du nom interne de l'élément, or ce nom interne a souvent une taille maximum et sera tronqué en cas de dépassement (voir prochain article pour ce problème...).

"Hé là l'ami, arrête un peu ton char, j'ai jamais vu de champs nom interne et nom d'affichage dans SharePoint..."

Je ne sais qui a lancé cette remarque très judicieuse mais grand bien lui en a pris car c'était justement le sujet de mon prochain chapître...(Et hop une transition rondement menée, une !)

En effet, rares sont les pages de paramètrage dans SharePoint qui font état de ces deux noms, cependant ils existent (si si croyez moi monsieur l'agent je les ai vus !!!).

Et en voici donc des exemples :

A - Colonnes et colonnes de site

J'ai groupé ces 2 champs car leur comportement est identique. Ils sont sûrement les éléments dont les noms interne et d'affichage sont les moins visibles.

Voici donc un petit exercice...

1 - Création d'une colonne

Rendez-vous dans une liste quelconque et créez une colonne : "Interlocuteur demandé" de type texte :

Cliquez sur les images pour agrandir

Laissez les valeurs par défaut puis valider votre saisie. Vous devriez obtenir ceci (ici dans une liste personnalisée)

Cliquez sur l'image pour agrandir

2 - Visualisation du nom interne

Cliquez sur votre champ et regardez dans l'url la section après "&field=". Ceci est le nom interne de votre champ, vous voyez que ce n'est pas très lisible.

Cliquez sur l'image pour agrandir

Sachant que vous aurez parfois à faire référence à ce nom dans votre code ou paramètrage (comme pour la recherche par exemple), c'est pas gagné !

3 - Modification du nom d'affichage

Tant que vous êtes dans la page de modification, profitez-en pour modifier le nom de votre champ de "Interlocuteur demandé" en "Correspondant".

Cliquez sur l'image pour agrandir

Valider votre modification, votre nom de champ a changé mais ici ce n'est que le nom d'affichage

Cliquez sur l'image pour agrandir

4 - Visualisation du nom interne et d'affichage

Si vous retournez dans la page de modification vous voyez que le nom d'affichage du champ a été changé mais pas le nom interne.

Cliquez sur l'image pour agrandir

/!\ Attention : pour une colonne il n'est pas possible de changer le nom interne d'un champ, celui-ci est fixé à partir du nom d'affichage lors de la création du champ selon les règles précisées plus haut.

Conclusion : à la création de votre champ il faut penser à d'abord créer le nom interne (sans caractères spéciaux, ni espace) puis modifier le nom du champ pour lui donner le nom voulu. Ainsi pour notre champ d'exemple nous aurions d'abord créé le champ avec le nom : "InterlocuteurDemande" puis serions venu modifier le nom en "Interlocuteur demandé"

B - Listes et bibliothèques

Pour les listes et bibliothèques le nom interne correspond au nom utilisé pour composer l'URL (adresse) de la liste. Voici donc un exercice pour voir le comportement de SharePoint dans ce cas

1 - Création d'une nouvelle liste

Créez une nouvelle liste de type "Liste personnalisée" et appelez la : "Ma liste personnalisée"

Cliquez sur l'image pour agrandir

2 - Visualisation de l'URL

Une fois votre liste créée, regardez l'URL et vous verrez que le caractère "é" contenu dans "personnalisée" a disparu (car les caractères spéciaux sont supprimés par SharePoint pour les URLs), de plus pour être conforme à la norme URL, les espaces sont remplacés par un %20

Cliquez sur l'image pour agrandir

3 - Modification du nom de la liste

Allez dans les paramètres de la liste pour modifier son nom

Cliquez sur l'image pour agrandir

Remplacer le nom "Ma liste personnalisée" par "Ma liste à moi" et validez.

Cliquez sur l'image pour agrandir

4 - Visualisation du nom de la liste

Votre liste à bien changée de nom d'affichage

Cliquez sur l'image pour agrandir

Mais l'URL continue d'afficher le premier nom (le nom "interne")

Cliquez sur l'image pour agrandir

/!\ Attention : Comme pour les colonnes il n'est pas possible de modifier le nom interne (l'URL) d'une liste. On peut cependant copier la liste vers une autre destination (une autre URL, donc un autre nom interne) et supprimer la première liste.

Conclusion : comme pour les colonnes, pensez à créer d'abord votre liste avec le nom interne désiré puis changez son nom vers le nom d'affichage voulu.

C - Les sites

Les sites fonctionnent de la même manière que les listes sauf que l'URL du site peut-être fixée lors de la création du site et en modification.

1 - Création du site

Cliquez sur l'image pour agrandir

2 - Modification du site

En passant par les paramètres du site, dans la section "Titre, description et icône"

Cliquez sur l'image pour agrandir

On peut modifier cette URL après que le site soit créé (mais attention aux liens pointant sur cette "ancienne" URL)

Cliquez sur l'image pour agrandir

Conclusion : Penser à créer votre site avec une URL explicite et lisible, en remplaçant les espaces par des sous-tirets bas (underscore), et en ne mettant pas de caractères spéciaux.

Disgression 2 : Si vous vous dîtes que l'URL n'est pas importante car personne ne la lit, demandez-vous alors pourquoi on ne met pas que des URLs du type http://152650/121321564/?sddsfd122... Qui seraient plus simples à gérer côté code... L'URLs est lue bien plus souvent qu'on ne le croit par les visiteurs pour vérifier qu'ils se trouvent au bon endroit.

D - Cas spécial 1: Les vues (affichages)

Les vues représentent un cas à part car elles sont à mi-chemin entre les listes et les sites : on ne peux fixer leur URL à la création (qui est déduit du nom de la vue), mais on peut le faire à la modification

1 - Création d'une vue

Cliquez sur les images pour agrandir

Le résultat dans l'URL est le suivant

Cliquez sur les images pour agrandir

2 - Modification d'une vue

Au contraire des listes on peut modifier l'URL d'une vue en modification (comme pour les sites)

Cliquez sur les images pour agrandir

J'avoue que je suis un peu perplexe sur la démarche... Mais c'est ainsi.

Conclusion : Pensez à modifier l'URL de vos vues après création pour quelles soient plus explicites et lisibles, en remplaçant les espaces par des sous-tirets bas (underscore), et en ne mettant pas de caractères spéciaux.

E - Cas spécial 2 : Les types de contenu

Les types de contenu sont eux aussi un cas à part car ils n'ont pas à proprement parlé de nom interne, ils disposent cependant d'un ID qui est créé automatiquement à partir de l'ID du type de contenu dont il hérite (si cela vous semble nébuleux, passez votre chemin car l'explication de la création d'un type de contenu pourrait largement dépasser la taille de cet article déjà conséquent :D )

Cliquez sur l'image pour agrandir

Ici l'ID est visible dans l'URL en bas et suit le paramètre "?ctype="

/!\ Attention : Cet ID n'est modifiable ni à la création (à moins de créer son type de contenu avec une feature), ni en modification.

Conclusion générale:

Voilà, j'espère que ceci vous permettra de mieux comprendre le fonctionnement de SharePoint sur l'attribution des noms internes et des URLs. Ceci est souvent source de problème lors de développement car certains objets font référence aux noms internes, aux noms d'affichage ou aux deux... C'est aussi un problème pour du "simple" paramètrage, par exemple si vous créez de nouvelles propriétés gérées dans le moteur de recherche de MOSS pour créer de nouvelles étendues de recherche, le mappage de la propriété gérée vers un champ se fait sur le nom interne...

D'une manière générale il est important de garder des noms internes propres et courts car la limite se situe à 32 caractères maximum. Mais ceci fera l'objet d'un prochain article (et hop voici comment je vous tiens en haleine pendant la pub...)

Bon code à tous !

Attention à la longueur des URLs des sites WSS (et MOSS ?)

Edgar — Fri, 13 Mar 2009 10:21:00 +0100

Bonjour,

Un hotfix vient de sortir pour corriger un problème qui peut se réveler critique pour vos fermes SharePoint.

En effet de base WSS ne supporte pas d'URL de plus de 64 caractères pour les sites, prefixe http(s):// compris. Soit pas plus de 56 ou 57 caractères pour la partie intéressante de l'URL (suivant le protocol).

Ce qui est troublant et potentiellement très dangereux c'est que WSS vous laisse créer des sites avec des URLs plus longues mais ne les restaurera pas au cas où vous devriez utiliser une de vos sauvegardes !!

Heureusement un hotfix vient d'être mis à disposition. Vous pourrez trouver plus d'infos à cette adresse :

http://kbalertz.com/960487/Windows-SharePoint-Service-cannot-restored-header-length-greater-characters.aspx

Attention cependant une fois le hotfix appliqué vous n'aurez pas 255 caractères disponibles, comme le prévoit le standard Internet, mais 136 maximum (c'est déjà mieux que 64).

L'annonce précise que le problème se pose pour WSS 3.0 et non pour MOSS, mais il y a fort à parier que le problème est identique sur cette plate-forme également...

Bon code à tous !

Vue en mode feuille de données (Access Web DataSheet) et répertoires : attention !

Edgar — Wed, 11 Mar 2009 18:05:00 +0100

Bonjour à tous,

Ce post fait suite au précédent (non ??? si si) sur le problème des répertoires et des éléments dans les listes SharePoint.

Pour l'édition en masse des éléments dans les listes SharePoint il existe le mode "feuille de données" qui permet grâce à un composant ActiveX de voir le contenu de la liste au travers d'une interface type 'Microsoft Access'. Ce mode fonctionne très bien pour l'édition y compris avec les répertoires. Ainsi lorsque je me déplace dans un répertoire je ne vois que les éléments de ce répertoire dans la feuille de données, ce qui est parfait.

"Et donc ?" ce disent les plus perspicaces d'entre vous...

Et donc, le problème vient d'ailleurs (comme la vérité...ouais facile je sais...). Le soucis c'est lors de l'ajout de nouveaux éléments. Dans ce cas le comportement est plutôt frustrant puisque peu importe où je me trouve dans la liste les éléments sont créés à la racine...

Après plusieurs recherches et tentatives diverses et infructueuses, je me suis résolu à faire un gestionnaire sur l'évènement ItemAdded qui me permet de déplacer mon élément dans le bon répertoire en fonction de la valeur d'un champ de l'item (oui je sais c'est moche mais là je ne savais pas vraiment quoi faire d'autre à part changer complètement le développement...).

Voici donc le gestionnaire d'évènement :

public override void ItemAdded(SPItemEventProperties properties)
{
   using(SPWeb web = properties.OpenWeb())
   {
      SPListItem item = properties.ListItem;
      SPFile dummyFile = web.GetFile(item.Url);
      this.DisableEventFiring(); 
      dummyFile.MoveTo(web.Url + "/Lists/" + properties.ListTitle + "/" + item["RepName"].toString() + "/" + item.ID + "_.000");
      this.EnableEventFiring();
   }
}

A présent mes créations d'éléments au travers des feuilles de données fonctionnent correctement, mais je n'ai pas testé cette action sur une montée en charge importante donc le code est "fournis tel quel" sans garantie aucune :p

Bon code à tous !

PS : 3 posts dans la même journée je viens de péter mon record

Déplacement d'un SPListItem dans un répertoire d'une SPList

Edgar — Wed, 11 Mar 2009 15:11:00 +0100

Bonjour à tous,

Quand il s'agit d'organiser l'information dans des bibliothèques de documents ou des listes SharePoint, il vaut mieux recourrir à des Content Types qu'utiliser des dossiers. Cependant parfois il est tout de même nécessaire d'utiliser des dossiers, notamment quand on nombre important d'items seront à terme stockés dans la liste (à cause de la fameuse barrière des (environ) 2000 items et de la chute de performance induite).

Le soucis lorsque l'on travaille avec des dossiers c'est que la création et le déplacement des éléments depuis le code SharePoint ce n'est pas si simple. On trouve un peu partout sur le net des exemples et des articles pour la création d'éléments dans une bibliothèque ou une liste (c'est la même procédure), par contre pour le déplacement c'est pas la même histoire.

Dans le cadre d'une bibliothèque le problème est assez simplement résolu via l'utilisation du SPFile associé à l'item (SPLIstItem.File) et plus précisement de la méthode MoveTo de cet objet. Par contre dans le cas d'une liste la propriété SPFile de l'objet SPListItem est null, donc impossible de faire le transfert...

Impossible ? non ! Un petit village d'irreductibles développeurs SharePoint (et bloggeurs) a percé le secret de ce déplacement. La méthode est pour le moins inattendue, complètement non documentée (à ce jour je n'ai trouvé qu'un post sur tout le net qui en parle) et très franchement capillotractée !!!

En réalité, en interne même pour les éléments d'une liste il existe bien un objet SPFile, mais celui-ci n'est tout simplement pas associé à l'item via la propriété File... Il faut le récupérer en utilisant la méthode GetFile() de l'objet SPWeb. Une fois que l'on a une référence à cet objet on peut utiliser la méthode MoveTo. Mais là aussi il y a une subtilité, il faut utiliser une URL de destination un peu particulière : URLduSite/Lists/NomListe/Rep/itemID_.000

Oui, oui vous avez bien vu "ID_.000", ce n'est pas très éloquent comme syntaxe mais cela fonctionne (ça sent un peu la bidouille quand même... si quelqu'un a une autre méthode...)

Voici donc un exemple de code (qui suppose que vous ayez déjà récupéré un SPListItem nommé item) :

using(SPWeb web = item.Web)
{
    SPFile dummyFile = web.GetFile(item.Url);
    dummyFile.MoveTo(web.Url + "/Lists/" + item.ParentList.Title + "/NomduRepertoire/" + item.ID + "_.000");
}

Et hop, votre item est transféré dans le bon répertoire, mais j'avoue quand même que cette technique me semble douteuse et j'émets les plus vives craintes sur la pérennité d'une telle méthode avec la future version de SharePoint (2010 ?). En attendant cela fonctionne et m'a tiré une belle épine du pied... (voir le prochain post...)

Bon code à tous !

CustomSiteAction.xml pour site de publication : fichier de ressource obligatoire !

Edgar — Wed, 11 Mar 2009 10:35:00 +0100

Bonjour à tous,

La plupart des développeurs .Net le savent bien, lorsqu'il s'agit de faire des sites multilingues, en dehors des fichiers de ressources point de salut ! C'est encore plus vrai lorsque vous travaillez avec les fichiers CustomSiteAction.xml, CustomQuickAccess.xml ou CustomEditingMenu.xml.

Ces fichiers que vous pouvez trouvez dans le répertoire EditingMenu de la gallerie de page maîtres (lorsque le site est un site de publication) servent respectivement à modifier

le menu "Actions du site" (pour un site de publication),
la barre d'outils de modification de page (appelé aussi Authoring Console en anglais)
et enfin les menus de cette même barre (Page, Flux de travail, Outils,...).

Vous pouvez y ajouter, remplacer ou supprimer des entrées grâce à des noeuds "ConsoleNode".

Tout ce passe bien tant que vous n'utilisez pas directement d'accents ou de caractères autres que ASCII dans le fichier. En effet le fichier est au format XML mais ANSI par défaut. Si vous indiquez un caractère accentué (par exemple dans une description de menu) le fichier n'est plus conforme (et refuse de s'afficher dans IE par exemple). De plus si vous tentez de l'insérer tel quel dans SharePoint vous obtiendrez un joli message : "L'index se trouve en dehors des limites du tableau" (notez au passage la pertinence du message d'erreur).

"Qu'à cela ne tienne" me diront les plus aguérris, "Enregistre donc ton fichier en UTF-8 !" Et d'autres de rajouter : "banane !"

"Oui mais," rétorquerais-je (pratiquement du tac au tac, le temps de finir mon pain au chocolat...), "là c'est SharePoint qui n'est plus d'accord", il nous renvoit d'ailleurs ce message (encore une fois très explicite...) : "Le noeud spécifié ne peut pas être inséré comme enfant valide de ce noeud, car le noeud spécifié n'est pas du type correct"

"Mais crévindieu" s'exclament-t-alors les plus aguerris de naguerre, "comment qu'cé ti qui font chez Microsoft pour n'en n'avoir des accents dans leurs descriptions, eux ?".

La réponse est simple : fichier de ressource !

En l'occurence le fichier cms.resx que vous pouvez trouvez dans le répertoire "c:\inetpub\wwwrroot\cheminversvotrewebapp\App_GlobalResources\".

Vous savez donc maintenant ce qu'il vous reste à faire... Non ? Et bien, ajouter un nouveau fichier de ressource que vous déploierez grâce à une solution (en utilisant un noeud : ApplicationResourceFile) et faire référence à cette ressource dans vos fichiers de configuration, et vous voilà à présent roi de la modif des menus d'un site de publication.

Bon code à tous !

VSeWSS 1.3 CTP : beaucoup de nouveautés et compatibles x64 :)

Edgar — Sat, 21 Feb 2009 16:09:00 +0100

Bonjour à tous,

Un message rapide pour vous dire que les Visual Studio extensions for WSS 1.3 en version CTP (Community Technology Preview) sont disponibles à cette adresse :

http://www.microsoft.com/downloads/details.aspx?FamilyID=b2c0b628-5cab-48c1-8cae-c34c1ccbdc0a&DisplayLang=en

J'avais été assez déçu lors de la release de la version 1.2 qui apportait le support pour Visual Studio 2008 mais pas en version x64. Cette version préliminaire 1.3 montre que Microsoft a travaillé dans ce sens, ce qui ne peux que me ravir :p

Beaucoup d'améliorations en vue dans le descriptif. Je n'ai pas encore testé tout ça mais ça à l'air bien fourni

Bon code à tous !

Windows Update, Framework.Net 3.5 SP1, et moteur de recherche MOSS : Pas Bon !

Edgar — Fri, 13 Feb 2009 10:24:00 +0100

Bonjour à tous,

Vous l'avez peut-être remarqué, mais Windows Update a modifié la façon d'installer les .Net Framework ces jours-ci. En effet il y a peu encore vous deviez installer le FrameWork 2.0 puis 3.0 puis les SP1 de chaque et ensuite le .Net Framework 3.5 par un installeur à part.

A présent il n'y a qu'une entrée .Net Framework 3.5 SP1 dans WU qui installe les FrameWorks 2.0 SP2, 3.0 SP2 et 3.5 SP1 : wunderbar ! (Comme dirait nos amis d'outre rhin).

Oui mais, il y a un problème connu avec le .Net FrameWork 3.5 SP1 qui empêche l'indexeur du moteur de recherche de MOSS de fonctionner correctement si celui-ci essaie d'indexer le serveur où il se trouve. Ce cas est fréquent pour nous autres consultants qui faisont des machines toute en un, mais aussi pour certains clients qui n'ont qu'un serveur. Du coup plus d'indexation possible et donc plus de recherche :s

Heureusement le problème est connu depuis quelques temps comme en témoigne ce post d'Octobre 2008 (en anglais) :

https://blogs.msdn.com/ronalg/archive/2008/10/27/crawling-issue-with-net-3-5-sp1.aspx

Et la solution aussi !

Elle passe par la modification de la base de registre du serveur, le tout étant expliqué ici (en anglais) :

http://support.microsoft.com/kb/896861/en-us

A noter que cet article de la KB n'est pas réellement rédigé pour corriger ce problème, mais le problème est similaire et la solution fonctionne.

Attention donc à vos prochaines machines toute en un ! Car vous ne pouvez plus installer les Frameworks par WU sans installer le SP1 du 3.5 !

Bon code à tous !

Développement d'applis x86 et SharePoint x64 : pas bon !

Edgar — Fri, 23 Jan 2009 09:13:00 +0100

Bonjour à tous

Après avoir perdu 1 h de mon temps sur un message d'erreur peu éloquent (étonnant non, de la part de SharePoint ?), je vous livre une info qui après coup semble logique mais qui ne m'a pas sauté au yeux au début.

Si vous avez un SharePoint en x64 (64bits) et que vous développez une application Windows ou console pour utiliser le modèle objet de SharePoint, cette application doit aussi tourner en x64 sinon vous ne pourrais pas vous connecter à SharePoint par le modèle objet. L'erreur arrive lors de la connexion à la collection de site en utilisant :

SPSite siteCol = new SPSite("http://urldemacollectiondesite");

Cette ligne renvoie l'erreur : "L'application Web est introuvable à l'adresse http://urldemacollectiondesite, vérifiez patati, patata...). Ce qui n'est pas du tout explicite.

Dans mon cas, après vérification de l'url, des accès de substitution, des différents paramètrages, tout était conforme et mon application aurait du trouver la collection de site.

En réalité, j'avais passé mon application en cible x86 (32 bits) car j'utilisais le composant d'accès à Access (AccessDataSource) qui ne fonctionne pas en x64. En repassant mon application en x64 (je vous passe les détails de l'investigation :p) tout fonctionnait pour SharePoint mais plus pour Access... Grrrrrrr !!!!

Heureusement Access 2007 dispose d'un module d'export très pratique qui m'a permis d'exporter ma base de données sur le serveur SQL qui fait tourner SharePoint, et du coup j'ai pu utiliser le composant d'accès à SQL Server qui lui fonctionne très bien en x64 ! Bon ça m'a pris juste 1h30 -<:o)

Moralité : ne mixez pas les environnements ou evitez autant que possible ! (qui a dit on le savait déjà ?)

Bon code à tous !

RadEditor et SharePoint (MOSS) "customisé" attention au DocType

Edgar — Wed, 21 Jan 2009 12:16:00 +0100

Bonjour à tous,

Comme vous le savez peut-être déjà la société Telerik founi (en remplacement de l'éditeur de contenu fourni par Microsoft) un éditeur de contenu compatible avec plus de navigateurs que l'éditeur standand : RadEditor.

Ce contrôle fabuleux (même dans sa version lite), nécessite cependant que la page en cours utilise un DocType compatible XHTML, sinon les barres d'outils flottantes, le gestionnaire de liens et d'images apparaîtront en dehors de la page ce qui n'est ni pratique, ni esthétique, et encore moins professionnel.

Or les pages master par défaut de SharePoint n'utilisent pas un DocType XHTML mais HTML 4.01, donc si vous placez ce contrôle sur la page sans plus de modifications vous vous heurterez aux problèmes sus-mentionnés (wow qu'est ce que je parle bien !!!). Il est donc important (sinon impératif) que vous modifiez le DocType sur votre (vos) page(s) master.

Pour y arriver rien de plus simple, dans votre page master recherchez la ligne (ou quelque chose d'approchant) :

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

et remplacez la par :

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

Attention, si votre mise en page est basée sur les CSS, le fait de passer en XHTML peut faire apparaître des défauts qu'il faudra corriger (pour tous les navigateurs...).

Une petite astuce ici : si des défauts apparaissent, avant de tout reprendre assurez vous que le nom de la classe ou de l'identifiant CSS soit bien écrit en respectant la casse. En effet, si une majuscule transfomée en miniscule ne gêne pas HTML 4.01, dans un DocType XHTML la classe ne sera pas du tout appliquée à votre élément ! (Ce qui vous en conviendrez est assez gênant tout de même...)

Morale : passer le plus tôt possible votre DocType en XHTML, cela vous évitera de devoir refaire votre mise en page...

Bon code à tous !

WSS 4.0 : Tester la compatibilité de votre code maintenant (enfin bientôt !)

Edgar — Tue, 23 Dec 2008 09:51:00 +0100

Bonjour à tous,

Après un (long) moment d'absence je reviens pour blogger sur cette news quelque peu inquiétante pour tous ceux qui ont fait des views avec du code CAML perso. Le SP2 de WSS et MOSS devrait bientôt sortir (aux dernières nouvelles au mois de février...), il apportera son lot de correctifs et des nouveautés tel que le Pre-Upgrade Checker, un outil vous permettant de tester votre code pour savoir s'il sera compatible avec le futur WSS 4.0 (MOSS 2009/2010 ?). On peut déjà trouver sur la base de connaissance Microsoft quelques infos à ce sujet :

List of all Windows SharePoint Services and SharePoint Server Pre-Upgrade Checker knowledge base articles

A noter donc si on (je) lit correctement que Microsoft mettra l'accent sur le XSLT dans la prochaine version de WSS au détriment de CAML (mais ce n'est que supposition au regard de ces quelques article de la KB). Entre ceci et l'anonce faite par Bill Gate durant sa Keynote à la SharePoint Conférence, il semblerait que pour le développement sur la future plate-forme SharePoint il faudra mettre l'accent sur deux languages par forcement toujours maîtrisé par les développeurs SharePoint à savoir : XSLT et SQL (T-SQL surtout). Tous à vos bouquins / Tutoriaux / Webcasts !!!

Bon code à tous !

L'install de Telerik Moss Editor a fusillé votre site ?

Edgar — Sun, 03 Aug 2008 22:49:00 +0200

Bonjour à tous,

Avant de vous dire comment l'installation du MOSS Editor peut fusiller votre site et surtout comment régler le problème, je voudrais juste faire un rappel pour ceux qui ne connaitraient pas les contrôles Telerik. Ceux sont des contrôles en ASP.Net Ajax (depuis peu) à la norme XHTML 1.1 (un n'est pas compatible), compatibles avec SharePoint et avec tous les grands navigateurs (Firefox, IE, Opera, Safari). On y trouve vraiment des contrôles fantastiques comme des menus très bien faits, des éditeurs de texte puissants, des Combobox avancées, etc... le mieux est d'aller visiter leur site et de regarder les démos c'est assez impréssionant -> http://www.telerik.com

Parmis tous ces composants il y en a un qui a particulièrement été développé pour SharePoint : MOSS Editor. Une alternative à l'éditeur de texte fourni dans SharePoint par Microsoft mais compatible avec Safari (sauf liste et indentation, cf la doc). Une version lite (gratuite) regroupant l'intégralité des fonctions de l'éditeur SharePoint standard est dispo ! La version complète quand à elle fournit bien d'autres fonctionnalités très intéressantes.

Intéressons nous maintenant au probème mentionné dans le titre de ce post. Telerik a récement mis à jour ses composants pour ASP.NET Ajax en version Q2, les assemblies sont maintenant en version 2008.2.723.35. Or si vous avez installé ces composants et que vous essayer d'installer le MOSS Editor cela va fusiller votre site avec une erreur très bizarre qui ne donne pas du tout l'origine réelle du problème. Plus aucunes pages ne fonctionnent sur le site (pas même les pages d'application.) et vous vous dîtes que votre lit était finallement si douillet...

Mais ne désespérez point, en réalité le problème et très simple et vient de la modification du fichier web.config lors de l'installation du MOSS Editor. En effet lors de ce processus le programme d'installation modifie le web.config pour ajouter les DLL du MOSS Editor comme Safe de la façon suivante :

Classique me direz-vous, c'est le Delco ! Heu non... c'est la façon de faire, isn't it ? (Je parfais mon anglais :p).

Oui mais si vous avez déjà installé les versions Q2 de Telerik, certaines DLL sont déjà enregistrées comme sûres. Et il semble que SharePoint n'aime pas du tout, mais alors pas du tout ça, et du coup vous le signifie avec une erreur qui ne signifie rien pour bien vous montrer l'absurdité de la situation :).

Alors ?

Alors que faire pour corriger ce problème ?

Sacré bon dieu va-t-il le dire ???

Oui, oui ca va on y vient, pour une fois que je vous tiens sur un article, je réserve mes effets

Donc disais-je pour corriger le problème il faut parler gentillement à SharePoint, et tout d'abord, il vous faut supprimer la première et la troisième ligne (celles comportant les namespaces : Telerik.Web.UI et Telerik.Web.UI.Design). En effet ces lignes ont déjà en principe étaient déclarée en tant que contrôle sûres. Il faut ensuite aussi remplacer la version de DLL (2008.2.723.20) pour les deux autres lignes par 2008.2.723.35. Et Tada ! Votre site refonctionne En tout cas pour moi cela a corrigé le problème.

Bien que je n'ai pas fais l'essai, le problème devrait se poser aussi si vous avec les Q1 de Telerik, car la version des DLL est 2008.1.619.35, et posera aussi un problème de conflit. Mais dans ce cas je pense que ce sont les déclarations pour les contrôle Q1 qu'il faudra supprimer (car MOSS Editor nécessite la version 2008.2.723.20 au minimum). Cependant encore une fois je n'ai pas tester ce cas là (ai-je dit que je ne l'avais pas testé ?)

N'hésitez pas à me faire part de vos remarques si cela fonctionne ou ne fonctionne pas chez vous ;). En attendant 'have fun" avec les contrôles Telerik (oui je parfais encore mon anglais ici aussi

Bon code à tous !

Vas-y Matt danse danse !!!

Edgar — Sat, 02 Aug 2008 22:04:00 +0200

J'adore ce que fait ce gars !!!

Certains trouveront qu'il n'y a aucune utilité ni aucun intérêt à voir un gars danser un mélange de la stick polka et de la Soggy Bottom Boys Dance partout dans le monde, mais moi ça me fait rêver !

Un peu d'humanité, autre chose que la sempiternelle danse des missiles, des catastrophes et de la misère. Comprenons-nous bien, je ne me voile pas la face, je sais que dans la pluspart des pays du monde on souffre, on meurt et on subit des injustices toute la journée et je ne minimise pas ce fait bien au contraire. Mais ce n'est pas en nous bardant toute la journée de ces images que cela fera avancer les choses au contraire, on arrive à un effet d'accoutumance et comme toujours avec le genre humain à un effet de surenchère dans les images choc. Un temblement de terre au Yémen, des centaines de morts ? Peuh ! L'asie à fait plus de 150 000 morts avec un raz de marée ! Le Yémen aurait pu faire mieux, non !!! Triste réalité...

Voilà pourquoi j'adore ce que fait ce gars, il ramène un peu d'humanité et de joie de ces pays, des images vraies, loin des paysages et autre monument stéréotypés, loin des images choc sensées interpeler ou divertir la populasse...

Vas-y Matt ! Danse, danse et ramène nous tes images, fait nous rêver avec autre chose

Matt en 2008

Matt en 2006

Retrouvez le site de Matt : http://www.wherethehellismatt.com

Bon code (et pas de dance) à tous
PS : J'adore même les musiques :p

Liste des libraries en ligne

Edgar — Mon, 07 Jul 2008 19:06:00 +0200

Bonjour à tous,

Une fois de plus ce post ne parlera pas directement de SharePoint (à croire que je ne travaille pas dessus :). Cela dit ce n'est pas si loin car ce dont je vais vous parler me sert tous les jours pour améliorer mes connaissances de cette plate-forme.

La plupart d'entre vous connaissent sûrement déjà ces merveilleux outils que sont les librairies en ligne. Pour ceux qui ne connaisse pas il s'agit (moyennement finance évidemment) d'accéder à tout un ensemble de livres au format électronique (souvent HTML, parfois PDF). L'avantage est que pour une modique somme (de $20 à $50 par mois) vous accéder en illimité à des milliers de références sur l'informatique (pour les librairies qui nous intéresse ici). Un autre avantage non négligeable est la possibilité de faire des recherches dans ces livres et de trouver instantanément ou presque le chapitre qui parle de ce que vous voulez. C'est assez puissant et pour tout dire je ne peux plus m'en passer, un nouveau sujet hop je file sur internet et je regarde s'il existe un bouquin ou un chapitre sur le sujet.

Beaucoup me diront qu'il suffit de faire une recherche sur Google (oups Live...) pour trouver ce qu'on cherche et gratuitement, et je répondrais que malheureusement la qualité est souvent fluctuante... On peut tomber sur d'excellents articles comme sur la millième redite du même bout de code (avez-vous remarqué cette propension qu'ont les bloggeurs à bêtement recopier la même news que le voisin parfois légèrement modifiée...).

Je ne sais pas vous mais moi je préfère un bon bouquin, je profite aussi des bons articles quand j'en trouve, mais rien ne remplace la joie d'ouvrir un bouquin (Ok là vous ne l'ouvrez pas réellement mais bon on fait comme si) et de tomber rapidement sur le chapitre qui parle de ce que je recherche, et non de me taper 50 pages de différents blogs qui disent tous la même chose mais pas de la même manière...

Bien, après cette longue (comme d'habitude) mais importante ode à la librairie en ligne je voudrais vous faire part de mes trois librairies préférées :

Safari Books online : Super ! Joint venture entre Pearson (Campus Press, MacMillan, etc...) et O'Reilly, cette librairie est la première que j'ai découverte. Le site est plaisant et regorge de petits plus comme l'export au format PDF des chapitres (limité à quelques uns suivant votre abonnement), Safari labs, les "Rought cuts" -> avant première des bouquins (ahhh la joie de voir un bouquin s'écrire sous vos yeux...)

Books24x7 : la librairie en ligne de Skillsoft, pour ma part très bon complément à Safari books online (qui ne dispose pas de Wrox et Apress, deux supers éditeurs). Cette librairie est plus fournie en éditeurs et en titres, mais le site dispose d'une ergonomie à faire pâlir...

MS Press E-Refrence Library : et oui j'ai découverts ça récemment, MSPress propose maintenant ses bouquins à lire en ligne. La plate-forme est la même que cette de 24x7 Books online mais limitée à MS Press et du coup le tarif s'en ressent ($20 par mois environ contre presque $40 pour 24x7). Peut être un bon complément à Safari qui dispose de MS Press mais pas toujours des derniers titres... (Certains oui, d'autres non ...)

Voila, à noter que books24x7 est aussi la plate-forme de Wrox Online. J'espère que ceci vous sera utile, si vous connaissez d'autres librairies en ligne n'hésitez pas à me laisser un commentaire. Ma préférence va à Safari pour son ergonomie et ses petites plus, par contre si vous cherchez la quantité 24x7 est plus fournie pour un tarif équivalent.

Bon code à tous !

VseWSS 1.2 sorties oui mais.... pas en x64 :(

Edgar — Tue, 01 Jul 2008 17:12:00 +0200

Bonjour à tous,

La pluspart d'entre vous l'on sûrement déjà noté, les VseWSS 1.2 (Visual Studio Extensions for WSS) sont sortis au début de ce mois. C'est une bonne nouvelle car elles apportent le support de Visual Studio 2008 ce qui manquait vraiment jusqu'à présent... Cependant un bémol (et de taille je trouve) vient ternir le tableau, ces extensions ne sont disponibles qu'en version 32 bits ! Exit les plates-formes de dév en x64. Or avec de plus en plus de serveurs disponibles en x64 et tout le buzz autour de cette avancée, beaucoup de clients ont migrés ou vont migrer leur infrastruture... Afin de limiter la casse lors du déploiement il vaut mieux avoir aussi des machines de développement en x64, J'ai donc décidé moi aussi de migrer certaines de mes machines de développement en x64, et là c'est le drame comme dirait l'autre.

Conséquence : Je me passerai des extensions pour le moment au profit d'autres outils disponibles sur CodePlex, mais c'est bien dommage quand même... En espérant que Microsoft sorte rapidement une version x64 mais pour le moment rien n'est annoncé, aller encore un petit effort les gars !

Bon code à tous !

I'm freeeeee(lance) ! Et de retour :)

Edgar — Sat, 07 Jun 2008 20:11:00 +0200

Bonjour à tous,

Cela fait une éternité que je n'ai pas blogué, mais j'ai une excuse en béton (oui madame...) : ma vie a été bien chargée ces dernières semaines (ah bon c'est tout, il aurait pu faire mieux, j'pensais qu'il s'était perdu au pôle sud...).

Comme l'annonce le titre je suis maintenant indépendant (freelance, à mon compte, choisissez le terme qui vous convient), et comme d'habitude les fins de contrats sont toujours chargées (il faut tout finir avant de partir !!!!). J'ai donc eu peu de temps pour venir trainer ma plume par ici (cette expression est vraiment dépassé à l'air des claviers :).

J'ai choisi de quitter mon poste de Directeur Technique pour pouvoir me consacrer entièrement à SharePoint et les technos annexes (rien que çà, oui, oui...). Je fournis donc du conseil, et de l'expertise (wouhaaa le terme pompeux...) pour tous mes clients (ouais j'en ai pas des centaines non plus hein...). Je fais aussi du développement, de l'archi et de l'admin car il faut rester dans le bain :p.

Donc après maintes zé maintes années de loyaux services pour diverses sociétés, j'ai choisi de créer ma propre structure sous le nom NFTInside (ohhh comme le nom du blog, étonnant non ?). Et ma foi, je suis agréablement surpris par la charge de travail qui m'est tombée dessus (oui oui tombée dessus) dès mon départ. Cela a rendu quelques unes de mes journées trèèèèèèès longues, mais cela permet de se sentir plus confiant dans l'avenir

Cela a aussi inévitablement retardé mon retour sur ce blog mais (et j'espère que vous ne m'en voudrez pas...=), entre un bon repas (richement payé en note de frais :p) et ce blog mon choix est (vite) fait (et mes pantalons crient au suplice....) :).

Bref, pour le moment beaucoup de choses à faire, tant à raconter mais si peu de temps pour le faire (j'en vois déjà qui se disent, roooh l'aut' hé moi aussi je galère...). Mais je ne me plains pas, fort au contraire, cette situation me comble et je tâche d'en savourer chaque instant, j'espère seulement trouver un peu plus de temps de pouvoir écrire sur ces pages. En attendant je savoure mon nouveau départ dans la vie. (je crois que vous l'avez compris non ?)

N'hésitez pas à me contacter si vous souhaitez des informations (sur moi -ben quoi on peut rêver non ???-, ou plus sûrement sur mon activité

Bon code à tous !

Slides du séminaire Visual Studio 2008 au Forum Emploi de la Défense

Edgar — Mon, 31 Mar 2008 00:32:00 +0200

Bonjour à tous,

J'ai animé une réplique du séminaire Visual Studio 2008 du mois de Janvier (voir le précédent billet) lors du Forum Emploi Microsoft organisé par MSEmploi à la Défense.

Ceux qui étaient présents auront sûrement remarqué que j'ai explosé le temps imparti pour cette sessions (preque 4 heures au final). A toutes les personnes qui sont parties juste avant la fin (spâaaa bien !) je souhaiterais présenter mes excuses pour ce retard, à tous ceux qui sont restés, mes remerciements ! Cette session était comme la première bien chargée, et comme j'ai tenté de tenir compte des remarques qui m'avaient été faîtes lors du premier séminaire et j'ai approfondi un peu la partie Linq et suis allé un peu plus en douceur sur la partie SharePoint

Les personnes souhaitant obtenir les slides de la présentation pourront trouver le lien ci-dessous, pour les personnes ayant assistées au premier séminaire (celui de Janvier) il n'est pas nécessaire de re-télécharger ces slides qui ne comportent que quelques corrections de fautes d'orthographe (quelques -> euphémisme.. :o)

Pour accéder au contenu du séminaire vous pouvez télécharger le PDF des slides /!\ 10.5 Mo -> Clic droit et "enregister sous..." et patience... :p

Bon code à tous !