응용 프로그램 도메인을 이해하지 못합니다.

응용 프로그램 도메인을 이해하지 못합니다.

---

.NET에는 내가 이해하는 바에서 어셈블리를 메모리에로드하는 데 사용할 수있는 애플리케이션 도메인 개념이 있습니다. 이 주제에 대한 추가 지식을 얻기 위해 응용 프로그램 도메인에 대한 조사를 수행하고 지역 서점을 방문했지만 매우 부족한 것 같습니다.

응용 프로그램 도메인으로 할 수있는 모든 작업은 메모리에 어셈블리를로드하고 원할 때 언로드 할 수 있다는 것입니다.

응용 프로그램 도메인에 대해 언급 한 다른 기능은 무엇입니까? 스레드는 애플리케이션 도메인 경계를 존중합니까? 통신 성능을 넘어서 주요 응용 프로그램 도메인이 아닌 다른 응용 프로그램 도메인에 어셈블리를로드하는 데 따른 단점이 있습니까?

응용 프로그램 도메인을 설명하는 리소스에 대한 링크도 좋습니다. 나는 그들에 대한 많은 정보가없는 MSDN을 이미 확인했습니다.

---

AppDomain은 매우 가벼운 프로세스로 가장 잘 시각화됩니다.

.Net 프로세스 당 N 개의 AppDomain이있을 수 있지만 일반적으로 말하면 하나만 있습니다. AppDomains의 진정한 장점은 프로세스 내에서 격리 경계를 제공한다는 것입니다. 개체는 원격 또는 직렬화를 통해 AppDomain 경계를 넘어서 만 서로 통신 할 수 있습니다.

프로세스 내에서 완전히 다른 보안 수준에서 2 개의 AppDomain을 실행할 수도 있습니다. 이렇게하면 훨씬 낮은 신뢰 수준에서 신뢰할 수없는 플러그인을 실행하면서 전체 신뢰에서 기본 애플리케이션을 실행할 수 있습니다.

스레드가 AppDomain을 존중하는지 여부에 대해 예 또는 아니오라고 말하는 것은 어렵습니다. 단일 스레드가 N 개의 서로 다른 AppDomain에있을 수 있습니다. 이러한 상황은 한 AppDomain의 개체가 다른 AppDomain의 개체를 원격 호출하는 경우 가능합니다. 스레드를 완료하려면 AppDomain간에 전환해야합니다.

AppDomains의 단점은 주로 복잡성입니다. Remoting은 머리를 돌리는 데 약간의 시간이 걸릴 수 있으며 AppDomain을 올바르게 설정하는 것은 간단한 프로세스가 될 수 있습니다.

AppDomains에 대한 MSDN 설명서를 살펴볼 수 있습니다. 복잡한 기능이 다양하기 때문에이를 설명하는 간결한 자습서를 찾기가 어렵습니다. 이것은 귀하의 질문에 직접 답변하지 않으면 최소한 올바른 위치로 안내하는 멋진 개요를 제공합니다.

http://msdn.microsoft.com/en-us/library/cxk374d9.aspx

이 문서는 더 이상 유지 관리되지 않습니다. 업데이트 된 버전은 https://msdn.microsoft.com/en-us/library/2bh4z9hs(v=vs.110).aspx를 참조하십시오.

---

JaredPar의 대답은 좋습니다. 단, AppDomains에 대한 이유 를 알지 못합니다 . 즉, AppDomain을 언로드하여 어셈블리를 언로드 할 수만 있다는 것입니다. 장기 실행 OS 프로세스이고 어떤 이유로 든 어셈블리 를로드 한 다음 나중에 언로드 해야하는 경우 AppDomain이 필요합니다. 여기의 프로토 타입 예제는 ASP.NET으로, 요청시 앱 코드 어셈블리를로드 한 다음 나중에 앱이 더 이상 활발하게 사용되지 않을 때 언로드 할 수 있습니다.

언로드 기능에 대해 지불하는 비용은 독립성입니다. AppDomain 경계를 넘어 통신해야합니다. 간단한 메서드 호출을 만들 수 없습니다. AppDomain 수명주기를 관리해야합니다. 기타.

그냥 동적으로로드 어셈블리에 필요하고 생각하지 않으면 당신은 그들을 언로드해야합니다 단일 프로세스의 수명 동안 그때는 아마 하지 않는 여러 응용 프로그램 도메인을 실행해야합니다. 여기에 좋은 예는 "etc"디렉토리에서 플러그인 어셈블리를 찾아 내고 모두로드하는 플러그인 모델을 지원하는 풍부한 앱일 수 있습니다. 그러나 플러그인 모델이 플러그인 언로드를 요구하는 경우 ... 음.

외부 시나리오가 있습니다. 마찬가지로 두 개의 서로 다른 버전의 어셈블리를 동시에로드한다고 가정합니다. AppDomain으로 분리하지 않으면 함정에 빠질 수 있습니다. 그러나 그것은 매우 드문 일입니다.

AppDomains의 존재를 정당화하는 핵심 시나리오는 어셈블리를 언로드 할 수 있어야하는 장기 실행 프로세스입니다.

물론 어셈블리를 언로드하려는 경우 애플리케이션은 OS 프로세스에 의존 할 수 있습니다. 즉, 각각 자체 어셈블리 집합이있는 3 개 또는 4 개의 협력 프로세스를 실행할 수 있으며 어셈블리를 언로드하려는 경우 해당 어셈블리를 호스팅하는 프로세스를 종료하면됩니다. 그러나 AppDomain은 프로세스 중지 / 시작 또는 프로세스 간 통신을 요구하지 않고이를 수행 할 수있는 더 높은 성능의 메커니즘을 제공합니다. 이는 앞서 설명한 교차 AppDomain 통신보다 여전히 무겁습니다. 내 말은 여전히 ​​원격이지만 더 느리고 더 많은 컨텍스트 전환입니다.

---

AppDomain으로 수행 할 수있는 작업 :

• 프로그램의 안정성을 위협하지 않고 종료 할 수 있습니다.
• 코드를로드하고 자신의 프로세스보다 적은 권한을 부여 할 수 있습니다 (예 : 프로세스가 완전히 신뢰할 수 있지만 디스크에 파일을 만들 수도없는 별도의 AppDomain에 코드를로드합니다).
• 프로세스를 중단하지 않고도 AppDomain의 처리되지 않은 예외를 처리 할 수 ​​있습니다.
• 기타.

간단히 말해서 보안 경계이며 대부분의 프로세스 경계입니다. 성능면에서 한 프로세스 내의 여러 AppDomain은 상당한 오버 헤드를 나타내지 않습니다. AppDomain 대신 별도의 프로세스를 시작하는 것은 훨씬 더 많은 비용이 듭니다.

참고 URL : https://stackoverflow.com/questions/622516/i-dont-understand-application-domains