ソリューションと機能を 1 対 1 の比率に保つ必要がありますか?

Question

複数の EventReceiver とワークフローを使用した複雑な SharePoint デプロイがあります。

また、既存のリストにスキーマを変更し、メタデータの新しい列を追加したり、既存の列を変更したりすることもあります。

単一の機能、イベントレシーバーまたはワークフローを単一のソリューションにパッケージ化する必要がありますか、それともすべて連携して動作するため、複数の機能を単一のソリューション内に配置する必要がありますか?

私が尋ねる主な理由の 1 つは、将来のコードのアップグレードのためです。機能が分離されている場合、コードの一部をアップグレードするだけで、ソリューション内のすべての機能を再デプロイする必要はありません。これは心配すべきことですか? それとも、「stsadmin -o upgradesolution」により、多くの機能を備えたソリューションのアップグレードに関する問題が解決されますか?

これが SharePoint の達人にとって意味があるかどうか教えてください。

ありがとう、
キース

アップデート：ウェブサイトを見てみると ドラックス 参考にしたところ、こんな参考サイトを見つけました。 http://msdn.microsoft.com/en-us/library/aa543659.aspx

このステートメントは、ソリューションの機能をアップグレードする際に大きなハンディキャップを課しているように見えます。

ソリューションのアップグレードは、以下の場合にのみ使用できます。 ファイルを置き換える。新しいファイルを追加できる ソリューションのアップグレードと古い しかし、そのようなことはできません。 フィーチャーをインストールするか、フィーチャー・イベントを使用する フィーチャー用のコードを実行するハンドラ インストールとアクティベーション。について 以下の操作はサポートされていません。 ソリューションのアップグレードで

• 新しいフィーチャーで古いフィーチャーを削除する 解決策のバージョン。

• ソリューションに新しいフィーチャーを追加する アップグレードする。

• 受信機の更新または変更 既存アセンブリー 既存アセンブリー 既存アセンブリー 既存アセンブリー 既存アセンブリー ソリューションの新バージョン。

• フィーチャー要素の追加と変更 (Element.xmlファイル)を新しいバージョンに追加した。 解決策の

• 機能の追加と変更 のプロパティを追加した。 解決策だ。

• 古いIDやスコープの変更 の新バージョンの特徴 解決策だ。

• フィーチャー要素の削除 (Element.xmlファイル)を新しいバージョンに追加した。 解決策の

• フィーチャー・プロパティの削除 解決策のバージョン。

それで...ソリューションをアップグレードすると何ができるようになりますか?

Answer 1

アドバイスさせていただきます に対して すべてを複数のソリューションに分割します。それを維持することはすぐに悪夢になる可能性があります。WSP を作成するために使用するプロジェクトを SharePoint の 12 フォルダーと同じように構成してみてください。その後、使用できます WSPビルダー, 、最後の安定バージョンには、便利なものがたくさんあります。

また、ソリューションの再デプロイに関する問題には気づきませんでした。によると これ この記事と私の経験では、WSP の展開によりバージョン間の同期が行われます。したがって、いくつかの新しい機能を追加すると表示され、機能を削除または変更すると、それに応じて変更されます。

編集済み:

そこで、MOSS 更新トピックについて簡単に調査しました。MS によると、ソリューションを更新するには 2 つの方法があります。

1. インプレース更新
2. 増分更新

基本的に、インプレース更新は標準的な更新方法です。で説明されているように、組み込み機能に依存していることを意味します。 これ （以前投稿したものと同じ文書）文書。このソリューションの問題は、非常に多くの機能 (バージョン管理、機能の ID の変更など) が欠けていることです。

増分更新 (おそらく MS ではこのように呼んでいます) は、組み込みのソリューションに依存しません。つまり、それを自分で実装するかどうかは誰もが決めることです:(。さらに良いことに、このアプローチに関するガイドラインを実際には見つけることができませんでした。あなたが採用したいアプローチは、増分更新（プロジェクトを多数の独立したソリューションに分割する）の例だと思います。

また、増分アップデートは MS によって正式にサポートされていないことにも注意してください。

ですから、あなたにどのようなアドバイスをすればよいのか、本当にわかりません。単一の WSP は他の WSP よりも保守しやすく、また、いくつかの小さな変更を行うだけであれば、更新は完全に機能します。しかし、より大きな構造的変更を加える必要がある場合、問題が見え始めます。

おそらく、MOSS の専門知識に詳しい人がこのトピックについて何か発言するかどうかを待ってみることにします。

Answer 2

基本的に (前述の理由により) .Net アセンブリ (他のものとは別にデプロイできるコードのアトミック単位) と同じようにソリューションを考える必要があります。upgradesolution を使用すると、含まれているすべての機能が再デプロイされます。何も変更されない場合、その機能を使用するサイトは何も変更されません。ただし、それが不安になる場合は、分割することを検討してください。

Answer 3

UpgradeSolution は、プロビジョニングされたファイルをそのままにしてアセンブリを更新するだけの場合に非常に便利です。

-local を指定しない限り、upgradesolution はインフラストラクチャ全体で完全な iisreset を実行します。これは、アップグレードを実行する適切な時期を計画する場合に非常に注目に値します。