TFS 2008 년과 공통 라이브러리

Question

TFS 2008 폴더 구조 및 공용 라이브러리 내가 TFS에 걸쳐 수많은 다른 팀 프로젝트에 사용 된 코드를 개최한다 "공용 라이브러리"라는 팀 프로젝트를 만든

. 논증을 위해서 "공통 라이브러리"팀 프로젝트, MailProject 및 LoggingProject 아래에 2 개의 별개의 라이브러리가 있다고 가정 해 봅시다. TFS의 다른 프로젝트는 실제 소스 코드가 아닌 분기를 통해이 프로젝트의 바이너리 표현을 사용합니다.

이 팀 프로젝트의 폴더 구조를 설정하는 가장 좋은 방법은 무엇입니까? "공용 라이브러리"에 프로젝트를 추가하고 단순히 bin/release 폴더를 프로젝트의 일부로 "포함"합니까?

별도의 "배포"폴더를 만드는 사람들의 사례를 보았습니다. 나는 이것이 bin/release 폴더와 synonamous라고 생각한다?

---

다른 솔루션에서 사용할 수있는 소스 코드가 필요하지 않습니다.

현재 각 프로젝트에는 프로젝트에 포함 된 dll이 있습니다. 예를 들어 메일 링 모듈을 사용하면 많은 프로젝트에서 메일을 보낼 수있는 기능이 필요합니다. 공통 모듈은 매우 안정적이며 대부분 정적입니다.

그러나 메일 모듈이 변경되면 어떻게 될까요? 각 프로젝트를 체크 아웃하고 dll을 업데이트하는 것보다 더 좋은 방법이있는 것 같습니다. 'get latest'가 호출되면 TFS가 최신 메일 모듈을 가져올 수 있도록 허용 할 수 있습니까? 명시 적 또는 묵시적.

Answer 1

다른 솔루션에서 사용할 수있는 라이브러리의 소스 코드가 정말로 필요한 경우가 아니라면 내 조언은 TFS에서이 둘 사이의 명시 적 링크가없는 라이브러리를 사용하는 프로젝트의 라이브러리 용 이진 파일을 포함하는 것이 좋습니다 . 라이브러리 빌드의 사용자 정의 레이블은 공유 라이브러리의 선택된 버전을 쉽게 리턴하고 다시 작성하는 데 도움이 될 수 있습니다.

공유 라이브러리에 서로 다른 프로젝트의 버전이 필요한 경우 특정 프로젝트에 맞게 사용자 지정해야하는 라이브러리의 모든 버전에 대해 별도의 분기를 만드는 것이 좋습니다.

TFS에는 SVN의 '외관'과 유사한 개념이 없습니다. 따라서 프로젝트에 공유 라이브러리의 브랜치를 포함하고 해당 프로젝트를 브랜치하는 경우 변경 사항을 올바르게 전파하는 것이 매우 어렵습니다.

빌드에서 Get task을 사용하고 DDL의 최신 버전을 다른 프로젝트의 현재 프로젝트로 가져올 수 있지만 다른 프로젝트의 작업 영역을 가리킬 수 있는지 확인하십시오 (필자는 MSDN이 여기서 다소 모호하다). 공유 프로젝트에 별도의 작업 공간이 필요할 수도 있습니다.

공유 라이브러리의 모든 빌드에서 알려진 위치에 일반 구성 요소의 DLL을 게시하고 개별 빌드가 복사 작업을 통해 해당 일반 위치 (네트워크 공유)에서 사용할 수있는 버전을 얻는 방법도 있습니다 . 이것은 단순하고 공통 구성 요소의 버전 관리에 문제를 일으킬 수 있지만 단순한 경우 충분히 잘 작동합니다.