.NET 어플리케이션의 호환성

.NET 프레임워크의 버전이 계속 올라가면서, 프로젝트를 진행하다 보면 프레임워크 버전간의 호환성 문제가 이슈가 되는 경우가 있습니다.

지금 참여하고 있는 프로젝트에서도 프레임워크 버전 문제가 잠깐 제기된 적이 있었습니다.

■ 상황

기존의 한 시스템이 .NET 1.1된 윈폼 어플리케이션이 있었습니다. 그리고 새로 만들게 될 시스템은 .NET2.0으로 만들 다른 윈폼 어플리케이션입니다.

문제는 .NET1.1 어플리케이션에서 .NET2.0의 어셈블리로 된 화면을 로딩시킬 수 있는가입니다.

얼른 생각해봐도 v1.1 어플리케이션에서 다이렉트로 v2.0 어셈블리를 로딩하는 것은 안될 것으로 추측했습니다.

그러나 다음 경우처럼 웹 페이지를 통해서 호출하면 어떨까하는 의문이 들었습니다.

그림처럼 호출하는 1.1 어플리케이션의 윈폼에서 webbrowser컨트롤을 사용하고 그 webbrowser 컨트롤에서는 웹 페이지(asp.net)를 호출합니다.

다시 그 웹 페이지에서는 <object> 태그를 이용해서 v2.0으로된 윈폼 화면을 로딩합니다.

[그림] v1.1 어플리케이션에서 웹 페이지를 이용해서 v2.0 어셈블리를 로딩하려는 경우

■ 추측

처음에 얼른 생각해 봤을때, 될 것 같기도 하고 안될 것 같기도 했습니다.

- 될 것 같다는 느낌 :  "AppDomain이 각각 버전 별로 하나씩 생성되면 되지 않을까?"

- 안될 것 같다는 느낌 :  "근데.. CLR 인스턴스가 버전별로 여러개 생성될 수 있나?...."

결론을 먼저 말하면 안될것 같은 느낌이 맞았던 것입니다.

■ 결론

만약 호출되는 어셈블리도 v1.1로 만들어졌다면 앞에서 설명한 상황의 윈폼 로딩은 정상적으로 작동합니다. AppDomain이 두개 생성되는 것도 맞습니다. 

그러나 AppDomain은 생성하는 CLR 인스턴스가 하나의 OS 프로세스에서는 하나만 존재할 수 있다는 것을 조금 생각 후에 상기하게 되었습니다. v1.1 어플리케이션이 시작할때 이미 그 프로세스에는 v1.1 버전의 CLR 인스턴스가 이미 하나 생성되어 있습니다. 그런 상태에서 다시 v2.0 CLR을 로딩시킬 수는 없습니다. OS 프로세스-CLR-AppDomain에 대한 관계는 지난 포스트에서 알아본 적이 있습니다. 

2009/04/23 - [01. 기술-APP] - 기본 AppDomain 생성자 변경하기

따라서 v1.1 어플리케이션용 OS 프로세스에서 v2.0용 AppDomin을 생성할 수가 없게 됩니다.

만약 v1.1용 AppDomain에서 v2.0 어셈블리를 호스팅할 수 있다면 그렇다면 이야기가 달라질 수 있을 것입니다. 그러나 이것도 Microsoft 호환성 정책에 의해서 지원되지 않고 있습니다. Microsostrk 지원하는 호환성 정책은 다음과 같습니다.

Side-by-side 호환성 정책 : 여러 버전의 프레임워크가 설치된 머신에서, 어플리케이션들은 자신이 만들어진 어플리케이션을 이용해서 실행될 수 있습니다. 즉 v1.1 어플리케이션은 v1.1 CLR을 사용하고 v2.0 어플리케이션은 v2.0 CLR을 사용할 수 있습니다.

Backward 호환성 정책 : 이전 버전(v1.1)의 프레임워크를 이용해서 만들어진 어플리케이션은 이후 버전(v2.0)의 프레임워크에서도 잘 작동하도록 지원하고 있습니다.

Forward 호환성 정책 : 그러나 Microsoft는 이후 버전(v2.0)의 어플리케이션이 이전 버전(v1.1)의 프레임워크에서는 정상 작동하도록 하는 것은 포기하고 있습니다.

.NET 프레임워크는 Forward 호환성 정책을 지원하지 않는다는 것은 v1.1용 AppDomain에서 v2.0 어셈블리를 로딩할 수 없다는 이야기입니다.

너무 당연한 이야긴가?  쉬운 얘기를 어렵게 만드는데에 무슨 재주 있다니까...-_-;;