닷넷 - TypeForwardedFrom / TypeForwardedTo 특성의 사용법
이에 대해서는 다음의 글을 보셔도 됩니다. ^^
Anatomy of a .NET Assembly - Type forwards
; https://www.simple-talk.com/blogs/anatomy-of-a-net-assembly-type-forwards/
우선, TypeForwardedFrom 특성은 모르셔도 됩니다. 이것은 CLR에게 있어 아무런 의미도 주지 않고 단지 해당 특성이 지정된 타입이 말 그대로 "Type Forwarded From"되었다는 것을 (개발자 스스로 인지할 수 있도록) 알리기 위한 정도의 용도로 사용될 뿐입니다. 즉, TypeForwardedFrom 특성 대신 사용자가 직접 또 다른 특성을 만들어서 지정하는 것과 별반 다를 게 없습니다.
하지만 TypeForwardedTo 특성의 경우는 다릅니다. 이 특성은 assembly 수준으로 정의되는데,
[assembly: TypeForwardedTo(typeof(...))]
해당 어셈블리에 정의되었던 타입이 이제는 다른 어셈블리에 정의되었다는 것을 CLR에게 알리는 역할을 합니다. 실제로 어떻게 사용되는지 한번 만들어 볼까요? ^^
우선, 2개의 DLL 프로젝트와 함께 그것을 참조해서 쓰는 EXE 프로젝트를 다음과 같이 구성해 줍니다.
// ClassLibrary1 DLL 프로젝트
using System;
namespace ClassLibrary1
{
public class Class1
{
public void Out()
{
Console.WriteLine("ClassLibrary1.Class1.Out");
}
}
}
// ClassLibrary2 DLL 프로젝트: 현재는 사용처가 없음.
// 아무거나 정의
// ConsoleApp1 EXE 프로젝트: ClassLibrary1.dll, ClassLibrary2.dll 참조
class Program
{
static void Main(string[] args)
{
ClassLibrary1.Class1 cl = new ClassLibrary1.Class1();
cl.Out();
}
}
이제 가정을 해보겠습니다. 여러분들은 ClassLibrary1.dll, ClassLibrary2.dll 어셈블리가 포함된 "라이브러리"를 개발해서 판매하는 개발자입니다. 그런데, 어느 순간 ClassLibrary1.dll에 정의되어 있던 Class1 타입을 ClassLibrary2.dll로 옮기는 것이 맞겠다는 판단이 든 것입니다. 문제는, 이렇게 변경한 후 라이브러리를 재배포하게 되면 기존의 프로그램들도 다시 빌드를 해야만 한다는 점입니다. 즉, DLL만 교체하게 되면 기존 빌드되었던 EXE 프로그램들은 모두 ClassLibrary1.dll로부터 Class1 타입을 찾을 수 없기 때문에 오동작을 하게 되는 것입니다.
바로 이런 상황에서 쓸 수 있는 것이 TypeForwardedTo 특성입니다. 이를 위의 상황에 적용해 보면, Class1 타입이 ClassLibrary2.dll로 옮겨갈 것이므로 원래의 ClassLibrary1.dll에서는 AssemblyInfo.cs 등의 소스 코드에 다음과 같이 특성을 남깁니다.
[assembly: TypeForwardedTo(typeof(ClassLibrary1.Class1))]
또한, ClassLibrary1.dll에서는 Class1 코드가 필요 없으므로 삭제하면 됩니다. 어~~~ 이상하군요. 그럼 위의 "[assembly: TypeForwardedTo(typeof(ClassLibrary1.Class1))]" 코드로 인해 빌드 실패할 텐데요... 맞습니다. 그렇기 때문에 ClassLibrary1은 ClassLibrary2 어셈블리를 참조 추가해야 합니다. 즉, 다음과 같이 구조가 바뀌는 것입니다.
// ClassLibrary1 DLL 프로젝트: ClassLibrary2.dll을 참조
using System;
[assembly: TypeForwardedTo(typeof(ClassLibrary1.Class1))]
namespace ClassLibrary1
{
// 모두 삭제
public class Class1
{
public void Out()
{
Console.WriteLine("ClassLibrary1.Class1.Out");
}
}
}
// ClassLibrary2 DLL 프로젝트
// ClassLibrary1으로부터 옮겨온 Class1 타입의 Namespace까지도 동일하게 맞춰서 정의
namespace ClassLibrary1
{
public class Class1
{
public void Out()
{
Console.WriteLine("ClassLibrary1.Class1.Out");
}
}
}
여기서, EXE 프로젝트는 아무런 변경도, 빌드도 필요 없습니다. 이제 라이브러리 개발자는 ClassLibrary1.dll, ClassLibrary2.dll을 배포하면 되고 기존 프로그램들은 정상적으로 ClassLibrary1.Class1을 ClassLibrary1.dll로부터 찾으려고 하지만 CLR은 TypeForwardedTo 특성이 정의되었다는 것을 보고 ClassLibrary2.dll 어셈블리의 ClassLibrary1.Class1 타입을 로드해 사용합니다.
한 가지 주의할 것은, TypeForwardedTo 특성에 입력받는 인자가 Type으로 되어 있어 반드시 대상 DLL에 대한 참조를 추가해야 한다는 점입니다. 이로 인해 순환 참조가 발생하는 상황에서는 사용할 수 없습니다. 가령, 위의 상황에서 ClassLibrary2 어셈블리가 처음부터 ClassLibrary1에 대한 참조 관계로 형성되었다면 ClassLibrary1에 있던 타입을 ClassLibrary2로 옮길 수는 없습니다.
사례를 찾아보면, .NET 4.0 BCL에서 확인할 수 있습니다.
System.Core.dll 어셈블리에 정의된 System.Action 타입이 있는데요. 원래, System.Core.dll은 .NET 3.5부터 제공되던 것으로 Generic 인자 4개까지 기본 정의된 유형으로 포함하고 있었습니다.
// System.Core (3.5.0.0)
namespace System
{
public delegate void Action()
public delegate void Action<T1, T2>(T1 arg1, T2 arg2)
public delegate void Action<T1, T2, T3>(T1 arg1, T2 arg2, T3 arg3)
public delegate void Action<T1, T2, T3, T4>(T1 arg1, T2 arg2, T3 arg3, T4 arg4)
// 생략
}
.NET 2.0부터 3.5까지 동일한 CLR 2를 기반으로 발전했기 때문에 새로운 타입들이 필요한 경우 부가적인 어셈블리가 포함되는 식이었는데 System.Core.dll도 .NET 3.5부터 새롭게 제공되는 어셈블리였던 것입니다. 하지만, CLR 4로 오면서 정비가 한번 이뤄지게 되는데 Action delegate 타입을 다른 어셈블리들에서도 의존해 사용하는 것이 있으므로 System.Core보다는 mscorlib.dll로 내려버리게 됩니다. 당연히 이렇게 바꾸면 기존 응용 프로그램들이 오동작을 하겠지만 TypeForwardedTo 덕분에 하위 호환성이 잘 지켜지게 된 것입니다.
실제로, 3.5.0.0버전의 System.Core.dll에 정의되었던 4개의 Action 타입은 4.0.0.0 버전의 System.Core.dll에는 제거되었고 대신 다음의 TypeForwardedTo 설정이 남겨지면서,
// System.Core (4.0.0.0)
[assembly: TypeForwardedTo(typeof(Action))]
[assembly: TypeForwardedTo(typeof(Action<,>))]
[assembly: TypeForwardedTo(typeof(Action<,,>))]
[assembly: TypeForwardedTo(typeof(Action<,,,>))]
4.0.0.0 버전의 mscorlib.dll에 위의 4개 타입을 포함하도록 바뀌었습니다.
정리해 보면, 현실적으로 봤을 때 사내 개발 중 사용하는 라이브러리 정도라면 가볍게(?) 하위 호환성 무시할 수 있으므로 TypeForwardedTo 같은 특성을 굳이 사용할 필요가 없습니다. (솔직히... 오픈 소스로 개발되는 유명한 프로젝트들 중에도 하위 호환성을 쌈 싸 먹는 경우가...!!!) 따라서 꽤 의미 있는 상용 프로젝트이면서 하위 호환성이 중대한 경우나 되어야 사용할 가치가 있을 것입니다. 좀 더 엄밀히 말하자면... 이것은 마이크로소프트 스스로 자신들이 제작한 BCL에서 발생하는 하위 호환성을 해결하기 위해 필요했으므로 만들어졌다고 봐도 무방합니다. ^^
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]