.NET Framework의 Strong-named 어셈블리 바인딩 (2) - 런타임에 바인딩 리디렉션
지난 글에서,
.NET Framework의 Strong-named 어셈블리 바인딩 (1) - app.config을 이용한 바인딩 리디렉션
; https://www.sysnet.pe.kr/2/0/12210
어셈블리의 버전 불일치에 대한 해결책을 app.config을 이용해 우회했는데요. 이것을 런타임에 AppDomain.CurrentDomain.AssemblyResolve 이벤트를 이용해 개발자가 직접 제어하는 것도 가능합니다.
AppDomain.CurrentDomain.AssemblyResolve += CurrentDomain_AssemblyResolve;
private static Assembly CurrentDomain_AssemblyResolve(object sender, ResolveEventArgs args)
{
AssemblyName asmName = new AssemblyName(args.Name);
string path = Path.GetDirectoryName(typeof(Program).Assembly.Location);
string dllPath = Path.Combine(path, $"{asmName.Name}.dll");
Console.WriteLine("Resolving path: " + dllPath);
return Assembly.LoadFile(dllPath);
}
AssemblyResolve 이벤트는 대개 특정 어셈블리를 로딩하지 못했을 때 개발자가 직접 로드하는 식으로 구현하는데요, 그 구현의 특성상 버전을 무시한 로딩을 하는 것도 가능합니다. 예를 들어, 아래의 코드는 "Version=1.0.0.0", "Version=1.5.0.0"의 ClassLibrary1.dll 요청에 대해 동일하게 2.0.0.0 파일로 처리를 합니다.
// ClassLibrary1, Version=2.0.0.0
using System;
namespace ClassLibrary1
{
public class Class1
{
public static int Version = 5;
public void Test()
{
Console.WriteLine(ClassLibrary1.Class1.Version ++);
}
}
}
// ConsoleApp1
using System;
using System.IO;
using System.Reflection;
namespace ConsoleApp1
{
class Program
{
static void Main(string[] args)
{
AppDomain.CurrentDomain.AssemblyResolve += CurrentDomain_AssemblyResolve;
// new ClassLibrary1.Class1().Test();
LoadAtRuntime("Version=1.0.0.0");
LoadAtRuntime("Version=1.5.0.0");
}
private static Assembly CurrentDomain_AssemblyResolve(object sender, ResolveEventArgs args)
{
AssemblyName asmName = new AssemblyName(args.Name);
string path = Path.GetDirectoryName(typeof(Program).Assembly.Location);
string dllPath = Path.Combine(path, $"{asmName.Name}.dll");
Console.WriteLine("Resolving path: " + dllPath);
return Assembly.LoadFile(dllPath);
}
private static void LoadAtRuntime(string versionText)
{
string clName = $"ClassLibrary1, {versionText}, Culture=neutral, PublicKeyToken=0086c02b325d69fe";
Assembly asm = Assembly.Load(clName);
Console.WriteLine(asm.FullName);
object objInstance = Activator.CreateInstance(asm.GetType("ClassLibrary1.Class1"));
dynamic clInst = objInstance;
clInst.Test();
}
}
}
실행해 보면, 동일한 DLL로 처리되었기 때문에 ClassLibrary1의 static 변수의 값이 바뀌는 것을 확인할 수 있습니다.
Resolving path: C:\temp\ConsoleApp1\bin\Debug\ClassLibrary1.dll
ClassLibrary1, Version=2.0.0.0, Culture=neutral, PublicKeyToken=0086c02b325d69fe
5
Resolving path: C:\temp\ConsoleApp1\bin\Debug\ClassLibrary1.dll
ClassLibrary1, Version=2.0.0.0, Culture=neutral, PublicKeyToken=0086c02b325d69fe
6
유의할 점이 있다면, Assembly 정보를 byte []로 로드해 반환하는 경우,
private static Assembly CurrentDomain_AssemblyResolve(object sender, ResolveEventArgs args)
{
AssemblyName asmName = new AssemblyName(args.Name);
string path = Path.GetDirectoryName(typeof(Program).Assembly.Location);
string dllPath = Path.Combine(path, $"{asmName.Name}.dll");
Console.WriteLine("Resolving path: " + dllPath);
byte[] buf = File.ReadAllBytes(dllPath);
return Assembly.Load(buf);
}
이를 구분할 수 있는 파일 Identity가 없는 Assembly이기 때문에 매번 반환하는 Assembly를 다르게 취급한다는 점입니다. 실제로 위와 같이 File.ReadAllBytes + Assembly.Load로 처리하는 경우 다음과 같이 "Version"의 값이 개별적으로 초기화되는 것을 볼 수 있습니다.
Resolving path: C:\temp\ConsoleApp1\bin\Debug\ClassLibrary1.dll
ClassLibrary1, Version=2.0.0.0, Culture=neutral, PublicKeyToken=0086c02b325d69fe
5
Resolving path: C:\temp\ConsoleApp1\bin\Debug\ClassLibrary1.dll
ClassLibrary1, Version=2.0.0.0, Culture=neutral, PublicKeyToken=0086c02b325d69fe
5
따라서, byte[]로 다뤄야 하는 어셈블리가 있다면 AssemblyLoad 이벤트에서는 기존에 로드된 어셈블리를 찾아보는 작업을 추가해야 합니다.
private static Assembly CurrentDomain_AssemblyResolve(object sender, ResolveEventArgs args)
{
AssemblyName asmName = new AssemblyName(args.Name);
Assembly everLoaded = EverLoaded(asmName);
if (everLoaded != null)
{
return everLoaded;
}
string path = Path.GetDirectoryName(typeof(Program).Assembly.Location);
string dllPath = Path.Combine(path, $"{asmName.Name}.dll");
Console.WriteLine("Resolving path: " + dllPath);
byte[] buf = File.ReadAllBytes(dllPath);
return Assembly.Load(buf);
}
static Assembly EverLoaded(AssemblyName asmName)
{
foreach (Assembly asm in AppDomain.CurrentDomain.GetAssemblies())
{
AssemblyName targetName = asm.GetName();
if (targetName.Name == asmName.Name &&
targetName.GetPublicKeyToken().SequenceEqual(asmName.GetPublicKeyToken()) == true)
{
return asm;
}
}
return null;
}
(
첨부 파일은 이 글의 예제 코드를 포함합니다.)
이 외에도 다음의 글을 보면,
How the Runtime Locates Assemblies
; https://learn.microsoft.com/en-us/dotnet/framework/deployment/how-the-runtime-locates-assemblies
바인딩에 관한 여러 가지 방법이 나옵니다. 그중에서 게시자 정책 파일(Publisher Policy File)의 경우,
How the Runtime Locates Assemblies - Publisher Policy File
; https://learn.microsoft.com/en-us/dotnet/framework/deployment/how-the-runtime-locates-assemblies#publisher-policy-file
Introduction to Publisher Policy File
; https://www.c-sharpcorner.com/UploadFile/satisharveti/introduction-to-publisher-policy-file/
해당 어셈블리를 사용하는 측에서 바인딩을 변경하는 것이 아니고, 어셈블리를 제공하는 측에서 바인딩을 변경하는 전용 어셈블리를 함께 배포하는 식입니다. 예를 들어, 기존의 app.config에서 했던 것처럼 바인딩을 우회하는 config 파일을 만든 후,
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="ClassLibrary1" publicKeyToken="0086c02b325d69fe" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-2.0.0.0" newVersion="2.0.0.0" />
</dependentAssembly>
</runtime>
</configuration>
al.exe를 이용해 다음과 같은 식으로 config의 내용을 담은 DLL로 변환합니다.
Al.exe /link:ClassLibrary1.dll.config /out:policy.1.0.ClassLibrary1.dll /keyfile:..\..\my.key /v:1.0.0.0
이 과정에서 특이하게 어셈블리 서명에 사용된 키 파일을 사용하는데, 따라서 원 저작자를 제외하고는 게시자 정책 파일을 만들 수 없다는 차별점이 있습니다. 그러니까, 특정 어셈블리를 개발한 측에서 그것의 업데이트를 배포할 때 기존 프로그램들이 새롭게 업데이트된 어셈블리를 로드하도록 만들고 싶을 때 사용할 수 있는 방법입니다.
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]