Mise à niveau des pages
Dernière modification : mardi 6 avril 2010
S’applique à : SharePoint Foundation 2010
Mises à niveau générales des pages
Microsoft SharePoint Foundation 2010 utilise une stratégie différente pour la mise à niveau d’une page selon qu’elle a été personnalisée ou non.
SharePoint Foundation effectue le suivi de la version de la définition de site par le biais de laquelle un site Web a été créé. Un site Web peut être mis à niveau s’il possède une définition de mise à jour qui convertit les fichiers de définition de site frontaux qui n’ont pas été personnalisés. Après le processus de mise à niveau, les références aux fichiers frontaux non personnalisés sont mappées à partir du répertoire antérieur au répertoire actuel, en l’occurrence :
%ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\
Tous les chemins d’accès des sites Web ne sont pas mis à niveau au moment de la mise à niveau initiale. Les définitions de site existantes qui n’ont pas de chemins de mise à niveau fonctionnent tout de même, mais continuent à pointer vers leurs pages d’origine. Par ailleurs, un site Web qui a été mis à jour peut toujours disposer de pages personnalisées de la version antérieure qui ont été stockées dans la base de données.
Pendant l’analyse du code et le rendu des pages, SharePoint Foundation détermine à quel site Web la page est associée, et par conséquent, la version des fichiers non personnalisés sur le serveur Web frontal. Les pages d’une version antérieure ne sont pas forcément compatibles avec les normes de la version actuelle. Ces pages s’exécutent en mode de compatibilité si le site n’a pas été mis à niveau, mais après l’application d’une définition de mise à niveau et la mise à niveau du site, SharePoint Foundation suppose que les pages sont totalement compatibles avec Microsoft ASP.NET 3.5. Cela signifie, par exemple, qu’elles possèdent un gestionnaire de composants WebPart si elles contiennent des zones WebPart, qu’elles disposent d’identificateurs (ID) de contrôle valides et qu’elles sont associées à une page maître.
Compatibilité des pages
Dans les versions antérieures de SharePoint Foundation, les pages personnalisées dans la base de données étaient analysées à l’aide de l’analyseur « Windows SharePoint Services », avec des tolérances différentes par rapport à l’analyseur ASP.NET. Si une page contient du langage de balisage mal formé, cela peut s’expliquer par le fait que même si la page fonctionne dans une version antérieure, elle risque de ne pas fonctionner dans ASP.NET et dans la version actuelle de SharePoint Foundation en raison des différences entre les analyseurs.
Le nouvel analyseur SharePoint Foundation résout un sous-ensemble de problèmes connus liés au balisage de page, notamment les suivants :
Les ID ne sont pas compatibles avec ASP.NET, par exemple lorsqu’un nom n’est pas valide, car l’ID commence par un chiffre ou un caractère non pris en charge, l’ID est une chaîne vide, ou l’ID n’est pas unique par rapport aux autres ID sur la page. Cette modification peut corrompre la page si le script côté client repose sur les anciens noms d’ID.
Des attributs connus ont été insérés dans la page par SharePoint Foundation (par exemple, __Preview,__Error,__Web PartId,WebPart) sont gérés par l’implémentation de l’interface IAttributeAccessor SharePoint sur les composants WebPart.
La suppression des attributs Trace.
L'ajout de directives appropriées pour l'enregistrement des balises comme <WebPart:WebPartZone> ou <SharePoint:Theme>.
SharePoint Foundation ne tente pas de résoudre les problèmes suivants de corruption des pages :
Attributs inconnus sur les contrôles.
Présence de balises <object runat=server>.
Présence d'expressions de liaison de données dans les attributs (<% ... %>).
SharePoint Foundation stocke un entier pour la version de chaque page personnalisée dans la base de données. Lorsqu’une page personnalisée est consultée, SharePoint en vérifie le numéro de version. Si le numéro de version correspond à une version antérieure qui n’a pas été mise à niveau, il résout les différents problèmes et met à jour la page en arrière-plan.
Pages d’application
SharePoint Foundation stocke les fichiers de mise en page dans un dossier indépendant du langage et configure automatiquement une redirection qui redirige les utilisateurs de l’emplacement /_layouts précédent vers l’emplacement actuel.
Les pages de mise en page sont en général adaptées pour utiliser une page maître qui est définie par l’intermédiaire de la propriété SPWeb.MasterUrl. Pour les définitions de site des versions antérieures, cette propriété doit faire référence à une page maître qui conserve l’apparence précédente.
Composants WebPart
Les composants WebPart des versions antérieures de SharePoint Foundation continuent à fonctionner dans la version actuelle, bien qu’ils puissent nécessiter quelques modifications dans leur configuration. Si vous créez une nouvelle application Web pour héberger une installation SharePoint Foundation, le fichier web.config de cette installation doit être mis à jour de manière à inclure les paramètres de contrôles sécurisés supplémentaires et les paramètres de stratégie de sécurité d’accès du code.
Bien que le niveau général des restrictions de sécurité d’accès du code reste le même dans SharePoint Foundation, les fichiers de stratégie sont modifiés pour qu’ils demeurent compatibles avec ASP.NET. Pour cette raison, il peut s’avérer impossible de réutiliser les fichiers de stratégie de sécurité d’accès du code d’une version antérieure dans la version actuelle de SharePoint Foundation. La meilleure option consiste à faire une copie du fichier wss_minimaltrust.config de la version actuelle et à ajouter de façon incrémentielle les autorisations nécessaires.
Pour plus d’informations sur la mise à niveau des composants WebPart, voir Mise à niveau des composants WebPart.
Voir aussi
Concepts
Mise à niveau des composants WebPart