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

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



Edited by jsobell - 24-Jun-2009 at 3:45pm

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

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

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.