728x90
엊그제 실버라이트 2 정식버전이 발매되면서 RIA 관련 개발자, 디자이너들 사이에 많은 포스팅들이 새롭게 올라오고있습니다. 그만큼 오래 기다렸고 기대가 되는 정식버전 발표이기 때문이겠지요. NoPD도 최근 추세(?)에 발맞추어 회사에서 진행되는 많은 프로젝트에 AJAX 를 넘어서 플랫폼 으로써의 RIA 의 역할에 대한 고민을 많이 하고 있는터라 테스트를 해보려고 부랴부랴 서둘렀습니다만...


실버라이트 2 개발도구를 설치하기 위한 기본조건이 Visual Studio 2008 에 서비스 팩 1이 설치된 개발 환경이라야 하는데, NoPD의 개발도구가 SP1이 미처 설치되지 않은터라 부랴부랴 느린 인터넷 속도를 감내해가며 (인도 출장중입니다 ;;) 다운로드 받아서 설치했습니다. 그런데, NoPD가 설치한 SP1 은 한글판! 반면 실버라이트 2 개발도구는 영문과 일본어로만 발매된 상태! 꽥! 실버라이트 2 개발도구의 언어와 맞지 않아서 설치를 진행하지 못하는 문제가 발생한 것입니다 ;;;;;;;;;


여기저기 수소문 해보니 VS2K8 SP1 한글버전 사용자들은 조금 더 기다려야 할 것 같다고 합니다. 다시 베타2를 설치하고 실버라이트 2 를 살펴봐야 하는게 맞는지 한글 버전 출시를 기다렸다가 하는게 더 나은건지 고민이 되는군요. 정식 발표를 하면서 한글 버전을 발표하지 않다니, 조금 실망입니다! 마이크로소프트!

- NoPD -
728x90
728x90
마이크로소프트가 의욕적으로 사업은 전개하고 있는 RIA (Rich Internet Application) 분야의 도구인 실버라이트(SilverLight)의 버전 2.0 이 오늘 공개되었다. 그동안 SilverLight 2 Beta 를 통해서 알려졌던 대부분의 기능들이 그대로 구현되어 출시되었다. 이미 많은 SilverLight 2 Beta 에 대한 소개에서 이번 버전의 특징과 강력해진 기능들이 소개되었지만 정식출시를 즈음하여 한번더 이러한 특징들을 살펴보고 RIA 어플리케이션 개발에 어떻게 응용할 수 있을지 생각해 보는 것도 나쁘지 않을 것 같다.

WPF UI FrameWork의 지원

베타 버전에서부터 누누히 강조되어온 특징인데, 닷넷 프레임웍 3.0 에서 WPF 를 개발했던 경험이 있는 사람이라면 어렵지 않게 실버라이트 2로 RIA 어플리케이션을 만들 수 있는 환경이 제공되는 것이다. 즉, WPF 기술이든 실버라이트 2 기술에 대한 한번의 기술 습득만으로 서로의 기술을 응용할 수 있는 잇점이 생기는 것이다.

Rich 컨트롤의 제공

기존 실버라이트 1.x 에서 가장 많은 사용자들의 고민이 바로 충분하지 못한 기본 컨트롤에 대한 것이었다. 실버라이트 2 에서는 기본적으로 제공되는 많은 Rich 컨트롤들로 어렵지 않게 RIA 어플리케이션을 개발할 수 있다. 체크박스, 라디오 버튼 같은 간단한 컨트롤 부터 데이터 그리드에 이르는 많은 유용한 컨트롤들이 기본적으로 제공된다.

다양한 네트워킹 방법의 제공

일반적인 웹 어플리케이션 제작에도 많이 사용되는 REST, WS*/SOAP, RSS, 표준 HTTP 뿐만 아니라 독특하게도 Socket 으로 통신할 수 있는 방법이 실버라이트 2 에서 제공이 된다. 표준 웹 통신 방법들은 당연히 크로스 도메인에 대한 지원이 되고 있으며 Socket 통신의 제공으로 보다 다양한 응용기술의 구현이 가능할 것으로 예측되고 있다.

닷넷 기반의 Rich 클래스 라이브러리 제공

닷넷에서 제공되던 제네릭스(Generics), 링크(Linq)와 같은 다양한 클래스 라이브러리들이 실버라이트 2 에서도 사용할 수 있게 되었다. 닷넷 기반이라고 이름 붙이긴 했지만, 실제로 닷넷 프레임워크가 필요한 것은 아니며 각 크라이언트 운영체제에 맞는 런타임 모듈만 설치가 되어 있으면 이 모든 기능들의 사용이 가능하다.

그 외에, 미디어 부문에서도 많은 변화가 있는 것으로 알려져 있는데 보다 자세한 내용은 마이크로소프트 기술 담당 부사장 스캇 구슬리의 블로그, RIA 분야 MVP 들의 웹사이트에 공개된 글을 참고하는 것이 더 좋을 것 같다. 바야흐로 실버라이트 2 가 RIA 세상에 본격적으로 발을 내딛기 시작한 것이 아닌가 싶다. 다만, 같이 공개될 것으로 알려졌던 RIA 저작도구 블렌드 2.5 는 공개되지 않았다.

p.s. 재미있는 것은 실버라이트 2 개발을 위한 이클립스 플러그인이 나온다는 것인데, 자세한 건 스캇의 로그를 참고하기 바란다.

- 스캇 구슬리의 Silver Light 2 발매(?) 소식
- 팀 하우어의 실버라이트 2 새로운 컨트롤들 소개
- 스캇 한셀먼의 실버라이트 2 발매 소식

  * 이 포스트는 blogkorea [블코채널 : 웹, 컴퓨터, it에 관련된 유용한 정보 및 소식] 에 링크 되어있습니다.   

- NoPD -
728x90
728x90
 
 
 

728x90
728x90
윈도우 모바일 6 부터 기본적으로 SQL Server 2005 Compact Edition (이하 SQL CE)가 기본적으로 OS 이미지에 올라가 있습니다. 배포하는 과정 없이 쉽게 사용할 수 있다보니 이전보다 개발자들이 SQL CE를 자주 쓰는 듯한 요즈음입니다. 하지만 몇가지 이유들로 인하여 데이터 엑세스시에 Not Enough Storage 에러를 발생하는 경우가 있는 것 같습니다.

윈도우 모바일 6 의 DLL 메모리 적재 방식

모든 문제점들의 원인이라고 단정지을 수는 없지만 기본적으로 윈도우 모바일 6가 DLL을 메모리에 적재하는 방식에 대하여 한번 집고 넘어갈 필요가 있습니다. SQL CE 팀블로그에 올라온 포스팅(http://blogs.msdn.com/sqlservercompact/archive/2007/10/26/troubleshooting-can-t-load-sqlce-dll.aspx) 에서 해당 내용을 발췌해 봤습니다.

When a DLL is loaded in one process, Windows CE reserves that address space in every process address space. Multiple processes that use the same DLL share it at the same relative address in every process. If your application does not use the same DLL, it cannot use the memory that is reserved for that DLL. In other words, Windows CE does not map a RAM-based DLL at an address where another process maps another DLL. For example, if Process A loads DLL X at address 0x00970000, Windows CE does not map DLL Y in the Process B address space at 0x00970000. Instead, Windows CE seeks the next lower address that is available, depending on the size of DLL Y. So if DLL Y is in the size range of 128 KB, Windows CE selects 0x00950000 if that address is available for Process B. Because of the way that Windows CE allows processes to share a common DLL, Windows CE does not permit two different processes to load two different DLLs at the same relative address of each process.

당연할 이야기일지 모르지만 서로 다른 DLL 에게 동일한 메모리 어드레스를 할당하지 않는 다는게 요입니다. 당연한 이야기도 한정된 메모리 영역을 가지고 있는 스마트 디바이스로 넘어오면 치명적인 문제가 될 수 있습니다. 여러개의 분산된 DLL 을 동적으로 로딩하는 어플리케이션이 있다고 가정하면, 모든 DLL 들은 자신의 용량과 관계없이 최소한의 메모리 이격을 둔채 (본문에서 128KB) 메모리를 할당받게 될 것입니다. 이는 곳, 메모리 영역이 금방 소진될 수 있다는 의미가 됩니다.

닷넷 컴팩트 프레임워크와 메모리 적재 방식의 상관관계

컴팩트 프레임워크를 포함한 모든 닷넷 프레임워크는 관리코드 (Managed) 사용시에 자동으로 GC (Garbage Collector)가 사용하지 않는 메모리 영역의 객체 인스턴스를 해제하고 자원을 해제시킵니다. 그런데 컴팩트 프레임워크에서 사용되는 SQL CE 관련 객체들에 자원 해제와 관련한 내부적인 문제가 있는 것으로 보입니다.  (참고 : http://support.microsoft.com/kb/824462, SqlCeCommand objects are not automatically disposed if you use a SqlCeDataAdapter object)

If you use the SqlCeDataAdapter object to populate a DataSet object, and you do not explicitly call the Dispose method for all the associated SqlCeCommand instances, you may receive the following error message:
Error Code: 8007000E
Message: Not enough storage is available to complete this operation.
Note The type of SqlCeCommand instances may be select, insert, update, or delete.

쿼리문 할당을 위해 사용한 SqlCeAdapter.SelectCommand, SqlCeAdapter.InsertCommand, SqlCeAdapter.UpdateCommand, SqlCeAdapter.DeleteCommand 객체가 할당된 SqlCeCommand 객체를 명시적으로 소멸(Dispose) 시켜줄 것을 권고 하고 있습니다. 추측컨데, 데이터 Row가 많은 자료의 경우 데이터를 Insert 하면서 객체를 소멸시키지 않고 반복적으로 루프문에서 사용할 가능성이 높은데 이 과정에서 메모리에 계속 새로운 영역들이 Reserve 되는 것이 아닌가 싶습니다.

다만 의아한 것은 이러한 에러가 발생한 시점에 메모리 용량을 점검해보면 수십메가 이상이 남아있는 경우가 많습니다. 이는 아마도 실제 메모리가 소모되어 발생했다기 보다 메모리 주소를 더이상 Reserve 할 수 없어서 발생하는 것이지 싶습니다.

참고자료

- INFO: Understanding Windows CE DLL Load Failures (http://support.microsoft.com/kb/326163)
- Methods to dispose of SQL Server CE, SQL Server 2005 Compact Edition, or SQL Server 2005 Mobile Edition managed objects from memory (링크)
- SQL Mobile 2005 - Error : Not Enough Storage is Available (링크)
728x90

+ Recent posts