Home/ Questions/Q 7813143
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-02T04:45:04+00:00

We have a large Silverlight, WCF RIA based solution that builds just fine with

  • 0

We have a large Silverlight, WCF RIA based solution that builds just fine with VS2010 on my desktop. However, on the TFS server we are seeing the following:

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'

.. and …

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

All was happy until a developer checked over the weekend (a very large check in unfortunately). We have looked at what changed in the changeset but haven’t spotted anything.

We are using an approach similar to the one mentioned in this question and here, whereby we have a prebuild solution to avoid the circular references RIA code generation process can introduce.

Our suspicion is that the build order has been altered and are checking into this, but can anyone suggest some diagnostic steps or a solution for this?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    We resolved what was the root cause (we think, at least it now compiles with MSBuild on TFS).

    We have our own DomainServiceFactory to create WCF RIA domain service instances. Inside this factory we inject in the current authenticated user with a custom object (assuming the user has logged in and the domain service needs an authenticated user). Additionally, we have a common domain service that other services consume.

    Ok that sets the scene.

    The culprit in this mess looks to be the custom object we use to represent the authenticated user. Somehow we had arrived at the situation on compilation that this object was being seen from the common domain services and the other domain services that had a reference to the common one.

    The solution was to separate the common domain away from the services that needed it by using the service locator.

    • 0