2013-01-19 3 views
1

먼저 내 시나리오의 경우 앱이 시작될 때 플러그인이로드되고 앱이 닫힐 때까지 언로드되지 않을 것이라고 말하면로드 된 후에 플러그인을 언로드 할 수 없다면 완전히 괜찮습니다.내 요구 사항에 따라 별도의 AppDomain에 플러그인을로드해야합니까?

그렇다면 플러그인 충돌로 인해 플러그인이 자체 애플리케이션 AppDomain에로드된다는 것은 알고 있지만 플러그인이 관리되지 않는 코드를 실행하지 않는다고 가정하면 try/catch 블록에서 플러그인에 대한 호출을 래핑 할 수 없습니다 내 앱 충돌을 피하려면? 아니면 여기에 뭔가 빠졌나요?

MAF를 사용하려고했지만 개체를 ​​원격 처리 할 때 문제가 발생했습니다. 즉, 내가 원격으로 사용할 수있는 옵션이 현재로서는 매우 바람직하지 않은 것입니다. 그래서 내가 더 원시적 인 플러그인 아키텍처로 전환하기 전에 누군가가 플러그인을 별도의 AppDomain에로드해야하는 다른 중요한 이유를 잊어 버렸다고 말할 수 있습니까? (또는 내가 단순히 충돌을 피할 수있는 것에 대해 오해하고 있는지 호출을 통해 try/catch 블록 사용)?

+1

_managed_ 코드가 충돌하면 어떨까요? 관리되는 코드가 충돌 할 가능성이 있습니다. 그런 경우 어셈블리/유형이 이미 AppDomain으로로드되었으므로 플러그인을 다시로드 할 수 없습니다. – Oded

+0

@Oded +1 내가 생각하지 못했던 위대한 포인트입니다. 그러나 나는이 시점에서 플러그 접속이 망가질 경우 고객이 앱을 다시 시작하도록 요구하는 것으로 여전히 괜찮다고 생각한다. –

답변

1

언로드 할 필요가없는 경우 별도의 AppDomains가 필요하지 않습니다.

AppDomains는 처리되지 않은 예외가 발생할 경우 프로세스가 강제 종료되지 않도록 보호하지 않습니다. new Thread(() => { throw null; }).Start()은 여전히 ​​치명적입니다.

플러그인 입구 지점이 try-catch이므로 협조해야합니다 (스레드 크래시가 없음).

일부 계산을 중단하려면 AppDomains가 유용합니다. 나중에 AppDomain 전체를 언로드하면 비교적 안전하게 Thread.Abort을 호출 할 수 있습니다.

관련 문제