바이너리 참조가 아닌 프로젝트 참조를 언제 사용해야 합니까?

Question

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

프로젝트 참조를 지지하는 몇 가지 주장:

• 프로젝트 참조를 통해 사용자는 추가 프로젝트/솔루션을 로드하는 오버헤드 없이 모든 솔루션 코드를 디버그하고 볼 수 있습니다.
• 활성 솔루션 없이도 변경 사항을 쉽게 식별할 수 있으므로 프로젝트 참조는 소스 제어 시스템에 적용된 공통 구성 요소 변경 사항을 따라잡는 데 도움이 됩니다.

바이너리 참조를 지지하는 몇 가지 주장:

• 이진 참조는 솔루션을 단순화하고 솔루션 로딩 시간을 더 빠르게 만듭니다.
• 바이너리 참조를 사용하면 개발자는 이미 구워지고 안정성이 입증된 코드로 인해 주의가 산만해지기보다는 새로운 코드에 집중할 수 있습니다.
• 바이너리 참조는 조직 외부의 사람들이 요구하는 것과 마찬가지로 공용 라이브러리를 사용할 때 우리가 우리의 자료를 적절하게 dogfood하도록 강요합니다.
• 바이너리 참조는 디버깅(단계화)할 수 없으므로 소비하는 애플리케이션의 컨텍스트 내에서만 테스트하고 수정하는 대신 기존 테스트 프로젝트를 확장하여 문제를 복제하고 수정해야 합니다.
• 바이너리 참조는 유입 버전이 아닌 바이너리의 안정적인 버전이 참조되므로 클래스 라이브러리 프로젝트의 동시 개발이 소비 애플리케이션에 영향을 미치지 않도록 보장합니다.필요한 경우 구성 요소의 최신 릴리스를 통합할지 여부는 프로젝트 리더가 결정합니다.

프로젝트 또는 바이너리 참조 사용과 관련하여 귀하의 정책/선호는 무엇입니까?

Answer 1

주요 내용을 모두 다루신 것 같습니다.최근 직장에서 비슷한 논의를 한 적이 있는데 아직 결정이 나지 않았습니다.

그러나 우리가 조사한 한 가지는 바이너리 파일을 참조하여 주목한 모든 이점을 얻으면서 소스 코드가 모든 개발자 컴퓨터에서 액세스할 수 있는 공통 위치에 있는 공통 빌드 시스템으로 바이너리를 구축하도록 하는 것입니다( 적어도 직장에서 네트워크에 앉아 있다면), 필요한 경우 모든 디버깅이 실제로 라이브러리 코드에 들어갈 수 있도록 합니다.

그러나 같은 메모에서 우리는 디버거가 완전히 건너뛰도록 하기 위해 적절한 속성을 사용하여 많은 기본 클래스에 태그를 지정했습니다. 왜냐하면 여러분이 자신의 클래스(개발 중인 수준에서)에서 수행하는 모든 디버깅은 기본 라이브러리의 코드에 의해서만 크기가 크게 커집니다.이렇게 쳤을 때 한 단계 더 나아가다 라이브러리 클래스의 바로 가기 키를 디버깅하면 수많은 라이브러리 코드를 헤쳐나가는 대신 현재 수준의 다음 코드 조각으로 다시 나타납니다.

기본적으로, 나는 검증된 라이브러리 코드를 일반 개발자의 눈에 띄지 않게 유지하는 것에 대한 귀하의 의견에 확실히 투표합니다(SO 용어로).

또한 모든 프로젝트와 기본적으로 모든 항목이 포함된 전역 솔루션 파일을 로드하면 Visual Studio가 사실상 정지 상태가 되므로 ReSharper 4에 일종의 관상 문제가 있는 것 같습니다.

Answer 2

제 생각에는 프로젝트 참조를 사용할 때 가장 큰 문제는 소비자에게 개발을 위한 공통 기준을 제공하지 않는다는 것입니다.도서관이 바뀌고 있다고 가정하고 있습니다.그렇다면 이를 구축하고 버전을 관리하면 쉽게 재현할 수 있는 환경을 얻을 수 있습니다.

이렇게 하지 않으면 참조된 프로젝트가 변경될 때 코드가 이상하게 중단될 수 있습니다.그러나 일부 기계에서만 가능합니다.

Answer 3

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

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

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

Answer 4

솔루션에서 이를 원하지 않거나 솔루션을 분할할 가능성이 있는 경우 모든 라이브러리 출력을 공통 bin 디렉터리 및 참조로 보냅니다.

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

Answer 5

귀하의 질문은 실제로 프로젝트가 동일한 솔루션에서 함께 진행되는 경우에 관한 것입니다.그 이유는 동일한 솔루션의 프로젝트에는 서로에 대한 프로젝트 참조가 있어야 하고, 다른 솔루션의 프로젝트에는 서로에 대한 이진 참조가 있어야 하기 때문입니다.

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

그러나 친밀감은 상대적입니다.정의에 따라 애플리케이션의 디자이너는 앱과 밀접하게 관련되어 있지만 디자이너와 애플리케이션이 동일한 솔루션 내에 있는 것을 원하지 않을 것입니다(즉, 둘이 전혀 복잡하다면).일반적인 일일 통합보다 더 먼 간격으로 병합되는 프로그램 분기에 대해 디자이너를 개발하고 싶을 것입니다.

Answer 6

프로젝트가 솔루션의 일부가 아니라면 거기에 포함하면 안 된다고 생각합니다...하지만 그건 내 생각일 뿐이야

요컨대 개념별로 나누어 본다