共有DLLを使用した複数のソリューションは、個々のソリューションを撤回すると大混乱を引き起こす可能性があります
-
16-10-2019 - |
質問
問題: 共有DLLを使用した複数のソリューションは、個々のソリューションを撤回すると大混乱を引き起こす可能性があります。
例: すべてのWebパーツコードで使用されるWebパーツヘルパーDLLがあります。このDLLへの参照を含むソリューションを撤回すると、SafeControlエントリが適切なWebアプリケーションから削除され、すべてのWebパーツが失敗し始めます。またはさらに良いことに、DLLはGACから完全に削除されます。
解決: 知らない?教えてください。
解決
あなたが話しているヘルパーDLLのような共通/共有コンポーネントがある場合、それはあなたの組織内の複数のソリューションで使用されます。私の推奨事項は、これらを「フレームワークソリューション」としてパッケージ化することです。これは、「機能ベースのソリューション」のサーバーに展開されます。
このようにして、「機能ソリューション」は、「フレームワーク」が常に利用可能であるという知識の中で開発されます。
SharePointは常にソリューションパッケージに追加したものを撤回/削除します。間違いなく、共有コンポーネントを検出するために組み込まれていません。
他のヒント
私が使用する方法は次のとおりです すべてのアセンブリをilmergeを使用して1つにマージします ビルドの一部として、パッケージングの前
これにより、その後、誰かが依存するアセンブリを何らかの形で削除することは不可能であるため、弾丸が妨げられます。
はい、それはSharePointの展開の一般的な問題です。私の解決策は、ヘルパーDLL-Sのバージョン番号を変更することです。したがって、GACに複数のヘルパーDLL-Sがあり、大きな問題ではないはずです。ヒント:SolutionInfo
各共有アセンブリを単一のWSPファイルに割り当てます。次に、機能依存関係を使用して、一部の人が共有コンポーネントを使用しているかどうかを説明し、アクティブな機能がそれに依存している場合、共有依存関係をアンインストールできないというルールを持っています。
難易度は、全員にルールに従うように説得することです。
チームは、アセンブリを独自のWSPファイルにコピーして貼り付けるか、ルールに注意を払わずに展開するWSPファイルをアンインストールする傾向があります。