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?

Community
  • 1
  • 1
Rus
  • 1,827
  • 1
  • 21
  • 32

2 Answers2

0

It's hard to say anything reasonable based on the given info.

If you are sure that everything was built fine before some changeset, you could get logs of clean builds of that 'good' revision and of a later 'bad' revision and compare them. A good diff tool might help in this task. And some analysis tool, probably hand-written, might be necessary since MSBuild logs might be quite verbose.

Also, check out this answer in the topic you've referenced. That advice can be thought of as of an official one, since a guy from the MSBuild team suggested the same in one of their blogs.

Community
  • 1
  • 1
Pavel Gatilov
  • 7,579
  • 1
  • 27
  • 42
0

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.

Rus
  • 1,827
  • 1
  • 21
  • 32