Cet article s’adresse aux développeurs SharePoint ayant développés des webparts multilingue.
Il est de bonne pratique de localiser son application lorsque que l’on effectue un développement SharePoint, en effet cela facilitera la prise en charge d’une nouvelle langue par la suite.
Lorsque l’on développait pour SharePoint 2010 nous avions l’habitude de placer des fichiers ressources dans la ruche/config/resources (et puis d’effectuer un stsadm –o copyappbincontent ou bien de l’automatiser avec un timerjob lors des phases d’activations de fonctionnalités)
Ou alors on créait un élément de solution SharePoint vide, dans lequel on rajoutait nos fichiers de ressources en indiquant une cible de déploiement directement vers l’appglobalresources ( voir https://stackoverflow.com/questions/296003/deploy-a-resource-file-to-app-globalresource-folder-on-activation pour plus de détails)
Lors de la sortie de SharePoint Beta, puis RTM et des outils de développement, on s’est tous empressés (ou peut être que moi ?) de tester tout ce qu’on savait faire sous 2010 en 2013, pour voir si ça avait changé etc. Et on s’est tous cassés les dents sur une erreur de type The name ‘InitializeControl’ does not exist in the current context lors de l’utilisation de ressources dans un webpart visuel.
En fait la manière de concevoir des webparts visuels a apparemment changé avec les outils pour SharePoint 2013, ils sont construits de la même manière que les webparts visuels dans les solutions de type sandbox. Et si vous vous souvenez bien on a eu quelques soucis avec sous visual studio 2010.
L’update 1 est sorti, ça n’a rien changé, le march update de SharePoint 2013 non plus, l’update 2 non plus. Et puis la version finale des outils de développement pour SharePoint 2013 est sortie.
Et là surprise, si on refait le webpart à l’identique, on change de message d’erreur ! « the name « resource » does not exist in the current context ».
Après quelques essais j’ai fini par trouver un contournement propre au problème. Il suffit de créer un contrôle utilisateur dans un dossier lié au dossier hive/templates/controlstemplates, de créer un webpart classique, d’enregistrer le namespace comme sûr (faites-le sur l’élément de webpart) et de modifier le code pour ça dans le fichier de code du webpart.
public class WebPart1 : WebPart
{
private const string _ascxPath = @"~/\_CONTROLTEMPLATES/15/NomDuUserControl.ascx";
protected override void CreateChildControls()
{
Control control = Page.LoadControl(_ascxPath);
Controls.Add(control);
}
}
Votre solution devrait ressembler à cela à la fin.
Je pense que l’objectif de Microsoft à terme est de simplifier la vie des développeurs en ajoutant une vérification des ressources à la compilation mais force est de constater que ce n’est pas encore au point.
PS : je ne parlais tout au long de cet article que des ressources « web » de SharePoint, il y a aussi ce qu’on déployait dans hive/resources, pour les workflows notamment, ça a surement aussi évolué, mais je ne l’ai pas encore testé.