VS에서 프로젝트 참조가 아닌 dll 참조로 .NET 어셈블리 종속성 관리

Question

우리는 여러 하위 프로젝트 (약 20 개)로 구성된 .NET 프로젝트를 보유하고 있습니다. 솔루션마다 몇 가지 솔루션이 있으며 각 솔루션에는 특정 솔루션과 관련된 하위 프로젝트 만 포함됩니다.

임의의 솔루션을 허용하기 위해 우리의 하위 프로젝트는 프로젝트 참조를 통해 서로를 참조하지 않고 직접 dll 참조를 통해 참조합니다. csproj 파일을 미세 조정하여 HintPath가 $ (Configuration)을 포함하도록합니다. Debug는 Debug Debug dlls 빌드를, Release 빌드는 Release DLL을 참조하도록합니다.

모든 잘 작동하지만, 두 가지 문제가있다 - 하나는 성가신이며, 다른 하나는 정말 심각하다 :

1. VS 종속성 계산의 목적을 위해 DLL 참조를 인식하지 못합니다. 새 프로젝트 나 참조가 추가 될 때마다 "프로젝트 종속성"대화 상자를 사용하여 수동으로 종속성을 지정해야합니다. 이것은 성가신 일입니다.
2. 우리는 Resharper도 시각적 지원도 사용하지 않습니다 (위대한 도구이지만 사용하지 않습니다.). 표준 "Browse to Definition"명령 (예를 들어, 소스 코드의 컨텍스트 메뉴에서 사용 가능)을 사용하고 싶습니다. 중요한 문제는 한 프로젝트가 프로젝트 참조를 사용하여 다른 프로젝트를 참조하고 참조 된 프로젝트가 솔루션에 포함되어 있어도 참조가 직접 DLL 참조 인 경우 일 때 교차 프로젝트에서만 작동한다는 것입니다. 소스로 이동하는 대신 메타 데이터로 이동하기 때문에 실제적으로 어리 석다.

나는 우리와 같은 dll 참조를 사용하는 이들 사람들의 조언을 구하고이 두 가지 문제를 어떻게 든 극복했습니다. 감사합니다. .

편집 : "찾아 정의에"문제 외에, 대신 프로젝트 참조의 DLL이 참조를 갖는 프로젝트 매니저에 한 번만 비용을 지불해야한다는

참고 - 각각의 프로젝트 종속성을 업데이트하는 것입니다 새 프로젝트가 추가되거나 새로운 종속성이 도입되어야하는 경우 영향을받는 솔루션입니다. 이러한 프로젝트 종속성은 .sln 파일에 유지되며 새 프로젝트가 도착하거나 새로운 종속성이 생성 될 때까지 유지 관리가 필요하지 않습니다.

우리는 VS 서버와 동일한 .sln 파일을 사용하는 CI 서버에서 프로젝트를 빌드하기 위해 msbuild를 사용합니다. 모든 하위 프로젝트를 포함하는 하나의 주 .sln 파일이 있습니다.

두 프로젝트가 참조가 dll 참조이므로 동일한 솔루션에 있지만 더 심각한 문제, 즉 다른 프로젝트에서 정의를 탐색 할 수 없다는 점을 강조하고 싶습니다. 이것은 성가신 일이며 성가신 일입니다. VS가이 기능을 사용하기 위해 프로젝트 참조를 주장 할 이유가 없습니다. Resharper 또는 Visual Assist 같은 다른 도구에는 이러한 제한이 없습니다. 아아, 우리는 이러한 도구를 가지고 있지 않으며 관찰 가능한 미래에는 가질 수 없을 것입니다.

Answer 1

임의의 솔루션을 허용하려는 이유가 있습니까? 단일 솔루션을 만들고이 솔루션에 모든 프로젝트를 넣는 것이 더 쉬워 진 것 같습니다. 나는 가능한 한 여러 솔루션을 피하려고 노력한다.

Answer 2

당신이 직면 한 문제가 도구 세트를 잘못 사용하여 직접적인 결과를 얻은 것처럼 들립니다. Visual Studio에는 관리자가 프로젝트 종속성을 자동으로 계산할 수있는 다른 방법이 없습니다.

두 가지 선택이있는 것 같습니다.

1. 를 사용하여 프로젝트 종속성
2. 사용 (은 NAnt와 같은) 다른 빌드 시스템을 관리 할 수있는 비주얼 스튜디오

당신이 옵션 # 1 배제했다처럼 소리, 그래서 더 이상 그 주소하지 않습니다 . 따라서 옵션 # 2 만 남습니다.

NAnt을 사용하여 개별 CSproj 프로젝트를 빌드하고 NAnt 빌드 스크립트를 사용하여 프로젝트 간 종속성을 정의 할 수 있습니다. 이것에는 두 가지 단점이 있습니다. 당신은 모든 것을 관리해야

1. 는 지금처럼 당신에게 깨진로
2. Visual Studio를 동등하게 될 것이다 (당신이 할 준비가되어처럼 소리) 손을 구입할 수 있습니다.

Visual Studio는 솔루션이 VS에서 외부 빌드 스크립트로 이동되었으므로 솔루션을 전체적으로 컴파일하지 못합니다. 이로 인해 개발자간에 혼란이 생길 ​​수 있으며 디버깅 프로세스를 방해 할 수 있습니다. 그러한 것들이 극복되지 않는다고 말하는 것은 아닙니다. 단지 개발 과정의 단계에서 추가 설정이 필요하다는 것입니다.

Answer 3

빌드 구성의 문제점은 다음과 같습니다. 3 개의 프로젝트와 2 개의 솔루션이 있다고 가정 해보십시오. Solution2를 구축

Solution1 
- Project1 
- Project2 
Solution2 
- Project1 
- Project3 

갑자기

가 잘못된 상태로 남겨 Solution1에 대한 코드의 일부를 구축 (최신 바이너리 중 호환되지 않는 또는 구축 할 필요가 없었다).

모든 프로젝트는 단일 솔루션에 포함되어야합니다. 다른 솔루션도 신뢰할 수 있지만 이러한 프로젝트의 코드를 변경해서는 안됩니다. 외부 종속성을 다시 빌드 할 이유가 없기 때문에 이러한 방법으로 빌드 된 DLL을 참조 할 수 있습니다.

은 시간이 좀 걸릴 다음과 같은 조건을 충족하는 솔루션을 구조 조정해야한다, 요약하면 :

• 모든 프로젝트는 정확히 하나 개의 솔루션에 포함되어 있습니다.
• 프로젝트가 동일한 솔루션 내의 다른 프로젝트에 종속되어있는 경우 프로젝트 참조로 만드십시오.
• 프로젝트가 다른 솔루션의 다른 프로젝트에 종속 된 경우이를 DLL 참조로 설정하십시오.

위의 내용 외에도 다른 솔루션에서 참조 할 때 빌드를 배치하는 "외부"디렉토리를 만드는 것이 좋습니다. 다음으로 재구성 말 :

Solution1 
- Project1 
- Project2 -> reference project Project1 
Solution2 
- Project3 -> reference Project1.dll 

이 경우 Externals\Project1\Debug 및 Externals\Project1\Release에 Project1.dll이와 Project1.pdb의 사본을 배치하고 프로젝트 3에서 External\Project1\$(Configuration)\Project1.dll를 참조 할 것. 다른 모든 솔루션에 빌드를 푸시 할 준비가되면 Externals 디렉토리의 빌드 만 업데이트하십시오.