2
다른 프로젝트 및 일부 '플러그인'어셈블리에 대한 참조를 마무리하는 프로젝트 "ProjA"가 있습니다. 이 모든 참조에는 로컬 복사가 '참'으로 설정되어 있습니다. 프로젝트 참조 인 플러그인 어셈블리의 코드는 "ProjA"에서 직접 참조되지 않지만 DI/Ninject를 통해로드되고 위치합니다. (그래서 나는이 프로젝트 참조를 출력 폴더에 플러그인 어셈블리를 가져 오는 방법으로 사용하고 있습니다. 이유는 아래 참조)Copy Local with reference with
또한 ProjA를 참조하는 프로젝트 "ProjB"도 있습니다. 그것은 참조 된 플러그인 어셈블리를 사용하여 그것을 수행해야하는 ProjA 코드를 호출합니다.
문제는 작동하지 않는다는 것입니다. 플러그인 어셈블리는 ProjA 출력 폴더 (ProjB 출력 폴더에 '로컬로 복사'되어 있음)에서 복사되지 않습니다. 그래서 Ninject는 그들을로드하지 않으며, 그 일은 실패합니다.
그래서 내 두 가지 질문 :
- 내가의 proja 프로젝트의 P1, P2, P3, P4, 진정한 로컬 설정 사본을 말한다 VS/msbuild를에 지시 한 경우 - 왜 그것은 단지 가정 것 ProjA를 만들기 위해서는 주 출력 어셈블리가 필요합니까? 다르게 생각해도 될까요?
- 저는 플러그인 로컬 어셈블리 참조를 플러그인 어셈블리와 플러그인 (현재 고정 된 플러그인 세트이므로이 경로) 사이의 빌드 종속성을 인식하는 방법으로 추가하는 것이 좋습니다. 이상. 그런 다음 프로젝트에 '컨텐츠'로 플러그인 어셈블리를 추가하는 것이 효과적 일 것이라고 생각하지만 두 가지 문제가 있습니다. 1) TFS 소스 제어. 플러그인 프로젝트는 작성하기위한 쓰기 가능한 타겟이 필요합니다. 아마도 컨텐트 파일이 '체크인'될 것입니다. 2) 플러그인 중 일부는 자체 컨텐트가 있습니다. 참고로 누락 된 항목에 대해 걱정할 필요가 없습니다. 콘텐츠 경로 가기 다른 프로젝트의 빌드 출력 폴더를 참조해야합니다. 모든 내용이 포함되지만 PDB는 포함되지 않습니다.
나는 또한 플러그인 프로젝트를위한 빌드 후 단계를 고려해 보았습니다 (이상적은 아닙니다. 포스트 빌드 단계를 추가하면이 새로운 솔루션을 다른 곳에서 가져올 것입니다. 다른 솔루션) 또는 프로젝트에 의존하는 (괜찮습니다. 그러나 상대 경로가있는 XCopy와 프로젝트 종속성을 수동으로 설정해야합니다.) 다시 해커처럼 보입니다.
내가 누락 된 내용이 있습니까? Copy Local이 프로젝트 참조를 통해 연결되면 완벽하게 맞을 것입니다.
더 많은 조사를 해보면 단일 출력 폴더를 만드는 것이 중요하다고 생각됩니다. 나는 플러그인을 주로 사용하는 '다른'솔루션을 위해 그렇게합니다. 그렇다면이 솔루션을 위해 프로젝트를 * 새로운 * '단일'출력 폴더로 구축하는 방법은 무엇입니까? –