.Net에서 여러 중복 솔루션 / 프로젝트를 구성하는 방법은 무엇입니까?

16

나는 최근 에 여러 개의 .net 솔루션이 있는 오래된 레거시 코드베이스로 새로운 클라이언트를 위해 일하기 시작했습니다 . 각 솔루션은 일반적으로 해당 솔루션에 고유 한 일부 프로젝트를 호스팅하지만 다른 프로젝트는 "빌리기"/ "링크"(기존 프로젝트 추가)합니다. 기술적으로 다른 솔루션에 속합니다 (적어도 TFS의 폴더 구조를 사용하는 경우)

나는 이것이 얽힌 설정을 보지 못했으며, 명확한 빌드 순서가 없으며 때로는 솔루션 A의 프로젝트가 솔루션 B에서 호스팅 된 프로젝트의 출력 디렉토리에서 직접 dll을 참조하고 때로는 프로젝트가 상주하더라도 직접 포함 된 경우가 있습니다. 폴더 구조에서 멀리 떨어져 있습니다.

모든 게 개발자 게으름에 최적화 된 것 같습니다.

CI 서버가없는 이유에 대해 대면했을 때와 같이 구성된 코드로 설정하기가 어렵다고 응답했습니다. (지금 설정 하고이 코드 구성을 저주하고 있습니다)

솔루션은 현명한 결정 이라고 생각 되는 배포 아티팩트 (함께 배포 해야하는 것들이 동일한 솔루션에 있음)를 중심으로 구성 되지만 해당 솔루션 (프로젝트)의 내용은 모든 곳에 있습니다.

여러 솔루션 / 배포 아티팩트에서 공통 클래스 라이브러리를 재사용 할 때 사용할 모범 사례에 대한 합의가 있습니까?

VCS에서 코드를 구성하는 방법
별도의 배포 아티팩트간에 비즈니스 로직 공유를 용이하게하는 방법

— 안드레아스
소스

9

다른 솔루션에 속하는 기존 프로젝트를 포함하는 팬은 결코 없었습니다. 하나의 솔루션에 대해 해당 프로젝트를 편집하면 다른 솔루션에서 무언가를 완전히 파괴하는 변수가 너무 많습니다. 그런 다음 해당 문제를 해결하면 원래 솔루션이 손상됩니다. 오히려 헹구고 반복하십시오.

이러한 종류의 종속성이 여러 솔루션으로 누출되면 종속 코드를 OWN 솔루션으로 분리하고 참조로 포함되는 블랙 박스 라이브러리를 만들고 싶습니다. 내 생각은 솔루션이 서로 얽혀있어 모든 솔루션에 대해 공유 프로젝트로 디버깅을 수행 할 수 있다는 것입니다. 라이브러리가 올바르게 빌드되고 테스트 된 경우 이러한 종류의 디버깅은 실제로 필요하지 않습니다. 도서관은 그 자체의 장점을 견딜 수 있어야하며 모든 소비자 프로젝트의 기대가 일관되게 충족 될 수 있도록 철저히 테스트되어야합니다.

— 조엘 이더 턴
소스

3

또한, 리팩토링은 당신이 경우 너무, 너무 쉽게이 일 할 느낌을 변화가 라이브러리 자체에서 확인하는 것이 중요 충분하다 충동 일부는, 당신이 그것을 응용 프로그램 프로젝트를 만들 수 있다는 것을 이제 라이브러리로 병합 이후 현재 작업에 집중하지 않고 적절한 테스트를 수행 할 시간이있는 경우.

— Aaronaught

@Aaronaught : +1.

— Joel Etherton

5

필자는 언급 한 것과 같은 TFS 구조를 실제로 구성했으며 CI에 고유 한 문제가 있지만 여러 가지 이점이 있습니다. 한 가지 분명한 점은 별도의 .NET 프로젝트에 대한 적절한 구성 요소 화를 지원 및 장려하고 100 % 테스트 범위를 장려함으로써 우수한 TDD를 지원한다는 것입니다. 바로 박쥐에서 나는 당신이 해결할 수있는 몇 가지 문제를 발견했습니다.

때로는 솔루션 A의 프로젝트가 솔루션 B에서 호스팅되는 프로젝트의 출력 디렉토리에서 직접 dll을 참조하기도합니다. 때로는 프로젝트가 폴더 구조에서 멀리 떨어져 있어도 프로젝트가 직접 포함 된 경우도 있습니다.

다른 디렉토리의 출력에 대한 이진 참조는 좋은 접근 방식이 아니며 프로젝트 참조와 혼합 될 때 나쁜 접근 방식이됩니다. 최소한 일관성을 위해 프로젝트 참조로 바이너리 참조를 변경하는 것을 선호하십시오. 이 시점에서 각 솔루션은 단일 빌드 가능한 애플리케이션 또는 애플리케이션 계층 (예 : SuperApp.sln, OtherAppServices.sln, OtherAppPresentationTier.sln)을 나타낼 수 있습니다.

모든 프로젝트를 구축하려면 마스터 솔루션을 만드는 것이 좋습니다. 마스터 솔루션은 모든 것에 대한 프로젝트 참조를 가지며 본질적으로 응용 프로그램 제품군의 모든 프로젝트를 처리하는 단일 빌드 명령을 갖는 유일한 이점을 위해 존재합니다. 개발자는 적극적인 개발 또는 디버깅을 위해 마스터 솔루션을 사용해서는 안됩니다. 이렇게하면 빌드 아티팩트를 훨씬 쉽게 조립할 수 있습니다.

그런 다음 간단한 배치, powershell 또는 Perl 스크립트를 사용하여 배포를 수행 할 수 있습니다. 이것은 본질적으로 적절한 솔루션 또는 마스터 솔루션을 구축 한 다음 모든 것을 적절한 환경에 배포합니다. 올바르게 수행하면 모든 CI 서버에 쉽게 통합 할 수 있습니다.

별도의 배포 아티팩트간에 비즈니스 로직을 공유하는 방법

공통 비즈니스 로직을위한 프로젝트를 만들거나보다 글로벌 또는 범용 비즈니스 로직에 대한 우려를 더 잘 분리하십시오. 이를 참조하려는 모든 배치 가능한 솔루션은 프로젝트 참조로 수행해야합니다.

TFS에서 코드를 구성 할 때 디렉토리 트리에서 공통 또는 공유 프로젝트를 더 높은 레벨로 유지하면이를 달성하기가 더 쉬워집니다.

— maple_shaft
소스