(**** 모두 읽어보신 다음에 댓글 필히 확인!!!! ****)

가끔, .NET 어셈블리의 버전을 구하는 경우가 있습니다. 그리고, 또 가끔은 어셈블리 버전만 구하고 해당 파일을 잠그면 안 될 때가 있습니다. 아시겠지만, .NET은 어셈블리 단위로 Unload 할 수 없어서 Reflection 등으로 로드하면 일단 그 파일은 잠기게 되고, 이를 풀기 위해서는 바로 그 어셈블리를 소유한 AppDomain 자체를 내려야만 합니다.

결국, AppDomain을 별도로 생성한 후 그 안에서 버전을 구하는 코드를 작성해야 하는데, 이 때 AppDomain 경계를 넘어서 제어하기 위해 대상 개체를 MarshalByRef 개체로 만들어야 하는 수고로움이 있습니다.

물론, 복잡한 코드를 수행해야 한다면 MarshalByRef가 답이겠지만, 단순히 어셈블리의 버전을 구하는 용도라면 AppDomain.DoCallBack 메서드로도 충분히 수행할 수 있습니다. 아래는 이를 위한 대략적인 코드입니다.

AppDomain appDomain = AppDomain.CreateDomain("testDomain");
appDomain.SetData("filePath", filePath);

appDomain.DoCallBack(
    new CrossAppDomainDelegate(
        () =>
        {
            string targetPath = AppDomain.CurrentDomain.GetData("filePath") as string;

            Assembly asm = Assembly.LoadFile(targetPath);
            Version version = asm.GetName().Version;

            System.Diagnostics.Trace.WriteLine(version.ToString());

            AppDomain.CurrentDomain.SetData("fileVersion", version);
        }
        ));

Version dllVersion = appDomain.GetData("fileVersion") as Version;
AppDomain.Unload(appDomain);

답은 이미 나왔지만, 그냥 끝내기 아쉬우니 약간의 부가 설명을 해보겠습니다. ^^

위에서 보면, 특이한 점이 있는데 바로 Callback 메서드와 주고 받을 인자를 AppDomain.SetData/GetData로 전달하는 것입니다. 만약, 그렇지 않고 다음과 같이 "captured variables" 방식으로 넘기면 어떻게 될까요?

AppDomain appDomain = AppDomain.CreateDomain("testDomain");

appDomain.DoCallBack(
    new CrossAppDomainDelegate(
        () =>
        {
            string targetPath = filePath;

실행해 보면 금방 답이 나오겠지요. ^^ 예상한 대로 다음과 같이 예외가 발생합니다.





이런 현상을 이해하기 위해서는 "captured variables"가 C#에서 어떻게 구현되는지를 알아야 합니다. C#의 문법적인 측면으로 보면 filePath는 직렬화 가능한 string 값이 넘겨지는 것 같지만, 실제로 이 값은 컴파일러가 생성해 주는 '래퍼 클래스'의 인스턴스에 속성값으로 담겨진 후, 그 속성값을 사용하는 코드를 담은 메서드가 delegate 인자로 전달됩니다.

이를 확인하기 위해 .NET Reflector로 보면 filePath를 'capture'하기 위해 다음과 같은 클래스가 생성된 것을 볼 수 있습니다.

[CompilerGenerated]
private sealed class <>c__DisplayClass3
{
    // Fields
    public string filePath;

    // Methods
    public <>c__DisplayClass3();
    public void <InvalidGetFileVersion>b__2();
}

그런데, 정작 .NET Reflector도 그러한 capture 변수에 대한 사용 코드를 다음과 같이 보여주어서 <>c__DisplayClass3 타입이 실제적으로 사용되었는지에 대해서 모호하게 만듭니다.

{
    AppDomain appDomain = AppDomain.CreateDomain("testDomain");
    appDomain.DoCallBack(delegate {
        Version version = Assembly.LoadFile(filePath).GetName().Version;
        Trace.WriteLine(version.ToString());
        AppDomain.CurrentDomain.SetData("fileVersion", version);
    });
    Version dllVersion = appDomain.GetData("fileVersion") as Version;
    AppDomain.Unload(appDomain);
    return dllVersion;
}

제 생각에, 위와 같이 보여지는 데에는 단지 .NET Reflector에서 서비스 차원으로 조작해 주는 것 같고, 이에 대해 정확히 확인하려면 해당 코드를 "IL"로 놓고 봐야 합니다.

{
    .maxstack 4
    .locals init (
        [0] class [mscorlib]System.AppDomain appDomain,
        [1] class [mscorlib]System.Version dllVersion,
        [2] class WindowsFormsApplication1.Form1/<>c__DisplayClass3 CS$<>8__locals4,
        [3] class [mscorlib]System.Version CS$1$0000)
    L_0000: newobj instance void WindowsFormsApplication1.Form1/<>c__DisplayClass3::.ctor()
    L_0005: stloc.2 
    L_0006: ldloc.2 
    L_0007: ldarg.1 
    L_0008: stfld string WindowsFormsApplication1.Form1/<>c__DisplayClass3::filePath
    L_000d: nop 
    L_000e: ldstr "testDomain"
    L_0013: call class [mscorlib]System.AppDomain [mscorlib]System.AppDomain::CreateDomain(string)
    L_0018: stloc.0 
    L_0019: ldloc.0 
    L_001a: ldloc.2 
    L_001b: ldftn instance void WindowsFormsApplication1.Form1/<>c__DisplayClass3::<InvalidGetFileVersion>b__2()
    L_0021: newobj instance void [mscorlib]System.CrossAppDomainDelegate::.ctor(object, native int)
    L_0026: callvirt instance void [mscorlib]System.AppDomain::DoCallBack(class [mscorlib]System.CrossAppDomainDelegate)
    L_002b: nop 
    L_002c: ldloc.0 
    L_002d: ldstr "fileVersion"
    L_0032: callvirt instance object [mscorlib]System.AppDomain::GetData(string)
    L_0037: isinst [mscorlib]System.Version
    L_003c: stloc.1 
    L_003d: ldloc.0 
    L_003e: call void [mscorlib]System.AppDomain::Unload(class [mscorlib]System.AppDomain)
    L_0043: nop 
    L_0044: ldloc.1 
    L_0045: stloc.3 
    L_0046: br.s L_0048
    L_0048: ldloc.3 
    L_0049: ret 
}

위에서 '굵은 글씨'로 나타낸 코드를 알기 쉽게 C#으로 재구성을 해보면 다음과 같습니다.

<>c__DisplayClass3 CS$<>8__locals4 = new <>c__DisplayClass3();
CS$<>8__locals4.filePath = filePath;

System.CrossAppDomainDelegate func 
    = System.CrossAppDomainDelegate(CS$<>8__locals4.<InvalidGetFileVersion>b__2);

이 때문에 사실상, <>c__DisplayClass3 클래스에 [Serializable] 특성이 정의되어야 하지만 C# 컴파일러는 이런 식으로 생성되는 내부 클래스에 대해 기본적으로 직렬화 특성을 부여하지 않기 때문에 AppDomain을 가로질러 전달하려면 오류가 발생하는 것입니다.

* 첨부된 코드는 위의 예제 코드를 담고 있습니다.

---

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

[최초 등록일: 5/2/2011]
[최종 수정일: 8/7/2021]


이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

by SeongTae Jeong, mailto:techsharer at outlook.com