SmartPartsを使用してASP.NETユーザーコントロールをSharePointで直接ホストする問題はありますか？

Question

SmartPartsを使用することを考えています（http://www.codeplex.com/smartpart）SharePointでASP.NETユーザーコントロールを直接ホストします。ただし、これには、すべてのユーザーコントロールをすべてのWFEサーバーに手動でコピーし、Webアプリケーションルートフォルダーの特別なフォルダーに配置する必要があります。

このアプローチに問題がありますか？パフォーマンスへの影響はどうですか？それに直面した人はいますか？またはそれが好きでしたか？

Answer 1

SmartPartを使用したことがないので、正確にコメントできません。ただし、などのパッケージングソリューションを使用している場合は、手動でコピーする必要はありません wspbuilder これはあなたのためにこれらすべてを処理できます。

スマートパート以外のルートにはかなり良いdocoがあります。

• SharePointDevwikiから、 ビジュアルデザインユーザーコントロールを使用したSharePoint開発
• SharePointガイダンスの記事： 方法：SharePointのWebパーツの内部にユーザーコントロールをラップする

いずれにせよ、最終的にはすべて同じビットであるため、PERFの問題はないか、無視できる問題があるはずです。

Answer 2

これがいいです Pro/Conの記事.. Jan自身がコメントした。

私はそれを決して使わない。デバッグして展開するのは苦痛であり、wspbuilderのようなものはそれを不要にします。

Answer 3

SmartPartsは、他のWebパーツと同様にWebパーツです。ユーザーコントロールは、サブディレクトリのControlTemplatesにドロップする別のアーティファクトにすぎません。どちらもパッケージ化され、ソリューションでプロビジョニングされ、機能を使用する必要があります（WebパーツギャラリーにWebパーツを追加したい場合）。

ソリューションを展開して機能コンテンツをアクティブにすると、すべてのWebフロントエンドサーバーで安全なコントロール、BIN/GAC、Webパーツギャラリー、ControlTemplatesなどに自動的に追加されます。

CreateChildControlsにコントロールを追加することとは対照的に、ユーザーコントロールのロードに関するパフォーマンスオーバーヘッドについて聞いたことがありません。

いくつかのリンク：ソリューションとWeb部品パッケージ

ソリューションパッケージを使用して、Windows SharePoint Services 3.0に機能とコンテンツを展開する

方法：シンプルな機能を作成します

機能を扱う

HTH ANDERS RASK