2011-04-08 9 views
1

저는 배포하기에 꽤 큰 시스템이 있으며 구성 요소가 풍부하고 확장 성이 뛰어납니다. 거의 모든 것에 필요한 핵심 구성 요소 세트와보다 전문화 된 기능을 수행하는 구성 요소 세트가 있습니다 (각 세트가 자체적으로 응용 프로그램이되는 시점까지 - 지금은 반드시 사실이 아니지만 그 방향으로 나아 갔다 ...)여러 폴더에 걸쳐있는 응용 프로그램 배포 .... 거의 <probing>

전개 할 때 어떤 구조를 넣고 싶습니다. 나는의 라인을 따라 생각하고 있었다 :

  • C : \ 프로그램 파일 \ MyCompany \ MyBigSystem 앱 1 \
  • C : \ 프로그램 파일 \ MyCompany \ MyBigSystem 앱 2 \
  • C : \ 프로그램 파일 \ MyCompany \ MyBigSystem \ 앱 3
  • C : \ 프로그램 파일 \ MyCompany \ MyBigSystem APPN \
  • C : \ 프로그램 파일 \ MyCompany \ MyBigSystem 예에서 코어 \

파일을 ... \ App1은 의심 할 여지없이 ... \ Core에 종속 파일을 가지지 만 분명히 ... \ App1 폴더에 이러한 파일을 재배포하지 않으려합니다. App1이 Core 폴더에서 그 (것)들을 줍기 원한다.

나는 이것이 가능한지보기 위해 고심하고 있습니다.

현재 모든 구성 요소가 내장되어 사용하여 정적 참조 :

는 여기에 몇 가지 제약과 관찰을합니다. 나는이 자세를 버리는 것보다 모든 것을 단일 폴더에 배치 할 가능성이 더 큽니다. 또한이 배포 구조를 가정하는 프로그램 코드를 수정하고 싶지 않습니다. Assembly.LoadFrom을 사용하거나 appDomain의 경로를 현명하게 설정하는 등의 대규모 변경 사항은 없습니다.

그러나 설치하는 동안 app.config 항목을 쓸 수 있기 때문에 app.config 항목을 사용해야합니다.

나는 < 먼저 눈에 이상적 나타 났지만 때문에

내가 < 코드베이스 > 살펴 보았다 하위 디렉토리에있는 자사의 제약 조건의 부적합 결국 >을 프로빙 보았다 (매우 간략 테스트) 한 - 12 개 정도의 핵심 어셈블리를 개별적으로 등록해야만하기 때문에 (이 말을 했더라도 문제를 해결할 준비가되면 원하는 것을 얻을 수있는 것처럼 보였으므로) 완전히 읽지 않았습니다.

아무도 내가 고려할 수있는 다른 방법을 제안 할 수 있습니까?

TIA, 피트

+0

App1의 ApplicationBase를 c : \ Program Files \ My Company \ My Big System으로 설정할 수 있다면 을 사용할 수 있습니다. 이 프로그래밍 방식으로 충분히 쉽게 (내 생각) 할 수 있지만 내가 어쩌면 구성을 통해 applicationBase 설정할 수 있습니까? – PeteH

+0

I * can * codeBase를 사용할 수 있습니다. 설정에서 사용자 지정 작업으로이 모든 것을 설정할 수도 있지만, 여전히 .config 파일로 끝나는 blurb 볼륨이 마음에 들지 않습니다. – PeteH

+0

내 시스템이 "글로벌"이라고 생각하는 것은 매우 허세이지만 GAC 사용을 고려 중입니다. – PeteH

답변

0

결국 나는 거의 원했지만 거의 그렇지는 않았다. 나는 내가 원하는 모든 폴더 구조로 끝났다 .... ....

  • C : \ 프로그램 파일 \ MyCompany \ MyBigSystem 앱 1 \
  • C : \ 프로그램 파일 \ MyCompany \ MyBigSystem 앱 2 \
  • C : \ 프로그램 파일 \ MyCompany \ MyBigSystem 앱 3 \
  • C : \ 프로그램 파일 \ MyCompany \ MyBigSystem APPN \
  • C : \ 프로그램 파일 \ MyCompany \ MyBigSystem 코어

\ ....하지만했다 "MyBig의 주요 실행 파일을 넣어 시스템 "폴더, 즉

  • C : \ 프로그램 파일 \ MyCompany \ MyBigSystem는 App1.exe \
  • C : \ 프로그램 파일 \ MyCompany \ MyBigSystem는 App1.exe.config \
  • C : \ 프로그램 파일 \ MyCompany \ MyBigSystem App2.exe \
  • C : \ 프로그램 파일 \ MyCompany \ MyBigSystem App2.exe.config
  • \

나는 예를 들어 실행 '설정 파일에 <probing> 항목으로이 구조를 보충

<runtime> 
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> 
     <probing privatePath="Core"/> 
    </assemblyBinding> 
    </runtime> 

이것은 내가 합리적으로 바라는 것처럼 루트 폴더를 깔끔하게 유지하는 것처럼 보였습니다. 또한 App6은 App1의 종속 라이브러리에 액세스 할 수 있습니다 (예 : 필요하다면). (이 이유 때문에 GAC에서 멀어졌습니다. 앱에 의존적 인 앱을 얻는다면 GAC에 모든 것을 부적절한 것으로 볼 수 있습니다. 부적절합니다.)

구성에서. 가장 큰 문제는 VS 설치 프로젝트에서 ( 제외) 및 하위 폴더에있는 .exe.config를 제외한 모든 것을 넣는 것이 었습니다.

0

당신은 아마 컴파일하고 공개하지해야합니다. 타사 설치 프로그램을 사용하는 것이 가장 쉽습니다. 설치 방패는 좋다.

+0

죄송 합니다만, 저는 VS2010 설치 프로젝트를 사용하는 데 제약이 많았습니다. 그러나 나는 이것이 지점을 놓친다고 생각한다. 필자는 필자가 설명한대로 셋업 프로젝트를 통해 파일을 쉽게 배치 할 수 있습니다. 설치 시간에 문제가있는 것보다 런타임에 참조를 찾을 수 없다는 것이 내 문제라고 생각합니다. – PeteH

0

Eclipse를 사용하는 경우 코어 용 프로젝트를 소스 라이브러리로 만들어 다른 모든 프로젝트에 포함 할 수 있습니다.

+0

좋은 소식입니다. 불행히도 저는 Eclipse를 사용하지 않습니다. – PeteH