Récemment, nous avons traversé un grave problème dans la ferme de production avec les types de contenu. J'aimerais d'abord expliquer le contexte de ce problème.
Nous avons une belle fonctionnalité de travail pour les types de contenu Installation dans la production et les exploitations d'essais. Nous avons développé et déployé (à l'aide de WSPS) cette fonctionnalité SharePoint dans Visual Studio. Nous utilisons le Publishing Pages à l'aide de la mise en page de la page et des types de contenu pour aider à des éditeurs de contenu pour publier rapidement les pages Web. Malheureusement, certains types de contenu et des colonnes de sites ont été mises à jour / ajoutées manuellement par certaines personnes de la production, de sorte que chaque fois que je (développeur) apporte quelques modifications aux types de contenu existants (à l'aide de Visual Studio et activation / désactivation / désactivation), SharePoint supprime un ou deux colonnes (pendant l'activation / la désactivation des fonctionnalités) des types de contenu; ou les colonnes qui n'ont pas été ajoutées de manière optimale. Je pense que la meilleure pratique consiste à mettre à jour les types de contenu à l'aide de Visual Studio.
Maintenant, je souhaite que les colonnes de sites ne soient pas supprimées des types de contenu lors de l'activation / de la désactivation des fonctionnalités.
Remarque: Notre fonctionnalité pour l'activation / la désactivation du type de contenu ne contient aucune dépendance d'activation dans la fonctionnalité.xml
3 Réponses :
Mise à jour des types de contenu est toujours l'une des parties sous-développées de SharePoint, ce qui provoque parfois des problèmes, en particulier dans les scénarios de déploiement de contenu.
La meilleure chose dans votre cas serait d'éviter de toujours éviter de modifier les types de contenu à la main (à l'aide de l'UI)
Chaque fois que vous installez le type de contenu, assurez-vous de supprimer le précédent, puis d'installer le nouveau. (Parfois, ce n'est pas possible en raison des pages déjà créées de celui-ci).
C'est encore plus de chaos si vous avez plus de 10 000 sites et sous-sites.
Je suis d'accord. Ce qui se passe, c'est que si vous mettez à jour le type de contenu, les modifications ne sont pas propulsées dans tous les sites, sous-titre. Dans ce cas, nous pouvons utiliser un outil court pour itérer et faire les changements
Je pense que je préférerais aller avec une fonctionnalité séparée (à l'aide du récepteur de fonctionnalités) pour mettre à jour des trucs pour nous.
Qu'en est-il de plusieurs environnements de déploiement, vous les mettrez donc à la mettre à jour à la main puis exécutez votre outil, dans chaque environnement ... Je suis d'accord avec Styler gratuit ici ... Votre suggestion est absurde.
Sur la base de tous ces facteurs, ma suggestion serait de:
• Créez deux fonctionnalités: une pour le balisage d'origine et une pour apporter des modifications. (Ou vous pouvez les mettre dans la même fonctionnalité; Je veux juste différencier l'endroit où vous faites quoi.)
• La fonctionnalité d'origine doit contenir la CAML pour les colonnes de site et les types de contenu. Cela garantit que les identifiants ont été attribués à l'avance et restent constants.
• Si vous souhaitez mettre à jour une colonne Site en modifiant presque quelque chose à ce sujet, à l'exception de son type de champ, utilisez-le un récepteur de fonctionnalités. En faisant cela, vous pouvez appeler la méthode de mise à jour et passer dans un booléen indiquant si vous souhaitez que tous les actifs existants du site qui héritent de mettre à jour (quelque chose que vous ne pouviez pas faire via le CAML.)
• Vous pouvez également ajouter une colonne de site existante (que vous avez provisionnée via la fonctionnalité CAML) à un type de contenu existant (qui a été provisionné via la fonction CAML). Ceci est utile si la colonne ne faisait pas partie de ce type de contenu avant, etc.
• Dans un scénario comme celui que je viens de mentionner dans la dernière balle, il est nécessaire de désactiver et de réactiver la fonction CAML (pour approvisionner les nouveaux actifs) avant d'appeler votre récepteur de fonctionnalité. Qu'est-ce que cela signifiera pour le site? Étant donné que toutes les colonnes de site et tous les types de contenu dans les listes du site utilisent les mêmes identifiants que ceux provisés dans la racine de collecte de sites, supprimer son parent de la collection de sites ne changera pas cela. Cela pourrait le laisser orphelinement temporairement (c'est-à-dire qu'il n'y aura aucune relation entre cet élément et un élément de la racine de la collection de sites, mais cela fonctionnera de la même manière qu'elle a toujours, car elle est vraiment une copie totalement fonctionnelle de l'article d'origine) Jusqu'à ce que vous réactivez la fonctionnalité qui met l'élément dans la collection de sites. C'est comme si les parents partent en vacances lorsque vous désactivez la fonctionnalité et revenez à la maison lorsque vous activez à nouveau la fonctionnalité.
Vous avez le choix en ce qui concerne la manière dont vous entretenez le CAML et le récepteur de fonctionnalités, car vous avez deux scénarios: collections de site existantes et neufs.
• Vous pouvez créer une stratégie que chaque fois que vous écrivez du code dans votre récepteur de fonctionnalité pour mettre à jour une colonne de site ou un type de contenu, vous devez également modifier votre CAML. Cela signifierait que chaque fois que vous avez activé la fonction CAML dans une collection de sites "frais", la CAML serait à jour et exacte; Il n'y aurait pas besoin d'exécuter la fonctionnalité "Updater". (Dans votre récepteur de fonctionnalité, vous devez vous assurer que vous vérifiez une vérification supplémentaire pour vous assurer qu'une colonne de site n'appartient pas déjà à un type de contenu avant de l'ajouter, etc. Si le changement est déjà en place avant que le code s'exécute avant.) Cette approche signifie que vous devez uniquement exécuter une fonctionnalité lors de la création d'une nouvelle collection de sites, mais cela signifie également que vous maintenez des modifications à deux endroits: dans votre récepteur de fonctionnalité pour modifier les sites existants et dans votre CAML pour de nouveaux sites. C'est une approche plus propre, mais contient également un élément de redondance, qui laisse toujours de la place pour une erreur humaine.
• L'autre approche consiste simplement à supposer que chaque fois que la fonction de base CAML est activée, vous allez toujours exécuter le récepteur de fonction. Cette approche dit que la seule fois que vous modifiez le CAML consiste à ajouter une nouvelle colonne de site ou nouveau type de contenu; Sinon, toutes les modifications se produisent dans le récepteur de caractéristiques. Cette approche réduit la redondance, mais signifie également que votre code du récepteur de fonctionnalité pourrait être assez grand avec tous vos changements au fil du temps, et cela pourrait laisser votre CAML comme très «héritage» au fil du temps.
Mon approche actuelle du déploiement de types de contenu consiste à faire autant que possible à l'aide du code plutôt que de CAML. De cette façon, il est facile de contrôler pleinement la logique des mises à jour, y compris en veillant à ce que les modifications apportées manuellement ne causent pas de conflits. J'ai la structure définie comme des attributs sur une interface que j'utilise également pour l'accès à la liste fortement tapée, mais il y a plusieurs autres moyens de le faire.
La seule pièce qui n'est pas disponible dans l'API est définie d'un identifiant de type de contenu spécifique, vous devez donc avoir un fichier CAML pour cela, mais c'est un fichier petit / simple, n'essaie pas de faire des mises à jour et est réservé uniquement à partir d'une fonctionnalité qui exécutera également le code de mise à jour.
Désolé je ne peux pas vous aider - vous avez une bien meilleure chance de trouver un expert SharePoint chez SharePoint
merci greg! Je vais poser la même question là-bas, aussi
Je ne sais pas si cette URL ait été correcte, mais le site actuel STACKEXChange pour SharePoint Questions est SharePoint.stackexchange.com