Programming/Dot.NET

IE에서 닷넷 스마트 클라이언트 개발3-스마트 클라이언트 배포하기1

bcheul 2008. 2. 25. 13:55

출처 블로그 .. 맨 땅에 헤딩~

IE에서 닷넷 스마트 클라이언트 개발3-스마트 클라이언트 배포하기1


스마트 클라이언트 배포하기 - 1
  저 자 : 정성태

  스마트 클라이언트의 경우 제작하는 방법만큼이나 배포가 쉽게 되어 있다. 이번 호에서는 배포하기 전 어셈블리에 대한 추가적인 작업을 먼저 다룬 후, 정상적인 클라이언트 측 동작을 위한 보안 설정과 함께 디버깅 방법에 대해 살펴보겠다.

연+재+순+서
1회 2004.2 | 스마트 클라이언트 탐험하기
2회 2004.3 | 인터넷 익스플로러와 연동하기
3회 2004.4 | 스마트 클라이언트 배포하기

연+재+가+이+드
운영체제 | IIS가 설치된 윈도우(필자의 경우 윈도우 2003 서버)
개발도구 | 비주얼 스튜디오 닷넷 2003, 닷넷 프레임워크 v1.1.4322
기초지식 | COM, C#, ASP.NET 기초
응용분야 | 현재로서는 기업 내부의 인트라넷 환경에서 액티브X 컨트롤 대체. 닷넷 프레임워크가 일반화되면 외부 웹 사이트에서 액티브X 컨트롤 대체.

================================================================================

첫회에서도 언급했지만 스마트 클라이언트의 경우 아직은 ‘인터넷’ 상으로의 배포에는 다소 무리가 있어 보인다. 왜냐하면 모든 클라이언트 컴퓨터에 ‘닷넷 프레임워크’가 설치되어 있지는 않기 때문이다. 현재 닷넷이 기본 포함된 운영체제는 윈도우 2003 서버뿐이며 그 외의 운영체제들은 ‘Windows Update’ 사이트를 통하거나 ‘MSDN 온라인 다운로드’ 사이트를 통해 선택적으로 설치하는 것이 가능한 정도이다.
환경 자체로만 본다면 이미 모든 윈도우 사용자들이 닷넷 프레임워크를 설치할 수 있지만, 사용자 인식이라는 측면에서 본다면 그러한 설치 방법은 의미가 없다고 봐야 한다. 일반 사용자들이 윈도우 업데이트 사이트를 방문해 닷넷 프레임워크 설치를 기대하기 보다는 오히려 자사의 웹 사이트에서 ‘닷넷 재배포 가능 모듈’을 포함한 셋업 파일을 제공해 주는 것이 더욱 현실적인 방안이 될 수 있다. 참고로 기사를 쓰고 있는 시점을 기준으로 버전 1.1은 http://www.microsoft.com/korea/ msdn/msdn-files/027/001/829/msdncompositedoc.asp에서 다운받을 수 있으며 모듈 크기는 20MB 정도이다.
앞으로 인터넷으로의 배포는 시간이 지나면 해결될 것이고, 현재 적용 가능한 분야라면 단연 인트라넷을 들 수 있겠다. 특정 단체의 내부라면 닷넷 프레임워크의 설치를 의무화할 수 있을 텐데, 요즘의 사내 네트워크 속도가 대개 100Mbps인 것을 감안해 본다면 20MB 정도의 런타임 환경을 설치하는 것은 그다지 부담되는 수준은 아니다. 한번 설치로 인해 이후에 개발되는 인트라넷 애플리케이션의 생산성이 높아진다면 오히려 설치는 부담이 아닌 투자라고도 볼 수 있을 것이다.

<OBJECT/> 안으로
닷넷 프레임워크 환경에 대한 설치는 기본적인 사항이니 더 언급할 것이 없고, 그보다는 개발에 관계된 사항들을 정리하는 것으로 글을 써나가겠다. 그럼, 이제부터 배포를 위한 현실적인 문제들을 하나씩 해결해 보자. 우선 다음과 같은 구문을 이용해 HTML 페이지에서 여러분이 만든 컨트롤을 위치시킨다.

<OBJECT id=”_Control1” style=”WIDTH: 272px; HEIGHT:
193px” classid=”SmartClient.dll#SmartClient.TreeControl” VIEWASTEXT>
<PARAM Name=”DebugEnable” VALUE=”True”>
</OBJECT>

직접적인 배포 문제는 아니지만, 우선 눈에 띄는 것은 <PARAM/> 태그를 들 수 있다. 필자는 처음에 <PARAM/> 설정을 생각했을 때 IPersistPropertyBag을 떠올렸다. 액티브X에서는 IPersist PropertyBag 인터페이스를 COM 개체에 구현해 두면 인터넷 익스플로러(이하 IE)가 해당 인터페이스가 COM 개체에 구현되어 있는지 QueryInterface를 해 보고, 구현되어 있다면 IPersistPropertyBag:: Load 메쏘드를 호출해 주기 때문이다.
IE가 활성화시키는 스마트 클라이언트의 경우도 그와 크게 다르지 않다. 하지만 다행히도 C# 컨트롤의 경우에는 그런 복잡한 과정을 IE용 닷넷 런타임 호스트(이하 IEHost.dll)가 숨겨 주고 있다. 앞에 예로 든 경우처럼 ‘DebugEnable’라는 이름과 동일한 ‘공용 속성’을 정의해 두면 나머지 맵핑 과정은 자동으로 이루어진다. 참고로 공용 속성은 반드시 get/set이 모두 구현되어 있어야 한다. <PARAM/>의 특성상 get 접근자는 필요없는 데도 구현을 하지 않으면 동작하지 않는다.

bool _debugEnable = false;
public string DebugEnable
{
get
{
return _debugEnable.ToString();
}
set
{
_debugEnable = Boolean.Parse( value );
}
}

닷넷 윈도우 폼으로 구현된 컨트롤의 경우에는 내부적으로 숨겨진 채로 IPersistPropertyBag이 구현되어 있고, IEHost.dll은 내부적으로 Reflection을 이용해 <PARAM/> 태그의 NAME 속성으로 있는 이름과 컨트롤에 구현된 공용 속성 중에서 동일한 이름을 찾아서 값을 설정해 준다.
다시 앞의 <OBJECT/> 구문으로 돌아가서 이번에는 CLASSID 속성을 살펴보자. 첫 회부터 당연하게 써왔던 것이지만 배포를 알아보는 것이니만큼 좀 더 자세히 알아봐야 할 필요가 있다. 마이크로소프트에 의해 정의된 의미로는 다음과 같이 구성된다.

컴포넌트 경로#네임스페이스 경로.컨트롤 이름

즉, CLASSID=“SmartClient.dll#SmartClient.TreeControl”이라고 되어 있다면 다음과 같이 적용된다.

컴포넌트 경로 : SmartClient.dll
네임스페이스 경로 : SmartClient
컨트롤 이름 : TreeControl

첫 회에서 필자는 무조건 개발된 컨트롤 DLL의 위치를 컨트롤이 포함될 웹 폼 페이지와 동일한 폴더에 있도록 했다. 이제는 바꿔보자. 관리적인 편의를 위해 웹 사이트의 루트 디렉토리에 ‘netcontrols’라는 폴더를 만들고 SmartClient.dll을 복사해 놓자. 이를 반영하기 위해 CLASSID는 다음과 같이 변경돼야 한다.

CLASSID=”/netcontrols/SmartClient.dll#SmartClient.TreeControl“

그럼, IE는 “GET /netcontrols/SmartClient.dll”라고 HTTP GET 호출을 하게 된다. 여기서 실제 HTTP 소켓 통신이 발생하는 과정을 살펴 볼 필요가 있다. 여러분도 ‘네트워크 모니터’ 등의 툴을 통해 알 수 있겠지만, IEHost.dll은 다소 이해할 수 없는 오버헤드를 발생시키고 있다. 다음은 네트워크 모니터를 통해 순서대로 나열해 본 GET 호출이다.

GET /netcontrols/SmartClient.dll
------- DLL 전송 ----------
GET /ko-KR/mscorlib.resources.dll ( File Not Found )
GET /ko-KR/mscorlib.resources.mscorlib.resources.dll ( File Not Found )
GET /bin/ko-KR/mscorlib.resources.dll ( File Not Found )
GET /bin/ko-KR/mscorlib.resources/mscorlib.resources.dll ( File Not Found )
GET /ko-KR/mscorlib.resources.EXE ( File Not Found )
GET /ko-KR/mscorlib.resources.mscorlib.resources.EXE ( File Not Found )
GET /bin/ko-KR/mscorlib.resources.EXE ( File Not Found )
GET /bin/ko-KR/mscorlib.resources/mscorlib.resources.EXE ( File Not Found )

GET /SmartClient.DLL ( File Not Found )
GET /SmartClient/SmartClient.DLL ( File Not Found )
GET /bin/SmartClient.DLL ( File Not Found )
GET /bin/SmartClient/SmartClient.DLL ( File Not Found )
GET /SmartClient.EXE ( File Not Found )
GET /SmartClient/SmartClient.EXE ( File Not Found )
GET /bin/SmartClient.EXE ( File Not Found )
GET /bin/SmartClient/SmartClient.EXE ( File Not Found )

GET /ko-KR/System.resources.DLL ( File Not Found )
GET /ko-KR/System.resources/System.resources.DLL ( File Not Found )
GET /bin/ko-KR/System.resources.DLL ( File Not Found )
GET /bin/ko-KR/System.resources/System.resources/DLL ( File Not Found )
GET /ko-KR/System.resources.EXE ( File Not Found )
GET /ko-KR/System.resources/System.resources.EXE ( File Not Found )
GET /bin/ko-KR/System.resources.EXE ( File Not Found )
GET /bin/ko-KR/System.resources/System.resources.EXE ( File Not Found )

처음에 한번 /netcontrols/SmartClient.dll에서 컴포넌트 DLL이 실제로 전송되고 이후 mscorlib.resources.dll/exe, smartclient.dll /exe, system.resources.dll/exe에 대한 GET 호출이 연이어서 이뤄진다. 리소스 DLL들에 대해서 찾는 과정이 발생하는 것은 다국어 지원 DLL들의 경로 풀이 과정으로 미뤄 볼 때 당연한 호출들이다. 그런데 어째서 SmartClient.DLL이 처음의 호출에서 발견되었는데도 그 이후에 또 다시 찾으려고 GET 호출을 발생시키는가 하는 점이 의문으로 남는다. 한마디로 쓸모없는 네트워크 트래픽을 발생시키는 것이다. 좀 더 생각해 본다면 리소스 DLL들에 대한 GET 호출까지도 스마트 클라이언트의 경우라면 제어할 수 있어야 하지 않았을까라는 아쉬움이 남는다. 테스트한 결과로는 마지막 GET 호출이 끝나야만 스마트 클라이언트 DLL이 <OBJECT/> 내에서 정상적으로 활성화되는 것을 볼 수 있다. 24번의 HTTP GET 통신은 인터넷 환경에서는 속도 저하라는 결과를 낳을 수 있다.
SmartClient.DLL의 경로 풀이는 한 가지 더 의문을 남기고 있다. 필자는 처음에 앞의 목록을 보고, 만약 CLASSID에 기본 지정된 폴더에서 SmartClient.dll이 발견되지 않는다면 앞의 HTTP GET 리스트에서 보여지는 것처럼 차례대로 해당 DLL을 발견하기 위한 호출이 일어나는 것이 아니냐고 생각했다. 하지만 실제 테스트를 해 보면 CLASSID에 명시된 폴더에 해당 DLL이 없다면 이후의 호출은 아예 발생하지도 않는다. 아직 초기 기술이라 그런지 미숙한 부분이 남아 있다.