출처 블로그 .. 맨 땅에 헤딩~
IE에서 닷넷 스마트 클라이언트 개발3-스마트 클라이언트 배포하기4
|
|
속도 개선을 위한 또 다른 <OBJECT /> 구문
이쯤에서 하나 더 짚고 넘어 갈 문제가 있는데 바로 ‘속도’ 문제이다. 앞에서 네트워크 모니터를 통한 패킷이 오고 가는 것에서 본 것처럼 아무 의미없는 GET 호출의 결과로 스마트 클라이언트의 활성화는 더욱 늦어지게 된다. 비록 완전한 해결책을 제시할 수는 없지만, <OBJECT/> 태그의 classid 속성에 대한 또 다른 사용법을 같이 설명하면서 특정한 상황의 컨트롤인 경우에 그러한 연속적인 GET 명령을 배제할 수 있는 방법을 소개하겠다. 원래의 액티브X 컨트롤의 경우와 비교해 스마트 클라이언트는 사실 classid 속성에 대해서 2가지 방식으로 사용할 수 있다.
◆ 액티브X 컨트롤 : Classid=“CLSID: 108C3529-A6FF-42b4-912A-4C4754DC0273”
◆ 스마트 클라이언트 : Classid=“SmartClient.dll#SmartClient.TreeControl”
Classid=“CLSID: 108C3529-A6FF-42b4-912A-4C4754DC0273”
<OBJECT/>의 Classid 속성에 CLSID를 지정하기 위해서는 몇 가지 선행 과정이 필요하다. 우선 해당 사용자 컨트롤 클래스에 Guid Attribute 특성을 사용해 CLSID를 지정해야 한다.
[ClassInterface(ClassInterfaceType.None), ComSourceInterfaces(typeof( ITreeEvent))]
[Guid(“108C3529-A6FF-42b4-912A-4C4754DC0272”)]
public class TreeControl : System.Windows.Forms.UserControl, ......
그리고 기존 스마트 클라이언트의 배포 방식과는 달리 해당 DLL이 클라이언트 측에 미리 다운로드돼 다음과 같은 등록을 거쳐야 한다.
gacutil /i SmartClient.dll
regasm SmartClient.dll
앞의 두 단계를 거쳐서 각각 GAC와 레지스트리에 COM 개체로 등록시켜야 한다. 하지만 문제가 있다. 아무래도 IEHost.dll은 스마트 클라이언트에 대한 클라이언트 측 활성화를 제대로 지원 못하는 듯한데, 컨트롤은안에서 정상적으로 활성화되지만 HTML 스크립트에서 해당 컨트롤에 대한 메쏘드, 속성 호출이 막혀 버린다. 그러므로 HTML 스크립트와 상호작용하지 않는 컨트롤의 경우 앞과 같은 방법으로 활성화하면 HTTP GET 호출에 대한 오버헤드를 줄일 수 있다. 게다가 클라이언트 측 활성화이므로 보안에 대한 한계가 없어져 특별한 보안 설정이 필요없다. 결국 일반 액티브X와 동일한 권한을 갖는다고 보면 된다. 그러한 경우가 그다지 많지는 않겠으나 가능성이 있다는 것을 아는 것만으로도 나중에 도움이 될 때가 있을 것이다.
<화면1>프로세스 디버그 메뉴
<화면2>프로세스 연결 화면
스마트 클라이언트 디버깅
여기까지 스마트 클라이언트에 관해서는 모두 얘기한 것 같다. 이제 마지막으로 디버깅하는 방법에 대해서만 언급하고 이 글을 마칠까 한다. 기존 통합 환경에 익숙한 개발자들의 경우 무조건 키를 눌러서 실행하면 디버그 모드로 진행할 것이라고 생각할 텐데, 스마트 클라이언트의 경우에는 그것이 적용되지 않는다. 실행 과정을 생각해 보면 그 이유를 알 수 있다.
우선 IE의 주소창에서 http://127.0.0.1/webapp/webform1.aspx라고 입력해 웹 폼을 방문하게 되면 로 포함되어 있던 SmartClient.DLL은 클라이언트 측으로 다운로드돼 캐시 폴더에 담기게 된다. 캐시 폴더의 위치는 탐색기를 통해 확인하는 경우 GAC 폴더 하위에 ‘Download’라는 폴더로 되어 있다. 통합 환경에 로딩돼 디버깅하려고 하는 대상은 WebApp 웹 가상 디렉토리에 담긴 SmartClient.DLL인데 정작 IE에 로딩되는 것은 캐시 폴더에 있는 SmartClient.DLL이니 디버깅이 안되는 것이다. 이런 상황에서는 디버깅을 키로는 불가능하고, VS.NET 통합 환경의 ‘’도구 메뉴’에 있는 ‘프로세스 디버그’ 기능을 이용해야 한다.
① IE를 실행한다.
② VS.NET 통합 환경에서 「도구 | 프로세스 디버그」 메뉴 선택
③ <화면 1>과 같이 IEXPLORE.EXE를 선택한 후 우측의 ‘연결’ 버튼 클릭
④ <화면 2>와 같은 결과가 나오면 반드시 ‘Common Language Runtime’과 ‘Native’를 포함시켜야 한다. CLR 코드만 디버깅할 뿐이라고 해서 Native를 체크하지 않으면 IE 내부에서 활성화된 스마트 클라이언트의 디버깅이 불가능하다.
⑤ VS.NET 통합 환경은 키로 시작한 디버깅 상황과 동일한 환경으로 전환되고 중단점이 위치한 곳마다 정상적으로 멈추게 된다.
필자의 경험상 얻은 팁을 하나 더 말하자면 해당 컨트롤이 클라이언트 측 GAC\Download 폴더에 캐시된다고 언급했었는데, 가끔 IE가 서버에 있는 최신 DLL을 로드하지 않고 캐시 폴더에 있는 DLL을 로드하는 상황이 발생하게 된다. 캐시 폴더가 GAC 하위에 있는 것으로 짐작할 수 있겠지만 스마트 클라이언트 캐시 폴더 역시 Gacutil. exe에 의해 관리된다.
앞서 언급했던 DLL 재사용으로 인한 문제가 발생하는 경우에는 명령행에서 ‘gacutil /cdl’하게 되면 다운로드 폴더에 있는 모든 캐시된 DLL을 비워 버린다. 명령행에서 다운로드 폴더 경로를 찾아가려면 C:\Windows\assembly\temp 폴더이지만, 캐시된 DLL은 /ldl 옵션을 주면 gacutil.exe가 더 편리하게 보여준다.
무한한 가능성을 가진 스마트 클라이언트
3회에 걸쳐 스마트 클라이언트를 IE에서 사용하기 위한 내용을 다뤄봤다. 필자로서는 기존에 출판된 책들에서 흔히 볼 수 있는 내용을 종합해서 다루기보다는 어디서도 쉽게 찾아 볼 수 없는 것을 위주로 글을 써나갔기 때문에 오히려 스마트 클라이언트와 관계되어 잘 알려진 사항들은 거의 다루지를 않았다. 그와 관계된 일반적인 것들에 대해서는 다른 책을 한번쯤 읽어보는 것도 좋을 것 같다. 필자 나름대로는 스마트 클라이언트의 활성화는 시간적인 문제만 있을 뿐 그 활용성은 무궁무진하다고 볼 수 있다. 또한 개인적인 바람이라면 스마트 클라이언트와 기존 레거시 COM 구현 관계에 대한 좀 더 많은 기술 공개와 협력이 있었으면 하는 것이다. 그런 정보가 많이 공개될수록 기존의 많은 액티브X 개체들이 더 쉽고 빠르게 스마트 클라이언트로 변경될 수 있기 때문이다. | |