Archives mensuelles : août 2014

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!

Advertisements