.NET Framework 버전 관리 시스템에서 타사 DLL의 위치

Question

버전 관리 시스템에서 .NET 프로젝트에 대한 타사 참조 Dll을 검사하는 데 이상적인 위치 (디렉토리)는 무엇이 될까요? 일반적으로 나는 대부분의 사람들이 빈 밑에 두는 것을 보았습니다. 그래서 런타임은 자동으로이 파일들을 픽업 할 수 있습니다. 그러나 그것이 올바른 길입니다.

필자는 원래 lib 디렉토리에있는 lib 디렉토리와 병렬 인 별도의 디렉토리를 원했습니다. lib 디렉토리는 모든 타사 DLL을 포함하지만 lib 디렉토리가 런타임에 선택되도록 응용 프로그램 구성 파일을 변경해야합니다. 여기에 내 생각은 lib 디렉토리에는 제 3 자 DLL이 포함되어 있고 bin에는 프로젝트 바이너리 (Dll 또는 Exe 일 수 있음)가 포함됩니다.

선호되는 방법은 무엇입니까? 물리적 파일 시스템.

Answer 1

우리는 다음과 같은 디렉토리 구조 (on my blog 사용할 수 자세한 내용)를 사용합니다. 이들은 컴파일 타임에 각 프로젝트의 "bin"폴더에 자동으로 복사됩니다. ("Libraries"폴더는 물론 버전 관리에 전념합니다.)

Answer 2

타사 어셈블리가 포함 된 별도의 디렉터리를 만들면 (이렇게하면 소스 제어에서 유지 관리가 더 쉬워집니다) 프로젝트에 이러한 어셈블리에 대한 참조가 만들어집니다. 그런 다음 빌드시 타사 어셈블리가 \bin에 복사되므로 구성을 변경할 필요가 없습니다. 은 "도서관"폴더에 (참조 추가 대화 상자에서 '찾아보기'탭을 사용하여)

Solution\ 
    Libraries\ 
    third-party DLLs here 
    Source\ 
    Project1\ 
    Project2\ 

각 프로젝트 참조 어셈블리 :

Answer 3

그 이상의 타사 DLL이 귀하의 프로젝트에서 더 많이 사용된다고 가정합니다. 따라서 DLL을 모든 프로젝트의 빈 밑에 직접 두는 것은 프로젝트가 우아하지 않은 것처럼 (VCS에서) 많은 DLL 복사본을 갖는 최종 사용자를 의미합니다. Andrew H. mentionned가 말하듯이, DLL이 정말로 공통적 인 경우, DLL은 공통 디렉토리에 있어야합니다.이 디렉토리는 필요한 다른 모든 프로젝트에서 참조됩니다. 여기에 유일한 캐치는 같은 DLL의 다른 버전을 구별 할 수있는됩니다 는 :

/common/ThirdPartyLibrary.dll (version 1.2)  
/common/ThirdPartyLibrary.dll (version 1.3) 

나는 (지금은) 알고있는 가장 좋은 방법은 그 주위에 제 3의 이름을 변경됩니다 : 시간이 지남에, 당신은 같은 끝낼 수 있습니다 명시 적 버전 번호를 가진 타사 DLL을 사용하고 프로젝트에서 새 이름을 참조하면 프로젝트가 항상 올바른 버전을 참조하게됩니다. 유사 :

/common/ThirdPartyLibrary_v1.2.dll  
/common/ThirdPartyLibrary_v1.3.dll