서버 2003 기능 지원 강화된「비주얼 스튜디오 닷넷 2003」

마이크로소프트(이하 MS)는 지난 2002년 10월경에 마이크로소프트 개발자 네트워크(이하 MSDN)를 통해 자사의 개발 툴에 대한 향후 로드맵을 발표한 바 있다. 이번 로드맵에서는 2002년부터 2004년까지 출시될 개발 툴의 주요 기능들을 열거하고 있으며, 이를 통해 앞으로의 MS 기술을 미리 살펴볼 수 있는 좋은 기회를 제공해주고 있다. 비주얼 스튜디오 닷넷이 출시된 지 얼마 되지 않은 시점에서 새로운 개발 툴의 등장이 개발자들에게 있어 부담감이 될 수 있을지도 모르겠다. 하지만 기술의 변화라는 흐름에 쉽게 편승하기 위해서는 일부러 시간을 내어 살펴보는 자세도 필요할 것 같다.

이번 개발 툴 리뷰에서는 먼저 MS가 제시하는 개발 툴 로드맵을 살펴본 뒤 비주얼 스튜디오 닷넷 이후 출시될 비주얼 스튜디오 닷넷 2003이 개발자들에게 제시하고 있는 기능들을 살펴보도록 하자.

MS 개발툴 로드맵 2002~2004

혹시 MS가 최초로 출시한 개발 툴이 무엇인지 그리고 그 출시 연도가 언제인지 알고 있는 독자들이 있을지 모르겠다. MS는 1975년, 그러니까 지금으로부터 28년 전에 ‘MS 베이직(Microsoft Basic)’을 처음으로 출시했다. 그 후 1997년에 하나의 언어를 제공하던 기존 형태의 개발 툴과는 달리 여러 언어를 하나의 툴로 통합한 비주얼 스튜디오가 세상에 모습을 드러냈다. 비주얼 스튜디오는 다양한 개발 언어를 하나의 개발 툴로 묶어서 제공하기 때문에 서로 다른 언어로 개발된 자원들을 쉽게 공유할 수 있을 뿐만 아니라 클라이언트/서버 환경부터 웹 환경에 이르기까지 다양한 프로젝트를 동시에 개발할 수 있는 특징을 갖고 있다. <화면 1>은 서로 다른 프로젝트를 이용해서 개발하고 있는 화면이다.

<화면 1> 비주얼 스튜디오 프로젝트 창

비주얼 스튜디오와 같은 통합 툴은 개발자들의 요구 사항을 만족하기에 충분했다. 하지만 정작 개발사인 MS는 비주얼 스튜디오의 기능에 만족하지 못한 것 같다. 이유인 즉 MS는 2002년 2월에 비주얼 스튜디오 닷넷이라는 통합 툴을 출시했기 때문이다.

초기 닷넷 프레임워크(.NET Framework)는 SDK 형태로 개발자들에서 소개되었다. SDK 형태로 배포가 되었기 때문에 닷넷 프레임워크를 이용한 애플리케이션 개발은 그렇게 활발하게 이루어지지 않았다. 이에 MS는 닷넷 프레임워크를 이용해서 개발할 수 있는 환경으로 비주얼 스튜디오 닷넷이라는 통합 툴을 출시한 것이다.

비주얼 스튜디오 닷넷 2003 ‘에버렛’ 등장

MS가 2002년에 출시한 비주얼 스튜디오 닷넷 환경은 조만간 출시될 윈도우 닷넷 서버 2003의 기능을 제공할 수 없다. 이에 MS는 에버렛이라는 새로운 코드명을 가진 비주얼 스튜디오 닷넷 2003을 준비하게 된 것이다. ‘에버렛’이 제공할 기능 중 가장 두드러지는 것은 윈도우 닷넷 서버 2003의 기능 지원, 닷넷 프레임워크 1.1, 스마트 디바이스 개발 환경 지원, ASP.NET 모바일 컨트롤 그리고 비주얼 J# 개발 환경 지원을 이야기할 수 있다. 이에 대한 자세한 소개는 다음 장에서 살펴보기로 하고 또 하나의 코드명 ‘Yukon’을 알아보자.

유콘을 지원하는 비주얼 스튜디오

MS는 SQL 서버를 한층 업그레이드한 코드명 ‘유콘(Yukon)’을 준비하고 있다. 유콘은 데이터베이스 엔진에서 다중 언어를 지원할 수 있는 CLR을 포함시킬 예정이다. 유콘을 통해 개발자들은 익숙한 개발 언어를 사용해서 개발자만의 스토어드 프로시저(Stored Procedure)를 만들 수 있다. 하지만 아직 유콘의 실체를 볼 수 없기 때문에 어떻게 구현될지는 좀더 지켜봐야 할 것 같다. 또한 현재까지 개발된 닷넷 프레임워크 1.1에서는 유콘을 지원할 수 없기 때문에 닷넷 프레임워크 2.0을 새롭게 준비 중에 있다. 이에 유콘의 기능을 최종적으로 반영한 비주얼 스튜디오가 개발될 예정이다.

<그림 1> MS 2002~2004 개발 로드맵

유콘에 이어 다음 주자로는 새로운 윈도우 플랫폼인 ‘롱혼(Longh orn)’이 대기 중에 있다. 비주얼 스튜디오 통합 툴은 롱혼에 대한 개발 계획을 가지고 있으며 향상된 사용자 인터페이스 및 롱혼의 추가 기능을 제공할 예정이다. <그림 1>은 MS가 2002년에서 2004년 사이에 계획 중인 비주얼 스튜디오에 대한 개발 로드맵을 정리한 것이다.

비주얼 스튜디오 닷넷 2003, 뭐가 달라졌나

비주얼 스튜디오 닷넷은 2002에서 2003으로 변화되면서 몇 가지 새로운 기능들을 추가했다. 그 중 필자가 가장 흥미롭게 느낀 점은 비주얼 J#을 위한 개발 환경이 비주얼 스튜디오 닷넷 2003에 통합되었다는 점과 스마트 디바이스 개발 환경이 제공되었다는 것이다. 이 외에도 몇 가지 추가 기능들이 있는데 하나씩 살펴보자.

<화면 2> 새롭게 제공되는 개발툴 시작 환경

통합 개발 환경에서의 업그레이드

새로운 기능을 제공하는 만큼 비주얼 스튜디오 닷넷 2003의 개발 환경 역시 <화면 2>와 같이 새롭게 디자인되었다. <화면 2>을 보면 프로젝트를 생성하고 관리하는 ‘Projects’ 탭, 개발자들에게 필요한 온라인 리소스를 제공하는 ‘Online Resources’ 탭, 그리고 개발자 자신만의 공간인 ‘My Profile’ 탭을 볼 수 있다. 사소한 기능이지만 개발자 입장을 고려해서 세심한 배려를 한 것 같다.

또한 솔루션 탐색기(Solution Explorer)에도 ‘Track Active Item’ 옵션이 추가되었다. ‘Track Active Item’은 「Tools

간단한 예를 통해 살펴보면 만약 Sample 프로젝트 아래의 Kamja 폴더 밑에 있는 kamja.cs 파일을 개발 중이었다고 생각해보자. 이전 개발 툴에서는 Sample 프로젝트 종료 후 다시 오픈할 경우 이전 개발시 열어둔 파일들만 볼 수 있었다. 하지만 ‘Track Active Item’을 설정할 경우에는 솔루션 탐색기를 통해서 kamja.cs 파일이 Sample 폴더 아래에 위치하고 있다는 것까지 알 수 있다. “어제 내가 어떤 폴더 아래에 있는 파일들을 작업했지?”라는 고민을 조금이나마 접을 수 있을 것 같다.

다음은 ‘웹 레퍼런스’로 비주얼 스튜디오 닷넷 2003에서는 로컬 머신에 있는 웹 서비스, UUDI 서비스, 그리고 UUDI 디렉토리 검색, 마이크로소프트 UUDI 디렉토리를 테스트할 수 있는 기능을 제공한다. 웹 서비스 개발시 필요한 자원을 찾아 인터넷을 헤맬 필요가 없이 단지 앞의 네 가지 링크의 클릭을 통해서 원하는 웹 서비스를 이용할 수 있다.

디버거 기능 역시 좀더 향상된 모습으로 등장했다. 로컬 머신에서 이루어지는 디버깅 작업에 제한을 적용할 수 있는 보안 기능, 원거리 디버깅 기능, 명령 입력창을 통한 디버깅 기능, 그리고 심블 서버로부터 디버깅 심블을 자동으로 다운받을 수 있는 기능 등을 제공한다. 각 기능에 대한 자세한 설명은 디버거 관련 문서를 참조하는 것이 좋을 듯 하다.

다음은 개발된 프로그램 배포에 대한 기능을 간단히 언급해보자. 지금까지 개발된 애플리케이션을 배포할 경우 버전 문제로 인해 많은 고민을 했어야 했다. 하지만 비주얼 스튜디오 닷넷 2003에서는 애플리케이션에서 사용하는 닷넷 프레임워크 버전을 선택해서 배포할 수 있고 새롭게 제공하고 있는 ‘Side-by-Side 실행’ 기능을 통해 애플리케이션이 사용하는 버전 정보만을 이용할 수 있게 되었다. 이를 통해서 서로 다른 버전 정보로 인해 발생된 문제점을 말끔히 해결할 수 있게 되었다. 그럼 어떤 방식을 통해서 해결점을 찾았는지 살펴보자.

비주얼 스튜디오 닷넷 2002와 2003 동시 사용

비주얼 스튜디오 닷넷 2003은 이전 버전인 2002와 같은 개발 환경에서 사용할 수 있도록 디자인되었다. 그래서 개발자는 닷넷 프레임워크 1.0과 닷넷 프레임워크 1.1 중 원하는 버전을 선택해서 애플리케이션을 실행시킬 수 있게 되었다. 이는 애플리케이션이나 컴포넌트가 지원하는 닷넷 프레임워크 버전을 지정할 수 있는 방법을 통해서 가능한데 그 방법을 다음에서 간략히 살펴보자.

일단 버전 정보를 지정하기 위해서는 애플리케이션 환경 파일(Application Configuration File)을 작성해야 한다. 먼저 닷넷 프레임워크 1.0에서 개발된 애플리케이션을 닷넷 프레임워크 버전 1.1에서 실행하는 방법은 <그림 2>와 같다.

<그림 2> 닷넷 프레임워크 1.0에서 개발된 애플리게이션을

닷넷 프레임워크 1.1에서 구동하기

애플리케이션 MyApp는 버전 1.0으로 개발되었고, 버전 1.0을 참조하는 어셈블리 A와 버전 1.1을 참조하는 어셈블리 B가 있다고 하자. 이런 경우 MyApp을 버전 1.1에서 실행시키기 위해서는 어셈블리 A와 MyApp를 버전 1.1을 참조하도록 설정해야 한다. 이런 설정을 앞에서 소개한 애플리케이션 환경 파일이 하게 되는데, 다음과 같은 수정을 통해서 버전 1.1에서 실행되도록 설정할 수 있다.

닷넷 프레임워크 1.0에서 실행되는 형태도 이와 같은 환경 파일 설정을 통해서 지정할 수 있다. 자세한 사항은 MSDN 문서를 참조하자.

나만의 도움말 설정하기

옵션 윈도우의 ‘도움말(HELP)’을 선택해보면 다음의 그림과 같이 ‘선호하는 콜랙션(Preferred Collection)’ 박스를 볼 수 있다. 도움말에 대한 아주 작은 기능이지만 개발자들에게 도움말 역시 개발자가 지정할 수 있도록 배려를 해둔 것 같다. 도움말은 Add-On 형태로 추가할 수도 있다. <화면 3>은 도움말을 설정할 수 있는 화면이다.

<화면 3>도움말 설정하기

비주얼 J#을 품으로 안은 비주얼 스튜디오 닷넷 2003

드디어 방황자 생활을 하던 비주얼 J#이 비주얼 스튜디오 닷넷 2003의 품에 안기게 되었다. <화면 4>는 비주얼 스튜디오 닷넷 2003에서 지원하는 비주얼 J# 개발 환경이다. 비주얼 J#은 비주얼 J++ 6.0의 기능들을 다 지원하고 있으며 따로 비주얼 J#을 설치해야하는 불편함이 사라졌다.

<화면 4>비주얼 J#을 지원하는 스튜디오 닷넷 2003

기업용 도구 프레임워크

기업용 도구 프레임워크, EIF(Enterprise Instrumentation Frame work)는 대규모 프로젝트를 수행하는 개발자들에게 필요한 기능들을 제공한다. 비주얼 스튜디오 닷넷 2003은 프로젝트 개발 환경 전체에 걸쳐서 통합된 이벤트, 로깅 등과 같은 정보를 제공하며 애플리케이션 관리자들은 이 기능의 수정을 통해서 애플리케이션들로부터 지속적으로 에러 정보·이벤트들을 제공받을 수 있다. 이를 통해 대규모 프로젝트 개발이 좀더 용이해지면 개발시 투자되었던 비용 역시 절감이 가능하다고 한다.

스마트 디바이스를 위한 개발 환경 추가

비주얼 스튜디오 닷넷 2003의 가장 큰 변화는 스마트 디바이스를 위한 개발 환경을 제공한다는 것이다. 그 핵심에는 닷넷 컴팩트 프레임워크라는 새로운 이름의 닷넷 컴팩트 프레임워크가 위치하게 되는데, 다음에서 간단히 스마트 디바이스 개발 환경에 대한 장점과 단점들을 언급해보자. 먼저 장점은 다음과 같다.

①온라인/오프라인 개발 지원

② 포켓 PC 기능을 최대한 활용

③ SQL 서버 CE와의 호환성

④ 멀티미디어 제공

장점뿐만 아니라 단점도 존재하는데 아직 모든 디바이스에 맞게 개발 환경을 제공하지 못한다는 데 있다. 이 부분은 각 디바이스에 맞게 테스트를 거쳐서 향후 추가되리라 생각된다. <화면 5>는 비주얼 스튜디오 닷넷 2003을 통해서 스마트 디바이스용 애플리케이션을 에뮬레이터를 통해서 살펴본 것이다.

모바일 개발에 관심이 많은 독자들에게는 또 하나의 흥미로운 공부거리가 생긴 것 같다. 혹시 이전에 임베디드 개발 툴을 이용해서 개발한 개발자들은 닷넷 컴팩트 프레임워크를 통한 개발이 얼마나 편한 환경을 제공하는가를 실감하게 될 것이다(필자 역시 너무도 황홀한 경험이었다).

스마트 디바이스 환경을 위한 개발뿐만 아니라 ASP.NET을 통한 모바일 웹 애플리케이션 개발 환경에도 새로운 기능을 추가했다. ASP.NET 모바일 디자이너가 바로 그것인데 비주얼 스튜디오 통합 툴 내에 모바일 디자이너를 추가해서 쉽게 모바일 애플리케이션을 개발할 수 있도록 했다. 다음의 <그림 3>과 <그림 4>는 스마트 디바이스용 개발과 ASP.NET 모바일 웹 애플리케이션 개발의 방향을 간단히 표현한 것이다.

<그림 3>닷넷 컴팩트 프레임워크를 통한 애플리케이션 개발

<그림 4>ASP.NET 모바일 웹 애플리케이션 개발

이상으로 비주얼 스튜디오 닷넷 2003의 새로운 기능들에 대한 설명을 마치고 1.1로 업그레이드된 닷넷 프레임워크의 새로운 기능들을 살펴보자.

닷넷 프레임워크 1.0에서 1.1로 진화

MS는 CLR(Common Language Runtime)과 통합된 클래스 라이브러리로 구성된 닷넷 프레임워크를 1년여 만에 1.0에서 1.1로 그 기능을 확장시켰다. 이번 버전 업그레이드는 새로운 기능들의 추가와 기존 기능들의 개선 그리고 향상된 문서화가 주를 이루었다고 한다. 먼저 닷넷 프레임워크 1.1에 새롭게 추가된 기능들과 이전 기능들이 어떻게 변화되었는지 살펴보자.

ASP.NET 모바일 컨트롤

혹시 필자가 마소에 기고한 ‘모바일 웹 SDK로 다시 시작하는 모바일 인터넷’이라는 연재를 기억하는 독자도 있을지 모르겠다. 모바일 웹 SDK를 통해서 모바일 프로그램을 하는 방법에 대해 이야기했었다. 필자가 갑자기 왜 이런 이야기를 하는지 조금 궁금할 것이다. 바로 ASP.NET 모바일 컨트롤의 시작이 바로 모바일 웹 SDK이기 때문이다. 다시 말해 「모바일 웹 SDK → MMIT(Microsoft Mobile Internet Toolkit) → ASP.NET 모바일 컨트롤」로 변경되었기 때문이다. 하지만 이전에 독립적으로 존재하던 모바일 웹 SDK나 MMIT는 ASP.NET 모바일 컨트롤로 모습을 바꾸면서 닷넷 프레임워크와 비주얼 스튜디오 닷넷의 기능 중 일부분으로 자리를 잡았다. <화면 6>은 비주얼 스튜디오 닷넷 2003을 이용해서 ASP.NET 모바일 컨트롤을 사용하는 화면으로 새롭게 추가된 모바일 컨트롤과 모바일 페이지를 좀더 쉽게 개발할 수 있는 환경을 볼 수 있다.

<화면 6>ASP.NET 모바일 컨트롤을 이용한 개발 환경

현재 ASP.NET 모바일 컨트롤로 개발된 모바일 웹 애플리케이션은 대부분의 단말 브라우저와 PDA 브라우저에 적용될 수 있기 때문에 개발자들은 다양한 디바이스들에 웹 애플리케이션을 적용해야 하는 문제에서 벗어날 수 있게 되었다.

ADO.NET 속에서 일어나는 변화들

ODBC, DataReader 객체

웹 애플리케이션을 데이터베이스와 연결할 경우 대부분 ODBC를 사용한 경험이 있을 것이다. 또한 데이터베이스에 맞는 ODBC 드라이버가 없을 경우에는 인터넷이나 소프트웨어 CD를 통해 적절한 ODBC를 설치해야 했다. 하지만 닷넷 프레임워크 1.1에서는 System.Data.Odbc라는 새로운 네임스페이스를 추가해서 기존의 ODBC를 이용할 경우에 발생하는 불편함을 조금이나마 해소시킬 수 있게 했다. 간단하게 System.Data.Odbc를 사용해서 데이터베이스 처리를 어떻게 하는지 살펴보자.

string myConnection = “DRIVER={SQL Server};SERVER=Kamja;DATABASE=kamja”;

OdbcConnection myConn = new OdbcConnection(myConnection); // OdbcConnection 클래스 생성

string myInsertQuery = “INSERT INTO Kamja {Name, Age} Values{‘Kamja’, ‘32’}”;

OdbcCommand myOdbcCommand = new OdbcCommand(myInsertQuery);// OdbcCommand 클래스를 이용해서

// SQL문 실행

myOdbcCommand.Connection = myConn;

myConn.Open();

myOdbcCommand.ExecuteNonQuery();

myOdbcCommand.Connection.Close();

<화면 7>ODBC 데이터 원본 관리자

이제 <화면 7>과 같이 ‘ODBC 데이터 원본 관리자’를 이용해서 따로 작업을 해줘야 하는 수고는 사라지게 된 것이다. 그리고 웹 애플리케이션을 배포할 경우 ODBC에서 데이터 원본을 생성해줘야 한다는 귀찮은 생각들도 이제 할 필요가 없는 것이다. 솔직히 필자는 가끔 데이터 원본을 생성하지 않아 문제점을 찾기 위해 다른 부분에 많은 시간을 보낸 적이 있다. 이제는 프로그램 코드 내에서 ODBC를 이용해서 데이터베이스에 접근할 수 있기 때문에 이와 같은 실수는 하지 않을 것 같다.

또한 오라클 데이터베이스 처리를 위해 System.Data.Oracle Client를 제공하고 있다. 사용법은 다음과 같고 System.Data. OracleClient를 사용해야 할 경우에는 ‘ODBC 데이터 원본 관리자’를 통해 오라클 드라이버에 맞는 데이터 원본을 생성해야 한다.

string myConnection = “Data Source=Oracle8i”;

OracleConnection myConn = new OracleConnection (myConnection); // OracleConnection

// 클래스 생성

myConn.Open();// 오라클 데이터베이스에 접속

myConn.Close();// 오라클 데이터이스 접속 종료

DataReader 객체와 Connection 객체에도 HasRows 속성과 EnlistDistibutedTransaction 속성 추가라는 조그마한 변화가 생겼다. HasRows 속성은 DataReader 객체에 추가된 속성으로 데이터를 읽지 않은 상태(Read 함수 호출 전)에서 읽을 데이터 열이 존재하는 지를 판단할 수 있는 기능을 제공한다. 이해를 돕기 위해 다음의 코드를 보자.

if(myReader.HasRows)

while(myReader.Read())

Console.WriteLine(“읽은 값 출력 {0}“, myReader.GetString(0));

else

Console.WriteLine(“읽을 데이터가 없습니다.“);

Side-by-Side 실행

닷넷 프레임워크 1.1은 하나의 컴퓨터에 설치된 다수 버전의 애플리케이션이 컴포넌트, CLR의 버전 정보에 상관없이 실행 가능하도록 하는 Side-by-Side 실행이라는 기능을 제공한다. <그림 5>를 보면 쉽게 이해할 것이다. 애플리케이션 A, B, C, D는 버전 정보가 다르며 또한 각기 다른 컴포넌트와 런타임을 사용한다. 자칫 이후에 설치된 애플리케이션 C 때문에 컴포넌트 버전 1.0을 사용해야 하는 애플리케이션 A와 B가 컴포넌트 버전 2.0을 사용해서 정상적으로 실행되지 않을 수 있다. 하지만 이러한 문제점들은 Side-by-Side 실행 환경 제공으로 말끔히 사라지게 되었다. <그림 5>에서처럼 버전 정보가 다른 애플리케이션들은 각기 사용하는 버전의 컴포넌트와 런타임을 사용해서 실행되기 때문에 문제가 발생하지 않는다.

<그림 5>Side-by-Side 실행

변화된 닷넷 프레임워크 보안

닷넷 프레임워크는 ‘코드 접근 보안(Code Access Security)’ 기능을 가지고 있다. 코드 접근 보안이란 실행되는 코드가 닷넷 프레임워크 어셈블리를 사용할 경우 적용되는 것으로서 실행되는 코드가 어셈블리를 이용할 수 있는 권한을 가지고 있는가를 확인하는 절차이다. 즉, 다음과 같이 어셈블리 A1을 호출하려는 코드는 먼저 다음과 같은 절차를 거쳐야 한다.

<코드> 어셈블리 A1씨, 당신을 좀 사용하려고 하는 데 어떤 권한이 필요한지요?

<어셈블리 A> P라는 권한을 제시하세요.

<코드> (코드 내에 있는 권한 관리자에게) 우리 P 권한이 있나요?

<코드 내 권한 관리자> 예. 여기 P 권한이 있습니다.

<코드> 어셈블리 A씨, 저한테 P 권한이 있습니다.

<어셈블리 A> 그럼 이제 저를 사용하세요.

앞의 예는 아주 간단한 형태로 표현한 것이다. 실제로는 내부에서 일어나는 일들은 좀더 복잡할 수 있다. 그럼 닷넷 프레임워크로 개발된 코드들은 코드 접근시 이와 같은 보안 모델을 적용하는 반면 COM 컴포넌트, 액티브X 컨트롤, WIN32 API로 제작된 코드들은 코드 접근 보안에 의해 닷넷 프레임워크가 제공하는 어셈블리를 사용할 수 없는 게 당연하다. 하지만 닷넷 프레임워크는 AllowPartially TruestedCallersAttribute 속성을 통해 어셈블리를 사용할 수 있도록 하는 길을 제시했다. <표 1>은 AllowPartiallyTrustedCallers Attribute 속성을 이용해서 접근할 수 있는 어셈블리들이다. 이들 중 닷넷 프레임워크 1.1에서는 System.Web.dll, System.Web.Mobile. dll, System.Web.RegularExpressions.dll이 새롭게 포함되었다.

또한 ASP.NET 에서도 라는 환경 지시자를 통해서 애플리케이션의 보안 레벨을 설정할 수 있다.

<표 1>AllowPartiallyTuestedCallerAttribute 속성으로 접근 가능한 어셈블리

IPv6 지원

IP 버전 6, 즉 IPv6는 현재 사용하고 있는 IPv4의 문제점들을 보완하기 위해 개발된 인터넷 프로토콜이다. 닷넷 프레임워크 1.1은 현재 사용되는 새롭게 적용될 IPv6에 대한 개발 환경을 제공하기 때문에 개발자들은 향후 변화하게 될 환경을 좀 더 빨리 접해볼 수 있다.

비주얼 스튜디오 닷넷 2003 리뷰를 마치며

비주얼 스튜디오 닷넷 2003 툴에 대한 리뷰를 하면서 좀더 많은 것을 다루었으면 하는 아쉬움이 남는다. 기회가 있다면 비주얼 C++.NET, 비주얼 C#,NET, 비주얼 J#.NET, 비주얼 베이직.NET에 대해 체계적인 글로 독자를 만나게 되기를 바란다. 두서없이 쓴 글이라 독자의 원성을 들을까 겁이 나지만 바쁜 와중에 새로운 정보를 제공하려는 필자의 마음을 조금이라도 이해해주었으면 한다. 항상 즐거운 하루되기를 바라며 대구 지하철 사건으로 인해 아까운 생을 마감한 분들에게 삼가 명복을 빈다.@