views:

204

answers:

1

Hi,

Following Situation:

  • 2 Team Projects
  • Dvelop of Team Project A added Project References of Team Project B to their projects.

For speeding up the Build I want to replace the project references with referencing the dll's directly.

My Idea:

in the csproj of Team Project A:

<ProjectReference Condition="'$(IsDesktopBuild)' == 'true'" Include="[Project Reference] >...

in the TFSBuild.proj

<AdditionalReferencePath Include="[buildoutputOfTeamProjectB]" />

OR

Disable SolutionToBuild and use the csproj files directly.

Thanks for your suggestions.

A: 

I would suggest that each project have a dependencies folder that contains the appropriate dlls that are required for each project. When a project that is depended upon is built it would be up to you to automatically update the dll in the dependencies folder or not via your build process (cruise control/nant/msbuild?). However, I would also give some consideration around deploying versions of the depended upon dll just in case you blow up the dependent projects usage of that dll. It would suck for someone to update their project (the depended on project), kick off a build, deploy their build output to the dependent project) only to break the project that relies on their code base. That sounds like a fragile way of managing dependencies.

Andrew Siemer
Hi Andrew, We are using MSBuild/TFSBuild. The developers want to use the project refererences to easier make changes to the lib project, without switching around 2 Solutions. But that leads to an excessive build process on the TFS. Therefore I need a way to remove the project references from the csproj File and replace them with dll references.
Marco Wlotzka
We have a folder with the shared buildoutput already, but it doesn't seem to be possible to configure the csproj for using them, when I remove the projectreferences with the IsDesktopBuild Condition.
Marco Wlotzka
What we are currently doing is having specialized solutions. In your case you might have a solution for ProjectA, and one ProjectB...and one that contains both ProjectA and ProjectB. Having multiple solutions shouldn't be an issue. Rather than doing cool logic in your project file, perhaps your local build script should take care of generating your project/solution files based on the environment. Knowing what environment a build is running in is easier than embedding logic in your project file!
Andrew Siemer
Project references within a project and Solutions containing projects from other solutions aren't the same. The only thing I see is that I have to configure the project to use the dll's and not the project references to get it build in both solutions. But doesn't that leads to the disadvantage that the dll's of project B have to be build on the local machine before source code changes takes an effect on the referenced dll's of project A?
Marco Wlotzka