カスタムチェックインポリシーはサーバーにまったく展開する必要がありますか？

Question

私はそれがどこに文書化されて見たことがないので、私はこの質問をしています。 Team Foundation Server 2008とTeam Explorer 2005の組み合わせを使用しています。

このような環境で動作するカスタムチェックインポリシーを展開することは可能ですか？

明らかに、カスタムチェックインポリシーには、クライアント側で実行する必要のあるコードが含まれています（ヘルプなどを表示するため）。したがって、チームエクスプローラ2005に付属するMicrosoft.TeamFoundation.VersionControl.Clientアセンブリを使用する必要があります。

しかし、私の考えでは、有効にするには、サーバー自体にチェックインポリシーを適用する必要があります（たとえば、コマンドラインからの変更のチェックインや生のWeb Services APIの使用をサポートするなど）。したがって、Team Foundation Server 2008に付属のMicrosoft.TeamFoundation.VersionControl.Clientに対して実行する必要があります。

したがって、最新のバージョンを使用する単一のカスタムチェックインポリシーを構築することは可能ですかMicrosoft.TeamFoundation.VersionControl.Clientアセンブリ（クライアントでは2005、サーバーでは2008）？

または、クライアント用とサーバー用の2つのカスタムチェックインポリシーを作成する必要がありますか。それは働くだろうか？

カスタムチェックインポリシーは、クライアント側にのみ存在しますか？

Answer 1

カスタムチェックインポリシーは、クライアント側にのみ存在し、クライアント側でのみ評価されます。クライアントコンピュータでDLLが見つからない場合、TFSはエラーを報告しますが、エラーを無効にして、チェックインするダイアログを提供します。

Answer 2

いいえ、必須ではありません。しかし、それは事をもっと簡単にします。最新のPower Toolsを使用すると、チェックインポリシーをソース管理に保存し、それらを「無料」に配備できます。

スクリーンショットとwalkthruはBrian's blogである：

....私たちはこれらの機能を導入しました日以来、顧客がクライアントにこれらのようなカスタムコンポーネントを配布する方法を求めてではなく、手動でインストールする必要がいます。まあ、私は、パワーツールのこの新しいリリースがまさにそれをすると言ってうれしい！

カスタムコンポーネントをダウンロードしてクライアント上で実行することは危険ですので、有効にするには相当な注意が必要です。チームプロジェクトのカスタムコンポーネントは、$ // TeamProjectConfigurationという新しい "特別な"フォルダにチェックインされます。私はあなたにいくつかのスクリーンショットを見せて、それがどのように動作するかを歩くのに役立ちます....