2012-04-16 175 views
0

我们有一个Silverlight,基于WCF RIA的大型解决方案,在我的桌面上与VS2010一起构建得很好。但是,TFS服务器上,我们看到了以下内容:Silverlight,WCF RIA构建失败与TFS MSBuild

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'. 

所有很高兴直到开发检查上周末(不幸中的一个非常大的检查) 。我们查看了变更集中发生了什么变化,但没有发现任何内容。

我们正在使用类似于此questionhere中提到的方法,因此我们有一个预构建解决方案来避免RIA代码生成过程可以引入的循环引用。

我们怀疑构建顺序已被修改并正在检查中,但任何人都可以提出一些诊断步骤或解决方案吗?

回答

0

我们解决了什么是根本原因(我们认为,至少它现在用TFS上的MSBuild编译)。

我们有自己的DomainServiceFactory来创建WCF RIA域服务实例。在这个工厂内部,我们使用自定义对象(假设用户已经登录并且域服务需要经过认证的用户)向当前已认证的用户注入。另外,我们还有其他服务使用的通用域服务。

好吧,设置场景。

在这个混乱中的罪魁祸首看起来是我们用来表示经过身份验证的用户的自定义对象。不知何故,我们已经得出了编译的情况,即这个对象是从常见域服务和其他域服务中看到的,这些域服务引用了常见域服务。

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

0

基于给定的信息,很难说任何合理的东西。

清洁如果您确信一切都被一些变更之前建立了良好的,你可以得到原木建造的是“好”的修订和以后的“坏”的修订并加以比较。一个好的差异工具可能有助于完成这项任务。一些分析工具,可能是手写的,可能是必要的,因为MSBuild日志可能非常冗长。

另外,请查看您引用的主题中的this answer。这个建议可以被认为是官方的建议,因为来自MSBuild团队的人在他们的一个博客中提出了相同的建议。