Team Development with Visual Studio Team Foundation Server

1. You want to reference an assembly generated by another project in the same
solution.
2. You want to reference an assembly generated by another project in a separate
solution.
3. You want to reference an assembly contained in another team project.
4. You want to reference a third-party assembly.
Referencing Assemblies Generated by another Project in the Same
Solution
If you need to reference another assembly in the same Visual Studio solution, use a
Visual Studio project reference. By using project references, you enable Visual Studio to
do a few things automatically for you, such as keeping build configuration
(debug/release) synchronized and tracking versioning and rebuilding of components as
necessary when assembly versions change.
Referencing Assemblies Generated by Projects in a Separate Solution
If you need to reference an assembly generated by a project in a different Visual Studio
solution, you have two choices:
• Use a file reference to point to the binary assembly.
• Add the Visual Studio project (project and source files) to your solution and then use
a project reference.
File references are more fragile than project references, do not adhere to your build
configuration, and are not tracked by Visual Studio build dependencies. Therefore, if the
assemblies that you have referenced changes, the Visual Studio build system does not
automatically know that a rebuild is required.
Alternatively you can branch the external project into your solution, build the binary and
then use a project reference. The reference will be more robust, although you need to
merge from the source branch regularly in order to pick up changes.
Referencing an Assembly from another Team Project
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.