Dois-je conserver des solutions et des fonctionnalités dans un rapport 1-1?

Question

J'ai un sharepoint complexe avec de multiples déployer EventReceivers et Workflows.

J'ai aussi des changements de schéma aux listes existantes, l'ajout de nouvelles colonnes de métadonnées et de modifier les colonnes existantes.

Dois-je emballer une seule fonction, eventreceiver ou flux de travail, à une seule solution, ou devrais-je mettre plusieurs fonctions à l'intérieur de la solution unique car ils travaillent tous ensemble?

Une des principales raisons que je vous demande est pour des mises à niveau futur code. Si les caractéristiques sont séparées, puis une mise à niveau dans une portion de code ne nécessiterait pas de redéployer de toutes les fonctionnalités de la solution. Est-ce quelque chose que je dois vous inquiéter ou ne la « stsadmin -o upgradesolution » prendre soin de tout problème avec la mise à niveau d'une solution avec de nombreuses fonctionnalités?

Faites-moi savoir si cela a un sens à tous les gourous de SharePoint là-bas.

Merci,
Keith

Mise à jour: En regardant le site Drax référencé, j'ai trouvé ce site de référence: http://msdn.microsoft.com /en-us/library/aa543659.aspx

Cette déclaration semble mettre un grand handicap sur la mise à niveau des fonctionnalités des solutions:

  

mise à niveau de la solution ne peut être utilisé pour   remplacer les fichiers. Vous pouvez ajouter de nouveaux fichiers   dans une mise à niveau solution et enlever le vieux   versions des fichiers, mais vous ne pouvez pas   installer ou utiliser Caractéristiques événement Feature   gestionnaires d'exécuter du code pour la fonction   l'installation et l'activation. le   les opérations suivantes ne sont pas pris en charge   dans la mise à niveau solution.

     

  

• Suppression des anciens Caractéristiques dans une nouvelle   version d'une solution.

  

• Ajout de nouvelles fonctionnalités dans une solution   mise à niveau.

  

• La mise à jour ou la modification du récepteur   assemblage pour les fonctionnalités existantes dans un   nouvelle version d'une solution.

  

• Ajout ou modification des éléments de fonction   (fichiers element.xml) dans une nouvelle version   d'une solution.

  

• Ajout ou modification de la fonction   propriétés dans une nouvelle version d'un   solution.

  

• Modification de l'ID ou la portée de l'ancien   Caractéristiques dans une nouvelle version d'un   solution.

  

• Suppression d'éléments de fonction   (fichiers element.xml) dans une nouvelle version   d'une solution.

  

• Suppression de propriétés de fonction dans une nouvelle   version d'une solution.

  

Alors ... Que pouvez-vous faire passer avec une solution?

Answer 1

Je conseillerais contre tout fractionnement en plusieurs solutions. Maintaing qui peut rapidement devenir cauchemar. Essayez de structurer votre projet, qui devrait est utilisé pour créer WSP, de la même manière que 12 dossiers de sharepoint. Ensuite, vous pouvez utiliser WSP constructeur , dernière version stable apporte beaucoup de choses utiles.

Aussi je ne l'ai pas remarqué de problèmes avec des solutions redéployant. Selon cet article et mon déploiement d'expérience de WSP prend en charge la synchronisation entre versions. Donc, si vous allez ajouter quelques nouvelles fonctionnalités, ils apparaîtront et si vous supprimez / caractéristiques du changement, ils seront modifiés en conséquence.

ÉDITÉ:

Je l'ai fait une recherche rapide sur MOSS sujet Mise à jour. Selon MS, il existe deux façons de solutions de mise à jour:

1. Dans la mise à jour place
2. Mise à jour incrémentale

En fait, la mise à jour en place est moyen standard de mise à jour. Qui signifie que vous comptez sur la fonctionnalité de construction en cette ( même document que publié avant) document. Problème avec cette solution est qu'il manque beaucoup de fonctionnalités (versioning, le changement d'identité de de fonctionnalités, ...).

Mise à jour incrémentale (ce qui est de la SP appelle probablement) ne repose pas sur des solutions de construction en. Cela signifie qu'il est à tout le monde à mettre en œuvre par eux-mêmes :(. Ce qui est encore mieux que je n'étais pas vraiment en mesure de trouver des lignes directrices pour cette approche. Je suppose que l'approche que vous voulez prendre est par exemple de la mise à jour incrémentale (projet de division en de nombreuses solutions indépendantes).

Notez également que la mise à jour incrémentale n'est pas officiellement pris en charge par MS.

Je ne sais pas vraiment quels conseils dois-je pour vous donner. Un seul WSP est plus maintanable que buch d'entre eux, même si vous faites seulement quelques modifications mineures mises à jour fonctionnent parfaitement. Mais si vous avez besoin de faire quelques changements structurels plus importants problèmes commencent à se montrer.

Je vais probablement attendre et voir si les gens avec plus d'expertise MOSS peuvent dire quelque chose à ce sujet.

Answer 2

En gros (pour les raisons que vous avez mentionné), vous devriez penser à des solutions que vous .Net ensembles - unités atomiques de code qui peuvent être déployées séparément des autres. L'utilisation upgradesolution provoquera une redéployer de toutes les fonctionnalités contenues - si rien n'a changé, rien ne devrait changer pour les sites qui utilisent cette fonctionnalité. Mais, si cela vous rend nerveux, pensez à la découper.

Answer 3

Upgradesolution est vraiment pratique si vous mettez à jour tout l'assemblage et en laissant les fichiers provisionnés intacts.

Si vous ne spécifiez -local puis upgradesolution effectuera une iisreset complète à travers votre infrastructure. Ceci est vraiment intéressant de noter lorsque vous planifiez le bon moment pour effectuer des mises à niveau.