약 100 개 이상의 프로젝트가있는 솔루션이 있으며 대부분 C#입니다. 당연히 오픈과 빌드 모두에 시간이 오래 걸리므로 그러한 짐승들에게 최상의 방법을 찾고 있습니다.Visual Studio (2008)의 대형 솔루션에 대한 유용한 정보
솔루션 '폴더를 정리하는 좋은 방법
같은 출력 폴더에 구축해야 물건?은 여러 개의 작은 솔루션으로 솔루션을 분할하는 옵션 것을 알고 있지만, 리팩토링과 건물 두통의 그것의 자신의 세트와 함께 제공됩니다, 그래서 아마도 우리는
:-) 별도의 스레드에 대한 그 저장할 수 있습니다우리는 비슷한 대규모 프로젝트를 수행합니다. 솔루션 폴더는 일을 구성하는 좋은 방법임이 입증되었으며, 우리는 copy local을 true로 설정하는 경향이 있습니다. 각 프로젝트는 자체 폴더로 빌드 한 다음 거기에 배치 가능한 각 프로젝트에 올바른 바이너리 하위 세트가 있음을 알 수 있습니다.
개방 및 시간 빌딩에 관해서는, 더 작은 솔루션을 깨지 않고 해결하기가 어려울 것입니다. 여기에서 속도를 향상시키기 위해 빌드를 병렬화 (google "Parallel MS Build"를 수행하고 UI에 통합하는 방법에 대해 조사 할 수 있습니다. 또한 디자인을보고 프로젝트 중 일부를 리펙토링하여 전체적인 도움이 적은 경우를 확인하십시오.
건물의 고통을 덜어주기 위해 빌드의 "구성 관리자 ..."옵션을 사용하여 특정 프로젝트의 빌드를 사용하거나 사용하지 않도록 설정할 수 있습니다. 특정 프로젝트를 제외하고 특정 프로젝트를 대상으로 할 때이를 사용할 수있는 "Project [n] Build"를 가질 수 있습니다.
100 개 이상의 프로젝트가 진행되는 동안 솔루션 크기를 줄이는 이점에 대해이 질문에서 망치고 싶지는 않지만 속도는 향상시킬 수있는 다른 옵션이 없다고 생각합니다. devenv의로드 시간 (및 메모리 사용량).
+1 을 절약하려면 물건 정리에 도움이되는 솔루션 폴더 사용.
+1 자신의 폴더에 프로젝트를 빌드하는 경우. 우리는 처음에 공통 출력 폴더를 시도했는데 이것은 구식 참조를 찾기 위해 미묘하고 고통 스러울 수 있습니다.
FWIW, 우리는 솔루션에 대한 프로젝트 참조를 사용하며, 오늘날 nuget이 더 나은 선택 일지 모르지만 svn : externals가 타사 및 프레임 워크 어셈블리 모두에서 잘 작동하는 것으로 나타났습니다. svn : externals (유죄 : 유죄)를 참조 할 때 HEAD 대신 특정 개정 번호를 사용하는 습관에 들기 만하십시오.
+1 일반 출력 폴더 솔루션에도 문제가 있습니다. 나는 "솔루션에 대한 프로젝트 참조"가 의미하는 바를 이해하지 못했습니다. 조금 더 설명하십시오 ... –
VS-> 참조 추가 -> 프로젝트 대신 VS-> 참조 추가 -> 찾아보기를 사용하십시오. 내가 아는 작은 점이지만 일부 사람들은 다르게 (그리고 나는 이것이 두통을 더 많이 야기한다고 생각한다). MSBuild csproj 텍스트를 보면 Reference 대신 ProjectReference 속성이 표시됩니다. – si618
흥미로운 대답입니다! 네가 들쭉날쭉 한 곳에서 우리가 지그재그로 움직였다. 솔루션 폴더가 전혀없고 프로젝트 이름 지정에 의존합니다 (프로젝트의 이름은 네임 스페이스와 동일 함). 우리의 모든 결과물은 하나의 폴더에 저장되므로 개발자는 배포 환경에 훨씬 가깝게 설정할 수 있습니다. 종속성이 올바르게 설정되면 우리는 구식 참조가 없습니다. –
일반적으로이 작업은 "디버그"프로세스가 실제로 어떻게 발생하는지에 따라 다릅니다. 일반적으로 copy local을 true로 설정하지는 않습니다. 각 프로젝트의 빌드 디렉토리를 설정하여 원하는 끝점까지 모든 것을 출력했습니다.
따라서 각 빌드 후에 모든 dll과 모든 windows/web 응용 프로그램이있는 채워진 폴더가 있고 모든 항목이 적절한 위치에 있습니다. dll이 결국 올바른 위치에 끝나기 때문에 로컬 복사가 필요하지 않았습니다.
주
일반적으로 웹 응용 프로그램입니다 내 솔루션에 대한위의 작품과 내가 참조하여 문제를 경험하지 않은,하지만 그것을 할 수 있습니다!
우리는 비슷한 문제가 있습니다. 우리는 더 작은 솔루션을 사용하여이를 해결합니다. 우리에게는 모든 것을 열어주는 마스터 솔루션이 있습니다. 그러나 perf. 그건 나쁘다. 따라서 개발자 유형별로 작은 솔루션을 분류합니다. 따라서 DB 개발자는 관심있는 프로젝트, 서비스 개발자 및 UI 개발자에게 동일한 작업을로드하는 솔루션을 제공합니다. 누군가가 하루 하루에 필요한 것을 얻기 위해 전체 솔루션을 열어야하는 경우는 거의 없습니다. 그것은 만병 통치약이 아닙니다. 그것은 단점과 단점이 있습니다. "다중 솔루션 모델"in this article을 참조하십시오. (VSS 사용에 관한 부분은 무시하십시오.)
우리는 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]
"하나의 출력 폴더로 빌드"하면 여러 스레드로 컴파일 할 때 문제가 발생합니까? – BrunoLM
내가이 큰 가장 좋은 방법은 그들을 깰 수 있어야 솔루션을 생각합니다. "솔루션"은 필요한 프로젝트와 문제 해결을위한 다른 요소를 모으는 장소라고 생각할 수 있습니다. 100 개 이상의 프로젝트를 전체적인 문제의 일부분만을위한 솔루션 개발에 특화된 여러 솔루션으로 나눔으로써 필요한 프로젝트와의 상호 작용을 가속화하고 문제 영역을 단순화함으로써 주어진 시간에 덜 해결할 수 있습니다.
각 솔루션이 담당하는 출력을 생성합니다. 이 출력에는 자동 프로세스에서 설정할 수있는 버전 정보가 있어야합니다. 출력이 안정되면 종속 프로젝트 및 솔루션의 참조를 최신 내부 배포로 업데이트 할 수 있습니다. 여전히 코드에 들어가서 소스에 액세스하려면 Visual Studio에서 참조 된 어셈블리로 들어가고 소스 코드를 가져올 수 있도록 Microsoft 기호 서버를 사용하여 실제로이 작업을 수행 할 수 있습니다.
개발이 완료되지 않은 종속성을 기다리는 동안 인터페이스를 미리 지정하고 개발중인 어셈블리를 조롱하여 동시 개발을 수행 할 수 있습니다.
전체적인 노력이이 방식으로 물리적으로 무너질 때 얼마나 복잡한 지에 대한 제한이 없기 때문에 이것이 최선의 방법이라고 생각합니다. 모든 프로젝트를 하나의 솔루션에 넣으면 결과적으로 상한선에 도달하게됩니다.
희망 사항은이 정보가 도움이되기를 바랍니다.
약 60 개 이상의 프로젝트가 있으며 솔루션 파일을 사용하지 않습니다. 우리는 C#과 VB.Net 프로젝트가 혼합되어 있습니다. 성과는 항상 문제였습니다. 우리는 동시에 모든 프로젝트에서 일하지 않습니다. 각 개발자는 자신이 작업하고있는 프로젝트를 기반으로 자신의 솔루션 파일을 만듭니다. 솔루션 파일은 소스 컨트롤에 체크되지 않습니다.
모든 클래스 라이브러리 프로젝트는 소스 디렉토리의 루트에 CommonBin 폴더를 만듭니다. 실행 파일/웹 프로젝트는 개별 폴더에 빌드됩니다.
우리는 프로젝트 참조를 사용하지 않고 CommonBin 폴더에서 파일 기반 참조를 사용합니다. 프로젝트를 검사하고 빌드 순서를 결정할 사용자 지정 MSBuild 작업을 작성했습니다.
우리는 몇 년 동안 이것을 사용해 왔으며 아무런 불만이 없습니다.
맞춤형 msbuild 작업을 공유 하시겠습니까? – andreapier
내가 작성한이 두 MSBuild 기사에 관심이있을 수 있습니다.
MSBuild: Best Practices For Creating Reliable Builds, Part 1
MSBuild: Best Practices For Creating Reliable Builds, Part 2
는 Specificially 2 부 당신이보고 싶을 수도 큰 소스 트리 구축 섹션 있다.간단히 여기에 비록 당신의 질문에 대답하려면 :
사예드 이브라힘 하시
내 도서 : 자주 사용하고, SSD를 구입하지 않는 Inside the Microsoft Build Engine : Using MSBuild and Team Foundation Build
언로드 프로젝트. SSD는 컴파일 시간을 향상시키지 않지만 Visual Studio는 열기/닫기/빌드 작업이 두 배 더 빠릅니다.
프로젝트 언로드는 사용자 단위 설정이므로 팀원의 개발자는주의해야합니다 관심있는 프로젝트 만로드 할 수 있으므로 실제로 팀을 도왔습니다. –
솔루션로드 관리자 확장 프로그램 http://visualstudiogallery.msdn.microsoft.com/66350dbe-ed01-4120-bea2-5564eff7b0b2를 사용하여 기본적으로로드되지 않습니다. –
모두 솔루션과 프로젝트의 정의와 견해와 관련이 있습니다. 내 마음 속에는 해결책이 있습니다. 매우 구체적인 요구 사항을 해결하는 논리적 인 프로젝트 그룹입니다. 대규모 인트라넷 응용 프로그램을 개발합니다. 인트라넷 내의 각 응용 프로그램에는 자체 솔루션이 있으며 exe 또는 Windows 서비스 용 프로젝트도 포함될 수 있습니다. 그리고 우리는 기본 클래스와 도우미, httphandlers/httpmodules 같은 것들로 중앙화 된 프레임 워크를 가지고 있습니다. 기본 프레임 워크는 상당히 크며 모든 응용 프로그램에서 사용됩니다. 이런 식으로 많은 솔루션을 나눔으로써 솔루션에 필요한 프로젝트의 양을 줄일 수 있습니다. 대부분의 솔루션은 서로 관련이 없기 때문입니다.
많은 프로젝트를 솔루션에 포함시키는 것은 잘못된 디자인 일뿐입니다. 솔루션 아래에 많은 프로젝트를 가질 이유가 없어야합니다. 내가 보는 다른 문제는 프로젝트 참조와 관련이 있습니다. 특히 솔루션을 더 작은 솔루션으로 분할하려는 경우에는 결국 실제로 문제가 발생할 수 있습니다.
제 조언은이 작업을 수행하고 중앙 집중식 프레임 워크 (사용자가 직접 엔터프라이즈 라이브러리를 구현)를 개발하는 것입니다. GAC로 공유하거나 공유 위치를 직접 참조 할 수 있습니다. 중앙 집중식 비즈니스 객체에 대해서도 동일한 전술을 사용할 수 있습니다.
DLL을 직접 참조하려면 프로젝트에서 로컬 (예 : c : \ mycompany \ bin \ mycompany.dll)을 사용하여 DLL을 참조 할 수 있습니다. 런타임에서는 app.config 또는 web.config에 GAC 또는 런타임 저장소가 아닌 파일을 참조하도록 일부 설정을 추가해야합니다. 실제로 모든 것이 로컬인지 아닌지 또는 dll이 bin에서 끝나거나 심지어 GAC에있는 경우에도 문제가되지 않습니다. 왜냐하면 config가 두 파일을 모두 무시할 것이기 때문입니다. 지역을 복사하고 지저분한 시스템을 사용하는 것은 나쁜 습관이라고 생각합니다. 이 어셈블리 중 하나를 디버깅해야 할 경우 로컬 임시 복사본을 임시로 복사해야합니다.
GAC없이 전역으로 DLL을 사용하는 방법에 대한 기사를 읽을 수 있습니다. GAC는 xcopy 배포를 방지하고 응용 프로그램에서 자동 다시 시작을 트리거하지 않기 때문에 정말 싫습니다.
설정 copylocal의 = 빌드 시간을 줄일 수 있지만, 배치 시간 동안 다른 문제가 발생할 수 있습니다 거짓.
'로컬로 복사'를 True로 설정해야하는 경우가 많이 있습니다. 최상위 프로젝트 두 번째 레벨 종속성, 리플렉션에 의해 호출되는 DLL.
CopyLocal = false로 설정 한 경험이 성공적이지 않았습니다. 내 블로그 게시물의 장단점 요약을 참조하십시오. "Do NOT Change "Copy Local” project references to false, unless understand subsequences."
단일 솔루션에 100 개 이상의 프로젝트가 필요한 이유를 묻습니다. 그들은 각각 자신의 어셈블리를 만들고 있습니까? –
예, 그렇습니다. 그리고 각각은 논리적으로 분리 된 기능을 나타냅니다. – Eyvind
우리는 Java에서 비슷한 점이 있습니다 ...하나의 프레임 워크, 약 200 개의 플러그인. 이클립스를 모두로드 할 때 테스트를 시작합니다. 드물지 않다고 생각합니다. (이것이 학계이지만, 아마도 The Real World ™와는 다를 것입니다.) – Joey