MsBuild generating different client side proxy code when using RIA services as opposed to Visual Studio.

Question

Hi,

Firstly I started this post on the silverlight.net forum as I orginally thought it may be a problem with RIA services: http://forums.silverlight.net/t/247888.aspx/1?Msbuild+ignoring+build+order+when+using+RIA+services

Basically in my solution I am taking advantage of the ability to share entities accross multiple domain services in different projects that I think was introduced in RIA Services 1.0 SP2.  What this allows me to do is reference projects with other domain services on the server but then crucially only generate client side proxy code in a single consuming project.  I then call AddReference on the appropiate DomainContext to load in any external entities from other domain contexts.

From what I have learnt the key part to this is making sure that any references between domain services on the server side are replicated on the client side, doing this is what allows RIA to only generate the proxy code in one location as it can figure out which entities etc are shared.

This all works fine in visual studio, however when I use MSbuild to build the code different generated code is genertated and it seems like shared entities are ignored and multiple proxys are generated in multiple locations.  This then causes build errors with ambiguous references.

Now I know that there is a documented issue with MSBuild 4.0 were it seems to ignore the dependancy between a client and server project which have RIA link.  The workaround has been to order the .sln file to what visual studio thinks is the correct order which has worked in the past.  I have done this but still no joy (also I'm not sure if this is a red herring).  When I review the build log the solution does seem to be building in the correct order.  I also believe this issue is fixed in MSbuild 4.5, I downloaded the developer preview but I see the same issue with this version too.

Now my solution is quite large 120+ projects and we have several domain services and this is only an issue in a couple of them, therefore I think there must be something I am doing different in these select few projects.  However I have compared everything I can think of (project file, domain service, entities and attributes, when shared entities are shared and there attributes) but nothing obvious stands out.  So I am hoping someone could provide me with a defintion of the logic MSbuild uses when deciding what proxy code to generate.  Then with this information hopefully I will be able to spot the difference!  If people have any other suggestions please let me know.

Thanks

Phil

Answer 1

Hello ,

Thank you for your question.

I am trying to involve someone familiar with this topic to further look at this issue. There might be some time delay. Appreciate your patience.

Thank you for your understanding and support.

Yi

---

Yi Feng Li [MSFT]
MSDN Community Support | Feedback to us

Answer 2

Thanks for the update.

Answer 3

Any update on this?  This is currently causing our build server to fail every build!

Answer 4

**bump**

Answer 5

And another.

Answer 6

Hi PhilDonegan,

Thanks for your patience!

We have involved more experts to investigate this thread.

Please be patient to get update.

Thanks for your understanding!

---

Best wishes,

---

Robin [MSFT]
MSDN Community Support | Feedback to us
Get or Request Code Sample from Microsoft
Please remember to mark the replies as answers if they help and unmark them if they provide no help.

Answer 7

As per my understanding of your question: your application works well if built within Visual Studio IDE, howerver, if we build the application using MSBuild commandline, the generated application doesn't work, am i right?

Since Visual Studio relay on MSBuild to perfrom build taks, the issue might be caused by arguments used in MSBuild commandline, so you may sets the verbosity level for the build output of Visual Studio: Tools -> Options -> Project and Solutions -> Build and Run -> set MSBuild project build output verbosity to Diagnostic; and then compare build output of Visaul Studio against your MSBuild commandline.

By the way, you also mentioned that "Now I know that there is a documented issue with MSBuild 4.0 were it seems to ignore the dependancy between a client and server project which have RIA link.", could you please let me know the documented issue's link? thanks.

---

Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Regards,
Eric Yang
Microsoft Online Community Support

Answer 8

Here's the raised bug http://connect.microsoft.com/VisualStudio/feedback/details/568097/ria-services-code-generation-fails-from-the-command-line-when-using-a-services-library

And here's someones explanation http://blogs.msdn.com/b/visualstudio/archive/2010/12/21/incorrect-solution-build-ordering-when-using-msbuild-exe.aspx apparently it's more related to the way MSBuild understands (or rather in this case completely ignores) build dependancies.  Please read the comments for the exact issue in RIA services.

Changing the verbosity level was one of the first things I did, however with a solution with over 120+ projects that produced a log file well over 100Mb.  I could not see anything related to RIA services and proxy generation in that file.  It would help if you could tell me what engine MsBuild uses to generate the client side proxy code is it sgen.exe?

Thanks

Phil

Answer 9

Any further news on this?

Answer 10

I spotted this in the build log today when spending more time on this issue:

[quote]

Task "CreateRiaClientFilesTask"
  RIA client proxy class generation starting for project 'SomeCompany.User.Services.csproj'.
  Analyzing project 'SomeCompany.User.Services.csproj' for project references.
  The project 'SomeCompany.User.Services.csproj' contains project references to:
      C:\TFS\P2 New\MAIN\Source\ClientTier\SomeCompany.Person.Services\SomeCompany.Person.Services.csproj
      C:\TFS\P2 New\MAIN\Source\ClientTier\SomeCompany.Common.Services\SomeCompany.Common.Services.csproj
      C:\TFS\P2 New\MAIN\Source\ClientTier\SomeCompany.UI.Interfaces\SomeCompany.UI.Interfaces.csproj
  A WCF RIA Services Link exists between project 'C:\TFS\P2 New\MAIN\Source\ClientTier\SomeCompany.Person.Services\SomeCompany.Person.Services.csproj' and project 'C:\TFS\P2 New\MAIN\Source\MiddleTier\SomeCompany.Person.Services.Web\SomeCompany.Person.Services.Web.csproj'.
  A WCF RIA Services Link exists between project 'C:\TFS\P2 New\MAIN\Source\ClientTier\SomeCompany.Common.Services\SomeCompany.Common.Services.csproj' and project 'C:\TFS\P2 New\MAIN\Source\MiddleTier\SomeCompany.Common.Services.Web\SomeCompany.Common.Services.Web.csproj'.
  Analyzing project 'SomeCompany.User.Services.Web.csproj' for project references.
  The project 'SomeCompany.User.Services.Web.csproj' contains project references to:
      C:\TFS\P2 New\MAIN\Source\MiddleTier\SomeCompany.Common.Services.Web\SomeCompany.Common.Services.Web.csproj
      C:\TFS\P2 New\MAIN\Source\MiddleTier\SomeCompany.Person.Services.Web\SomeCompany.Person.Services.Web.csproj
  Analyzing project 'SomeCompany.User.Services.Web.csproj' for shared source files.
  Analyzing project 'SomeCompany.Common.Services.Web.csproj' for shared source files.
  Analyzing project 'SomeCompany.Person.Services.Web.csproj' for shared source files.
  Shared files will not be copied from 'C:\TFS\P2 New\MAIN\Source\MiddleTier\SomeCompany.Common.Services.Web\SomeCompany.Common.Services.Web.csproj' due to an existing WCF RIA Services Link from 'C:\TFS\P2 New\MAIN\Source\ClientTier\SomeCompany.Common.Services\SomeCompany.Common.Services.csproj'.
  Shared files will not be copied from 'C:\TFS\P2 New\MAIN\Source\MiddleTier\SomeCompany.Person.Services.Web\SomeCompany.Person.Services.Web.csproj' due to an existing WCF RIA Services Link from 'C:\TFS\P2 New\MAIN\Source\ClientTier\SomeCompany.Person.Services\SomeCompany.Person.Services.csproj'.
  Copying file 'C:\TFS\P2 New\MAIN\Source\MiddleTier\SomeCompany.User.Services.Web\Model\IRole.shared.cs' to 'C:\TFS\P2 New\MAIN\Source\ClientTier\SomeCompany.User.Services\Generated_Code'.
  Copying file 'C:\TFS\P2 New\MAIN\Source\MiddleTier\SomeCompany.User.Services.Web\Model\ITask.shared.cs' to 'C:\TFS\P2 New\MAIN\Source\ClientTier\SomeCompany.User.Services\Generated_Code'.
...
  Files visible to both the client and the server are:
      C:\TFS\P2 New\MAIN\Source\MiddleTier\SomeCompany.User.Services.Web\Model\IRole.shared.cs
      C:\TFS\P2 New\MAIN\Source\MiddleTier\SomeCompany.User.Services.Web\Model\ITask.shared.cs
      C:\TFS\P2 New\MAIN\Source\MiddleTier\SomeCompany.User.Services.Web\Model\RoleBase.shared.cs
      C:\TFS\P2 New\MAIN\Source\MiddleTier\SomeCompany.User.Services.Web\Model\TaskBase.shared.cs
...
  Assembly 'Microsoft.Practices.ServiceLocation, Version=1.0.0.0, Culture=neutral, PublicKeyToken=537c3450b3658434' could not be loaded and will be ignored.
  Could not load file or assembly 'Microsoft.Practices.ServiceLocation, Version=1.0.0.0, Culture=neutral, PublicKeyToken=537c3450b3658434' or one of its dependencies. The system cannot find the file specified.
  Assembly 'Divelements.SandRibbon, Version=2.0.0.17784, Culture=neutral, PublicKeyToken=75b7ec17dd7c14c3' could not be loaded and will be ignored.
  Could not load file or assembly 'Divelements.SandRibbon, Version=2.0.0.17784, Culture=neutral, PublicKeyToken=75b7ec17dd7c14c3' or one of its dependencies. The system cannot find the file specified.
  Failed to load types from assembly 'SomeCompany.Common.Services, Version=1.0.4437.22678, Culture=neutral, PublicKeyToken=537c3450b3658434' so the assembly will be ignored.
  Cannot resolve dependency to assembly 'Microsoft.Practices.ServiceLocation, Version=1.0.0.0, Culture=neutral, PublicKeyToken=537c3450b3658434' because it has not been preloaded. When using the ReflectionOnly APIs, dependent assemblies must be pre-loaded or loaded on demand through the ReflectionOnlyAssemblyResolve event.
  Generating proxy classes for the DomainService 'SomeCompany.User.Services.Web.DomainServices.AuthenticationService'.
  Failed to load types from assembly 'SomeCompany.Common.Services, Version=1.0.4437.22678, Culture=neutral, PublicKeyToken=537c3450b3658434' so the assembly will be ignored.
  Cannot resolve dependency to assembly 'Microsoft.Practices.ServiceLocation, Version=1.0.0.0, Culture=neutral, PublicKeyToken=537c3450b3658434' because it has not been preloaded. When using the ReflectionOnly APIs, dependent assemblies must be pre-loaded or loaded on demand through the ReflectionOnlyAssemblyResolve event.
  ...

[/quote]

I've googled for hours as to what this reflection only API thing could and have no idea.  It does however make sense to me that this could be the cause of my issue.  The log says that it is creating the proxy's for the User module.  It knows that User has a reference to Person and Common, but when it tries to analyise these it says that a required assembly cannot be found.  So therefore I imagine it is just creating proxys for everything since it can't compare to Person and Common which entities are shared.

Any ideas?

Thanks

Phillip Donegan

Answer 11

So I finally figured this out so thought I'd post an update.  It turns out that in the last post these messages about not being able to find certain 3rd party dlls were the problem.  It looks like when you reference projects A -> B on the client side, if B is dependant on 3rd party dlls then these need to also be referenced in A.  However VS nor MSBuild report these as errors or warnings.  They are just low priority information only found in the output of MSBuild.

So the pro's are my solution is working again.  The cons, I have to reference dlls that I don't actually need in that project which feel dead wrong to me.  We had some Microsoft ADM's in my place of work on Monday I showed them this issue and they're going to look into it in more detail.  If they send me an update I'll update this thread.

Phil

Answer 12

Phil,

I've seen this problem in our solutions before, you can avoid adding the unused (but required) dependencies in a folder that MSBuild will search at build-time.

For instance if A references B, where B is a custom internal dll and B depends on C, where C is a 3rd party dll then when B and C are in the same directory MSBuild will find C at build-time.

If B is not a dll but a project in the same solution as A, then you'll need to get more creative. If you look at the build log you will notice that MSBuild says multiple times "Cannot resolve dependency to assembly..." and each time it gives a the directory in which it looked for the dependency. So if you put the dll for C in any of these directories, MSBuild will be able to resolve the dependency at build-time and you won't need the unused reference.

Also remember, it's always a good idea to keep all dll dependencies (both internal and 3rd party) in a single binaries folder that also gets checked into source control.

Hope this helps