Silverlight，WCF RIA生成因TFS MSBuild而失败

我们有一个基于WCF RIA的大型Silverlight解决方案，可以在我的桌面上与VS2010配合使用。但是，在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'.

所有人都很高兴，直到一个开发人员在周末进行了检查（不幸的是，这是一个非常大的检查）。我们已经查看了变更集中发生的变化，但没有发现任何变化

我们使用的方法与本文和中提到的方法类似，因此我们有一个预构建解决方案，以避免RIA代码生成过程可能引入的循环引用

---

我们怀疑构建顺序已被更改，正在对此进行检查，但有人能提出一些诊断步骤或解决方案吗？

根据给定的信息，很难说有什么合理的建议

如果您确信在某个变更集之前构建的一切都很好，那么您可以获取该“好”版本和以后“坏”版本的clean构建日志，并对它们进行比较。一个好的diff工具可能有助于完成这项任务。由于MSBuild日志可能非常冗长，因此可能需要一些分析工具（可能是手工编写的）

---

此外，请查看您参考的主题。这个建议可以看作是一个正式的建议，因为来自MSBuild团队的一个人在他们的一个博客中提出了同样的建议。

我们解决了根本原因（我们认为，至少现在它在TFS上使用MSBuild编译）

我们有自己的DomainServiceFactory来创建WCF RIA域服务实例。在这个工厂中，我们使用一个自定义对象（假设用户已经登录并且域服务需要一个经过身份验证的用户）注入当前的经过身份验证的用户。此外，我们还有一个其他服务使用的公共域服务

好了，那就开始了

这一混乱局面的罪魁祸首似乎是我们用来表示经过身份验证的用户的自定义对象。不知何故，我们在编译时已经达到了这样一种情况：这个对象是从公共域服务和其他引用公共域服务的域服务中看到的

解决方案是使用服务定位器将公共域从需要它的服务中分离出来