Partager via

Resolving assembly references in Team Build ( Part - 1 )

  • Article

 

In this entry I will be discussing about project to project references. I will be enumerating about different scenarios and mentioning workarounds to get them to build in Team Build.

  • Scenario 1 - Single solution containing multiple projects. Projects have inter-dependencies.

Case 1.1: All the sources are in the same team project. References are added using “project references”.

Recommendations/guidelines

  1. Team Build handles this scenario well. There is no need for customization of build scripts and you will get all the build statistics like work item resolved, change sets affected, etc.
  2. Project to project references within the solution are automatically resolved using MS build. MS build also takes care of the versioning problem.
  3. The only recommendation is to avoid having file references.

Case 1.2: Sources are distributed across different team projects. References are added using “project references”.

Recommendations/guidelines

  1. You are responsible for preserving the folder structure under the build directory. This is required to honor the project to project references links. (defined in individual project build scripts)

  2. Try to avoid referencing sources across team projects. Ideally all related projects and sources should be checked in under the same team project.

  3. Again the recommendation is to avoid having file references.

  4. Team Build requires of the build scripts customization.

    1. User is expected to include a custom task to sync sources belonging to different team projects.

    2. By default reports will show the build details of active team project only. If user wants to get the build details (change sets, work items, etc) for sources belonging to different team project, he has to manually customize the targets file. We strongly discourage any modification of targets file.

[example]

Case 1.3: Sources are distributed across different team projects. The team projects belong to different AT.

Recommendations/guidelines (same as case 1.2)

[example]

  • Scenario 2 – Multiple (independent) solutions belonging to same team project.

Team Build supports this scenario. User can specify the solution ordering in the build type definition wizard.

Recommendations/guidelines (same as same as scenario 4)

  • Scenario 3 – Multiple (independent) solutions belonging to different team projects.

Recommendations/guidelines

  1. Team Build support this scenario but requires customization of build scripts.

  2. The main issues are

    1. Wizard will only display solutions belonging to active team project. User is responsible to edit the build type definition to include the solutions belonging to different team project

    2. User is responsible for syncing the sources from different team projects and maintaining the same directory structure under the build directory.

    3. User will get build statistics for only active team project. If user wants to get the build details (change sets, work items, etc) for sources belonging to different team project, he has to manually customize the targets file. We strongly discourage any modification of targets file.

[example]

  • Scenario 4 – Multiple (dependent) solutions with project references across solutions belonging to same/different team projects

    Recommendations/guidelines

    1. MS Build and Team Build do not support this scenario because project to project references across solutions are not supported in Whidbey.
    2. The workaround is to avoid project to project references across solutions and have file references to resolve dependencies.

    [example]