How do I handle two assemblies with the same filename during a TFS build?

How do I handle two assemblies with the same filename during a TFS build?

Old forum URL:

JasonRShaver posted on Tuesday, February 16, 2010

I am following the CSLA.NET for Silverlight pattern of using the same filename for the business objects assemblies. For example:

CSLA.dll               // .NET assembly
MyProject.Entities.dll // .NET assembly
.dll               // Silverlight assembly
MyProject.Entities.dll // Silverlight assembly

This is done so you can use a single code file in the .NET project, "file link" it to the Silverlight project and have both assemblies use the same code (compiling out the .NET and Silverlight functionally as needed).

The reason for the same Assembly file names is so that WCF serialization bindings just automatically work.

The issue I am having is that my build server seems to be putting both assemblies in the same output directory and using that directory for resolving project references, but it is getting the wrong file (the Silverlight one instead of the .NET one).

Does anyone know how to deal with this situation?

ajj3085 replied on Wednesday, February 17, 2010

Is there a way to put the output into a \net or \silverlight folder?

JasonRShaver replied on Wednesday, February 17, 2010

Aaron Hallberg mentioned to me that you can change the MSBuild activity in the workflow to not set anOutDir. This worked, but caused the Binaries folder to not get a copy of the output.

Instead, what I did was make three Build Configurations in the solution, ClrOnly, SilverlightOnly, and WebsiteOnly. Then in the Process tab of the build definition, I set the Items to Build to build "1 project(s) and 3 configuration(s)". Now the Binaries output looks like this:

\Multi Platform\
\_Published Sites

And my unit tests and everything are working great.

I really am curious to know how others have delt with this issue in the past.  Anyone?

DancesWithBamboo replied on Wednesday, February 17, 2010

I've used a couple different ways but the one I like best is to change the project file and leave the TFS build files alone.  Here is a snippet of my server side business dll .proj file.  Notice that what you have to do is determine if it is building in Visual Studio or not and then rename the output location if you aren't.

 <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">





<OutDir Condition=" '$(TeamBuildOutDir)'=='' And '$(BuildingInsideVisualStudio)' != 'true' ">..\Output\Alcatraz.Business.Server\</OutDir>

 <OutDir Condition=" '$(TeamBuildOutDir)'!='' ">$(TeamBuildOutDir)Alcatraz.Business.Server</OutDir>






And you also have to set "CustomizableOutDir" to true in the TFSBuild.proj file to get it to respect the project level configurations.




skagen00 replied on Wednesday, May 12, 2010

I'm encountering this issue with TFS 2010....

CustomizableOutDir is no longer applicable, from what I'm reading, as the TFSBuild.proj concept is no longer used with TFS 2010.

If I use OutputPath suitably, I can have my binaries dump to a different directory when I build on my machine, but the TFS server seems to pay no attention -- everything gets dumped into \binaries\ and I get CI build errors because my .NET code in this case is building against a Silverlight class library DLL.

I've got to imagine that with TFS now being free with subscriptions that more people will use it and encounter this issue when dealing with a CSLA.Net Silverlight app - where the binaries are named the same between Silverlight and .NET.

Anyone encounter this issue recently and get through it?? What's the trick?

Aaronomics101 replied on Monday, October 08, 2012

I am running into the exact same problem. I have yet to find a solution to it, and hope that Rocky could help us out. This is bothering our company as we get everything else to work fine except automatic builds which is huge for us.

Copyright (c) Marimer LLC