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이 필요하긴 합니다. 이에 대한 테스트를 다음의 단계로 진행할 수 있습니다.
- Assembly.Load 라인에 Breakpoint를 설정, F5 키를 눌러 디버깅
- new SharedLib.Class1() 코드로 인해 SharedLib.dll이 로딩된 것을 확인
- 실행 파일 경로에서 "SharedLib.dll"을 "test.dll"로 이름 변경 (왜냐하면, 이미 로딩돼 잠겨 있으므로 삭제를 할 수 없기 때문에!)
- 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을 로딩해 어떤 정보를 구하는 것은 또 아니라는 점입니다. 이에 대한 테스트를 다음의 과정으로 할 수 있습니다.
- Assembly.Load 라인에 Breakpoint를 설정, F5 키를 눌러 디버깅
- new SharedLib.Class1() 코드로 인해 SharedLib.dll이 로딩된 것을 확인
- 실행 파일 경로에서 "SharedLib.dll"을 "test.dll"로 이름 변경, 빈 파일을 하나 생성해서 이름을 "SharedLib.dll"로 변경
- 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.0.0.1 GAC 버전의 SharedLib.dll을 참조하고 빌드
- 빌드 디렉터리에 출력된 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+ 환경은 축복이라 할 수 있겠습니다. 비록 있던 기능이 없어져 경우에 따라 마이그레이션이 불가능한 상황이 나오긴 해도, 개인적으로는 저렇게 가는 것이 나쁜 선택은 아닌 듯합니다.
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]