J'ai plusieurs composants WebPart personnalisés que je suis en train de déployer en production. Au cours de ce processus, j'ai trouvé une poignée de petites choses qui doivent être peaufinées dans les différentes parties. Pour déployer le nouveau code, je crée un nouveau package de solution, désactive puis supprime les fonctionnalités, retire puis supprime la solution, puis recommence dans l'ordre inverse avec le nouveau package. Inutile de dire que cela peut prendre beaucoup de temps. Est-il nécessaire de supprimer complètement un composant WebPart pour le mettre à niveau, ou est-il possible de mettre à niveau un composant/composant/une solution Web?Mise à niveau de composants WebPart SharePoint
Répondre
Cela dépend de ce qui change exactement dans votre solution. Il existe une opération stsadm spécifiquement destinée à la mise à niveau des solutions, mais elle comporte certaines limitations en ce qui concerne les éléments pris en compte, notamment la suppression des anciennes fonctionnalités et l'ajout de nouvelles fonctionnalités. Cependant, si toutes vos nouvelles fonctionnalités existent dans les DLL Webpart, l'exécution d'une mise à niveau de solution déploiera vos modifications sans que vous ayez à faire quoi que ce soit d'autre.
Nous avons utilisé les extensions Visual Studio 2008 pour Windows SharePoint Services 3.0, v1.3 - Mar 2009 CTP. Cela nous a donné quelques problèmes, mais quand on s'y habitue et qu'on s'assure de faire les choses dans le bon ordre, cela fonctionne.
Cet outil automatise la retact/supprimer/deploy/activer .... travail.
Une autre chose que nous essayons de faire est de garder aussi peu de fonctionnalités dans les parties Web que possible. Déplacez ce qui peut être déplacé vers des DLL séparées, alors il est souvent possible de mettre à jour juste en faisant face à une nouvelle version de la DLL.
Si vous apportez des modifications mineures à vos parties Web, vous pouvez simplement remplacer de la DLL si la version assemblage reste le même.
Bien sûr, utilisez une certaine discrétion ici sur ce qui est un changement mineur et ne cassera rien. Voir le sujet pour how to use FileVersion and AssemblyVersion correctly.
Fondamentalement, vous gardez la même valeur pour les mises à jour mineures lors de l'édition de FileVersion avec la compilation.
C'est exactement la façon dont Microsoft le fait avec des choses comme Microsoft.SharePoint.dll - le AssemblyVersion est fixé à 12.0. tandis que FileVersion change avec chaque correctif/service pack.
Oh - Je viens de lire la "partie production" de votre réponse ce raccourci peut être plus approprié pour Dev/Test plutôt que QA/Production
utilisent ce
stsadm -o upgradesolution -name "WSPName.wsp" -filename "c:/WSPName.wsp" -immediate -allowgacdeployment -allowcaspolicies
puis exécutez le sharepoint emploi
stsadm -o execadmsvcjobs
de l'autre côté, vous pouvez mettre à jour les dll en utilisant la commande SharePoint PowerShell
Set-location "C:\Users\Documents\WSP"
[System.Reflection.Assembly]::Load("System.EnterpriseServices, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a")
$publish = New-Object System.EnterpriseServices.Internal.Publish
$publish.GacInstall("C:\Users\Documents\WSP\wspcustom.dll")
stsadm -o upgradesolution est ce que je cherchais. J'ai lu sur ses mises en garde, mais aucun d'entre eux ne s'applique à ma situation immédiate, donc je peux l'utiliser en toute sécurité. –