친절한 .NET 씨

필자는 최근 ActiveX 컨트롤 코딩을 하고 있다. 뭐 별건 아니고... 몇몇 DLL이 컴퓨터에 존재하는가 확인하고 닷넷 CAS(Code Access Security) 설정이 어플리케이션이 요구하는 설정을 따르고 있는가를 확인하는 컨트롤이다. 이 코드에서 DLL이 존재하는가를 살펴보는 것 뿐만 아니라 이 DLL의 버전을 확인하여 필요로 하는 버전 이상을 제공하는가 확인해야 했다. 뭐 별거 아니겠거니 생각하고 코딩을 시작했다. 별거 아니겠거니 생각한 결정적인 이유는 닷넷 프레임워크 상에서 파일의 버전 정보(물론 버전 정보를 담을 수 있는 .DLL, .EXE, .SCR 파일이어야 할 것이다)를 알아내는 것은 대단히, 매우, 정말, 진짜로, really, certainly 쉽기 때문이다. 파일 버전 정보를 알아내기 위해서는 System.Diagnostics 네임스페이스의 FileVersionInfo 클래스를 사용하면 된다. FileVersionInfo 클래스의 스태틱(static) 메쏘드인 GetVersionInfo 메쏘드에 알아내고자 하는 파일의 경로만 던져주면 파일 버전 정보가 들어있는 FileVersionInfo 클래스의 인스턴스를 반환해 준다. 이 클래스에는 파일 버전부터 시작해서 작성자, 회사, 저작권 정보 등, 파일 속성 대화상자에서 보여주는 파일의 정보를 모두 보여준다. 파일 버전 정보는 전체 버전이 통합되어 문자열 형태로도 존재하며, 버전의 각 Major, Minor, Build, Revision 부분을 별도로 알아낼 수도 있다. 대충 다음과 C# 코드가 파일 버전을 알아내는 코드가 되겠다.

불친절한  WIN32 API 씨

뭐... 이따구의 간단한 코드를 작성해본 경험이 있으니... ActiveX 를 제작할 때도 이와 상응하는 WIN32 API가 있겠지 생각하며 MSDN을 뒤지기 시작했다. 뭐 십 수년을 도움말을 뒤지고 살았으니 그닥 어렵지 않게 WIN32 API를 찾아 냈다. GetFileVersionInfo 함수가 바로 이 녀석인데... 매개변수가 영 심상치 않다. 뭔가가 있을 듯한 불길한 예감이 들었다.

아니나 다를까. 이 녀석은 파일의 버전정보를 모두 담는 메모리 블록을 반환할 뿐이며, 이 메모리 블록에서 필요한 정보를 추출하는 함수는 별도로 존재했다. 즉, 추가적으로 VerQueryValue 라는 함수를 호출해 주어야만 원하는 정보를 뽑을 수 있었던 것이다. 쓰봉... 게다가 이 함수를 달랑 한번 호출하는 것이 아니라 필요한 정보 마다 이 함수를 호출해 주어야 한다. 뭐... 이 함수를 상세히 설명하기 위한 글이 아니므로 대략 앞서의 닷넷 코드와 동등한 C/C++ 코드를 적어보면 다음과 같다. -_- C/C++ 및 기타 WIN32 프로그래밍을 해보지 않은 독자라면 아래 코드를 이해하려고 하지 마라. 머리만 터지므로 대충 쭈욱 살펴보기 바란다.

친절한 .NET 씨

좀 길다. 아니 졸라 길다. 왜 이렇게 긴 것일까? 필자는 고민하기 시작했다. 내 코드가 삽질은 아닐까? 불안해진 필자는 Reflector 를 꺼내들고 닷넷의 FileVersionInfo 클래스를 까보았다. 아니나 다를까... 필자가 호출했던 WIN32 API들을 줄줄이 호출하는 닷넷 코드를 볼 수 있었다. 뭐... Windows 상에서 파일 버전을 알아내는 API는 GetFileVersionInfo 함수와 VerQueryValue 함수 둘 뿐이니 닷넷이라고 해봤자 지가 용빼는 재주는 없었을 것이다.

닷넷 프레임워크와 FileVersionInfo 와 같은 클래스들이 모여있는 BCL (Base Class Library)은 정말로 친절하게도 개발자의 수고를 줄여주고 있는 것임을 새삼스럽게 느꼈다. FileVersionInfo 클래스 뿐인가? 수많은 WIN32 API, COM 인터페이스, ADSI 관련 API, MSMQ API 등을 모두 닷넷 프레임워크 CLR과 BCL은 친절하게도 wrapping 하고 있다. 덕분에 개발자는 보다 쉽게, 보다 빠르게 코드를 작성할 수 있는 것이다. C/C++ 혹은 VB 6.0으로 이벤트 로그에 로그 한 줄을 남기기 위해 얼마나 많은 코드와 작업이 필요했던가? Windows 서비스를 작성하기 위해 얼마나 많은 C/C++ 코드가 필요했던가는 코드를 작성해 본 사람만이 알 것이다. 닷넷은 어떤가? 이벤트 로그에 로그 남기는 것은 단 한 줄의 코드로도 가능하고, Windows 서비스 역시 VS.NET의 프로젝트 템플릿 도움 없이도 쉽게 코딩할 수 있다.

VB 6.0은 친절했을까?

닷넷이 없던 시절엔 어떠했을까? 파일 버전 정보를 읽어오는 오늘의 예제를 생각해 보자면, C/C++ 개발자라면 죽으나 사나 앞서 보여준 대로 졸라 코딩을 했어야 할 것이고... C/C++ 보담은 보다 4GL에 가까운 VB 6.0은 어떠했을까? VB 6.0은 C/C++에 비교해서 빠르게 프로그램을 개발할 수 있도록 해주긴 해준다. 하지만 VB 6.0이 기본적으로 제공하는 기능은 한계가 뚜렷했다. KB 160042 와 KB 139491 을 살펴보더라도 VB 6.0과 그 이전 버전에서도 상당히 많은 삽질을 해야만 원하는 기능을 구현할 수 있다는 것을 알 수 있다. (링크 클릭하는 것마저 귀찮아 하는 독자를 위해, 위 두 KB는 VB 6.0 에서 앞서 언급한 GetFileVersionInfo 함수, VerQueryValue 함수들을 어떻게 호출하고 사용하는가 예제를 다루고 있다. C/C++ 코드에 만만치 않게 졸라 길다)

닷넷 이전 시절에 그나마 개발 생산성이 좋다고 알려졌던 VB 6.0 이지만, 이런 세세한 기능까지 모두 커버하지 않았다는 것이 명백했으며, 그다지 친절하지 못한 VB 6.0 덕에 개발자들은 MSDN과 구글, 인터넷 등을 헤메였던 것이다. 꺼이 꺼이... 옛날 생각하면 슬프다... T_T

결론(?)

뭐 결론 내리자고 글 쓴 건 아니지만... 닷넷 프레임워크의 CLR 과 BCL 등 많은 컴포넌트들은 개발자를 위해 많은 일을 하고 있다. 조청과 단꿀, 물엿과 엿기름, 버터와 쇼트닝유가 흐르는 "친절한 닷넷의 개발 환경"에 우린 감사해야 할 것이다. (결론 치고 졸라 썰렁하다... 난 왜 블로그를 쓸까? 아아... -_-)

부록. 파일 버전 정보에 대하여

(부록까지... 이젠 별짓을 다한다...)구라만 풀기 좀 뭐하니깐... 파일 버전 정보에 대해서 간략히 언급하고자 한다. 파일 정보는 EXE, DLL 등 PE 포맷의 파일의 리소스로서 존재한다. Visual Studio를 이용하여 C/C++ 프로젝트를 만들면 .rc 파일 내에 항상 VS_VERSION_INFO 라는 버전 자원(resource)이 생성되는 것을 보곤 했을 것이다. 바로 여기에 기록되는 버전 정보가 WIN32 리소스로서 EXE, DLL 내에 표준 위치(위치라기 보다는 표준 리소스 아이디인 1을 사용한다)에 기록된다. 이렇게 표준적으로 기록된 정보를 읽어오는 API가 GetFileVersionInfo 함수인 것이다. 파일 버전 정보가 리소스 형태로 존재하기 때문에 Microsoft가 제정하고 권고하는 표준 정보들(버전, 회사명, 파일설명, 저작권, 제품이름, 제품버전 등)외에도 추가적인 정보를 기록하는 것이 얼마든지 가능하며, 이것이 잘못된 것이거나 이상한 것이 전혀 아니다. 그래서 각 파일마다 이 파일버전 정보의 크기가 다를 수 있는 것이다.

그렇다면 이 리소스가 없는 EXE, DLL은 ? 당근 파일 버전 정보는 없다. DLL 이나 EXE를 오른쪽 클릭하고 속성 메뉴를 선택하면 나타나는 파일 정보 대화 상자에서 버전 탭이 없는 것들이 있는데, 이런 경우가 바로 버전 정보 리소스를 포함하지 않는 DLL, EXE 이기 때문이다. 당연하게 GetFileVersionInfo 함수 호출은 실패하게 된다.

닷넷은 어떤가? 닷넷 컴파일러는 AssemblyTitle, AssemblyDescription, AssemblyCompany, AssemblyVersion 등의 특성(attribute)의 값을 이용하여 DLL, EXE 에 버전 리소스를 알아서 생성해 준다. 대개 AssemblyInfo.cs 파일에서 이러한 특성들의 값을 기록하는 것임을 독자들도 잘 알 것이다. 정말 친절한 닷넷씨가 아닌가?