간만에 글을 쓰네요... 이번 포스트는 스마트 클라이언트 시리즈의 글은 아니지만, 스마트 클라이언트에 관련된 팁 정도로 생각하시면 되겠습니다. 어떤 분이 질문을 하셔서, 여러 사람이 알아두면 좋겠다 싶어 키보드를 잡았습니다. 스마트 클라이언트 시리즈 포스트는 좀 더 기다리셔야... -_-;

클라이언트 PC에 닷넷 프레임워크가 설치되어 있는지 확인하는 방법을 간단히 설명하고자 합니다. 일반적으로 스마트 클라이언트 아키텍처를 선뜻 적용하기 어려운 이유 중 하나가 클라이언트에 닷넷 프레임워크가 설치되어 있어야 한다는 전제를 깔고 있기 때문입니다. 특정 조직의 인트라넷이라면 닷넷 프레임워크를 설치하도록 강제할 수 있겠지만, 불특정 다수를 대상으로 하는 일반 인터넷(포털, 커뮤니티 등)에는 적용이 사실상 불가능 합니다. 뭐, 닷넷 프레임워크가 기본 설치되는 OS를 절대 다수가 사용한다거나 IE의 차기 버전(7.0이 될지 8.0이 될지는 모르겠습니다만)이 닷넷 프레임워크를 기본적으로 포함한다면 또 이야기는 다르겠지요...

비록 사내 사용자들에게 닷넷 프레임워크 설치를 강제할 수 있다 하더라도 실제로 사용자가 닷넷 프레임워크를 설치 했는지 아직 설치하지 않았는지를 검출할 필요는 있습니다. 따라서 클라이언트 PC에 닷넷 프레임워크가 설치되어 있는지 여부를 알아내는 것은 상당히 중요한 작업이 되지요. 닷넷 프레임워크가 설치되어 있지 않다면 닷넷 프레임워크를 설치하는 설치 패키지를 다운로드 하는 페이지로 리다이렉트(redirect) 하는 것이 가장 쉽고 일반적인 접근 방법입니다.

Detection of .NET Framework on Client

스마트 클라이언트를 구동하기 위한 최소한의 전제는 클라이언트 컴퓨터에 닷넷 프레임워크가 설치되어 있어야 한다는 점이다(이외에도 브라우저로서 IE를 요구하지만 우리나라는 절대 다수가 IE를 사용하기 때문에 큰 문제는 되지 않을 것이다). 클라이언트 어셈블리 다운로드니 활성화니 CAS 보안이니 하는 것들이 일단 닷넷 프레임워크가 클라이언트에 설치되어 있어야만 의미를 갖기 때문이다. 이는 독립 스마트 클라이언트이건 브라우저 임베디드 스마트 클라이언트이건 이 요구사항은 동일하다.

따라서, 웹서버에서 클라이언트에 닷넷 프레임워크가 설치되어 있는지 먼저 검사하고, 설치되어 있다면 스마트 클라이언트를 구동하는 웹 페이지로 리다이렉트 하고 그렇지 않다면 닷넷 프레임워크를 설치하도록 가이드 하는 페이지로 리다이렉트 하면 깔끔한 처리가 될 것이다. 실제로 필자가 컨설팅 한 P 건설의 프로젝트 역시 이러한 방법을 통해 클라이언트들이 닷넷 프레임워크를 비롯한 설치 패키지를 설치하도록 유도하였다.

Using HTTP Header

웹 서버가 클라이언트에 닷넷 프레임워크가 설치되어 있는지 검출하는 가장 쉬운 방법은 IE가 HTTP Request를 날릴 때 User-Agent HTTP 헤더에 기록하는 값을 이용하는 것이다. 일반적으로 IE가 User-Agent 헤더에 기록하는 값은 IE의 버전, 그리고 윈도우즈 버전, 서비스 팩을 기록하는데 그 값은 다음과 같다(Fiddler를 사용하면 손쉽게 이러한 정보를 얻을 수 있다).

리스트1. 닷넷 프레임워크가 설치된 PC에서 IE가 사용하는 UserAgent 헤더 값 예제

리스트1의 User-Agent 헤더 값은 모질라(Mozilla)와 호환되는 IE 6.0 버전의 브라우저임을 웹 서버에게 알리고 있으며 클라이언트의 운영체제는 WIndows 2003 서비스 팩 1(SV1)임을 표시하고 있다. 일반적으로 닷넷 프레임워크가 설치되어 있지 않다면 여기서 User-Agent의 값은 끝난다. 하지만 닷넷 프레임워크가 설치되어 있다면 .NET CLR x.x.x 형태의 값이 포함되어 설치된 닷넷 프레임워크의 버전을 웹 서버에게 전달한다. 리스트1의 경우, 닷넷 프레임워크 1.1과 2.0이 모두 설치된 경우가 되겠다. 당연 빤쑤로다가 둘 중 하나만 설치되어 있다면 User-Agent의 값도 하나만 존재할 것이다.

닷넷 프레임워크가 설치되면 IE가 User-Agent에 설치된 닷넷 프레임워크의 버전 정보를 실어 알리므로 웹 서버는 클라이언트에 닷넷 프레임워크가 설치되었는지 그렇지 않은지를 손쉽게 파악할 수 있는 것이다. 대부분, 아니 모든 웹 서버는 HTTP 헤더를 액세스할 수 있으므로 User-Agent 값을 직접 살펴볼 수 있겠지만, ASP.NET 이라면 더욱 더 쉽게 User-Agent 정보를 읽을 수 있다.

ASP.NET의 Request 객체(HttpRequest 클래스)는 Browser 속성을 가지고 있다. 이 속성은 HttpBrowserCapabilities 클래스 객체를 반환하는데, HTTP 헤더의 User-Agent 값을 기반으로 하여 브라우저의 여러 가지 속성을 알려준다. 예를 들어, Reqest.Browser.Version은 브라우저의 버전을, Request.Browser.Cookies는 브라우저가 쿠키를 지원하는지 등등 수많은 속성이 제공된다. 이들 중 ClrVersion 이라는 멋진 속성이 있다. ClrVersion 속성은 User-Agent 헤더의 값에 닷넷 프레임워크의 설치 버전에 대한 값에 반응한다. 만약 닷넷 프레임워크가 설치되어 있다면 최선 버전의 값을, 그렇지 않다면 0.0.0.0 버전값을 반환한다. 다음 코드는 ClrVersion 속성을 사용하는 예제 코드 이다.

리스트2. HttpBrowserCapabilities 클래스의 ClrVersion 속성을 이용하는 예제

리스트2 코드를 살펴보자. 존나게 간단한 코드이다. ClrVersion 속성의 Major 버전 값이 0 이라면 클라이언트에 닷넷 프레임워크는 설치되어 있지 않은 것이다. 왜냐면 Major 버전이 0 인 닷넷 프레임워크는 없기 때문이다. 그리고 추가적으로 요구되는 버전으로 1.1.4322 보다 낮은 경우에도 처리를 수행하고 있다. 생각 보다 매우 간단하지 않은가? 뭐 이미 이러한 내용을 알고 있었던 독자도 많았으리라 보지만...

리스트2와 같이 ClrVersion 속성을 이용한 방법은 매우 간편하지만 문제점을 갖고 있다. 때때로, 닷넷 프레임워크가 정상적으로 설치되었음에도 불구하고(설치 프로그램이 오류를 보고하지 않았음에도 불구하고), User-Agent의 값에 닷넷 프레임워크의 버전 정보가 실리지 않는 경우가 가끔씩 나타난다. 원인은 User-Agent의 값은 기본적으로 IE가 기본으로 사용하는 값과 더불어 다음 레지스트리에 설정된 값을 사용하는데 설치 시에 이 레지스트리에 정상적인 값이 기록되지 않기 때문이다. 원인은 필자도 모른다. -_-;

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\User Agent\Post Platform

정상적으로 닷넷 프레임워크가 설치된 경우, 이 레지스트리 값에는 .NET CLR X.X.XXX 값이 적재되어 있다. 정확한 이유를 알 수 없지만, 몇몇 PC에는 닷넷 프레임워크가 설치되어 있음에도 불구하고 이 값이 비어 있는 경우가 있다. 이 때문에 리스트2의 코드를 100% 믿을 수 없게 되어 버린다.

필자가 관여된 P 건설 프로젝트에서도 이러한 현상이 발견되었으며(극 소수이지만), 이들 PC에 대해서는 위 레지스트리에 강제로 값을 집어넣어 해결할 수 밖에 없었다(닷넷 프레임워크를 재 설치 해도 마찬가지였으니...). 프로젝트를 하다 보면 벼라 별 PC들을 다 만나게 된다. 별별 이상한 프로그램을 설치해 놓는 바람에 쥐뿔도 되는 것이 없는 PC들이 태클을 걸면 무쟈게 피곤해지곤 한다.

주의) 위 레지스트리 위치는 IE 6.0 기준이다. 왜 5.0 레지스트리 설정에 값이 기록되어 있는 지를 필자에 묻지 마라. 그건 MS IE 개발팀에게 물어봐야 할 질문이다.

Using ActiveX Control

또 한 가지 클라이언트에 닷넷 프레임워크가 설치되어 있는가를 알아보는 방법은, 흔히 생각해 낼 수 있는 ActiveX를 작성하는 것이다. 간단한(?) ActiveX를 작성하여 닷넷 프레임워크가 존재하는지 검사하고 존재 여부에 따라서 다른 페이지로 이동한다던가 등의 작업을 수행할 수 있다. User-Agent 헤더를 이용하는 방법에 비해 ActiveX 를 이용하는 방법은 확실하게 클라이언트에 닷넷 프레임워크가 설치되어 있는가를 파악해 낼 수 있다는 것이 장점이라 할 수 있겠다. 하지만 ActiveX를 작성해야 한다는 부담감은 단점으로 작용한다. VB 6.0이나 Delphi 를 사용하면 개발은 쉽게 할 수 있지만 기능에 비해 너무 무거운 DLL(혹은 OCX)을 요구한다. 그렇다고 VC++로 작성하자니 해본 적도 없고 졸라 빡셔 보이지 않은가? 게다가 ActiveX가 제대로 사용되려면 CAB 파일도 만들어야 하고, 인증서도 사야 하고... 걸리는 것이 존나게 많다.

참고로, ActiveX 컨트롤이 닷넷 프레임워크가 존재하는지 판단하는 방법은 레지스트리를 검사던가, 닷넷 프레임워크가 설치되는 디렉터리에서 몇몇 필수적인 DLL 들이 존재하는가를 살피는 방법을 사용하면 되겠다.

Conclusion

결론이라고 할 것도 없지만... 스마트 클라이언트 시나리오 상에서 클라이언트 PC에 닷넷 프레임워크가 설치되어 있는가를 파악하는 것은 중요한 작업 중 하나라고 볼 수 있다. 이를 위해 User-Agent HTTP 헤더를 사용하거나 ActiveX를 이용할 수 있다. User-Agent를 사용할 때, 닷넷 프레임워크의 설치 상태에 따라서 User-Agent가 제대로 설정되지 않은 클라이언트 컴퓨터가 존재할 수 있음 역시 배제하지 말도록 하자.