런타임 호출 가능한 래퍼 (RCW) 범위 - 프로세스 또는 응용 프로그램 도메인?

Question

관리되지 않는 COM 개체를 참조 할 때 런타임 호출 래퍼 (RCW)의 범위는 얼마입니까? 문서에 따르면 :

런타임은 해당 객체에 존재하는 참조 수에 관계없이 각 COM 객체에 대해 정확히 하나의 RCW를 만듭니다.

내가 "추측"해야한다면 -이 설명은 "프로세스 당 하나"를 의미해야하지만 실제로는입니까? 추가 문서는 매우 환영합니다.

내 응용 프로그램은 자체 애플리케이션 도메인 (Outlook Addin)에서 실행되며, Count가 0에 도달 할 때까지 (권장되는대로) Loop에서 Marshal.releasecomobject (x)를 사용하면 어떻게되는지 알고 싶습니다. 다른 Addins (동일한 Outlook 프로세스에서 다른 응용 프로그램 도메인에서 실행)의 참조를 공개합니까?

편집 : 완벽 - 이제 혼란이 훨씬 큽니다. 2 개의 답변 (Lette와 Ilya)을 기반으로 2 가지 답변이 있습니다. 공무원 MSDN DOC 프로세스 당 말하지만 (Ver. 2.0+), 그러나이 문장이 누락되었습니다. ver. 문서의 1.1.

동시에, Mason Bendixen의 기사에서, 그것은 그것이 appdomain 당이라고 말합니다.

그의 기사가 오래 되었기 때문에 (2007 년 4 월), 나는 그에게 설명을 요청하는 이메일을 보냈지 만, 다른 사람이 무언가를 추가해야한다면,하십시오.

감사

Answer 1

Managed에서는 RCWS로 다시 Canonical Iunknown을 앱 도메인 캐시 매핑을 보유하고 있습니다. iunknown이 시스템에 들어가면 (마샬 호출을 통해, 활성화를 통해, 메소드 호출의 리턴 매개 변수로) 캐시를 확인하여 RCW가 COM 객체에 이미 존재하는지 확인합니다. 매핑이 존재하면 기존 RCW에 대한 참조가 반환됩니다. 그렇지 않으면 새 RCW가 생성되고 캐시 매핑이 추가됩니다.

~에서 메이슨의 블로그

Answer 2

Ilya가 인용 한 Mason Bendixen 블로그 기사는 정확합니다. RCW는 프로세스가 아닌 AppDomain으로 범위를 띠고 있습니다. 나는 단지 그것을 추측 할 수있다 런타임 호출 가능한 래퍼 (MSDN 2.0) 기사는 "자연스럽게"말하고있었습니다. 이 기사는 일반적인 의미에서 반드시 잘못된 것은 아닙니다. 단일 앱 도메인 만 사용하는 것이 가장 일반적이지만 그 문장은 기술적으로 정확하지는 않습니다.

특정 질문에 관해서 :

"Count가 0에 도달 할 때까지 (권장대로)에 도달 할 때까지 Loop에서 Marshal.ReleaseComoBject (x)를 사용하면 어떻게되는지 알고 싶습니다. 다른 AddIns의 참조를 해제 할 것입니까 (동일한 Outlook 프로세스에서 다른 응용 프로그램 도메인에서 실행). ? "

이에 대한 답은 추가 기능을 설정하는 방법에 따라 다릅니다. 일반적으로 예방 조치를 취하지 않으면 대답은 예입니다. 동일한 appDomain 내에서 작동하는 다른 추가 기능의 참조에 영향을 미칩니다. 그러나 당신은 당신이 별도의 appdomain에서 실행되고 있다고 말하기 때문에 그렇지 않을 것입니다.

이있다 Com Shim Wizard 버전 2.3.1 추가 기능을 분리하는 데 사용할 수 있습니다. COM Shim Wizard에 대한 문서는 다음과 같습니다. Com Shim Wizard 버전 2.3.1로 Microsoft Office 확장 분리.

Com Shim Wizard는 반사를 사용하여 별도의 앱 도메인 내에 애드 인 어셈블리를로드하는 맞춤형 COM 프론트 엔드 로더를 구축합니다. 이것은 두 가지 측면에서 안전을 만듭니다.

(1) 별도의 맞춤형 COM 진입 점을 사용하면 다른 모든 추가 기능에서 Microsoft Office에서 추가 기능이 별도로 식별됩니다. 그렇지 않으면 기본적으로 모든 애드 인은 동일한 기본 mscoree.dll 로더를 공유합니다. 동일한 로더를 공유하는 데있어 문제는 추가 기능이 충돌이 발생하면 Mscoree.dll이 Microsoft Office에서 문제의 원인으로 식별되고 다음 번에는 자동으로로드되지 않는다는 것입니다. 수동으로 다시 켜질 수 있지만 다른 사람의 추가 기능에 문제가 발생하여 다음 번에 추가 기능을 자동으로로드하지 않습니다!

(2) 별도의 appDomain 내에 어셈블리를로드함으로써 런타임 호출 가능한 포장지 (RCW)는 동일한 프로세스에로드 된 다른 애드 인에서 분리됩니다. 이 경우 Marshal.reneasecomobject (Object) 또는 Marshal.FinalReleaseComobject (Object)를 호출하면 다른 사람의 추가 인에게 영향을 미치지 않을 것입니다. 더 중요한 것은, 다른 애드 인 중 하나라도 그러한 호출을하는 경우, 추가 기능이 손상되지 않도록 보호됩니다. :-)

Com Shim Wizard를 사용하는 단점은 별도의 appdomain에서 작동함으로써 여분의 마샬링 오버 헤드가 있다는 것입니다. 나는 이것이 Microsoft Outlook 애드 인에게 눈에 띄어 야한다고 생각하지 않습니다. 그러나 Microsoft Excel 애드 인의 경우와 같은 객체 모델에 대한 많은 호출이있는 일부 집중적 인 루틴의 경우 요인이 될 수 있습니다.

당신은 당신이 이미 별도의 appdomain에서 추가 기능을 실행하고 있다고 말했습니다. 이것이 사실이라면, 당신은 이미 다른 appdomains와 관련하여 Marshal.reneasecomobject (Object) 및 Marshal.FinalReleasecomObject (Object) 호출에서 분리되어 있습니다. (그건 그렇고, 당신이 어떻게이 일을하고 있는지 궁금합니다 ... 당신은 자신의 appdomain을 명시 적으로 만들고 있습니까? Visual Studio의 기본 추가 템플릿은 ~ 아니다 별도의 appDomain에서 실행하고 mscoree.dll을 사용하여로드.)

자신만의 appDomain을 작성하는 경우 코드가 격리되어 있지만 다른 수단을 활용하지 않는 한, 추가 기능이 여전히 기본 MScoree.dll 로더를 공유 할 수 있으므로 신분이 다른 애드 인과 분리되지 않을 수 있습니다. 이것을 해결하기 위해.

이게 도움이 되길 바란다...

Answer 3

동일한 문서에 따르면 :

런타임은 단일 RCW를 유지합니다 프로세스 당 각 객체에 대해.

나는 우리가 그것을 안전하게 가정 할 수 있다고 생각합니다 물체 = 사례, addins/appdomains가 동일한 인스턴스에 대한 참조를 보유하지 않으면 ReleaseComObject 다른 곳에서 생성 된 인스턴스에 대한 참조를 공개하지 않습니다.

편집 : 문서의 문구가 잘못되었을 수 있습니다. 다른 곳에서 언급했듯이. 그렇다면 추가 기능이 별도의 AppDomain에서 실행되므로 운이 좋을 것입니다. 다른 애드 인이 동일한 인스턴스를 참조하더라도 (예 : Outlook의 메시지 객체) ReleaseComObject AppDomain에서 호출하면 다른 앱 도메인의 RCW가 해당 인스턴스에 대한 참조를 잃지 않습니다.