5
잠재적으로 많은 수의 (최대 300 개까지) 다양한 유형의 스크립트 파일을 사용하는 Visual Studio 프로젝트를 디자인하고 있습니다. 이 파일은 다른 프로젝트와 공유되지 않습니다. 즉, 프로젝트에만 적용됩니다. 을 모두임베디드 리소스 (빌드 작업 설정)으로 설정 한 다음 실행시에 Assembly.GetManifestResourceStream()을 사용하여 이러한 파일을 검색하는 것에 반대하는 좋은 인수가 있습니까? 아니면 이것이 임베디드 리소스의 오용일까요? 이러한 리소스를 파일로 유지하는 파일 시스템 디렉토리가 대신 사용해야합니까? 포함 된 리소스를 사용하는많은 수의 스크립트를 프로젝트에 포함 된 리소스로 포함시키는 것은 나쁜 습관입니까?
장점은 것으로 나타납니다
- 생성 어셈블리 (스크립트 파일 또는 유효하지 않은 경로 누락에 대해 걱정할 필요없이 하나의 파일 배포를) 공유하고 배포하기 쉬운;
- 격리 및 편의성 : VS 프로젝트 내에서 모든 리소스에 액세스 할 수 있습니다.
이 방법에 대한 인수는 일반적으로 다음과 같습니다
- 당신이 어셈블리의 재 컴파일 및 재배치없이 자원을 수정할 수 없습니다. 그러나 텍스트 기반 리소스가 많은 프로젝트의 경우에도 결과 어셈블리는 다소 작고 재배포하기 쉽습니다. 단일 파일 시스템에 위치한 스크립트 파일이됩니다. 이론적으로 어셈블리의 변경된 부분 (따라서 작은 업데이트)을 대체 할 수 있어야하지만 기존의 diff/merge 도구가 있는지는 잘 알지 못합니다.
- 생성 된 DLL은 더 커질 것이고 결국에는 상당히 클 것입니다. 그런 다음 다시 임베디드 리소스가없는 린 어셈블리를 만든 다음 리소스를 별도로 디렉터리에 배포 한 경우 배포 할 전체 프로그램 크기가 동일합니다.
다른 고려 사항이 있습니까? 보다 일반적으로 프로젝트 리소스가 수정 된 경우 필요한 어셈블리 재 컴파일 이외에 포함 리소스로 포함되어서는 안되는 이유가 무엇입니까?