커뮤니티 Visual Studio 솔루션을 어떻게 분리합니까?




비주얼 스튜디오 커뮤니티 (7)

솔루션에 500 개 이상의 프로젝트가 있습니다. 특히 기본 프로젝트가 변경되어 다른 모든 프로젝트 (예 : 도우미 클래스)에 영향을 줄 때 모든 프로젝트를 단일 솔루션으로 유지하는 것이 이점입니다.

우리는 Visual Studio에 vsFunnel 확장 을 사용하는 것이 가장 좋은 방법이라는 것을 발견했습니다. 프로젝트없이 솔루션을로드 할 수 있습니다. 프로젝트는 여전히 솔루션에 나열되지만 실제로 필요할 때까지로드되지 않습니다. UI를 통해 프로젝트가 열리면 필요에 따라로드됩니다.

진정한 트릭은 vsFunnel UI에서 "종속성로드"를 활성화하는 것입니다. 프로젝트를 열면 모든 종속 프로젝트 등이로드되므로 대상 프로젝트에서 작업하는 것이 훨씬 수월합니다.

예를 들어 500 개 이상의 프로젝트에서 우리는 종종 하나의 애플리케이션에 초점을 맞추고 20 개의 종속 프로젝트가있을 수 있습니다. 500+ 전체가 아닌로드 된 것만입니다.

힌트 : 의존성로드 및로드 없음을 선택합니다. 그러면 UI에서 대상 프로젝트를 열 때 모든 관련 프로젝트가로드됩니다.

이것은 엄청난 시간을 절약하는 것으로 나타났습니다 (더하기 SSD 드라이브!)

서로 의존하는 40 개 이상의 C # 및 C ++ / CLI 프로젝트로 Visual Studio 2008 솔루션을 보유하고 있습니다. 이 솔루션으로 작업하는 것은 매우 느리고 일반적으로 한 번에 몇 개의 프로젝트 만 필요합니다. 그래서 솔루션을 3-5 개 프로젝트가 포함 된 여러 솔루션으로 분할하기로 결정했습니다. 또한 모든 프로젝트에서 "전체"솔루션을 유지하고자합니다. 자동화 된 빌드 또는 모든 프로젝트에 영향을주는 대규모 리펙토링 작업에 유용합니다. (여기가 주된 조건입니다. 그렇지 않으면 프로젝트를 솔루션으로 분할하는 것은 당연합니다.)

그것을 할 방법이 있습니까?

나의 첫 번째 아이디어는 새로운 빈 솔루션을 생성하고 기존의 프로젝트 파일 중 일부를 이들 각각의 솔루션에 추가하는 것이 었습니다. 하지만 그렇게하면 VS가 프로젝트 참조를 더 이상 찾을 수 없습니다 (동일한 솔루션에 있지 않기 때문에). 참조를 "정상적인"파일 참조로 추가 할 수 있습니다. 하지만 그렇게하면 종속성이 없어지므로 "전체"솔루션이 더 이상 작동하지 않습니다.

편집하다:

답장을 보내 주셔서 감사합니다. 내 질문을 조금 명확히하고 싶습니다. 내 솔루션에는 테스트가 아닌 44 개의 프로젝트가 포함되어 있습니다. 그래서 두 부분으로 나누는 것은 제가 마음 속에 가지고 있었던 것이 아닙니다. 나는 5-8 부분에 대해 더 생각하고있었습니다. 그래서 VS가 전체 빌드의 올바른 빌드 순서를 파악할 수있는 "전체"솔루션을 유지하고자합니다. 손으로 8 개의 개별 솔루션 (예 : 배치 파일)을 빌드 순서로 유지하면 오류가 발생하기 쉽습니다.

또한 "논리적으로"프로젝트를 그룹화하고 싶습니다 (즉, 일반적으로 하나의 솔루션으로 함께 수정되는 프로젝트를 갖기를 원합니다). 하지만 그 그룹화가 항상 종속성과 일치하는 것은 아닙니다. 예를 들어, 내가 의존성 체인을 가지고 있다고 상상해보십시오.

A is referenced by B is referenced by C is referenced by D

A와 D는 종종 함께 수정되지만 B와 C는 거의 바뀌지 않는다고 상상해보십시오. (분명히 B가 사용하는 A의 인터페이스는 변경되지 않아야합니다.) 그런 다음 A와 D를 하나의 솔루션에, B와 C를 다른 솔루션에 갖고 싶습니다. 그러나 모든 프로젝트를 처음부터 구축하고자한다면 A, B, C 및 D가 포함 된 완전한 "솔루션"을 사용할 수있는 경우에만 작동합니다. 빌드가 완료되면 내 A / D 솔루션을 열고 편집 / 빌드 할 수 있습니다.

하지만 내 문제에 대한 우아한 해결책이 없다는 두려움이 있습니다. (의도하지 않은 말장난)


여러 솔루션을 만들고 원하는 각 솔루션에 프로젝트를 추가 할 수 있습니다.

빌드하려는 프로젝트는 다른 프로젝트에 종속 될 수 있습니다. 이 경우 "프로젝트"참조 (솔루션의 다른 프로젝트를 참조)를 사용하는 것으로부터 File 참조 (프로젝트에서 만든 어셈블리 .dll을 참조)를 사용하도록 변경해야합니다.

그래서 그것들을 "라이브러리"(한 번 컴파일 한 후 많이 사용함)와 "핵심"프로젝트 (많이 바꾸고 있음)로 생각합시다. 솔루션에 "라이브러리"프로젝트를 포함시키고 결과 디버그 / 릴리스 dll을 공유 라이브러리 폴더에 복사하는 사후 빌드 단계를 추가하는 것이 좋습니다. 핵심 프로젝트를 새로운 솔루션에 추가하십시오. 모든 핵심 솔루션 참조를 공유 폴더의 미리 빌드 된 바이너리 dll을 통해 라이브러리를 참조하도록 변경하십시오 (최종 릴리스가 제대로 작동하도록 릴리스 빌드 dll을 참조하십시오).

라이브러리를 변경 한 경우 라이브러리 솔루션을 빌드하여 다시 빌드해야하며 그런 다음 핵심 솔루션을 사용하여 라이브러리에 종속 된 응용 프로그램을 다시 빌드해야합니다. 따라서 자주 변경되는 코드를 라이브러리가 아닌 핵심 솔루션에 넣는 것이 좋습니다. 프로젝트가 나중에 성숙 될 때 옮길 수 있고, 또는 필요에 따라 libraire를 핵심 프로젝트로 만들 수 있습니다. 무겁게 잠시 동안 수정 됨)

[2018 편집] 요즘 라이브러리는 로컬 nuget 또는 npm 서버를 사용하여 배포 할 수 있습니다.이 방법은이 접근 방식을 채택하지 않는 특별한 이유가없는 한 선호되는 옵션입니다.

마지막 옵션은 라이브러리를 구축하는 데 시간이 오래 걸리고 매우 자주 변경 되지 않는 경우 라이브러리를 "미리 컴파일 된"라이브러리로 만드는 것입니다. 소스 제어에 대한 최종 dll 파일을 확인하면 팀 구성원이 최신 버전을 얻을 수 있습니다. 라이브러리를 만들거나 소스 코드를 전혀 만들지 않아도 라이브러리를 구축 할 수 있습니다. 이러한 라이브러리를 업데이트하려면 빌드하기 전에 이진 .dll 파일을 체크 아웃 한 다음 다시 빌드 한 후 다시 체크인해야하므로 단점에 비해 장점 (빠르고 쉬운 일별 빌드)을 비교해야합니다 ( 라이브러리를 변경하기위한 노력, 소스 제어에서보다 큰 바이너리 파일).


Visual Studio Solution 내에서 프로젝트를 그룹화 할 때 특히주의해야합니다. 나는 최근에 단위 테스트를 많이 만들어야하는 직장에서이 문제를 접했고 개발자가 만든 원래 테스트가 솔루션에 포함되었습니다. 처음에 나는 OK 테스트를 여기에 넣을 것이라고 생각했다. 나는 그것이 작동하고 종속성을 올바르게 얻는 것에 대해 걱정할 필요가 없다는 것을 안다. 그런데 나중에 각기 다른 단위에 대해 20 개의 테스트 프로젝트를 추가 한 후 매우 놀랍도록 느리게 구축되고 있음을 깨달았습니다.

그런 다음 각 테스트 세트를 모두 한 곳에 모으는 대신 솔루션을 만들기로 결정했습니다. 이렇게하면 코드를 더 잘 구성 할 수 있으므로 찾기가 더 쉽습니다. 예를 들어, 'Test> Unit> MyUnitTest'및 'Test> Integration> MyIntegrationTest'폴더를 만들었습니다. 나중에 쉽게 찾을 수있을뿐만 아니라 빌드를 빠르게 할 수 있습니다. 또한 각 개발자가 잠재적으로 프로젝트 설정과 구성을 변경하고 다른 것들을 엉망으로 만들 수없는 코드를 작성하는 사람들이 많으면.

일반적으로 하나의 특정 영역에만 7 개 이하의 항목을 그룹화하는 것이 일반적입니다. 7 개 이상의 항목이있는 경우 인간의 두뇌가 모든 복잡한 세부 사항을 한 눈에 파악할 수 있도록보다 추상적이고 쉽게 만들 수있는 또 다른 하위 범주가 있습니다 (특히 시스템을 처음 사용하는 사람들이나 프로젝트 개월 또는 심지어 년 후에 다시오고있다).


고려하고 싶은 또 다른 접근법은 사용하지 않는 프로젝트를 언로드하는 것입니다. 작업하지 않는 프로젝트를 마우스 오른쪽 버튼으로 클릭하고 언로드하면 Visual Studio가 훨씬 더 멋지게 나옵니다. 그것은 VS 메모리에서 많은 것들을 유지합니다.

당신이 할 수있는 다른 일은 빌드 정의를 편집하고 수정되지 않은 프로젝트를 제거하는 것입니다 (링크가 어떤 방식인지 ... 필요 / 업데이트 / 필요 없음).

솔루션 -> 오른쪽 클릭 -> 구성 관리자 -> 변경되지 않고 다른 이유로 인해 모든 빌드 가 필요하지 않은 프로젝트에서 빌드 선택을 취소 하십시오 . 이렇게하면이 프로젝트의 마지막 빌드 출력을 사용하여 바이너리를 덤프 할 때마다 빌드 속도를 높일 수 있습니다.

참고 : 여전히 프로젝트를 마우스 오른쪽 단추로 클릭하고 출력을 업데이트 한 다음 솔루션을 다시 빌드하여 최신 정보를 얻을 수 있습니다. 빌드 구성을 변경하기 위해 앞뒤로 변경하는 대신이 작업을 수행 할 수 있습니다.

최신 정보
성능 경로 (예 : VS 2010까지 기다리는 등)에 대한 정신으로 다른 스택 오버 플로우 관련 질문에 나열된 조치를 취한 적이 있습니까? Visual StudioVisual Studio 최적화 에서 컴파일 시간이 매우 느립 니까? 이는 VS 2010을 출시때까지 기다리는 동안 상당한 차이를 만들 수 있으며 성능을 수용 가능한 수준으로 끌어 올릴 수 있습니다.
성능에 좋은 영향을 미칠 수있는 몇 가지 사항 :

  • 옵션이라면 SSD를 강력히 추천합니다 . 그들은 값이 비싸지 만 그만한 가치가 있습니다. 솔루션에 파일이 많을수록 갚을 확률이 높아집니다. 우리가 새로운 컴퓨터를 주문했을 때 전체 개발 팀이 SSD를 사용했는데 그 차이는 놀랍습니다. 대용량 솔루션을 다루고있을 때 실제 헤드를 수천 개의 위치로 전환하는 드라이브를 돌리고 있습니다. SSD가있는 위치에서 파일을 읽는 것만으로도 시간은 효과적으로 0ms입니다.
  • 같은 라인을 따라, 무료 솔루션은 훌륭한 dracragmenter입니다 (물리적 인 경우에만 , SSD를 조각 모음하지 마십시오 ) 큰 차이를 만듭니다 ... 시각적 인 스튜디오를 염두에두고있는 무언가를 사용한다면 .... 내가 defragging에 대한 네이티브 알고리즘을 염두에두고 디렉토리 구조를 유지하므로 MyDefrag (프리웨어)를 권장합니다. 그래서 적어도 물리적 드라이브는 솔루션에서 필요한 파일을 스무딩하기 위해 많은 시간을 소비하지 않습니다. 모두 매우 가깝습니다. 디스크.
  • 위의 SSD 제안을 통해, 저렴한 드라이브와 빠른 드라이브 사이에서 SSD 성능에 큰 불균형이 있다는 것을 명심하십시오. 여기서 약간의 연구를하십시오. gParted와 같은 무료 유틸리티로 시스템을 걱정하지 마십시오. 전체 OS 드라이브를 매우 쉽게 옮길 수 있으며 이전 드라이브는 여전히 백업입니다 ... SSD가 C 드라이브의 데이터를 저장할 수있는 한 너 괜찮아.

여기에 언급 된 soldr 및 Funnel 외에도 솔루션로드 관리자를 사용하는 것이 좋습니다. 그렇습니다, SSD가 도움이되지만 VS는 버그가 있습니다 : 충돌이 발생하고 응답이 없으며 100 개 이상의 프로젝트에서 작업 할 때 다른 문제가 발생합니다. 주요 리팩토링, 리빌딩 및 디버깅을 위해 모든 것을 함께 유지해야하지만, 일상적인 기반의 프로젝트 중 더 작은 부분에 대한 작업은 성능과 만족도를 크게 향상시킵니다.

추신. 누군가가 비교를했는지 알고 싶습니다 깔때기 대 솔루션 부하 관리자?


또 다른 옵션은 하나의 포괄적 인 솔루션을 갖고 다른 빌드 구성을 만드는 것입니다.

창의 맨 위에 콤보 상자가 있습니다. 여기서 콤보 상자를 사용하여 디버그 또는 릴리스 빌드 구성을 선택할 수 있습니다. 이것을 버리고 "구성 관리자 ..."옵션을 선택하십시오.

"액티브 솔루션 구성"에서 콤보 상자를 드롭 다운하고 <새로 만들기 ...>를 선택하십시오. 새 구성 (예 : "CoreOnly")을 만들고 "설정 복사"를 "디버그"로 선택하십시오. "새 프로젝트 구성 만들기"옵션의 선택을 취소하십시오.

이제 "CoreOnly"빌드 구성이 창에 나타납니다. 모든 프로젝트의 목록을 보여줍니다. 빌드하지 않으려는 프로젝트의 경우 오른쪽 열의 "빌드"확인란의 선택을 취소하십시오. 대화 상자를 닫으십시오.

이제 모든 프로젝트를 빌드하려면 구성 드롭 다운에서 "디버그"를 선택하고 정상적으로 빌드하십시오. 모든 프로젝트가 빌드되면 CoreOnly 구성으로 전환하여 "핵심"프로젝트 만 빌드 할 수 있습니다. 핵심 프로젝트에없는 코드를 편집 할 때 Debug (모든 프로젝트) 빌드를 빌드하는 것을 잊지 않는 한, CoreOnly 빌드가 훨씬 빠를 것입니다.

이 접근 방식의 단점은 솔루션을 매우 느리게 열 수 있다는 것입니다 ( Visual Studio 2008 , Visual Studio 2010Visual Studio 2012 에서 Visual Studio 2005 보다 훨씬 우수하므로 문제가 없을 수도 있음). ) 그리고 만약 당신의 구성에서 프로젝트가 가능하지 않다면, 다시 빌드되지 않을 것이고 그래서 당신의 빌드 (또는 실행중인 어플리케이션)가 분해 될 수 있습니다 - 당신은 일반적인 "build everything "설정을 사용하면 장애가 발생한 프로젝트를 변경 (또는 영향을 미친 경우) 할 수 있습니다.


귀하의 질문이 있은 지 3 년 후 우리 팀은 시간을 컴파일하는 것이 아니라 논리적으로 분리 된 솔루션을 별도의 솔루션으로 분리하는 좋은 방법이 없다는 사실과 동일한 문제에 여전히 직면 해 있습니다.

우리는 솔루션 간 빌드 도구 인 sellr (오픈 소스) 형태로 자체 도구 를 구축했습니다. 선택적으로 너겟 을 활용하여 코드 기반을 관리하거나 자체적으로 작업 할 수 있습니다. 아이디어는 논리적으로 의미있는 것처럼 많은 솔루션 (.sln)으로 작업을 분할하는 것입니다. 우리의 경우 우리는 사내 프레임 워크를위한 라이브러리를 가지고 있고 백엔드 라이브러리 각각에 대해 하나씩, 각 제품에 하나씩 등등이 있습니다. 각 솔루션에는 "components"디렉토리가 있습니다 (nuget "packages"디렉토리와 비슷합니다). 현재 솔루션에서 참조하는 실제 라이브러리 파일 (DLL 등)을 저장하십시오. 이러한 DLL은 새 버전을보기 위해 대상 sln에 대한 종속성의 새로운 빌드에서 업데이트해야합니다.

수동 노동 대신 앞서 말한 구축 도구 를 사용 합니다 . 매우 간단한 규칙과 규칙을 사용하여 솔루션 간 종속성을 자동으로 추론합니다 . 그런 다음 각 단계 빌드에서 다음 대상의 구성 요소 디렉터리에 출력을 복사하여 전체 종속성 그래프를 올바르게 만들거나 MSBuild 파일을 생성하여 MSBuild 파일을 생성 할 수 있습니다. 우리는 또한 무엇이 빌드 될지 (예 : 직접적인 의존성 만 빌드), 의존성 그래프 인쇄, 유닛 테스트 실행 등을 필터링하는 기능을 추가했습니다.

업데이트 : nuget 을 활용하기 위해 자동 추론 된 종속성을 가진 nuspec 파일 생성을위한 지원이 추가되었습니다.





visual-studio-2008