내 솔루션에는 특수 환경 (많은 외부 라이브러리 및 도구)을 필요로하는 라이브러리 프로젝트가 있지만 응용 프로그램에는 중요하지 않습니다. 필요하지 않을 때 이러한 도구를 설치하지 않는 것이 좋습니다. 대부분의 개발자가 다른 코드 부분을 작업합니다.Visual Studio 2008, MSBuild : "replacement"projects
동일한 API를 가지고 있지만 구현이 비어 있으며 외부 도구없이 컴파일 가능한 다른 프로젝트를 만들었습니다. 나는 그 프로젝트들 사이를 쉽게 전환 할 수 있기를 원하고 여전히 다른 프로젝트의 모든 참조가 정확하도록하고 싶습니다.
나는 VS/MSBuild를 잘 모른다. 그러나 무엇이든지 배울 의향이있다. 가능한가? 저는 아이디어를 찾고 있습니다 ... 우리는 Subversion을 사용하고 있으며 VCS 내부의 해킹과 관련된 솔루션도 환영합니다.
라이브러리 프로젝트가 기본 솔루션에서 분리되어 도구 수하물로 간주 될 수있는 것처럼 들립니다. 그러면 전문 솔루션을 별도로 구축 할 수 있으며 컴파일 된 어셈블리를 기본 솔루션과 연결할 수 있습니다.
토론을 위해 솔루션 파일, "RealLibrary \ RealLibrary.csproj"프로젝트 파일 ("실제"라이브러리, 종속성 포함) 및 "MockLibrary \ MockLibrary"가 포함 된 프로젝트 디렉토리가 있다고 가정합니다. csproj "파일 (비공개 구현을 사용하는"모의 (mock) "라이브러리).
정확하게 이해했다면 솔루션의 RealLibrary에 대한 MockLibrary를 쉽게 "바꾸기"를 원할 것입니다.
"RealLibrary.csproj"프로젝트를 찾기 위해 솔루션 (및 종속 프로젝트)이 "RealLibrary"디렉토리의 이름을 바꾸도록 설정되어 있다고 가정 할 때 가장 쉽고/해킹 할 수있는 방법은 무엇입니까?), "MockLibrary"디렉토리의 이름을 "RealLibrary"로 변경하고 "MockLibrary.csproj"의 이름을 "RealLibrary.csproj"로 바꿉니다. 이렇게하면 "실제 라이브러리"를 참조하는 경우에도 솔루션 및 종속 프로젝트를 "모의 라이브러리"를로드하는 데 효과적으로 "속이게"됩니다.
좀 더 복잡하고 (아마도 더 깨끗한) 해결책은 실제로 "sln"및 "csproj"파일을 "RealLibrary.csproj"대신 "MockLibrary.csproj"를 참조하도록 수정하는 것입니다. 은 "SLN"파일에서, 당신은 상단에있는 섹션에서 프로젝트의 경로를 변경해야합니다 :
Microsoft Visual Studio Solution File, Format Version 10.00
# Visual Studio 2008
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "RealLibrary", "RealLibrary\RealLibrary.csproj", "{E1714F9A-E1D9-4132-A561-AE2B4919391C}"
EndProject
당신은 그 길 "RealLibrary \ RealLibrary.csproj"에서 "MockLibrary \ MockLibrary을 변경해야 .csproj ". 완성도를 높이려면 이름을 변경하거나 이름에 "라이브러리"와 같은 일반적인 이름을 사용하십시오.
마찬가지로 종속 csproj 파일에서 "RealLibrary.csproj"를 참조하고 경로를 수정하는 "ProjectReference"노드의 모든 인스턴스를 찾아야합니다. 이 섹션은 다음과 같습니다.
<ProjectReference Include="..\RealLibrary\RealLibrary.csproj">
<Project>{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</Project>
<Name>RealLibrary</Name>
</ProjectReference>
이 스왑을 수행하기위한 스크립트를 비교적 쉽게 작성할 수 있습니다. 그러나 여기에는 더 깊은 문제가있어보다 직접적으로 해결 될 수 있다고 생각합니다. 나는 그것을 별도의 답변으로 게시 하겠지만, 당신이 먼저 찾고 있던 실제 답변을 갖고 싶었습니다.
언제든지'svn update'를하고 싶다면 이름 바꾸기를 취소해야할까요? – liori
그래, 내 첫 번째 방법으로가는 것은 일부 svn 재해로 이어질 수 있습니다. 두 번째는 그리 나쁘지는 않지만 sln/csproj 파일에 충돌 가능성이 있습니다. 개발자가 일반적으로 "모의"라이브러리를 사용하려는 의도가있는 경우이를 사용하여 솔루션을 svn으로 확인하고 CI의 사전 빌드 스크립트를 사용하여 "실제"라이브러리로 교체하십시오. 개발자는 "진짜"라이브러리로 작업해야한다면 임시로 스크립트를 실행할 수 있습니다. –
내가보기에 더 심한 문제는 특히 "외부 라이브러리와 도구가 많이 있습니다"에 의존하기 때문에 라이브러리에 "특수 환경을 구축해야합니다."라는 것입니다. 나는 당신이 모의 라이브러리를 만드는 길을 걷지 말고, 특별한 환경없이 라이브러리를 올바르게 만드는 것에 집중할 것을 제안한다. 프로젝트와 함께 모든 종속성을 소스 제어에 포함하고 작업 복사본 내의 상대 경로를 통해 이러한 종속성을 참조하면이 작업을 수행 할 수 있습니다.빌드 환경에서는 가능한 한 정적 인 환경 의존성을 피하려고합니다. 이상적으로는 .NET 프레임 워크 자체만으로 제한됩니다.
소스 제어에 대한 종속성을 얻으려면 프로젝트 자체에서 직접 확인하거나 다른 위치로 체크인 한 다음 svn:external 정의를 통해 프로젝트에서 참조 할 수 있습니다. 제 환경에서는 이러한 종류의 제 3 자 라이브러리 종속성에 사용되는 별도의 "bin"저장소가 있으며 많은 종속 프로젝트가 외부를 통해 가져올 수 있습니다.
라이브러리의 빌드 타임 환경 의존성을 제거 할 수 있으면 빌드가 훨씬 강력 해지고 개발자가 프로젝트 작업을 훨씬 쉽게 수행 할 수 있습니다.
이러한 라이브러리/도구는 설치 당 비용이 많이 들고 설치 후 ~ 10GB의 공간을 필요로하며 적절한 설치가 필요합니다 (일부 미친 과학 소프트웨어). 나는 그것에 영향을 미치지 않는다. 우리는 이미 svn : external을 좀 더 작은 라이브러리에 사용합니다. – liori
충분히 공정한 - 그렇다면 완전히 합법적입니다. 이러한 제약 조건을 지니는 것은 너무 안 좋은 일이지만 때로는 주위를 둘러 볼 수없는 경우도 있습니다. 이 점을 감안할 때, 3 가지 옵션이 있습니다 : 1) 라이브러리를 별도로 컴파일하고 다운 스트림 프로젝트 (@Grant Palin)에서 컴파일 된 바이너리를 참조하십시오. 2) 다른 답변에서 설명한대로 프로젝트를 바꿉니다. 3) 별로 매력적이지 않다). –
프로젝트의 다른 빌드 구성을 만듭니다. 그래서 최소한 2 개의 빌드 구성을 갖게됩니다. Debug_SpecialNeeds 및 디버그.
Visual Studio에서 관리되는 프로젝트의 참조를 빌드 구성별로 지정할 수 없습니다. 참조에 조건을 추가하기 위해 MSBuild 파일을 수정했지만 (시스템의 일부 파일의 존재 여부에 따라 제 경우) VS가이를 무시하고 실제 및 모의 프로젝트에 대해 경고/오류를 발생시키는 것으로 보입니다. – liori
우리는 이것을 우리의 주요 솔루션의 일부로 유지하고 싶습니다 (이것은 f.e. 연속 통합 설정을 간소화합니다). 그러나 다른 아이디어가 없다면, 나는 당신을 고려할 것입니다. 고맙습니다. – liori
@liori 외부 종속성이 라이브러리 및 독립 실행 형 도구 형식 인 경우 소스 제어에 추가하고 필요할 때 참조 할 수 있습니다. 이렇게하면 "특별 설정"이 필요하지 않습니다. –