NuGet 패키지를 참조하면서 고통없는 로컬 개발

Question

로컬 개발을위한 두통을 피하면서 버전 관리 된 NuGet 클래스 라이브러리 패키지를 게시하고 사용하려고합니다. 다음은 Visual Studio 솔루션의 샘플 레이아웃입니다.

| Libraries 
    | LibraryA 
    | LibraryB 
    | LibraryC 
| Applications 
    | ApplicationD 
    | ApplicationE 

이것은 공유 클래스 라이브러리와 여러 응용 프로그램을 모두 포함하는 단일 솔루션입니다. 현재 응용 프로그램에서 클래스 라이브러리에 대한 참조는 로컬의 솔루션 내 참조입니다.

라이브러리 (A, B, C)를 필요에 따라 응용 프로그램에서 참조하는 버전 NuGet 패키지로 게시하는 것이 좋습니다 (D, E). 이렇게하면 배포 된 응용 프로그램에 대한 업데이트와 독립된 공유 라이브러리 변경이 가능합니다. 이렇게하지 않으면 한 라이브러리를 변경하면 기술적으로 테스트해야하는 12 개 이상의 응용 프로그램에서 바이너리가 변경 될 수 있습니다. 이는 바람직하지 않으며 NuGet을 사용한 버전 관리로 해결됩니다.

그러나 LibraryA와 ApplicationD의 내용을 동시에 업데이트하려고한다고 가정 해 보겠습니다. NuGet으로 전환 한 후에이 작업을 수행하려면 LibraryA를 변경하고 커밋하고 패키지 생성을 기다리고 ApplicationD에 LibraryA에 대한 참조를 업데이트 한 다음 ApplicationD에서 테스트 또는 개발해야합니다. 이는 로컬 솔루션 내 참조를 사용하여 동시에 두 가지 작업을하는 것보다 훨씬 복잡합니다.

내 공유 클래스 라이브러리에 대해 버전이 지정된 NuGet 패키지의 견고 함을 얻는 동시에 여러 프로젝트 및 응용 프로그램에 걸쳐 있어도 개발을 간단하게 유지하는 더 좋은 방법은 무엇입니까? 내가 찾은 유일한 해결책은 모두 NuGet 패키지와 로컬 프로젝트 사이의 ApplicationD에 대한 참조를 끊임없이 변경해야하는 등 너무 많은 오버 헤드 또는 두통을 포함합니다.

편집 :는 전제를 명확히하기 위해,이 문제는 가정 다음 크게

공유 라이브러리가 비에 변경하려는 재구성 할 수

• 아키텍처 (솔루션 및 프로젝트 조직) 사소한 주파수
• 공유 라이브러리를 변경하면 응용 프로그램을 강제로 업데이트 할 수 없습니다.
• 응용 프로그램이 다른 버전의 공유 라이브러리를 참조 할 수 있습니다.

Answer 1

불행히도 두 가지 장점을 모두 활용하는 방법은 없습니다. 회사 내부적으로, NuGet 패키지를 항상 참조하면서 대부분의 부담을 줄이는 빠른 빌드/배포 프로세스로 어느 정도 완화되었습니다. 기본적으로 모든 응용 프로그램은 로컬 NuGet 저장소에서 호스팅되는 동일한 라이브러리의 다른 버전을 사용합니다. 패키지를 제작, 배포 및 호스트하기 위해 자체 소프트웨어를 사용하기 때문에 라이브러리를 신속하게 업데이트 한 다음 다른 솔루션에서 NuGet 패키지를 업데이트 할 수 있습니다. 기본적으로, 우리가 발견 한 가장 빠른 작업 흐름이 있습니다 :

1. 하는 라이브러리
자동
2. 소비자 응용 프로그램에서
3. 업데이트 NuGet 패키지를 공급 구축 및 내부 NuGet에 1 씩 증가 라이브러리의 버전을 배포을 변경합니다

체크인부터 소비 프로젝트 업데이트까지 전체 프로세스는 약 3 분이 걸립니다. NuGet 저장소에는 또한 디버깅과 함께 대단히 도움이되는 심볼/소스 서버가 있습니다.

Answer 2

일부 작업이 필요하지만 적절한 참조에 Condition 특성을 추가하여 조건부 참조를 설정하기 위해 .csproj 파일을 직접 편집 할 수 있습니다.

편집이 나는이 내 언급 생산 코드가 작동하는 방법이다 보인다, ItemGroups에 이러한 조건을 이동 한, 2013

<ItemGroup Condition="'$(Configuration)' == 'Debug Local'"> 
    <!-- Library A reference as generated by VS for an in-solution reference, children unmodified --> 
    <ProjectReference>... 
</ItemGroup> 

<ItemGroup Condition="'$(Configuration)' == 'Debug NuGet'"> 
    <!-- Library A reference as generated by NuGet, child nodes unmodified --> 
    <Reference Include="LibraryA">... 
</ItemGroup> 

VS이있는 가능한 문제에 대한 언급이있다

이렇게하면 프로젝트 D & E에서 라이브러리를 다르게 참조하는 "Debug NuGet"대 "Debug Local"구성을 가질 수 있습니다. 그 다음에 해당 프로젝트의 해당 구성에 매핑 된 여러 솔루션 파일이있는 경우 솔루션 구성이므로 최종 사용자는 대부분의 작업에 대해 "디버그"및 "릴리스"이상을 볼 수 없으며 A, B, & C 프로젝트 편집을위한 전체 솔루션을 열어야합니다.

이제는 A, B, & C 프로젝트를 방해하지 않으므로 subrepo로 표시된 폴더 아래에 설정할 수 있습니다 (Git과 같이 이것을 지원하는 SCM을 사용한다고 가정) . 대부분의 사용자는 ABC 프로젝트에 액세스하지 않기 때문에 서브 페어를 가져올 필요가 없으며 대신 NuGet에서 가져옵니다.

정비가 현명한 경우, VS가 조건부 참조를 편집하지 않으며 편집 중에이를 존중할 것입니다. VS 2010 및 2013 (EDIT : Professional 버전을 모두 통과했습니다. 같은 익스프레션과 동일 함). VS에서보다 명심하십시오. 참조는 버전에 구애받지 않으며, NuGet은 버전을 유지해야하는 유일한 곳으로 만들고, 다른 NuGet 패키지처럼 수행 할 수 있습니다. 나는 희망이 있지만, NuGet이 조건부 참조로 싸울 지 여부는 테스트하지 않았습니다.

EDIT 조건부 참조는 누락 된 DLL에 대한 경고를 유발할 수 있지만 실제로 컴파일 또는 실행을 방해하지는 않습니다.

Answer 3

나는 이것이 2 년 된 게시물이라는 것을 알고 있지만, 같은 상황에 직면하면서 발견했다. VS2015에서도이 점을 발견했습니다. 테스트를 진행하고 있습니다. 나는 다시 와서 내 대답을 적절하게 조정할 것이다.

https://marketplace.visualstudio.com/items?itemName=RicoSuter.NuGetReferenceSwitcherforVisualStudio2015