단일 Visual Studio 솔루션의 여러 응용 프로그램 [닫기]


17

모든 .Net 응용 프로그램 (웹 응용 프로그램, Windows 응용 프로그램 및 콘솔 응용 프로그램)을 단일 Visual Studio 솔루션에 모으려는 회사에서 일하고 있습니다.

나는 이런 식으로 자신의 응용 프로그램을 구성하거나 회사에서 일하는 개발자의 경험을 찾고 있습니다. 이것이 좋은 생각입니까?

  • 각 응용 프로그램에 대해 별도의 솔루션을 두지 않고 모든 응용 프로그램을 단일 솔루션에 배치하는 전문가는 무엇입니까?

  • 20 개 이상의 프로젝트 솔루션으로 Visual Studio는 얼마나 빠릅니까?

  • 그리고 소스 제어 동시 개발로 솔루션 파일이 얼마나 안정적입니까?


답변은 특정 버전의 Visual Studio에만 해당 될 수 있습니다.
stakx

답변:


21

최근 우리 회사의 거의 모든 소스 코드를 단일 솔루션으로 마이그레이션했습니다.

왜?

원래 수십 개의 솔루션이있었습니다. 솔루션의 일부 프로젝트는 다른 프로젝트의 프로젝트를 재사용했으며 아무도 패키지 관리자 사용에 신경 쓰지 않았습니다. 거의 모든 곳에서 사용되는 프로젝트를 실질적으로 변경 한 날에는 다음 며칠 또는 몇 주 동안 회사 전체에서 몇 시간과 몇 시간의 손실 된 작업이 예상됩니다. 최악의 부분은 당신이 알지도 할 수 없다는 것입니다 무엇인지 정확히 변화에 의해 영향을받을 것입니다.

모든 코드를 하나의 솔루션으로 병합하는 것이 대안이었습니다. 현재로서는 잘 작동하고 종속성을 쉽게 따라갈 수 있습니다. 메소드를 수정하고이 변경이 코드베이스의 어느 곳에있을 수있는 영향을 추적하고 싶습니까? Visual Studio는이를 쉽게 수행 할 수 있습니다. 저에게는 성공입니다.

지속적인 통합도 더욱 쉬워졌습니다. 컴파일하고 배포 할 수있는 솔루션입니다. 거의 구성 할 것이 없습니다.

확장 가능합니까?

성능면에서 Visual Studio에 매우 놀랐습니다 . 나는 그것이 50 프로젝트와 같은 해결책으로 울기 시작할 것이라고 생각했습니다. 현재 200 개가 넘는 프로젝트가 있습니다. Visual Studio는 그 중 20 개만있는 것처럼 관리 할 수있을 정도로 확장 가능한 것으로 보였습니다. 예, 시간이 걸리는 것들이 있습니다. 코드 계약, 코드 분석 등 기본적으로 모든 프로젝트를 다시 컴파일하면 시간이 오래 걸릴 것으로 예상됩니다. 그러나 아무도 10 개의 빠른 속도로 200 개의 프로젝트를 컴파일 할 것으로 예상하지 않으며, 그렇게하지 말아야합니다. 이것이 Continuous Integration Server의 역할입니다. 시작 시간 (콜드 스타트 ​​후 솔루션로드)은 매우 빠릅니다 . 아마도 10 개의 프로젝트만큼 빠르지는 않지만 5 년 이상 전에 구입 한 기계에서 20 초 미만이면 여전히 수용 가능합니다.

더 나아가서 프로젝트를 체계적으로 언로드 하는 것이 좋습니다 (프로젝트가 솔루션 내의 디렉토리에 구성되어 있으면 정말 쉽습니다). 누군가 3 개의 프로젝트 만로드해야하는 작업을 수행하는 경우 200 개의 프로젝트를 모두로드 할 필요는 없습니다 (물론 종속성이 영향을받지 않는 한).

버전 제어도 예상대로 작동합니다 (중요하다면 SVN 서버를 사용하고 있습니다). 예를 들어, 수십 명의 개발자가 자주 코드를 커밋하는 실제 동시 환경에서 일하지는 않았지만 문제가 너무 많지는 않을 것이라고 생각합니다. 많은 개발자가 동시에 새 프로젝트를 추가하는 경우를주의하십시오. .sln 파일을 병합하는 것이 가장 쉬운 방법은 아닙니다.

결론

다시 결정을 내려야한다면 :

  1. 여전히 모든 것을 단일 솔루션으로 마이그레이션합니다. 이렇게하면 종속성이 깨지는 고통을 크게 줄일 수 있으며이 이점만으로도 그만한 가치가 있습니다. 모든 코드를 중앙에 배치하는 것도 좋은 생각입니다. 이를 통해 예를 들어 Visual Studio 내에서 무언가를 검색 할 수 있습니다. 또한 약한 두 개의 관련 프로젝트에서 작업 할 수 있지만 여전히 하나의 Visual Studio 창이 열려 있습니다.

  2. 또한 NuGet과 개인 NuGet 서버를 호스팅하는 기능에 대해 조금 더 연구했습니다. NuGet을 통해 종속성을 관리하면 몇 가지 프로젝트를 공통 솔루션으로 병합하지 않을 때 일부 문제를 해결할 수 있습니다. 개인적으로, 나는 그런 경우가 없었지만 다른 회사가있을 것이라고 상상합니다.

  3. 마지막으로 모든 개발자를위한 SSD에 투자하면 큰 차이를 만들 수 있습니다. 그러나 필요하지 않으며 필자의 경우 코드베이스는 여전히 일반 하드 드라이브에 저장됩니다.


2
참고 사항 : 참고 : 속도 / 성능에 문제가있는 경우 VS의 .csproj 파일을 통해 프로젝트를 열 수도 있습니다. NuGet "비공개 서버"는 네트워크 폴더 일뿐입니다 (그리고 VS에서 패키지 소스 위치로 해당 폴더 추가).
Steven Evers

단일 솔루션 설정으로 경험을 공유해 주셔서 감사합니다. 매우 상세하고 유용한 답변입니다. 내가 가진 예약은 모든 응용 프로그램을 하나의 솔루션으로 함께하는 것입니다. 주요 개발자에게 모든 것에 대한 액세스 권한을 부여해야합니다. 우리는 Ankhsvn을 사용하고 있으며 주니어 개발자에게 모든 응용 프로그램에 액세스하는 것보다 작업하려는 단일 응용 프로그램의 URL을 제공하려고합니다. 이것에 대한 생각?
BruceHill

@BruceHill : SVN을 사용하면 누가 무엇에 액세스 할 수 있는지 정확하게 구성 할 수 있습니다. 주니어 개발자는 여전히 모든 루트 디렉토리를 볼 수 있지만 ( 서버 결함에 대한 내 질문 참조 ) 제한된 프로젝트에 액세스 할 수는 없습니다.
Arseni Mourzenko

2
매일 코드를 커밋하는 대규모 개발자 팀이있는 소수의 대기업에서 일하면서 단일 솔루션 접근 방식이 작동하지 않는다고 말할 수 있습니다. 각 프로젝트는 오버 헤드입니다. 로드, 빌드 및 신은 누군가 해당 프로젝트에 어떤 사전 / 사후 빌드 단계를 첨부했는지 알고 있습니다. 이제 대규모 개발자 팀과 함께 매일 많은 프로젝트에서 변경 사항이 발생합니다. 지속적인 통합을 위해 각 체크인에 실행 단위 테스트 등을 포함하면 더 많은 오버 헤드가 발생합니다. 배포 가능한 단위 (서비스, 웹 사이트) 당 단일 솔루션을 보유하고 NuGet과 같은 패키지 관리자를 사용하십시오.
항상 배우기

8

이것은 의도 된 사용법입니다.

각 응용 프로그램에 대해 별도의 솔루션을 두지 않고 모든 응용 프로그램을 단일 솔루션에 배치하는 전문가는 무엇입니까?

  • 찬성 :
    • 프로젝트 간 용이성 참조
    • 보다 쉬운 디버깅 / 스텝핑
    • 프로세스에 쉽게 첨부 할 수 있습니다 (예 : 공유 라이브러리 코드로 건너 뛸 때 Windows 서비스를 단계별로 실행하고 있으며 모든 기호가 이미로드되어 있고 설명되어 있기 때문에 작동합니다).
    • IDE 내의 코드 검색이 더 잘 작동합니다 (원하는 코드가있는 프로젝트를 알 필요는 없습니다)
    • 프로젝트 간 변경 목록을보다 쉽게 ​​관리 할 수 ​​있습니다 (예 : 라이브러리 코드를 변경 했으므로 한 번의 체크인으로 클라이언트 코드를 동시에 업데이트해야 함)
  • 단점 :
    • 빌드 속도 : "모두 다시 작성"습관이있는 경우 빌드 시간이 더 오래 걸립니다. 훨씬 길고 증분 빌드에는 때때로 펑키 동작이 있습니다.
    • ide speed : 다음 참조

20 개 이상의 프로젝트 솔루션으로 Visual Studio는 얼마나 빠릅니까?

20 개 이상의 프로젝트로 ... 나쁘지 않을 수 있습니다. VS에 문제가 없으면 더 많이 보았습니다. 꽤 안정적입니다. 그러나 ... 문제가되면 완화 할 수 있습니다 : VS에서 .csproj를 열고 거기에서 작업하십시오. 하나의 솔루션으로 모든 것을 얻는 이점을 얻지는 못하지만 필요할 때 언제든지 sln을 다시 열고 필요할 때만 .csproj에서 작업 할 수 있습니다 (지금처럼).

그리고 소스 제어 동시 개발로 솔루션 파일이 얼마나 안정적입니까?

솔루션 파일은 프로젝트 또는 솔루션 수준 개체를 추가 / 제거 할 때만 변경되므로 거의 변경되지 않습니다. xml이므로 내용을 볼 수 있습니다. 그들은 거의 변하지 않습니다.


스티브, "이것은 의도 된 사용법입니다." 이에 대한 참조를 제공 할 수 있습니까? 감사!
개혁
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.