Archives de catégorie : Solutions de ferme

3 choses que chaque programmeur devrait savoir

Introduction

Dans mes tâches de tous les jours, je dois modifier régulièrement du code et bien évidemment il y a des cas où on se dit vraiment « WTF? ».  Dans ce billet, je vais vous présenter quelque points à considérer afin d’améliorer la qualité de votre code et ainsi réduire le nombre de WTFs/minute lorsque vos collègues vous relirons.

Un commentaire sur les commentaires!

Assurez-vous que vos commentaires clarifient votre code et qu’il ne le rende pas plus obscur. Ajouté uniquement des commentaires pertinents expliquant ce que le code est censé accomplir. Vos commentaires d’en-tête devraient donner à n’importe quel programmeur assez d’information pour utiliser votre code sans avoir à le lire, tandis que vos commentaires au niveau des lignes devraient aider le développeur suivant à le corriger ou à le modifier. Comme avec toute autre forme d’écriture, il y a une habileté à écrire de bons commentaires et une grande partie de la compétence consiste à savoir quand ne pas les écrire.

À éviter :

'Instancie un nouveau dataset
Dim ds As New System.Data.DataSet

'Retourne la liste
Return listXYZ

Ne pas ignorer les erreurs!

Ignorer une erreur n’est pas une stratégie gagnante pour avoir du code solide. En fait, c’est tout simplement de la paresse. Peu importe la probabilité que vous pensez qu’une erreur se retrouve dans votre code, vous devriez toujours la vérifier et toujours la retourner. Vous ne gagnez pas de temps si vous ne le faites pas. Vous conservez des problèmes potentiels pour l’avenir.

À éviter :

try {
    // ...do something...
}
catch (...) {} // ignore errors

N’ayez pas peur de briser des choses!

Tout le monde a sans aucun doute travaillé sur un projet où le code était de qualité douteuse. Le système est mal architecturé et changer une chose vient toujours en briser une autre. Chaque fois que quelqu’un doit ajouter un module, l’objectif est de changer le moins de chose possible et de se croiser les doigts que ça ne plante pas. Bref, c’est l’équivalent de jouer une partie de Jenga.

N’ayez pas peur du code. Investir le temps de refactoriser le code va se payer plusieurs fois au cours du cycle de vie de l’application. Un avantage supplémentaire est que l’expérience de votre équipe face au système vous rend un peu plus experts en sachant comment il devrait fonctionner. En plus, travailler sur un système que vous détestez n’est pas la façon dont tout le monde devrait avoir à passer leur temps.

Comment récuperer le code source de vos projets SharePoint perdu à partir d’un WSP?

Introduction

Un de mes collègues a récemment perdu une partie de son code source suite à un problème technique avec un poste virtualisé. Il n’avait pas eu le temps d’archiver le code dans le gestionnaire de code source et tout ce dont il disposait était le code compilé (WSP). Après avoir essayé de recréer sont code à partir de rien, il s’est résolu à venir me voir pour trouver une solution à sont problème.

Dans ce billet nous allons voir comment il est possible de recréer un projet SharePoint à partir d’un fichier WSP et si requis de dé-compiler les DLL d’un projet.

Recréer un projet SharePoint à partir d’un WSP

Pour importer un fichier .wsp

  1. Dans Visual Studio, dans la barre de menus, choisissez Fichier, Nouveau, Projet pour afficher la boîte de dialogue Nouveau projet.  Si votre interface IDE est définie pour utiliser les paramètres de développement Visual Basic, dans la barre de menu cliquez sur Fichier, puis Nouveau Projet.

  2. Développez le nœud SharePoint sous Visual C# ou Visual Basic,

  3. Choisissez le modèle Importer le package de solution SharePoint dans le volet Modèles, puis cliquez sur OK.

    L’Assistant Personnalisation de SharePoint s’affiche.

  4. Dans la page Spécifier le site et le niveau de sécurité pour le débogage, spécifier un site existant.

  5. Dans la section Quel est le niveau de confiance de cette solution SharePoint ?, sélectionner une des deux options.

  6. Dans la page Spécifier la nouvelle source de projet, accédez à l’emplacement du système où vous avez stocké le fichier .wsp, puis cliquez sur le bouton Suivant.

    123012_2133_importingsh6

  7. Dans la zone Sélectionner les éléments à importer, sélectionner tous les éléments que vous voulez récupérer, puis cliquez sur Terminer.

    123012_2133_importingsh8

    Une fois l’opération d’importation terminée, un nouveau projet appelé WspImportProject1 dans lequel figure un dossier nommé Champs est alors créé.  Ce dossier contient les colonnes de site personnalisée.

    123012_2133_importingsh9

Cette opération vous permet de recréer un projet avec les différents artefacts. Cependant, certains éléments comme les DLL peuvent se retrouver dans les « éléments non importés ».

Décompiler les DLL

Ensuite, pour les éléments qui n’ont pas pu être importés, il est possible de dé-compiler les DLL à l’aide d’un outil comme ILSpy ou Reflector :

Capture

Vous pourrez ensuite, extraire le code et recréer vos classes dans votre projet.

Conclusion

Bien évidemment, ça ne permet pas de reproduire exactement le projet dans le même état initial mais on peut tout de même récupérer le code source perdu. Idéalement, pensez à archiver vos sources régulièrement dans votre gestionnaire de code source afin d’éviter de vous retrouver dans cette fâcheuse situation.

Les meilleures pratiques d’accès aux données avec le modèle objet SharePoint

J’ai dernièrement publié un billet intitulé : « Les meilleures pratiques d’accès aux données avec le modèle objet SharePoint » sur le blog de Technologia.

En voici un aperçu :

Introduction au langage CAML (Collaborative Application Markup Language)

Le CAML est un langage XML utilisé dans SharePoint pour définir les champs et les affichages des sites et des listes. On peut aussi effectuer une requête en CAML pour accéder à du contenu SharePoint avec l’aide de l’objet SPQuery.

  CAML   Le CAML est sensible à la case

Objectif

Optimiser l’accès au contenu SharePoint afin d’améliorer les performances et de respecter les bonnes pratiques de développement.

L’objet SPQuery

  • Exécute des requêtes sur les données efficacement;
  • Utilise le langage CAML pour spécifier le SELECT, le WHERE, le ORDER BY et le GROUP BY de l’instruction SELECT SQL sous-jacente;
  • S’adresse à un objet SPList précis;
  • Est la bonne pratique à utiliser lorsqu’on effectue une requête sur une liste.

Utilisation de l’objet SPQuery

Les objets SPQuery peuvent causer des problèmes de performance quand ils retournent un grand nombre de résultats.

Les recommandations suivantes vous aideront à optimiser votre code de manière à limiter l’impact sur la performance quand vos requêtes retournent un trop grand nombre de résultats :

  • Ne pas utiliser un objet SPQuery illimité (unbounded);
  • L’utilisation d’un objet SPQuery sans spécifier une valeur à la propriété RowLimit ne fonctionnera pas de manière efficace et va échouer sur de grandes listes. Il est recommandé de spécifier un RowLimit entre 1 et 2000;
  • Utilisez des champs indexés.

Si vous effectuez une requête sur un champ non indexé, la requête sera bloquée chaque fois que celle-ci retourne plus d’éléments que le seuil de requête (dès qu’il y aura plus d’éléments dans la liste que dans le seuil de requête). Il est recommandé de spécifier un RowLimit à une valeur qui est plus petite que le seuil de requête.

Pour conclure

Que vous utilisiez le modèle objet serveur (SSOM) ou un modèle de programmation client (CSOM/JSOM), le CAML est indispensable pour réaliser des requêtes performantes en plus de respecter les bonnes pratiques de développement.

Retrouvez l’article complet ici.

SharePoint 2016 – Les types de contenu, les colonnes de site ainsi que d’autres éléments de sites sont finalement multilingue!

Les éléments suivants prennent maintenant en charge le multilingue dans SharePoint 2016 Preview (et les versions suivantes) :

  • Titre d’un site
  • Description d’un site
  • Titre d’une liste
  • Description d’une liste
  • Nom d’un type de contenu
  • Description d’un type de contenu
  • Titre d’une colonne de site
  • Description d’une colonne de site

Ceci avait été annoncé pour Office 365 en 2014 cependant ce n’était pas disponible pour les versions On-Premise. L’article est donc encore une excellent source de référence.

Dans l’exemple suivant je vais modifier la description d’un site pour la culture « en-US » et « fr-FR » avec du PowerShell.

Avant l’exécution (Affichage en-US) :

MultilangualDescriptionBefore

MultilangualDescriptionPowerShell


$web = get-spweb http://sp2016preview
$web.DescriptionResource.SetValueForUICulture("en-US", "Support multilangual")
$web.DescriptionResource.SetValueForUICulture("fr-FR", "Supporte le multilangue")
$web.Update()
$web.DescriptionResource.GetValueForUICulture("en-US")
Support multilangual
$web.DescriptionResource.GetValueForUICulture("fr-FR")
Supporte le multilangue

Après l’exécution (Affichage en-US) :

MultilangualDescriptionAfter

Pour l’instant, nous sommes un peu dans le néant en ce qui concerne les nouveautés au niveau de l’API de SharePoint alors je n’ai pas eu le choix de d’ouvrir la DLL avec Reflector. Il est possible de voir que la propriété « DescriptionResource » est disponible sur plusieurs éléments :

DescriptionResourceClient

Maintenant, les fonctions pour obtenir ou modifier cette propriété :

GetValueForUICulture

SetValueForUICulture

De plus, les fonctions se retrouvent autant au niveau de Microsoft.SharePoint.DLL que dans Microsoft.SharePoint.Client.DLL.

Ceci permet l’appel de ces fonctions avec du code serveur ainsi qu’avec du code client (Ex : CSOM)

Conclusion

Cette amélioration est des plus apprécié pour les entreprises qui désirent offrir une interface multilingue sans avoir à dupliquer les sites, les colonnes, les types de contenu, etc…

Cheat sheet pour les développeurs SharePoint

Introduction

Règle générale, je vous propose des billets sur des problèmes rencontrés lors de mes expériences avec SharePoint. Cette fois-ci, je vous propose quelque chose de différent avec une Cheat Sheet spécifique pour les développeurs SharePoint. Le concept de Cheat Sheet existe depuis longtemps et présente généralement de la façon la plus concise possible, les grandes lignes d’un logiciel ou d’un langage informatique.

Pourquoi une Cheat Sheet ?

Lorsqu’on forme des développeurs SharePoint, on a beau leurs donner plusieurs trucs, il y a tellement de chose à savoir que souvent ils ont de la difficulté à retrouver toute l’information qu’ils recherchent.

C’est alors qu’on se fait poser plusieurs questions du genre :

  • Quel est le Token pour avoir le URL de la collection de site dans un Custom Action?
  • Comment je peux éviter d’hardcoder le URL absolue de mon site SharePoint?
  • Comment je peux récupérer le GUID de ma liste?
  • Comment je peux supprimer une WebPart qui a brisé ma page?
  • Comment je peux afficher un formulaire dans une boite de dialogue?
  • etc…

Si vous vous posez souvent ce genre de question, je vous inviter a télécharger et imprimer ma cheat Sheet.

telecharger-bouton

Voici un bref aperçu :

cheetSheetPreviewEffect

N’hésiter pas à commenter si vous avez des suggestions!

Personnaliser vos sites SharePoint 2013 avec le Client Side Rendering (CSR) et le JS Link

Introduction

Effectuer des personnalisations dans l’interface utilisateur de SharePoint a toujours été un défi pour bien des développeurs. Dans les versions 2007 et 2010, on utilisait majoritairement le XSLT pour faire des personnalisations bien que c’était relativement complexe à s’y familiariser. D’autres utilisaient des WebParts de type Éditeur de contenu pour effectuer des modifications JavaScript directement dans une page et dans ce cas la difficulté est de trouver une « poignée » pour appliquer les modifications sur un élément précis. La fonctionnalité JSLink est arrivé dans SharePoint 2013 pour simplifier la vie aux développeurs en leur permettant de faire des personnalisations avec des langages qu’ils connaissent déjà : HTML, JavaScript et CSS. Grâce à cette fonctionnalité, on peut contrôler via un fichier JavaScript le rendu visuelle des éléments suivant :

  • Champ
  • Élément
  • Formulaire de liste
  • Vue
  • WebPart

XSL/XSLT vs Client Side Rendering

Le tableau ici-bas résume bien les différences entre les deux fonctionnalités :

XSL/XSLT Client Side Rendering
Performance
  • Plus rapide lorsqu’il y a un grand nombre d’éléments à afficher.
  • Aucune charge additionnel dans le navigateur.
  • Plus lent lorsqu’il y a un grand nombre d’éléments à afficher.
  • La vitesse du navigateur client peut avoir un impact sur la performance.
  • Réduit la charge du serveur.
Complexité
  • Langage complexe à apprendre initialement.
  • Difficile à déboguer (Souvent par essaie-erreur).
  • Temps de développement plus grand.
  • Facile de déboguer du JavaScript, HTML et CSS avec les navigateurs modernes.
  • Temps de développement réduit.
Flexibilité
  • Limité aux fonctions XSLT 1.0 pour SharePoint 2010 et 2013.
  • Limité pour faire un rendu visuel complexe.
  • Très efficace pour faire des opérations coûteuse (ex : Count dans une vue).
  • Permet de cibler les personnalisations sur une vue, un champ, une WebPart, etc…
  • Possibilité d’utiliser des plugins (ex : JQuery).
  • Très adapté pour faire un rendu visuel complexe.
  • Inefficace pour faire des opérations coûteuses (ex : Count dans une vue).
Compatibilité
  • Indépendant du navigateur.
  • Supporté dans SP2010 et SP2013.
  • Fonctionne même si le JavaScript est désactivé dans le navigateur.
  • Génère du contenu statique qui est bien interprété par les robots d’indexation.
  • Adapté pour des sites publiques.
  • Dépendant du navigateur.
  • Supporté dans SP2010 et SP2013
  • Requiert que le JavaScript soir activé dans le navigateur.
  • Génère du contenu dynamique qui n’est pas bien interprété par les robots d’indexation.
  • Non-adapté pour des sites publiques.

Comment configurer le JSLink?

Pour référencer vos fichiers dans la propriété JSLink vous pouvez spécifier un jeton de remplacement (Token) ainsi qu’un séparateur (|) si vous avez plusieurs fichiers.

Les jetons disponibles sont les suivants :

  • ~site : correspond au URL du site Web courant.
  • ~sitecollection : correspond au URL de la collection de site parent du site Web courant.
  • ~layouts : correspond au dossier « _layouts/15 » de la web application.
  • ~sitelayouts – correspond au dossier layouts du site courant (ex : site/monsite/monsoussite/_layouts/15).
  • ~sitecollectionlayouts : correspond au dossier layouts de la collection de site courante (Ex:  /sites/monsite/_layouts/15).
  • ~sitelayouts – correspond au dossier layouts du site courant (Ex: /site/monsite/monsoussite/_layouts/15).

En utilisant ces jetons avec le séparateur on peut donc référencer plusieurs fichiers de scripts dans le JSLink.

Ex : ~site/style library/­monScript1.js|~sitecollection/style library/monScript2.js.

On peut spécifier la propriété JSLink en utilisant ces méthodes :

  • PowerShell
  • Code serveur C#/VB en utilisant l’API
  • Code serveur déclaratif XML
  • Interface utilisateur

Pour simplifier ce billet, je vous propose la méthode utilisant l’interface utilisateur :

jslink_link

Pour plus de détail sur les autres méthodes permettant de spécifier la propriété JSLink, je vous recommande le billet de Tobias Zimmergren.

Fonctionnement technique

À l’intérieur de ces fichiers, le JavaScript est utilisé pour « overrider » :

  • la manière dont les données sont affichés
  • le contenu à afficher

Voici un exemple de code permettant de modifier la valeur d’un champ dans une vue :

// Créer un namespace pour la fonction afin d'éviter des collisions avec les autres fonctions
var sharepointerie = sharepointerie || {};

(sharepointerie.CustomizeFieldRendering = function () {

// Initialise les variables pour overrider les objets
 var overrideCtx = {};
 overrideCtx.Templates = {};

 /*
 * Force la valeur "SharePointerie" dans le titre de tous les éléments.
 */
 overrideCtx.Templates.Fields = {
 'LinkTitle': { 'View' : 'SharePointerie' }
 };

 /*
 * Enregistre l'override du template.
 */
 SPClientTemplates.TemplateManager.RegisterTemplateOverrides(overrideCtx);
})();

Techniquement, on construit un objet qui sera ensuite utilisé afin d’enregistrer l’override du template. L’objet « overrideCtx » peut ensuite interagir avec ces propriétés :

  • View
  • Header
  • Body
  • Footer
  • Group
  • Item
  • Fields
  • OnPreRender
  • OnPostRender

Dans l’exemple on utilise la propriété Fields avec ce format :

overrideCtx.Templates.Fields = {NomDuChamp: {Porté : Override}}

  • NomDuChamp : Le nom interne du champ que l’on veut overrider.
  • Porté : Les choix possibles « View », »DisplayForm », »EditForm », et « NewForm » permettent de spécifier l’endroit ou l’on veut faire l’override.
  • Override : Contient une chaîne HTML ou une fonction à exécuter à l’intérieur de tags « <#= #> ».

Résultat (avant l’ajout du CSR) :

jslink_technique_avant

Résultat (après l’ajout du CSR) :

jslink_technique_apres

Des exemples concrets

1) Limiter la taille du texte dans le champ « Corps » d’une liste d’annonces

Cet exemple de code, réalisé par Muawiyah Shannak, permet d’afficher un résumé du corps d’une annonce et d’afficher la version intégrale dans une infobulle.

Pour déployer la solution :

  1. Télécharger le fichier CSR.
  2. Ajouter le fichier sous /Style Library/.
  3. Créer une liste de type Annonces
  4. Créer ou modifier une vue afin d’afficher le champ Corps.
  5. Modifier la page contenant la List View WebPart.
  6. Aller dans les propriétés de la WebPart et ajouter le fichier JSLink (~sitecollection/Style%20Library/SubstringLongText.js) dans la propriété Lien Js (JSLink) sous l’onglet Divers
  7. Cliquer sur Appliquer et quitter l’édition de la page.

Résultat (avant l’ajout du CSR) :

jslink_limite_texte_avant

Résultat (après l’ajout du CSR) :

jslink_limite_texte_apres

2) Ajouter des onglets dans un formulaire

Cet exemple de code, réalisé par Muawiyah Shannak, permet d’utiliser JQuery Tabs pour afficher des onglets dans un formulaire.

Pour déployer la solution :

  1. Télécharger le fichier CSR.
  2. Ajouter le fichier sous /Style Library/.
  3. Créer une liste personnalisé
  4. Ajouter des colonnes à la liste
  5. Modifier l’objet tabsObj selon vos besoin.
  6. Créer une nouvelle vue contenant le champ Lien
  7. Modifier les pages « newform » et « editform » de la liste
  8. Aller dans les propriétés de la WebPart et ajouter le fichier JSLink (~sitecollection/Style%20Library/Tabs.js) dans la propriété Lien Js (JSLink) sous l’onglet Divers
  9. Cliquer sur Appliquer et quitter l’édition de la page.

Résultat (avant l’ajout du CSR) :

jslink_tabs_avant

Résultat (après l’ajout du CSR) :

jslink_tabs_apres

Points à faire attention

  • Il peut y avoir des conflits avec le CSR si vous utilisez la fonctionnalité « Minimal download strategy ». Pour corriger ce problème consulter ce billet.
  • Le code de vos fonctions CSR ne devrait pas être défini dans le Namespace globale.
  • Le nom interne des colonnes est utilisé dans le code JavaScript des fonctions CSR alors favoriser des noms de colonnes sans espaces et sans caractères accentués.
  • Le CSR, contrairement au XSLT, dépend du navigateur alors assurez-vous de tester dans plusieurs navigateurs.

Conclusion

Pour conclure, le CSR comporte plusieurs avantages au niveau de la flexibilité et de la complexité comparativement au XSLT. Cependant, il vient aussi avec certaines lacunes en lien avec la performance et la compatibilité. Il y a donc énormément de potentiel à utiliser le CSR pour vos personnalisations (Validations, AJAX, etc…) mais comme il y a des limitations, je crois que le XSLT va continuer d’exister en parallèle. Je vous invite donc à l’essayer et à me donner vos commentaires!

Références

Voici quelques liens pour approfondir vos connaissance sur le CSR / JSLink.

Exemples de codes CSR réalisé par Muawiyah Shannak

Perfomance de l’utilisation du CSR via le JSLink

5 faits concernant l’utilisation du JSLink

Comment : personnaliser un type de champ à l’aide de rendu côté client

Comment : personnaliser le mode Liste dans les apps pour SharePoint à l’aide du rendu côté client

Introduction au CSR par Ross Bradbrook

Bon point de départ sur l’utilisation de l’API CSR

Conversion de solutions de ferme SharePoint 2010 vers SharePoint 2013

De retour sur mon blog après des vacances bien mérité. On m’attendait de pied ferme pour évaluer avec d’autres collaborateurs la conversion de plusieurs solutions de ferme SharePoint 2010 vers SharePoint 2013. Je vais donc tenter, dans ce billet, de vous aider à identifier et à corriger plus rapidement d’éventuelles problématiques de conversion.

Conversion des Requête de contenu (Content Query WebPart) SharePoint 2010 vers SharePoint 2013

Dans les composantes contenant des Requêtes de contenu (Content Query WebPart), nous sommes tombés sur une SharePointerie lors de la conversion. À première vue, après avoir effectué la conversion vers SharePoint 2013 de cette composante avec Visual Studio 2013, le code compile!

conversion_sp2013_Upgrade

On est prêt pour aller en PROD ? Pas tout à fait! J’ai alors déployé la composante et lorsque j’ai essayé de la tester alors j’ai obtenu un message d’erreur lors de l’affichage de la WebPart.

Dans la plupart des Requête de contenu à convertir vers 2013, l’aspect visuel a été modifié afin de fournir une expérience utilisateur plus riche. Pour s’y prendre, le lien vers les fichiers XSL par défaut a été modifié dans le XML du fichier *.webpart.

Exemple d’un fichier *.webpart SharePoint 2010

<webParts>
<webPart xmlns="http://schemas.microsoft.com/WebPart/v3">
 <metaData>
   ...
 </metaData>
 <data>
 <properties>
   <...>
   <property name="MainXslLink" type="string">/Style Library/XSL Style Sheets/POC.SHP.WebPart.Main.xsl</property>
   <property name="ItemXslLink" type="string">/Style Library/XSL Style Sheets/POC.SHP.WebPart.Item.xsl</property>
   <...>
 </properties>
 </data>
 </webPart>
</webParts>

J’ai alors tenté de retirer les liens XSL afin d’utiliser l’affichage par défaut de la Requête de contenu (Content Query WebPart) et le tout s’est affiché mais sans inclure l’aspect visuel personnalisé. On s’est donc dit que le URL vers le fichier XSL n’était pas bon. Je me suis alors rappelé que dans SharePoint 2013, il faut maintenant spécifier dans le URL le dossier /15/ (Aussi appelé Hive) avant le /Style Library/.

Exemple d’un fichier *.webpart corrigé pour SharePoint 2013

<webParts>
<webPart xmlns="http://schemas.microsoft.com/WebPart/v3">
 <metaData>
   ...
 </metaData>
 <data>
 <properties>
   <...>
   <property name="MainXslLink" type="string">/15/Style Library/XSL Style Sheets/POC.SHP.WebPart.Main.xsl</property>
   <property name="ItemXslLink" type="string">/15/Style Library/XSL Style Sheets/POC.SHP.WebPart.Item.xsl</property>
   <...>
 </properties>
 </data>
 </webPart>
</webParts>

Pourquoi est-ce ainsi?

Dans SharePoint 2013, il est possible d’installer à la fois des solutions SharePoint 2010 et 2013. Ceci est supporté par le fait qu’il y a deux dossiers virtuel, un pour le SP2010 (14) et l’autre pour les SP2013 (15).

Si votre code SharePoint 2010 contient des références vers /_layouts/ ou /Style Library/, il vous faudra les mettre à jour respectivement pour /_layouts/15/ ou  /15/Style Library/ afin que le chemin soit résolus correctement lors de l’utilisation de la solution dans SharePoint 2013.

Le tableau ici-bas présente les différences des chemins :

SharePoint 2010 SharePoint 2013
/Style Library/scripts/jquery.min.js /15/Style Library/scripts/jquery.min.js
/_layouts/images/test.jpg /_layouts/15/images/test.jpg

Conversion des Visual WebParts SharePoint 2010

Lors de la conversion des composantes de ferme de type Visual Web Part nous sommes tombé sur une autre SharePointerie. Cependant, lorsqu’on connait la recette vue précédemment ça devient un peu plus évident.

Lorsque j’ai ajouté la Visual WebPart dans ma page, ça à tout simplement fait exploser la page et SharePoint m’a proposé la page de maintenance afin de supprimer la WebPart en erreur. C’est très gentil de sa part, mais ce n’est pas très utile pour diagnostiquer un problème. Alors, j’ai décidé de m’attacher au code et de déboguer la méthode CreateChildControls qui est lancé au tout début lors de l’affichage de la Visual WebPart.

C’est alors que j’ai eu ce message d’exception : The file ‘/_controltempates/…/…UserControl.ascx’ does not exist.

conversion_sp2013_debug_visualwebpart

Pourtant mon fichier *.ascx est bien déployé dans le dossier :

conversion_sp2013_15_visualwebpart

J’ai alors appliqué la même recette que vue précédemment en ajoutant le /15/ dans le URL tout de suite après le /_controltemplates/ et bien sûr ça a bien fonctionné :

conversion_sp2013_debug_passed_visualwebpart

Il faut comprendre que le commentaire dans le haut de la constante _ascxPath indique : Visual studio might automatically update this path when you change the Visual WebPart.

Cependant, Visual Studio ne l’a pas fait lors de la conversion de SharePoint 2010 vers SharePoint 2013 ! J’ai ouvert un billet sur le site de Visual Studio User Voice alors n’hésiter pas à aller voter pour celui-ci. Qui sais, un jour Visual Studio sera peut-être amélioré et cette SharePointerie n’existera plus!

Conclusion

En conclusion, si votre code SharePoint 2010 contient des références vers /_layouts/, /_controltemplates/ ou /Style Library/ vous aurez à modifier vos URL pour que ça fonctionne dans SharePoint 2013. Il ne s’agit pas d’une liste exhaustive des problématiques de conversion que l’on peut retrouver mais c’est un bon point de départ. De plus, lorsque l’on connait la recette pour corriger les problèmes c’est beaucoup plus simple et on perd beaucoup moins de temps.

Avez-vous effectué des conversions SharePoint 2010 vers SharePoint 2013 ? Est-ce que vous avez rencontré des SharePointeries? N’hésitez pas à commenter pour lancer la discussion!