2011-01-05 2 views
0

ServicedComponent에서 상속받은 관리되는 .Net COM + 구성 요소가 있으며 IIS의 웹 응용 프로그램에서 side-by-side 어셈블리로 사용하려고합니다 6.0 Windows Server 2003에서.IIS6.0에서 .Net COM + 서비스가 나란히 실행됩니다.

mt.exe을 사용하여 어셈블리 매니페스트를 생성했으며이를 테스트 콘솔 응용 프로그램에서 side-by-side 모드로 성공적으로 실행했습니다. 그러나 IIS에 관해서는 작동하지 않는 것으로 보이며 매니페스트를 읽는 대신 레지스트리에서 COM + 응용 프로그램을 찾으려고 시도합니다.

매니페스트는 mt.exe -managedassemblyname:myassembly.dll -out:myassembly.manifest을 사용하여 생성 된 다음 웹 응용 프로그램의 가상 디렉터리에 복사됩니다. filemon을 사용하면 매니페스트가 읽히지 않습니다.

디렉토리를 bin 디렉토리로 이동하면 읽히지 만 같은 문제가 발생합니다.

이 작업에 성공한 사람의 도움을 받아 주시면 대단히 감사하겠습니다.

답변

0

".manifest"로 끝나는 외부 매니페스트는 실행 파일에 대해서만 자동으로 선택됩니다. IIS 나 Windows에 매니페스트에 대해 말해야합니다. 그렇지 않으면 아무도 읽지 않아도됩니다.

아마도 콘솔 응용 프로그램 테스트에서 실행 파일의 매니페스트가 MyAssembly에 대한 참조를 가지거나 관련 정보를 직접 포함했을 수 있습니다.

이제 저는 ServicedComponent에 대해별로 익숙하지 않으므로 일반적인 용어로 이야기하겠습니다.

  1. 당신이 MyAssembly로 호출하는 모든 소프트웨어를 제어 할 수 있다면, 당신은 의도적으로 매니페스트 최초의 정보를로드 할 수는 MyAssembly를 호출하고, 비활성화, 스레드 위에 해당 정보를 활성화합니다. 이것은 부모 프로세스를 오염시키지 않기 때문에 이런 종류의 플러그인 아키텍처를 충족시키는 가장 좋은 방법입니다. 코드가 실행되는 동안 코드가 실행되는 스레드 만 구성하면됩니다. 이 접근법은 All-in One Code Framework
  2. 번들로 묶인 reg-free COM 샘플에서 훌륭한 예제를 찾을 수있는 활성화 컨텍스트 API의 호출을 통해 수행됩니다. MyAssembly (을 (를) 호출하는 모든 코드를 제어하지 않으면 IIS에서 자동으로 호출되는 경우) 또는 너무 많은 곳에서 호출되고 위에 제안 된 접근 방식이 너무 비싸면 여기에서 "해킹"을 시도 할 수 있습니다. IIS6.0 작업자 프로세스 실행 파일을 가져 와서 매니페스트가 있으면 편집하거나 그렇지 않은 경우 새 매니페스트를 추가합니다 (포함 된 매니페스트가 있는지 확인하는 것을 잊지 마십시오). MyAssembly에 종속성을가집니다. 이 접근법에서는 MyAssembly의 매니페스트 컨텐츠가 IIS6 내부에서 실행되는 모든 코드의 실행 컨텍스트의 일부가되므로 상당히 큰 접근 방법입니다.
+0

종합 정보 주셔서 감사합니다. 우리가 다시 나란히 볼 때 나는 그것을 시험 할 것이다. – Alex