zespołu Budowanie z wielu projektów zespołu

Question

Mam następującą strukturę:

$ 
--TeamProject1 
---Solution1.sln 
----TestProject1 
--TeamProject2 
---Solution2.sln 
----TestProject2 

W TestProject1 dodam TestProject2.dll jako odniesienie (nie Przykładowy projekt, ale referencyjny nadany). Moje pytanie brzmi: jak zbudować rozwiązanie odnoszące się do zespołów należących do innego projektu zespołowego?

Mam plik TFSBuild.proj zawierającą następujące informacje:

<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="&quot;$(TfCommand)&quot; workspace /new $(WorkspaceName) /server:$(TeamFoundationServerUrl)" /> 
    <Exec WorkingDirectory="$(SolutionRoot)" Command="&quot;$(TfCommand)&quot; workfold /unmap /workspace:$(WorkSpaceName) &quot;$(SolutionRoot)&quot;" /> 
    <Exec WorkingDirectory="$(SolutionRoot)" Command="&quot;$(TfCommand)&quot; workfold /map /workspace:$(WorkSpaceName) /server:$(TeamFoundationServerUrl) &quot;%(Map.Identity)&quot; &quot;%(Map.LocalPath)&quot;" /> 
    </Target> 

Z góry dzięki.

Xiaosu

Answer 1

AFAIK nie jest to możliwe i to będzie problematyczne na maszynach autora. Odniesienia do pliku są drogą do zrobienia. Zwykle organizować projekty tak:

$ 
-- 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 

ten sposób TeamProject1 jest niezależny od kodu źródłowego TeamProject2 i zawiera wszystkie niezbędne zależności. Jeśli zmieni się TeamProject2, nie będzie konieczne przerwanie TeamProject1.

Answer 2

Cytując official TFS guide on CodePlex:

Jeśli dzielisz źródła lub pliki binarne w projektach zespołowych, masz dwie opcje:

• rozgałęzienia. Dzięki takiemu podejściu odsyłasz źródło z projektu drugiego zespołu do obecnego rozwiązania. Tworzy to konfigurację, która ujednolica źródło ze współdzielonej lokalizacji i twojego projektu po stronie serwera.

• Mapowanie obszaru roboczego. Dzięki takiemu podejściu mapujesz źródło z projektu drugiego zespołu do obszaru roboczego na komputerze programistycznym. Tworzy to konfigurację, która ujednolica źródło z innego projektu zespołu i twojego projektu po stronie klienta.

Rozgałęzienie jest preferowanym podejściem, ponieważ przechowuje relację zależności na źródłowym serwerze sterującym. Mapowanie obszaru roboczego jest podejściem tylko po stronie klienta, co oznacza, że ​​ty i każdy programista musi utworzyć mapowanie na własnych komputerach, a także na serwerze kompilacji, aby pomyślnie zbudować aplikację.

Rozgałęzienie dodaje dodatkowy koszt scalenia, ale umożliwia podjęcie decyzji o wyraźnym pobraniu zaktualizowanych plików binarnych lub źródła.

Answer 3

Bardzo trudno było znaleźć właściwą odpowiedź na to i zmarnował wiele mojego czasu.Więc jeśli kiedykolwiek miał ten problem, tu jest link do właściwego rozwiązania

https://social.msdn.microsoft.com/Forums/sqlserver/en-US/9918911f-5951-43be-9ee9-00214cf17400/buildvnext-and-multiple-team-projects?forum=tfsbuild

Zasadniczo UI nie pozwalają wybrać projekt więcej niż jeden zespół na swojej kolekcji. Ale zawsze możesz wpisać rzeczywistą ścieżkę do innych projektów zespołu i zadziała