도메인 중립적인 어셈블리가 비-도메인 중립적인 어셈블리를 참조하는 경우
도메인 중립적인 어셈블리(domain-neutral assembly)에 대해 아래의 글에서 설명을 했는데요.
.NET - 눈으로 확인하는 SharedDomain의 동작 방식
; https://www.sysnet.pe.kr/2/0/10948
위의 글을 "도메인 중립적인 어셈블리"의 기준으로 정리해 보면 다음과 같습니다.
- SingleDomain 모드에서는 어차피 모든(mscorlib.dll을 제외한) 어셈블리가 비-도메인 중립적인 어셈블리로 로드가 되고,
- MultiDomain 모드에서는 어차피 모든 어셈블리가 도메인 중립적인 어셈블리로 로드가 되고,
- 반면, MultiDomainHost에서는 GAC에 설치된 어셈블리만 도메인 중립적인 어셈블리로 로드가 됨.
그렇다면, MultiDomainHost 모드에서 GAC에 설치된 어셈블리가 로드되지만, 그것이 GAC에 등록되지 않은 어셈블리를 참조하는 경우라면 어떻게 처리가 될까요?
이에 대해서는 다음의 글에 이미 답이 있습니다.
Application Domains
; https://learn.microsoft.com/en-us/dotnet/framework/app-domains/application-domains
MultiDomainHost loads strong-named assemblies as domain-neutral, if they and all their dependencies have been installed in the global assembly cache
실제로 코드로 한번 확인해 볼까요? ^^
방법은 간단합니다. "
.NET - 눈으로 확인하는 SharedDomain의 동작 방식"의 소스 코드를 조금 변형할 텐데요.
우선, ConsoleApplication 프로젝트의 Main 메서드는 다음과 같이 StrongDLL 메서드만 호출합니다.
using System;
namespace ConsoleApplication1
{
partial class Program
{
[LoaderOptimization(LoaderOptimization.MultiDomainHost)]
static void Main(string[] args)
{
ShowProcessInfo();
new StrongDLL.Class1().DoMethod(); // "StrongDLL.Class1.DoMethod called" 문자열 출력 코드 포함
Console.WriteLine();
AppDomain appDomain = AppDomain.CreateDomain("TestAppDomain 1");
appDomain.DoCallBack(
() =>
{
new StrongDLL.Class1().DoMethod(); // "StrongDLL.Class1.DoMethod called" 문자열 출력 코드 포함
}
);
Console.WriteLine("Press any key to exit...");
Console.ReadLine();
}
}
}
그다음, WeakDLL 프로젝트는 '강력한 이름의 어셈블리'가 되도록 서명을 추가하고 StrongDLL에서 이를 참조합니다. 이후 다시 StrongDLL만 GAC에 등록하고 예제를 실행한 다음 windbg.exe의 !dumpdomain 명령어로 조사하면 됩니다. 다음은 이를 정리한 결과입니다.
0:007> !dumpdomain
--------------------------------------
Shared Domain: 00007ffb1707d720
00007ffb0b521000 C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System\v4.0_4.0.0.0__b77a5c561934e089\System.dll
00007ffb042d1000 C:\WINDOWS\Microsoft.Net\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll
--------------------------------------
Domain 1: 000001482b89b140
00007ffb042d1000 C:\WINDOWS\Microsoft.Net\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll
00007ffab70240c0 c:\jit_dependency\ConsoleApplication1\bin\Debug
00007ffab7025b80 C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\StrongDLL\v4.0_1.0.0.0__677c36b6f45d74b0\StrongDLL.dll
00007ffb0b521000 C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System\v4.0_4.0.0.0__b77a5c561934e089\System.dll
00007ffab7027308 c:\jit_dependency\ConsoleApplication1\bin\Debug\WeakDLL.dll
--------------------------------------
Domain 2: 000001482b92c190
00007ffb042d1000 C:\WINDOWS\Microsoft.Net\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll
00007ffab7185308 c:\jit_dependency\ConsoleApplication1\bin\Debug\ConsoleApplication1.exe
00007ffab7185c88 C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\StrongDLL\v4.0_1.0.0.0__677c36b6f45d74b0\StrongDLL.dll
00007ffab71864c0 c:\jit_dependency\ConsoleApplication1\bin\Debug\WeakDLL.dll
"LoaderOptimization.MultiDomainHost"가 정상 동작 중임을 System.dll이 "Shared Domain" 영역에 있는 것을 통해 알 수 있습니다. 반면, StrongDLL.dll은 원래는 "Shared Domain" 영역에 로드되는 것이 정상이지만 GAC에 등록되지 않은 "WeakDLL.dll"을 참조한 덕분에 "domain-neutral assembly"의 자격을 만족하지 못해 공유되지 못했습니다.
(
첨부한 파일은 이 글의 예제 코드를 포함합니다.)
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]