c# - 호환 - 프로젝트 파일 이 불완전 합니다 필요한 가져 오기 가 없습니다




간접적으로 참조 된 프로젝트에서 내용 파일을 복사하지 않는 Visual Studio (3)

나는 다음과 같은 프로젝트 구조를 가지고있다 :

Library1 <--[project reference]-- Library2 <--[ref]-- Executable
--------                          --------            ----------
ContentFile                      .cs files           .cs files
.cs files

모든 프로젝트 참조에는 CopyLocal = true가 있습니다.

프로젝트를 빌드 할 때 ContentFileLibrary2 의 출력 디렉토리에 복사되지만 Executable 의 출력 디렉토리에는 복사되지 않습니다. 즉, 응용 프로그램이 실행될 때 실행 파일에 ContentFile 이 누락되었습니다.

왜 Content 파일은 Library2 의 출력 디렉토리에 복사되지만 Executable 은 복사되지 않습니까? 후자에게 복사하는 방법이 있습니까 (사람들이 그 사실을 잊어 버릴 것이므로 빌드 이벤트없이이 작업을하고 싶습니다)?

합리적이고 유지 보수가 가능한 솔루션을 찾고 있습니다. 새로운 프로젝트 간접적으로 참조되는 새로운 컨텐트 파일을 추가 할 때 최소한의 노력 만 필요로하기 때문에 가능한 일을 잊어 버릴 가능성은 거의 없습니다.

빌드 후 이벤트 사용 (예 : xcopy ../Library/bin/Debug/SomeDll.dll bin/Debug ); 수동으로 프로젝트의 출력 디렉토리를 기본값 (프로젝트별로) 대신 $(SolutionDir)/bin/... 으로 설정하면 모두 빠르게 커다란 혼란이됩니다. "주 프로젝트"에서 링크로 콘텐츠 파일을 추가하는 것은 너무 지루했습니다. Visual C ++ (즉, $SolutionDir/$Platform/$Configuration )와 같은 출력 파일에 대해 C #이 동일한 기본 설정을 갖고 있으면 좋지만 실제로는 그렇지 않습니다.

나는 또한 표준 MSBuild 프로 시저를 전혀 사용하지 않고 Atmel Studio에서 gcc를 사용하는 것처럼 사용자 지정 빌드 대상을 작성하는 방법을 고려해 왔지만 전혀 얻지 못했습니다. 또한 Visual Studio의 표준 "빌드"및 "디버그"명령이 일반적으로 수행하도록합니다.

최신 정보:

내가하는 일에 대한 자세한 내용은 여기에있다.

Executable 프로젝트가있는 솔루션이 있습니다. 또한, Plugin 이라고 부를 수있는 프로젝트가 많이 있습니다. Executable 은 관리되는 프로젝트 참조를 통해 모든 Plugin 참조합니다.

플러그인 프로젝트는 실행 파일에 맞게 조정 되었기 때문에 재사용 가능한 구성 요소가있을 수 있으므로 주요 기능은 종종 External 프로젝트에서 구현되므로 Plugin 프로젝트는 단순한 래퍼로 유지됩니다.

External 프로젝트는 때로는 타사에서 제공 한 네이티브 DLL을 사용합니다. 그런 다음 해당 DLL을 External 프로젝트에 내용 파일로 추가하고 Copy to output dirCopy always 설정합니다. 따라서 구조는 위의 다이어그램과 같습니다.

External <---------------[is not aware of]--------------------+
--------                                                      |
.cs files <--[reference]-- PluginWrapper <--[reference]-- Executable
"Native DLL"               -------------                  ----------
                           .cs files                      .cs files

이상하게도, "네이티브 DLL"은 PluginWrapper 뿐만 아니라 External 의 출력 디렉토리 ( 물론)에도 PluginWrapper 되지만 Executable 은 복사 되지 않습니다 .

개발자의 워크 플로우는 완전히 격리 된 엔티티 (매우 자주 재사용되고 있음)로 작동하는 External 을 작성하고 PluginWrapper 랩핑 한 다음 PluginWrapper to Executable 대한 프로젝트 참조 만 추가하는 것입니다. 나는 이것이 분명히 그렇게 드문 일이라고 생각한다.

나는 Executable 의 MSBuild target XML을 편집하는 것이 간접적으로 참조 된 내용 파일을 포함하기 때문에 문제를 해결할 수 있다고 생각했다.

제안 된대로 임베디드 리소스로 DLL을 프로젝트에 추가하는 방법을 살펴보고 싶지만, 네이티브 DLL을 임베드하는 것은 나에게 이상한 것처럼 보일 수 있습니다. 결국 Brenda Bell이 제안한 것처럼 위의 다이어그램에서 '[인식하지 못함]'을 제거하고 External 프로젝트 참조를 추가하여 개발자의 워크 플로우를 변경하는 것이 이상적이지 않더라도 가장 합리적인 해결책 일 수 있습니다.

업데이트 2

임베디드 리소스 아이디어는 모든 경우에 작동하지 않을 수 있습니다. 실행 파일의 디렉토리 (cwd 또는 기타가 아님)에 종속성을 배치해야하는 경우, 임베디드 리소스에서 파일을 압축 해제하기 위해 설치 폴더에서 관리자 권한이 누락되어 작동하지 않을 수 있습니다. 이상하게 들리지만, 이것은 우리가 사용하고있는 타사 라이브러리 중 하나에 심각한 문제가되었습니다.


Brenda의 대답에 대한 한 가지 변형은 Library1의 콘텐츠 파일을 실행 파일 프로젝트에 링크로 추가하는 것입니다. 여전히 프로젝트에 항목이 있지만 각 파일의 여러 사본을 관리 할 필요는 없습니다.


Executable 프로젝트에 Library1 참조를 추가하십시오.


편집하다:

모든 컨텐트를 별도의 프로젝트에 넣고 모든 항목을 "content"및 "copy always"로 설정하고 해당 프로젝트를 External 및 Executable에서 참조 할 수 있습니다

-

IMO에서는 컨텐츠 파일이 아닌 임베디드 리소스를 찾고 있습니다.

라이브러리 1을 컴파일하면 내용 파일이 해당 bin 폴더에 저장됩니다. 라이브러리 2가 컴파일 될 때 컴파일러는 참조 된 코드를 인식하고 포함 (라이브러리 1.dll)하지만 라이브러리 2에 언급되지 않았기 때문에 인식되지 않습니다. 라이브러리 2를 실행 파일에 연결할 때도 마찬가지입니다.

콘텐츠 파일이 상대적으로 작고 (아이콘, 템플릿 등) 소스 코드를 잃어 버렸다면 편집 할 필요가 없다고 생각하면 리소스로 포함시킬 수 있고 다음과 같이 내용을 반환 할 수있는 공개 방법을 제공 할 수 있습니다. :

 public static Stream GetResourceContent(string rName){
     string resName = System.Reflection.Assembly
         .GetExecutingAssembly().GetManifestResourceNames()
         .FirstOrDefault(rn => rn.EndsWith("."+rName));
    if(resName!=null)
        return System.Reflection.Assembly.GetExecutingAssembly().GetManifestResourceStream(resName);
    else
        return null;
}

콘텐츠가 변경 될 수있는 경우 (예 : 템플릿 등) 실행 가능한 프로젝트에 사본을 포함시키는 것을 고려하십시오





projects-and-solutions