I am following the CSLA.NET for Silverlight pattern of using the same filename for the business objects assemblies. For example: 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?CSLA.dll // .NET assembly
MyProject.Entities.dll // .NET assembly
CSLA.dll // Silverlight assembly
MyProject.Entities.dll // Silverlight assembly
Is there a way to put the output into a \net or \silverlight folder?
Aaron Hallberg mentioned to me that you can change the MSBuild activity in the workflow to not set an Instead, what I did was make three Build Configurations in the solution, 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?OutDir
. This worked, but caused the Binaries folder to not get a copy of the output.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
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.
And you also have to set "CustomizableOutDir" to true in the TFSBuild.proj file to get it to respect the project level configurations.
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?
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