I have got the following structure:
$
--TeamProject1
---Solution1.sln
----TestProject1
--TeamProject2
---Solution2.sln
----TestProject2
In TestProject1, I add TestProject2.dll as reference (Not a project reference, but a file reference). My question is: how to build a solution that reference to assemblies belonging to different team project?
I have got TFSBuild.proj file containing the following info:
<TfCommand>$(TeamBuildRefPath)\..\tf.exe</TfCommand>
<SolutionToBuild Include="$(BuildProjectFolderPath)/../../DEV/TeamProject1.sln">
<Targets></Targets>
<Properties></Properties>
</SolutionToBuild>
<Map Include="$/TeamProject1">
<LocalPath>$(SolutionRoot)</LocalPath>
</Map>
<Map Include="$/TeamProject2">
<LocalPath>$(SolutionRoot)</LocalPath>
</Map>
<Target Name="BeforeGet">
<DeleteWorkspaceTask TeamFoundationServerUrl="$(TeamFoundationServerUrl)" Name="$(WorkspaceName)" />
<Exec WorkingDirectory="$(SolutionRoot)" Command=""$(TfCommand)" workspace /new $(WorkspaceName) /server:$(TeamFoundationServerUrl)" />
<Exec WorkingDirectory="$(SolutionRoot)" Command=""$(TfCommand)" workfold /unmap /workspace:$(WorkSpaceName) "$(SolutionRoot)"" />
<Exec WorkingDirectory="$(SolutionRoot)" Command=""$(TfCommand)" workfold /map /workspace:$(WorkSpaceName) /server:$(TeamFoundationServerUrl) "%(Map.Identity)" "%(Map.LocalPath)"" />
</Target>
Thanks in advance.
Xiaosu
AFAIK this is not possible and it will be problematic on developer's machines. File references is the way to go. I usually organize projects like this:
$
-- TeamProject1
-- branches
-- trunk
Solution1.sln
-- lib
TestProject2.dll
-- src
-- test
TestProject1.csproj references TestProject2.dll from lib
-- TeamProject2
-- branches
-- trunk
Solution2.sln
-- lib
-- src
-- test
TestProject2.csproj
This way TeamProject1 is independent from the source code of TeamProject2 and it contains all the necessary dependencies. If TeamProject2 changes it won't necessary break TeamProject1.
To quote the official TFS guide on CodePlex:
If you share source or binaries across team projects, you have two options:
Branching. With this approach, you branch the source from the other team project into your current solution. This creates a configuration that unifies the source from the shared location and your project on the server-side.
Workspace Mapping. With this approach, you map the source from the other team project into a workspace on your development computer. This creates a configuration that unifies the source from the other team project and your project on the client-side.
Branching is the preferred approach because it stores the dependency relationship on the source control server. Workspace mapping is a client-side-only approach, which means that you and every developer must create the mapping on your own computers and also on the build server in order to successfully build the application.
Branching adds additional merge overhead but it enables you to make the decision to pick up updated binaries or source more explicitly.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With