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

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
CSLA.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?

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:

Nightly_20100217.1\
                  \Multi Platform\
                                 \ClrOnly
                                 \SilverlightOnly
                                 \WebsiteOnly\
                                             \_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' ">

<DebugSymbols>true</DebugSymbols>

<DebugType>full</DebugType>

<Optimize>false</Optimize>

<OutputPath>bin\</OutputPath>

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

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

<DefineConstants>DEBUG;TRACE</DefineConstants>

<ErrorReport>prompt</ErrorReport>

<WarningLevel>4</WarningLevel>

</PropertyGroup>

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

<CustomizableOutDir>true</CustomizableOutDir>

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?