Visual Studio 솔루션 간의 외부 종속성을 어떻게 공유합니까?

StackOverflow https://stackoverflow.com/questions/1217005

문제

Java 배경이 있으므로 Maven이 다운로드 및 의존성을 최신 상태로 유지하는 데있어 모든 문제를 처리하는 데 익숙합니다. 그러나 .NET 환경에서는 이러한 모든 외부 종속성을 관리하는 좋은 방법을 아직 찾지 못했습니다.

여기서 주요 문제는 내가 대량 생산 솔루션을 생산하고 모두 동일한 제 3 자 DLL에 의존하는 경향이 있다는 것입니다. 그러나 각 솔루션에서 각 구성 요소의 별도 사본을 유지하고 싶지 않습니다. 따라서 모든 다른 솔루션을 동일한 DLL 세트에 연결하는 방법이 필요합니다.

하나의 솔루션은 모든 솔루션에 포함 된 "라이브러리 프로젝트"에 외부 라이브러리를 포함하고 다른 프로젝트가이를 통해이를 참조하도록하는 것임을 깨달았습니다. (또는 모든 프로젝트에 대해 동일한 장소에서 외부 DLL을 참조하십시오.)

그러나 이것을하는 더 좋은 방법이 있습니까? (가급적 Visual Studio에 일종의 플러그인을 사용합니다.)

나는 보았다 Visual Studio Dependency Manager 그리고 그것은 완벽한 경기처럼 보이지만 누군가가 그것을 시도한 사람이 있습니까? 나는 또한 Maven의 .NET 포트를 보았지만 불행히도 나는 그 상태에 너무 깊은 인상을주지 않았습니다. (그러나 내가 그들에게 또 다른 시도를해야한다고 생각한다면 그들에게 추천하십시오.)

그렇다면이 문제를 해결하는 가장 현명한 방법은 무엇입니까?

업데이트:

나는 내가 의미하는 바를 설명해야한다는 것을 깨달았다. 동일한 DLL 세트에 연결됩니다.

여기서 달성하려는 것 중 하나는 다른 솔루션이 각 구성 요소의 다른 버전을 참조하는 것을 피하는 것입니다. 구성 요소를 새 버전으로 업데이트하면 다음 빌드시 모든 솔루션에 대해 업데이트해야합니다. 이를 통해 모든 솔루션이 최신 구성 요소와 최신 상태인지 확인해야합니다.

Update 2:이것은 도구 전에 묻는 오래된 질문입니다. 너겟 또는 OpenWrap 존재했다. 누구든지 최신 정보를 기꺼이 제공하려는 경우 계속해서 수락 된 답변을 변경하겠습니다.

도움이 되었습니까?

해결책

  1. 어셈블리를 보관할 곳을 찾으십시오. 예를 들어 .NET 코어 어셈블리를 다음과 같은 저장합니다.

    • <branch> netfx 2.0527\*
    • <branch> netfx 3.0\*
    • <branch> netfx 3.5\*
    • <branch> netfx silverlight 2\*
    • <branch> netfx silverlight 3\*

  2. MSBuild (또는 Team Build의 추가 회의 경로)의 ReferencePath 속성을 사용하여 프로젝트를 적절한 경로를 가리 킵니다. 단순성과 유지 보수가 용이하기 위해서는 그러한 모든 디렉토리에 대해 알고있는 1 *.targets 파일이 있습니다. 내 모든 프로젝트는 해당 파일을 가져옵니다.

  3. 버전 제어 전략 (분기, 병합, 로컬 <-> 서버 매핑)이 프로젝트와 참조 경로 간의 상대 경로를 일정하게 유지하십시오.

편집하다

질문의 업데이트에 대한 응답으로 한 단계 더 추가하겠습니다.

4) 모든 프로젝트 파일의 모든 어셈블리 참조가 전체 .NET 강력한 이름을 사용하는지 확인하십시오. 그리고 다른 것은 없습니다.

나쁜:

<Reference Include="Microsoft.SqlServer.Smo">
  <SpecificVersion`>False</SpecificVersion>
  <HintPath>..\..\..\..\..\..\..\Program Files (x86)\Microsoft SQL Server\100\Shared\Microsoft.SqlServer.Smo.dll</HintPath>
</Reference>

좋은:

<Reference Include="Microsoft.SqlServer.Smo, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91, processorArchitecture=MSIL" />

후자의 장점 :

  • 협업 개발 환경에서 힌트 경로를 사용하면 필연적으로 "나를 위해 일하는"상황이 아니라 다른 사람들이 아닌 상황으로 이어질 것입니다. 특히 빌드 서버. 생략하면 참조 경로를 올바르게 얻거나 컴파일하지 않습니다.
  • 약한 이름을 사용하면 "DLL Hell"의 가능성이 초대됩니다. 강한 이름을 사용하면 링커가 모든 기준과 일치하는 링커 만로드하기 때문에 참조 경로에 동일한 어셈블리의 여러 버전을 갖는 것이 안전합니다. 또한, 일부 어셈블리를 제자리에 업데이트하기로 결정하면 (사본을 추가하는 대신) 컴파일 시간 대신 컴파일 변경 사항을 깨뜨릴 수 있습니다. 버그가 들어올 때마다.

다른 팁

다른 사람들이 말하는 것에 추가하면 기본적으로 두 가지가 있습니다.

  1. 모든 개발자가 동일한 버전의 외부 라이브러리를 가지고 있는지 확인합니다.
  2. 모든 개발자가 동일한 장소에 외부 라이브러리가 있는지 확인하십시오 (적어도 소스 코드와 관련하여)

Richard Berg가 지적했듯이 ReferencePath 및/또는 추가 레시피 스팟을 사용하여 #2를 해결할 수 있습니다. 빌드 프로세스에서 MSBuild를 사용하는 경우 (우리의 경우 MS 팀 빌드 대신 CruiseControl을 사용하고 있음) 명령 줄에서 참조 경로를 전달할 수도 있습니다. #1을 해결하기 위해 찾았습니다 SVN : 외부 유용합니다 (SVN을 사용하는 경우).

Maven에 대한 나의 경험은 대부분의 목적에 대한 과도한 길이라는 것입니다.

나는 일반적으로 외부 또는 내부 종속성에 대한 소스 컨트롤에 별도의 폴더 구조를 가지고 있으며,이 filders는 예를 들어 빌드 또는 버전 번호에 따라 어셈블리를 가지고 있습니다.

공개 외부 라이브러리 nunit 2.6

또는

공개 내부 라이브러리 logger 5.4.312

그리고 솔루션 내부에서 의존성을 사용해야하는 모든 프로젝트는 공개 내부 또는 외부 폴더의 어셈블리에 대한 참조를 추가합니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top