Silverlight、WCF TFSでRIAビルドが失敗するMSBuild

Question

私たちはデスクトップ上でVS2010でうまく構築できる大規模なSilverlight、WCF RIAベースのソリューションを用意しています。しかし、私たちは次のことを見ているTFSサーバー上：開発者は、週末に確認されるまで

ViewModels\MyVM.cs (47): The type 'TestService.Web.SystemAccount' exists in both 
'd:\Builds\1\MyProduct\Binaries\Silverlight\TestService.dll' and 'd:\Builds\1\MyProduct 
\Binaries\Silverlight\CommonService.dll' 

...と...

Generated_Code\TestService.Web.g.cs (37476): The type 'TestService.Web.GroupToRule' in 
'd:\Builds\1\MyProduct\Sources\Source\UI\TestService\Generated_Code\TestService.Web.g.cs' 
conflicts with the imported type 'CommonService.GroupToRule' in 'd:\Builds\1\MyProduct 
\Binaries\silverlight\CommonService.dll'. Using the type defined in 'd:\Builds\1\MyProduct 
\Sources\Source\UI\CommonService\Generated_Code\CommonService.Web.g.cs'. 

全て（残念ながら非常に大きなチェック）幸せでした。私たちはチェンジセットで何が変わったのかを見てきましたが、何も発見していませんでした。

このquestionおよびhereに記載されているのと同様の方法を使用しています。これにより、RIAコード生成プロセスが導入できる循環参照を回避するための事前ビルドソリューションが用意されています。

私たちの疑問は、ビルドオーダーが変更されており、これをチェックしているということですが、誰かが何かの診断ステップまたはこれに対する解決策を提案できますか？

Answer 1

私たちは根本原因を解決しました（少なくとも、現在はTFSのMSBuildでコンパイルされていると思います）。

WCF RIAドメインサービスインスタンスを作成するための独自のDomainServiceFactoryがあります。このファクトリの内部では、現在の認証されたユーザにカスタムオブジェクトを挿入します（ユーザがログインし、ドメインサービスが認証されたユーザを必要とすると仮定します）。さらに、他のサービスが消費する共通のドメインサービスもあります。

シーンを設定するOK。

この混乱の原因は、認証されたユーザーを表すために使用するカスタムオブジェクトのように見えます。どういうわけか私たちはコンパイル時の状況に、このオブジェクトが共通ドメインサービスと共通ドメインサービスを参照している他のドメインサービスから見られていたことに気付きました。

解決策は、サービスロケータを使用して共通ドメインを必要なサービスから分離することでした。

Answer 2

与えられた情報に基づいて合理的なことを言うのは難しいです。

チェンジセットの前にすべてがうまく構築されていることが確かであれば、のログが「良い」リビジョンとそれ以降の「悪い」リビジョンのビルドを比較して比較することができます。この作業では、優れた差分ツールが役立ちます。 MSBuildのログは非常に冗長かもしれないので、おそらく手書きの解析ツールが必要かもしれません。

また、参照したトピックのthis answerもご覧ください。そのアドバイスは、MSBuildチームのメンバーがブログの1つで同じことを提案して以来、正式なものとして考えることができます。