Microsoft MVP성태의 닷넷 이야기
닷넷: 2221. C# - LoadContext, LoadFromContext 그리고 GAC [링크 복사], [링크+제목 복사],
조회: 2867
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일

(시리즈 글이 6개 있습니다.)
.NET Framework: 574. .NET - 눈으로 확인하는 SharedDomain의 동작 방식
; https://www.sysnet.pe.kr/2/0/10948

.NET Framework: 575. SharedDomain과 JIT 컴파일
; https://www.sysnet.pe.kr/2/0/10949

.NET Framework: 577. CLR Profiler로 살펴보는 SharedDomain의 모듈 로드 동작
; https://www.sysnet.pe.kr/2/0/10951

.NET Framework: 578. 도메인 중립적인 어셈블리가 비-도메인 중립적인 어셈블리를 참조하는 경우
; https://www.sysnet.pe.kr/2/0/10952

닷넷: 2220. C# - .NET Framework 프로세스의 LoaderOptimization 설정을 확인하는 방법
; https://www.sysnet.pe.kr/2/0/13568

닷넷: 2221. C# - LoadContext, LoadFromContext 그리고 GAC
; https://www.sysnet.pe.kr/2/0/13569




C# - LoadContext, LoadFromContext 그리고 GAC

아래의 글에서,

BindingContext - Load() vs. LoadFrom()
; https://imhumanvirus.tistory.com/186

.NET 어셈블리 로드 컨텍스트(최종이길 바라며...)
; https://imhumanvirus.tistory.com/315

각각의 차이점에 대해 잘 설명해 주고 있습니다. 이것을 간단하게 테스트해 볼까요? ^^




우선, 테스트에 사용할 라이브러리 프로젝트를 간단하게 만들고,

// .NET Framework 4.8 DLL 프로젝트

using System;

namespace SharedLib
{
    public class Class1
    {
        public Class1()
        {
            Console.WriteLine($"{nameof(SharedLib)}.{nameof(Class1)}: {typeof(Class1).Assembly.Location}");
        }
    }
}

이것을 참조하는 Console App 프로젝트를 다음과 같이 만듭니다.

// .NET Framework 4.8 Console App 프로젝트

namespace ConsoleApp1
{
    internal class Program
    {
        public static string _dllFileName = "SharedLib.dll";
        static void Main(string[] args)
        {
            Console.WriteLine($"[Load - {_dllFileName} into LoadContext]");
            TestLoadContext();
        }

        private static void TestLoadContext()
        {
            SharedLib.Class1 instance = LoadSharedLib() as SharedLib.Class1;
            Console.WriteLine($"Is SharedLib.Class1 (Load): {instance}");
        }

        private static void PrintLoadedAssemblies()
        {
            Console.WriteLine("---------------------------------------------------");
            foreach (var item in AppDomain.CurrentDomain.GetAssemblies())
            {
                Console.WriteLine($"{item.FullName}, FromGAC: {item.GlobalAssemblyCache} at {item.CodeBase}");
            }
            Console.WriteLine("---------------------------------------------------");
        }

        private static object LoadSharedLib()
        {
            SharedLib.Class1 cl = new SharedLib.Class1();

            Assembly asm = Assembly.Load("SharedLib");
            object objInstance = asm.CreateInstance("SharedLib.Class1");

            PrintLoadedAssemblies();
            return objInstance;
        }
    }
}

이렇게 하고 실행하면 다음과 같은 출력을 볼 수 있습니다.

[Load - SharedLib.dll into LoadContext]
SharedLib.Class1: C:\temp\ConsoleApp1\ConsoleApp1\bin\Debug\SharedLib.dll
SharedLib.Class1: C:\temp\ConsoleApp1\ConsoleApp1\bin\Debug\SharedLib.dll
---------------------------------------------------
mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, FromGAC: True at C:\Windows\Microsoft.NET\Framework\v4.0.30319\mscorlib.dll
ConsoleApp1, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null, FromGAC: False at C:\temp\ConsoleApp1\ConsoleApp1\bin\Debug\ConsoleApp1.exe
SharedLib, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null, FromGAC: False at C:\temp\ConsoleApp1\ConsoleApp1\bin\Debug\SharedLib.dll
---------------------------------------------------
Is SharedLib.Class1 (Load): SharedLib.Class1

ConsoleApp1이 소스코드에 직접 사용한 "SharedLib.Class1" 코드는,

private static object LoadSharedLib()
{
    SharedLib.Class1 cl = new SharedLib.Class1(); // JIT 컴파일러가 LoadSharedLib() 메서드를 컴파일하는 시점에 SharedLib.dll을 LoadContext에 로드

    Assembly asm = Assembly.Load("SharedLib"); // SharedLib.dll을 LoadContext에서 찾아서 반환
    object objInstance = asm.CreateInstance("SharedLib.Class1");

    PrintLoadedAssemblies();
    return objInstance;
}

비록 내부에서 "new SharedLib.Class1" 및 "Assembly.Load" 코드가 사용됐지만, 그것을 실행하기도 전에, 즉 LoadSharedLib 메서드를 JIT 컴파일러가 jitting하는 동안 (SharedLib를 정적 참조했기 때문에) SharedLib.Class1의 메타데이터를 매핑하기 위해 LoadContext에 DLL을 로드합니다. 그리고 이후 Assmelby.Load 코드 실행도 "new SharedLib.Class1()"으로 로딩되었던 그 DLL로 처리하게 됩니다.

따라서, 당연하겠지만 이렇게 LoadContext에서 반환받은 Assembly로부터 CreateInstance한 개체는 (소스코드에 직접 사용한) SharedLib.Class1로의 형변환이 가능합니다.

SharedLib.Class1 instance = LoadSharedLib() as SharedLib.Class1;
Console.WriteLine($"Is SharedLib.Class1 (Load): {instance}"); // 출력 결과: Is SharedLib.Class1 (Load): SharedLib.Class1




이쯤에서, 정적 참조한 어셈블리와 Assembly.Load 코드를 좀 다르게 테스트를 해보겠습니다. ^^

SharedLib.Class1 cl = new SharedLib.Class1();
Assembly asm = Assembly.Load("SharedLib");

위와 같이 한 경우, Assembly.Load는 얼핏 이전 코드에서 LoadContext에 cache한 DLL을 곧바로 사용할 것 같은데요, 실제로는 Assembly.Load 단계에서 여전히 SharedLib.dll이 필요하긴 합니다. 이에 대한 테스트를 다음의 단계로 진행할 수 있습니다.

  1. Assembly.Load 라인에 Breakpoint를 설정, F5 키를 눌러 디버깅
  2. new SharedLib.Class1() 코드로 인해 SharedLib.dll이 로딩된 것을 확인
  3. 실행 파일 경로에서 "SharedLib.dll"을 "test.dll"로 이름 변경 (왜냐하면, 이미 로딩돼 잠겨 있으므로 삭제를 할 수 없기 때문에!)
  4. F10 키를 눌러 Assembly.Load 코드를 실행

만약, 단순히 LoadContext에 cache한 DLL을 사용하고 있다면 위의 4번 단계에서 오류 없이 로딩을 하겠지만, 실제로 해보면 "System.IO.FileNotFoundException: 'Could not load file or assembly 'SharedLib' or one of its dependencies. The system cannot find the file specified.'" 예외가 발생합니다.

재미있는 건, 그렇다고 해서 Assembly.Load가 SharedLib.dll을 로딩해 어떤 정보를 구하는 것은 또 아니라는 점입니다. 이에 대한 테스트를 다음의 과정으로 할 수 있습니다.

  1. Assembly.Load 라인에 Breakpoint를 설정, F5 키를 눌러 디버깅
  2. new SharedLib.Class1() 코드로 인해 SharedLib.dll이 로딩된 것을 확인
  3. 실행 파일 경로에서 "SharedLib.dll"을 "test.dll"로 이름 변경, 빈 파일을 하나 생성해서 이름을 "SharedLib.dll"로 변경
  4. F10 키를 눌러 Assembly.Load 코드를 실행

이번에는, 그냥 빈 껍데기인 SharedLib.dll이지만 Assembly.Load는 그것과 상관없이 기존 정적 참조로 로딩했던 SharedLib.dll을 LoadContext에서 찾아 성공적으로 어셈블리를 반환합니다. 즉, 파일의 존재만 중요한 것입니다.

또 한 가지 재미있는 점은, Assembly.Load가 동일하다면 두 번째 부터는 파일 유무를 확인하지 않습니다.

Assembly asm = Assembly.Load("SharedLib"); // SharedLib.dll을 찾지만
Assembly asm2 = Assembly.Load("SharedLib"); // 이 단계에서는 SharedLib.dll이 없어도 성공

위의 상황을 종합해 보면, Assembly.Load는 인자로 넘어온 이름의 DLL이 배포 경로에 존재하는지 확인만 하고, 만약 있다면 LoadContext cache로부터 "SharedLib"라는 식별자로 어셈블리를 찾아 반환하거나 직접 로딩을 합니다. 반면, 없다면 예외를 발생시킵니다.




자, 그럼 LoadFromContext에 SharedLib.dll을 로딩해 볼까요? ^^ 비교를 위해 다음과 같이 추가 코딩을 한 후 실행해 봅니다.

namespace ConsoleApp1
{
    internal class Program
    {
        public static string _dllFileName = "SharedLib.dll";
        static void Main(string[] args)
        {
            Console.WriteLine($"[Load - {_dllFileName} into LoadContext]");
            TestLoadContext();

            Console.WriteLine();

            Console.WriteLine($"[LoadFrom - {_dllFileName} into LoadFromContext]");
            TestLoadFromContext();
        }

        private static void TestLoadFromContext()
        {
            CopyToTemp(deleteSource: false);
            {
                SharedLib.Class1 instance = LoadSharedLibFrom() as SharedLib.Class1;
                Console.WriteLine($"Is SharedLib.Class1 (LoadFrom): {instance?.ToString() ?? "(null)"}");
            }
        }

        private static object LoadSharedLibFrom()
        {
            string dirPath = Path.GetDirectoryName(typeof(SharedLib.Class1).Assembly.Location);
            string dstFilePath = Path.Combine(dirPath, _dllFileName);
            Assembly asm = Assembly.LoadFrom(dstFilePath);
            object objInstance = asm.CreateInstance("SharedLib.Class1");

            PrintLoadedAssemblies();
            return objInstance;
        }

        // ...[LoadContext 관련 코드 생략]...
    }
}

그럼 출력 결과는 이렇습니다.

[LoadFrom - SharedLib.dll into LoadFromContext]
SharedLib.Class1: C:\temp\ConsoleApp1\ConsoleApp1\bin\Debug\SharedLib.dll
---------------------------------------------------
mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, FromGAC: True at C:\Windows\Microsoft.NET\Framework\v4.0.30319\mscorlib.dll
ConsoleApp1, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null, FromGAC: False at C:\temp\ConsoleApp1\ConsoleApp1\bin\Debug\ConsoleApp1.exe
SharedLib, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null, FromGAC: False at C:\temp\ConsoleApp1\ConsoleApp1\bin\Debug\SharedLib.dll
---------------------------------------------------
Is SharedLib.Class1 (LoadFrom): SharedLib.Class1

결과가 똑같군요. ^^ 즉, Assembly.LoadFrom을 했어도 무조건 LoadFromContext로 처리되는 것은 아닙니다. ".NET 어셈블리 로드 컨텍스트(최종이길 바라며...)" 글에서도 나오지만, LoadFrom의 대상이 AppDomain.CurrentDomain.BaseDirectory (및 CLR이 privateBin 등의 설정으로 어셈블리를 검색하는 경로에 포함된 경우)라면 LoadContext로 관리합니다.

따라서, 명시적으로 LoadFromContext에 SharedLib.dll을 로드하고 싶다면, (응용 프로그램의 배포 디렉터리가 아닌) c:\temp 등에 SharedLib.dll을 복사한 다음,

private static void TestLoadFromContext()
{
    CopyToTemp(deleteSource: false);
    {
        SharedLib.Class1 instance = LoadSharedLibFromTemp() as SharedLib.Class1;
        Console.WriteLine($"Is SharedLib.Class1 (LoadFrom): {instance?.ToString() ?? "(null)"}");
    }
}

private static void CopyToTemp(bool deleteSource)
{
    string filePath = typeof(Program).Assembly.Location;
    string srcDir = Path.GetDirectoryName(filePath);

    string srcFilePath = Path.Combine(srcDir, _dllFileName);
    string dstFilePath = Path.Combine(@"C:\temp", _dllFileName);

    System.IO.File.Copy(srcFilePath, dstFilePath, true);

    if (deleteSource && File.Exists(srcFilePath))
    {
        File.Delete(srcFilePath);
    }
}

바로 그 c:\temp\SharedLib.dll을 LoadFrom으로 로딩해야 합니다.

private static object LoadSharedLibFromTemp()
{
    string dirPath = @"C:\temp";
    string dstFilePath = Path.Combine(dirPath, _dllFileName);
    Assembly asm = Assembly.LoadFrom(dstFilePath);
    object objInstance = asm.CreateInstance("SharedLib.Class1");

    PrintLoadedAssemblies();
    return objInstance;
}

그럼 출력 결과는 다시 이렇게 바뀌고,

[LoadFrom - SharedLib.dll into LoadFromContext]
SharedLib.Class1: C:\temp\SharedLib.dll
---------------------------------------------------
mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, FromGAC: True at C:\Windows\Microsoft.NET\Framework\v4.0.30319\mscorlib.dll
ConsoleApp1, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null, FromGAC: False at C:\temp\ConsoleApp1\ConsoleApp1\bin\Debug\ConsoleApp1.exe
SharedLib, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null, FromGAC: False at C:\temp\ConsoleApp1\ConsoleApp1\bin\Debug\SharedLib.dll
SharedLib, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null, FromGAC: False at C:\temp\SharedLib.dll
---------------------------------------------------
Is SharedLib.Class1 (LoadFrom): (null)

보는 바와 같이 SharedLib 항목이 2개 나오는데요, 첫 번째 것은 LoadContext, 두 번째 것은 LoadFromContext에 로딩된 것입니다.




위의 결과는 SharedLib를 서명해도 마찬가지입니다. 현재 실행 파일의 경로에 "SharedLib, Version=1.0.0.0, Culture=neutral, PublicKeyToken=691b755f429954a2" 어셈블리가 있다고 가정했을 때, LoadFrom("C:\temp\SharedLib.dll")을 하게 되면 1) LoadContext에 이미 로딩돼 있는 DLL도 무시하고, 2) 실행 파일의 경로에 있는 SharedLib.dll도 무시한 채로 새롭게 LoadFromContext에 로드합니다.

그런데, SharedLib를 GAC에 등록하면 사정이 달라집니다. Assembly.LoadFrom("C:\temp\SharedLib.dll")은 GAC에 있는 어셈블리를 찾아서 LoadContext에 로드를 하게 됩니다. 재미있죠? ^^ LoadFrom에 넘겨준 인자에는 분명히 Strong Name을 위한 어떠한 정보도 없는데 GAC로 매핑할 수 있다는 것은 어쨌든 LoadFrom 메서드는 내부적으로 SharedLib.dll 파일을 Open/Read 까지는 한다는 것을 의미합니다. 이후 Strong Name 정보를 읽고, 그것이 GAC에 있다면 LoadContext로 연결을 하는 듯합니다.

그렇다면 Assembly.Load는 GAC DLL에 대해 어떻게 반응할까요? 기본 동작은 이전에 설명했던 원칙을 따르긴 하지만 약간 달라지는 점이 있습니다. 예를 들어 다음의 코드를 보면,

SharedLib.Class1 cl = new SharedLib.Class1(); // 정적 참조를 "SharedLib, Version=1.0.0.0, Culture=neutral, PublicKeyToken=691b755f429954a2"로 가정

Assembly asm = Assembly.Load("SharedLib");

정적 참조로 인해 GAC에 있는 DLL을 로딩했기 때문에 배포 디렉터리에 있는 SharedLib.dll은 삭제가 가능합니다. (또는 아예 배포 디렉터리에서 없는 체로 실행해도 됩니다.) 하지만, 삭제를 하는 경우 당연히 Assembly.Load에서 예외가 발생할 텐데요, 이 예외를 벗어나기 위해 단순히 "빈 파일"의 dll을 놓아 두면 "System.BadImageFormatException: 'Could not load file or assembly 'SharedLib' or one of its dependencies. The module was expected to contain an assembly manifest.'" 예외가 발생합니다.

즉, 이번에는 단순히 파일의 존재 유무만 보는 것이 아니고 그 파일로부터 정보를 읽어내기까지 하는 것입니다. 그래서 다음과 같은 식의 테스트를 해보면,

  1. 프로젝트에 1.0.0.1 GAC 버전의 SharedLib.dll을 참조하고 빌드
  2. 빌드 디렉터리에 출력된 SharedLib.dll을 삭제하고 1.0.0.0 GAC 버전의 SharedLib.dll을 복사

이전 코드는 다음과 같이 동작하게 됩니다.

SharedLib.Class1 cl = new SharedLib.Class1(); // 정적 참조를 1.0.0.1 버전의 SharedLib.dll을 했으므로 GAC로부터 로딩

Assembly asm = Assembly.Load("SharedLib"); // 빌드 디렉터리에 있는 1.0.0.0 버전의 SharedLib.dll을 읽었고,
                                           // 그 버전이 로딩돼 있지 않으므로 새롭게 1.0.0.0 버전으로 로드 (GAC에 있다면 GAC로부터, 없다면 로컬에서)

결국, Assembly.Load는 LoadContext에 cache된 DLL의 (Strong name을 가진) GAC 로딩 여부에 따라 배포 디렉터리의 SharedLib.dll을 단순히 존재만 확인할 것인지, Strong name까지 읽어야 할 것인지가 결정됩니다.




정말 복잡하죠? ^^ 다중 AppDomain만으로도 복잡한데, GAC까지 더해지니 매우 복잡한 Assembly 풀이가 엮입니다. 어찌보면 그 2가지 요소가 없어진 .NET Core/5+ 환경은 축복이라 할 수 있겠습니다. 비록 있던 기능이 없어져 경우에 따라 마이그레이션이 불가능한 상황이 나오긴 해도, 개인적으로는 저렇게 가는 것이 나쁜 선택은 아닌 듯합니다.




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]







[최초 등록일: ]
[최종 수정일: 2/28/2024]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 




1  2  3  [4]  5  6  7  8  9  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
13602정성태4/20/20242364닷넷: 2244. C# - PCM 오디오 데이터를 연속(Streaming) 재생 (Windows Multimedia)파일 다운로드1
13601정성태4/19/20242435닷넷: 2243. C# - PCM 사운드 재생(NAudio)파일 다운로드1
13600정성태4/18/20242523닷넷: 2242. C# - 관리 스레드와 비관리 스레드
13599정성태4/17/20242417닷넷: 2241. C# - WAV 파일의 PCM 사운드 재생(Windows Multimedia)파일 다운로드1
13598정성태4/16/20242890닷넷: 2240. C# - WAV 파일 포맷 + LIST 헤더파일 다운로드2
13597정성태4/15/20242658닷넷: 2239. C# - WAV 파일의 PCM 데이터 생성 및 출력파일 다운로드1
13596정성태4/14/20242961닷넷: 2238. C# - WAV 기본 파일 포맷파일 다운로드1
13595정성태4/13/20242956닷넷: 2237. C# - Audio 장치 열기 (Windows Multimedia, NAudio)파일 다운로드1
13594정성태4/12/20242896닷넷: 2236. C# - Audio 장치 열람 (Windows Multimedia, NAudio)파일 다운로드1
13593정성태4/8/20242934닷넷: 2235. MSBuild - AccelerateBuildsInVisualStudio 옵션
13592정성태4/2/20243724C/C++: 165. CLion으로 만든 Rust Win32 DLL을 C#과 연동 [1]
13591정성태4/2/20242822닷넷: 2234. C# - WPF 응용 프로그램에 Blazor App 통합파일 다운로드1
13590정성태3/31/20242665Linux: 70. Python - uwsgi 응용 프로그램이 k8s 환경에서 OOM 발생하는 문제
13589정성태3/29/20242894닷넷: 2233. C# - 프로세스 CPU 사용량을 나타내는 성능 카운터와 Win32 API파일 다운로드1
13588정성태3/28/20243481닷넷: 2232. C# - Unity + 닷넷 App(WinForms/WPF) 간의 Named Pipe 통신 [2]파일 다운로드1
13587정성태3/27/20242988오류 유형: 900. Windows Update 오류 - 8024402C, 80070643
13586정성태3/27/20244481Windows: 263. Windows - 복구 파티션(Recovery Partition) 용량을 늘리는 방법
13585정성태3/26/20243220Windows: 262. PerformanceCounter의 InstanceName에 pid를 추가한 "Process V2"
13584정성태3/26/20243538개발 환경 구성: 708. Unity3D - C# Windows Forms / WPF Application에 통합하는 방법 [4]파일 다운로드1
13583정성태3/25/20243179Windows: 261. CPU Utilization이 100% 넘는 경우를 성능 카운터로 확인하는 방법
13582정성태3/19/20243346Windows: 260. CPU 사용률을 나타내는 2가지 수치 - 사용량(Usage)과 활용률(Utilization)파일 다운로드1
13581정성태3/18/20243315개발 환경 구성: 707. 빌드한 Unity3D 프로그램을 C++ Windows Application에 통합하는 방법
13580정성태3/15/20242838닷넷: 2231. C# - ReceiveTimeout, SendTimeout이 적용되지 않는 Socket await 비동기 호출파일 다운로드1
13579정성태3/13/20243354오류 유형: 899. HTTP Error 500.32 - ANCM Failed to Load dll
13578정성태3/11/20243681닷넷: 2230. C# - 덮어쓰기 가능한 환형 큐 (Circular queue)파일 다운로드1
13577정성태3/9/20243920닷넷: 2229. C# - 닷넷을 위한 난독화 도구 소개 (예: ConfuserEx)
1  2  3  [4]  5  6  7  8  9  10  11  12  13  14  15  ...