Print Page | Close Window

MAJOR (and V.Urgent!) incompatibility problems with DF, Blend and TFS

Printed From: IdeaBlade
Category: DevForce
Forum Name: DevForce 2009
Forum Discription: For .NET 3.5
URL: http://www.ideablade.com/forum/forum_posts.asp?TID=1347
Printed Date: 19-May-2025 at 9:26am


Topic: MAJOR (and V.Urgent!) incompatibility problems with DF, Blend and TFS
Posted By: jsobell
Subject: MAJOR (and V.Urgent!) incompatibility problems with DF, Blend and TFS
Date Posted: 24-Jun-2009 at 3:44pm
This has been sent in as an email, but we've had no response so I'll post it here too...

We’re experiencing extreme issues with the duplicate assembly name requirements of DevForce for SL3, and it’s making it impossible to mock data in the way Ward discusses in the forums.
When Blend loads it imports the current project and runs MSBUILD, but this creates all of the assemblies in a single folder.  Since DF insists that both client and server be named identically, the SL project becomes overwritten by the web one, so Blend fails.

The output can be seen here overwriting the Web DLL with the SL one:

CopyFilesToOutputDirectory:
  Copying file from "obj\Release\QuestManager.Web.dll" to "D:\Binaries\Release\QuestManager.Web.dll".
  QuestManager.Web -> D:\Binaries\Release\QuestManager.Web.dll
  Copying file from "obj\Release\QuestManager.Web.pdb" to "D:\Binaries\Release\QuestManager.Web.pdb".
:
:
CopyFilesToOutputDirectory:
  Copying file from "obj\Release\QuestManager.Web.dll" to "D:\Binaries\Release\QuestManager.Web.dll".
  QuestManager.Entities.Client -> D:\Binaries\Release\QuestManager.Web.dll
  Copying file from "obj\Release\QuestManager.Web.pdb" to "D:\Binaries\Release\QuestManager.Web.pdb".
Done Building Project "D:\Source\QuestManager\QuestManager.Entities.Client\QuestManager.Entities.Client\QuestManager.Entities.Client.csproj" (default targets).

How do we work around this?  It causes both Blend and TFS builds to fail, and makes it impossible to use DF as a mocking source in disconnected mode.
Is there any way to make DF allow two differently named DLLs?

Cheers,
 Jason

 file:///C:%5CUsers%5CJASON%7E1.QUE%5CAppData%5CLocal%5CTemp%5Cmsohtmlclip1%5C01%5Cclip_colorschememapping.xml -


Replies:
Posted By: kimj
Date Posted: 24-Jun-2009 at 8:05pm
The duplicate assembly name requirement is only for the assembly containing the domain model.  So, if your domain model is located in QuestManager.Entities.Server and the linked project is QuestManager.Entities.Client, then these two assemblies must have the same assembly name.  All other assemblies can (and should) have unique names - this includes the assemblies built from the Silverlight application project and the web project.   The assembly name requirement is currently needed in order to serialize the entities between client and web, and we plan to remove this requirement in a future release - which release is TBD.
 
I unfortunately don't really understand the Blend requirement here to place the assemblies into a single folder.  Do you set the Output Path in your projects to a common location?
 
When mocking in disconnected mode, you shouldn't need to communicate with the EntityService and the server-side domain model at all ...
 
Ward may have some better guidance to offer you.
 

Posted By: jsobell
Date Posted: 24-Jun-2009 at 8:17pm
Thanks Kim,
The issue with Blend (and any MS process that uses MSBuild to prepare its files) is that the default for MSBuild is to perform what is sometimes referred to as a 'train wreck' process where they throw every file into one folder.
The workaround we've just found is here:
http://piers7.blogspot.com/2009/06/preserving-output-directory-structure.html - http://piers7.blogspot.com/2009/06/preserving-output-directory-structure.html
This at least allows our code to compile using MSBuild, which is essential for Blend as well as automated build systems.  When Blend loads it compiles your project so that it can use the underlying BindingConvertors, mock data etc, so any code must be MSBuild compatible.

For the time being I would suggest you publish the above link, as every developer using TFS (and possibly all using Blend for mocking) will most likely hit this issue.

It doesn't matter where the duplicate names exist; if any two files share the same name, this issue breaks everything.

Cheers,
 Jason

Posted By: kimj
Date Posted: 24-Jun-2009 at 8:44pm
Thanks, that TFS tip is good to know.  Glad you found a solution to the problem.

Posted By: jsobell
Date Posted: 24-Jun-2009 at 11:29pm
And this code in the PostBuild event...

rem [IdeaBlade-begin]
copy  "$(SolutionDir)QuestManager.Web.Data\bin\Debug\QuestManager.Web.Data.dll" "$(TargetDir)"
goto BuildEventOK
:0
goto BuildEventFailed
:BuildEventFailed
echo IdeaBlade post-build event for $(ProjectName) failed: one or more files could not be copied to the output directory
exit 0
:BuildEventOK
echo IdeaBlade post-build event for $(ProjectName) completed Ok
rem [IdeaBlade-end]

This is not good either :/

How often and how is this script inserted? Is it an automated process that we can expect to be stonked over, or can we modify the template to add the correct copy:
"$(SolutionDir)QuestManager.Web.Data\bin\$(ConfigurationName)\QuestManager.Web.Data.dll" "$(TargetDir)"

Cheers,
 Jason

Posted By: kimj
Date Posted: 25-Jun-2009 at 11:21am
You can turn the post build event generation off altogether in the Object Mapper - it's the "Copy Entity Model Artifacts" checkbox on the ibedmx property page.  The script is not configurable, and is generated each time the project is built.  The script is generated using the current active configuration, it's not using a hardcoded "debug" folder name.  We'll open a bug report to see about using the ConfigurationName macro.

Posted By: jsobell
Date Posted: 25-Jun-2009 at 3:55pm
Yes, we realised that it's not hard-coded in the DF tool, but the tool is hard-coding it into the script, so anything subsequently using the project file (such as any of Microsoft's other build-related tools) will break in release/debug/anyother mode.
According to the Microsoft guys we have here at the moment that includes Blend, explaining the three days we've just spent trying to get it to work!
 
Cheers,
 Jason


Print Page | Close Window