본문 바로가기

IT 살이/04. 기술 - 프로그래밍

.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 어셈블리를 로딩할 수 없다는 이야기입니다.


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