언제 바이너리 참조와 반대되는 프로젝트 참조를 사용해야합니까?

Question

우리 회사는 테스트 프로젝트 지원과 함께 많은 클래스의 libary 프로젝트로 구성된 공통 코드 라이브러리를 보유하고 있습니다. 각 클래스 라이브러리 프로젝트는 단일 바이너리를 출력합니다. Company.Common.Serialization.dll. 컴파일되고 테스트 된 바이너리와 소스 코드를 소유하고 있기 때문에 우리가 사용하는 응용 프로그램에서 바이너리 또는 프로젝트 참조를 사용해야하는지 여부에 대한 논쟁이 있습니다. 프로젝트 참조에 찬성

일부 인수 :

• 프로젝트 참조는 사용자가 디버깅 및 추가 프로젝트/솔루션을로드하는 오버 헤드없이 모든 솔루션 코드를 볼 수있다.
• 프로젝트 참조는 소스 제어 시스템에 커밋 된 공통 구성 요소 변경 사항을 유지하는 데 도움이되며 변경 사항은 활성 솔루션없이 쉽게 식별 할 수 있습니다. 바이너리 참조 찬성

일부 인수 :

• 진 참조 솔루션을 단순화하고 빠른 솔루션 로딩 시간을 위해 만들 것입니다.
• 바이너리 참조는 개발자가 이미 구워지고 안정된 것으로 입증 된 코드에주의를 기울이지 않고 새로운 코드에만 집중할 수있게합니다.
• 진 참조는 우리가 우리 조직의 그 외부가 수행해야하는 것과 마찬가지로 공용 라이브러리를 사용하는 것처럼 적절하게 우리의 물건을 dogfood에 우리를 강제.
• 바이너리 참조 디버깅 할 수 없기 때문에 (에 들어갔다), 하나 복제하고 기존 테스트 프로젝트를 확장보다는 테스트하고 혼자 소비 응용 프로그램의 컨텍스트 내에서 고정하여 문제를 해결하도록 강요 될 것이다.
• 진 참조는 이진의 안정 버전이 유입 버전보다는 참조 할 것 같은 클래스 라이브러리 프로젝트에 동시 개발이 소비하는 응용 프로그램에 영향을주지 않습니다 것을 보장합니다. 필요한 경우 구성 요소의 최신 릴리스를 통합할지 여부는 프로젝트 책임자의 결정입니다.

이 프로젝트 또는 바이너리 참조를 사용에 관해서 정책/환경 설정은 무엇입니까?

Answer 1

모든 주요 사항을 다 뤘던 것처럼 들립니다. 우리는 최근에 직장에서 유사한 토론을 가졌으며 아직 결정되지 않았습니다.

그러나 우리가 살펴본 한 가지는 바이너리 파일을 참조하여 모든 이점을 얻을 수 있지만 소스 코드가 공통 위치에 있으며 공통 소스 코드에서 액세스 할 수있는 공통 빌드 시스템으로 바이너리를 작성하는 것입니다 모든 개발자 머신 (적어도 직장에서 네트워크에 앉아있는 경우), 필요한 경우 모든 디버깅이 실제로 라이브러리 코드로 다이빙 할 수 있습니다.

그러나 동일한 메모에서 우리는 디버거가 완전히 건너 뛰도록하기 위해 많은 기본 클래스에 적절한 속성을 태그했습니다. 왜냐하면 자신의 클래스에서 수행하는 모든 디버깅 (' 재 개발)은 기본 라이브러리의 코드에 의해서만 크게 표준화 될 것입니다. 당신이 라이브러리 클래스에 디버깅 바로 가기 키 안으로 정제 단계에 충돌이 방법 대신 라이브러리 코드의 톤을 통해 웨이드 필요없이, 현재의 수준에서 코드의 다음 조각으로 재 포장.

기본적으로, 나는 확실히 일반 개발자 보이지 않는 검증 된 라이브러리 코드를 유지 대해 (SO 측면에서) 귀하의 의견을 투표.

또한 ReSharper 4에는 모든 프로젝트가 포함되어 있고 기본적으로 모든 것이 들어있는 글로벌 솔루션 파일을로드하는 경우 Visual Studio가 실질적으로 정지 상태가되기 때문에 관상 동파 문제가있는 것으로 보입니다.

Answer 2

제 생각에는 프로젝트 참조를 사용할 때 가장 큰 문제점은 소비자에게 개발을위한 공통 기준을 제공하지 않는다는 것입니다. 나는 도서관이 변화하고 있다고 가정하고있다. 그렇다면 버전을 빌드하고 버전이 만들어 졌는지 확인하면 쉽게 재현 할 수있는 환경을 제공 할 것입니다.

이렇게하지 않으면 참조 된 프로젝트가 변경 될 때 코드가 신비하게 깨지게됩니다. 그러나 일부 기계에서만 가능합니다.

Answer 3

나는 프로젝트가 솔루션의 일부가 아닌 경우, 당신은 거기에 포함되지해야한다고 생각 ...하지만 나는 짧은

Answer 4

의 개념으로 그것을 분리 그냥 내 의견

때 당신 돈 귀하의 솔루션에 그것을 원하지 않거나 귀하의 솔루션을 분할 할 가능성이 있습니다. 모든 라이브러리 출력을 공통의 bin 디렉토리에 보내고 참조하십시오.

개발자가 도메인, 테스트 및 웹 프로젝트 만있는 엄격한 솔루션을 열 수 있도록하기 위해이 작업을 수행했습니다. 우리의 승리 서비스와 실버 라이트, 웹 컨트롤 라이브러리는 바라 볼 때 필요한 프로젝트가 포함 된 별도의 솔루션에 있지만, 모든 것을 구축 할 수는 없습니다.

Answer 5

귀하의 질문은 실제로 프로젝트가 동일한 솔루션으로 통합 될 때의 질문이라고 생각합니다. 그 이유는 동일한 솔루션의 프로젝트가 서로 프로젝트 참조를 가져야하고 다른 솔루션의 프로젝트가 서로 바이너리 참조를 가져야하기 때문입니다.

솔루션에 밀접하게 함께 개발 된 프로젝트가 포함되어야한다고 생각하는 경향이 있습니다. API 어셈블리 및 해당 API 구현과 같은

그러나 클로징은 상대적입니다. 정의에 따르면 응용 프로그램 디자이너는 응용 프로그램과 밀접한 관련이 있지만 동일한 솔루션 내에 디자이너와 응용 프로그램을 갖고 싶지는 않습니다. 아마도 일상적인 통합보다 간격을 두어 간격을두고 병합되는 프로그램 분기에 대해 디자이너를 개발하고 싶을 것입니다.

Answer 6

이와 같은 공용 라이브러리를 제 3 자 리소스로 취급하는 경향이 있습니다. 이를 통해 라이브러리는 자체 빌드 프로세스, QA 테스트 등을 가질 수 있습니다. QA (또는 누구든지)가 라이브러리 릴리스를 축복하면 모든 개발자가 사용할 수있는 중앙 위치로 복사됩니다. 바이너리를 프로젝트 폴더에 복사하고 프로젝트에서 바이너리 참조를 사용하여 라이브러리 버전을 결정하는 것은 각 프로젝트마다 다릅니다.

중요한 점 중 하나는 라이브러리의 각 빌드와 함께 디버그 기호 (pdb) 파일을 만들어 사용할 수있게 만드는 것입니다. 다른 옵션은 실제로 네트워크에 로컬 심볼 저장소를 만들고 각 개발자가 해당 심볼 저장소를 VS 구성에 추가하도록하는 것입니다. 이렇게하면 코드를 통해 디버깅 할 수 있고 여전히 바이너리 참조를 사용하는 이점이 있습니다.

프로젝트 참조를 위해 언급 한 이점에 대해서는 두 번째 사항에 동의하지 않습니다. 필자는 소비 프로젝트가 자신이 소비하고있는 공통 라이브러리의 버전을 명시 적으로 알고 해당 버전을 업그레이드하기 위해 의도적으로 조치를 취하는 것이 중요합니다. 이것은 완료되지 않았거나 테스트되지 않은 라이브러리의 변경 사항을 우연히 선택하지 않도록하는 가장 좋은 방법입니다.