다음 시나리오를 일반 버전의 VS로 구현할 수 있는지 알려주십시오. 비 팀 에디션입니다. 첫째, 우리 팀은 약 10 명 정도의 개발자이며 SVN을 저장소로 사용하고 있습니다. 디렉토리 구조는 모든 개발자 상대적으로 동일하며Visual Studio에서 팀 작업 구성
작업 \ 배포
작업 \ 소스
모든 프로젝트는 "소스"디렉토리에 상주하고 "배포"디렉토리에 출력 DLL을 넣어처럼 단순 위해 같습니다.
그래서 "CoreLibrary"프로젝트에서 작업 중이며 출력 dll은 CoreLibrary.dll이고 두 번째 프로젝트는 "CoreLibrary.dll"이라는 참조로 사용되는 "SomeLibrary"프로젝트에서 작업 중입니다. 이것은 단순한 상황입니다, 실제 생활 에서이 프로젝트는 다른 개발자의 책임의 대상이되는 수많은 dll에 의존 할 수 있습니다. 이 시나리오에서는 SomeLibrary가 컴파일 된 후 CoreLibrary가 변경되는 상황이 될 수 있습니다. 그리고 예를 들어 다른 개발자에게 그들의 참조를 갱신하는 것을 잊어 버린 경우. 그리고이 변경으로 인해 SomeLibrary 프로젝트는 컴파일되지 않지만 실행시에만 알 수 있습니다.) 그래서이 문제를 피하기 위해 하나의 프로젝트가 다른 프로젝트를 참조 할 수있는 하나의 복합 솔루션으로 모든 프로젝트를 통합하도록 결정했습니다. , 그렇다면 전체 솔루션 빌드가 모든 것이 호환된다는 것을 의미합니다. 하지만 한 가지 문제가 있습니다.이 때문에 소스 프로젝트의 종속성을 dll에서 프로젝트로 변경해야합니다. 독립 실행 형 프로젝트를 열면 excalmation 아이콘이이 참조에 반대하지만 프로젝트는 여전히 컴파일 할 수 있습니다.
나는 결론으로서 - 우리는 dll을 통한 프로젝트 (각 프로젝트 - 원자력 기능) 사이의 참조를 가진다. 원자 성은 우리가 하나의 "원자"를 변경할 때이 변화가 다른 종속 원자와 호환되는지를 확인해야합니다. 이것은 우리가 최신 소스를로드하고 컴파일하려고하는 전반적인 솔루션을 갖는 것이 더 편리합니다. 그러나 dll에서 프로젝트로 프로젝트 간의 종속성을 변경해야합니다. 이는 소스 독립형 프로젝트에서 변경 사항이 참조하는 것처럼 "적절하지 않은 것 같습니다. 모든 개발자를위한 하나의 큰 솔루션을 만들고, 모든 소스를 다시 컴파일하도록 강요하고, 그의 프로젝트뿐만 아니라 나쁜 것도 있습니다.
모든 솔루션 개발자가 자신의 프로젝트를 작업 할 때 주 솔루션에 포함될 때마다이 솔루션에서 다른 프로젝트의 모든 소스를 다시 컴파일 할 때마다 디버깅 할 때마다 생각합니다. 이 순간에 프로세스가 느려집니다 –
공유 프로젝트를 진행하고 있다고 하시겠습니까? 각 개발자에게는 솔루션을 빌드 할 때만 다시 빌드해야하는 자체 프로젝트가 있어야합니다. – msarchet