Module - Forcer la mise a jour
Forcer la mise a jour d'un document qui n'est plus ghosté
19/05/2011
994 lectures
0 commentaire
5/5 (1 vote)
Dans un projet, il n'est pas rare d'utiliser une feature de provisioning (une feature permettant le déploiement en masse de pages layouts, images, javascript, css, etc..).
Une fois ces fichiers déployés sur votre environnement, ils sont accessibles via votre code pour vous permettre de faire votre propre design. De plus, une fois les fichier présents, ils sont toujours "vivants", rien ne vous empêche par exemple, d'aller récupérer votre fichier css dans la bibliothèque adéquate pour faire des modifications a la volée et changer le rendu de votre site. Jusque là , pas de soucis.
Mais que se passe-t-il lorsque vous déployez une mise a jour de votre wsp après avoir modifié votre fichier css via l’interface ?
Là , on se rend compte que les css, pages et autres documents que nous avons modifiés ne sont pas mis à jour par la feature ! La raison est simple, lors du déploiement de votre premier wsp, les éléments sont présents dans votre site (là où votre feature de provisioning les a placé) et dans le dossier 12. De plus, ces éléments sont ghostés. Quand un élément est ghosté, SharePoint fait le lien directement avec ceux présents dans le 12 et non ceux présents dans les listes sur le site. Mais une fois que vous avez modifié votre css via l'interface, le lien est changé et SharePoint pointe maintenant vers le fichier présent dans le site. Fichier qui n'est pas mis a jour lors de l'update de votre wsp vu que c'est celui sur le disque qui est mis à jour.
Cette situation a ses bons cotés comme ses mauvais, mais si vous voulez forcer la mise a jour des documents, il suffit d’ajouter le bout de code suivant en feature receiver.
Lors de l'activation de la feature, le code va récupérer l'ensemble des données du fichier elments associé qui sont de type module (le type utilisé pour uploader des fichiers. Voir le tuto de sébastien a ce sujet) pour les uploader "manuellement".
Tout d'abord, vérifiez la présence des 2 using suivants
Dans le feature receiver :
Classes a ajouter :
Une fois ces fichiers déployés sur votre environnement, ils sont accessibles via votre code pour vous permettre de faire votre propre design. De plus, une fois les fichier présents, ils sont toujours "vivants", rien ne vous empêche par exemple, d'aller récupérer votre fichier css dans la bibliothèque adéquate pour faire des modifications a la volée et changer le rendu de votre site. Jusque là , pas de soucis.
Mais que se passe-t-il lorsque vous déployez une mise a jour de votre wsp après avoir modifié votre fichier css via l’interface ?
Là , on se rend compte que les css, pages et autres documents que nous avons modifiés ne sont pas mis à jour par la feature ! La raison est simple, lors du déploiement de votre premier wsp, les éléments sont présents dans votre site (là où votre feature de provisioning les a placé) et dans le dossier 12. De plus, ces éléments sont ghostés. Quand un élément est ghosté, SharePoint fait le lien directement avec ceux présents dans le 12 et non ceux présents dans les listes sur le site. Mais une fois que vous avez modifié votre css via l'interface, le lien est changé et SharePoint pointe maintenant vers le fichier présent dans le site. Fichier qui n'est pas mis a jour lors de l'update de votre wsp vu que c'est celui sur le disque qui est mis à jour.
Cette situation a ses bons cotés comme ses mauvais, mais si vous voulez forcer la mise a jour des documents, il suffit d’ajouter le bout de code suivant en feature receiver.
Lors de l'activation de la feature, le code va récupérer l'ensemble des données du fichier elments associé qui sont de type module (le type utilisé pour uploader des fichiers. Voir le tuto de sébastien a ce sujet) pour les uploader "manuellement".
Tout d'abord, vérifiez la présence des 2 using suivants
Dans le feature receiver :
Classes a ajouter :

0 commentaires
Ajouter un commentaire