[c#] Visual Studio (2008)의 대규모 솔루션에 대한 모범 사례 [닫기]

우리는 109 개의 개별 프로젝트를 처리해야하는 것과 비슷한 문제가 있습니다. 경험을 바탕으로 한 원래 질문에 답하려면 :

1. 프로젝트 간의 참조를 가장 잘 처리하는 방법

‘참조 추가’컨텍스트 메뉴 옵션을 사용합니다. ‘프로젝트’를 선택하면 기본적으로 단일 글로벌 솔루션 파일에 종속성이 추가됩니다.

2. “로컬 복사”를 설정하거나 해제해야합니까?

우리의 경험에서 벗어났습니다. 추가 복사는 빌드 시간을 추가합니다.

3. 모든 프로젝트가 자체 폴더에 빌드되어야하거나 모두 동일한 출력 폴더에 빌드되어야합니까 (모두 동일한 애플리케이션의 일부 임)

모든 출력은 ‘bin’이라는 단일 폴더에 저장됩니다. 이 폴더는 소프트웨어가 배포 될 때와 동일하다는 생각입니다. 이렇게하면 개발자 설정이 배포 설정과 다를 때 발생하는 문제를 방지 할 수 있습니다.

4. 솔루션 폴더가 항목을 구성하는 좋은 방법입니까?

우리 경험으로는 아닙니다. 한 사람의 폴더 구조는 다른 사람의 악몽입니다. 깊이 중첩 된 폴더는 항목을 찾는 데 걸리는 시간을 증가시킵니다. 우리는 완전히 평평한 구조를 가지고 있지만 프로젝트 파일, 어셈블리 및 네임 스페이스의 이름을 동일하게 지정합니다.

---

프로젝트를 구조화하는 방법은 단일 솔루션 파일에 의존합니다. 프로젝트 자체가 변경되지 않았더라도이를 구축하는 데 오랜 시간이 걸립니다. 이를 돕기 위해 일반적으로 다른 ‘현재 작업 집합’솔루션 파일을 만듭니다. 우리가 작업중인 모든 프로젝트가 여기에 추가됩니다. 빌드 시간이 크게 개선되었지만 현재 세트에없는 프로젝트에 정의 된 유형에 대해 Intellisense가 실패한다는 문제점이 있습니다.

솔루션 레이아웃의 일부 예 :

\bin

OurStuff.SLN

OurStuff.App.Administrator
OurStuff.App.Common
OurStuff.App.Installer.Database
OurStuff.App.MediaPlayer
OurStuff.App.Operator
OurStuff.App.Service.Gateway
OurStuff.App.Service.CollectionStation
OurStuff.App.ServiceLocalLauncher
OurStuff.App.StackTester
OurStuff.Auditing
OurStuff.Data
OurStuff.Database
OurStuff.Database.Constants
OurStuff.Database.ObjectModel
OurStuff.Device
OurStuff.Device.Messaging
OurStuff.Diagnostics
...
[etc]