2009년 7월 6일에, Microsoft가 기존의 Windows Related Protocol에 대하여 한정적으로 시행해왔던 Community Promise를 ECMA-334와 ECMA-335에 대해서도 적용을 시작한다는 공식 발표가 있었습니다. ECMA-334는 C# 프로그래밍 언어에 대한 사양을, ECMA-335는 Common Language Infrastructure (CLI)에 대한 사양을 정의하는 표준안입니다.
이 발표를 통하여, 이전까지는 자생적인 차원에서 진행되었던 오픈 소스 프로젝트들이, ECMA-334와 ECMA-335 사양을 구현하기 위하여 직접 Microsoft와 의사 교류를 진행할 수 있음은 물론 라이선스 계약서 등에 동의해야 할 필요가 없습니다. 즉, Community Promise 정책 아래에 놓여있는 표준 사양에 대한 모든 활동이 자유롭게 진행될 수 있음을 뜻합니다.
Mono 2.4가 발표된 이후로 지속적으로 Mono 프로젝트는 발전에 발전을 거듭하고 있습니다. 최근 흥미로운 툴킷 하나가 새로 등장하였는데 바로 Mono Tools for Visual Studio가 그 주인공입니다. 이전에는 Embacadero Delphi Prism을 통하여 Delphi Prism IDE 레벨에서 Mono와의 동시 Build를 제공한 것이 최선이었습니다만 이제 공식적으로 기본 IDE 위에서 사용할 수 있는 공식적인 Tool이 등장하게 되었습니다.
현재 Mono Tools for Visual Studio는 Private Preview 형태로 배포되는 것으로 소정의 가입 절차가 필요함을 알아두시면 좋겠습니다.
Mono Tools for Visual Studio의 주요 기능을 살펴보면 다음과 같습니다.
호환성 검사: 이전부터 제공되어오던 MoMA (Mono Migration Assistant)를 활용한 호환성 검사 기능을 제공합니다. 개발 중인 닷넷 응용프로그램을 Mono로 가지고갈 때 발생할 수 있는 문제점들을 보고서의 형태로 알려주는 기능으로 호환성 문제에 대한 충분한 검토를 사전에 해 볼 수 있도록 해줍니다.
Windows에서 실행: Mono의 Win32 프레임워크를 이용하여 현재 개발 중인 닷넷 응용프로그램을 직접 실행할 수 있도록 해줍니다.
Linux에서 원격 실행: 미리 준비되어있는 Linux Workstation 컴퓨터 위에서 현재 개발 중인 닷넷 응용프로그램을 직접 실행할 수 있도록 해줍니다.
Linux에서 원격 디버깅: Mono Tools for Visual Studio의 중요한 기능이라고 할 수 있습니다. Linux에서의 원격 실행을 전제로, 원격 디버거를 통하여 Visual Studio의 Debugging Feature를 그대로 사용하여 문제점을 진단하고 파악할 수 있게 해 주는 기능입니다. 참고로, ASP.NET 디버깅도 지원된다고 합니다.
여기서 주목할 것은 VMware Virtual Appliance의 형태로 무료로 배포되는 가상 PC 패키지에 관한 것으로, 가상 PC 패키지를 이용하거나 Windows 7의 Windows Virtual PC 위에서 오픈수세 리눅스 + 모노를 설치하면 컴퓨터 앞을 떠나지 않고도 동시에 두 개의 운영 체제에서 테스트를 수행할 수 있는 편리성을 보여줍니다.
이 중에서 호환성 검사 기능과 원격 디버깅에 관한 내용은 블로그 강좌 형태로 다루어볼 계획이니 많은 관심 바랍니다. :-)
이미 여러 블로그 아티클로도 잘 다뤄진 내용이지만 몇 가지 부수적인 내용을 덧붙여서 ActiveX 패키징 및 배포에 관한 내용을 총 정리해보았습니다. 실무에서는 아직도 ActiveX 컨트롤에 관한 유지보수를 틈틈이 수행할 필요가 있다보니 이런 문서를 작성하게 되는 것 같습니다. :-)
1. INF 파일에 대한 이해
INF 파일은 ActiveX 패키지 배포 시 내장되는 설치 정보 파일로 보통 배포되는 CAB 파일의 이름과 동일하게 맞추어서 배포합니다. 예를 들어 MyControl.cab을 배포한다면 MyControl.inf 파일을 내장하고 있어야 하는 것입니다.
그리고 INF 파일의 문법적인 구조에 대한 상세한 설명이 없어서 상당히 답답한 때가 많습니다만 간략하게 두 가지 사례를 짚어서 설명해보도록 하겠습니다.
a. Hooking 없이 설치하는 경우
Hooking이란 설치 도중에 별도의 외부 프로세스를 이용하여 설치 자체를 자동화하거나 설치 전/후 과정을 제어하기 위한 일종의 옵션 기능입니다. ActiveX에 수많은 보안 결함이 존재하지만 디자인적으로 보았을 때에도 충분히 문제가 드러납니다. 대부분 간단한 유형의 ActiveX 컨트롤은 Hooking 기능 없이 배포가 되는 편입니다. 다음의 샘플 INF 코드를 살펴보기로 합니다.
흔히 볼 수 있는 형태의 INF 파일입니다. 제일 상단에 있는 것이 INF 파일의 형식에 관한 기본 정보이고 Windows 95 이후로부터는 대체로 Advanced INF 2.0 규격을 따르는 것 같네요. (시그니처에 Windows 95의 코드 네임인 Chicago가 적혀있는 것으로 보았을 때도 그러합니다.)
하단의 [Add.Code] 섹션에서는 이 CAB 파일을 통해서 배포될 파일들을 기술합니다. 편의 상 파일 이름과 엔트리 이름을 일치시켜두는 것도 좋습니다. 그리고 각각의 파일명으로 기술된 섹션이 해당 파일을 어떤 식으로 복사되고 관리되어야 하는지를 서술하는 부분으로 이후에 설치 제거를 할 때 근거 정보가 됩니다.
각 섹션 별로 file-win32-x86 이라는 엔트리 명이 보이는데 파일의 플랫폼과 대상 아키텍처를 지정하는 부분입니다. 옛날 (NT 시절)에는 Alpha나 MIPS 계열 프로세서를 위하여, 요즈음에는 x64 (AMD64) 프로세서를 위하여 이 부분이 달리 할당될 수도 있을 것입니다. 그리고 thiscab 이라는 값은 이 CAB 파일 내에 파일이 있음을 뜻하는 부분입니다.
DestDir 엔트리는 이 파일이 어느 위치로 복사되어야 하는지를 나타내는 부분으로 많은 옵션이 있을것 처럼 보이지만 실제로 알려진 것은 세 종류인듯 합니다. 값을 10으로 지정하면 %windir% 경로 (흔히 C:\Windows)에, 11로 지정하면 %windir%\system32 (Windows 9x 계열 운영체제에서는 %windir%\system)에, 비워두면 OCCACHE 디렉터리 (%windir%\Downloaded Program Files)에 복사됩니다.
그리고 이제 OCX 파일 섹션의 내용을 살펴보기로 합니다. OCX 파일의 내용에서 꼭 확인해야 할 것은 RegisterServer=yes 항목과 Version 항목, 그리고 clsid 항목입니다. Version은 OCX 파일을 빌드할 때 추가되는 Win32 리소스의 버전 테이블 정보와 일치할 필요가 있으며, clsid 항목은 실제로 브라우저에서 인스턴스화되어 실행되어야 하는 COCLASS의 CLSID와 일치해야 합니다.
ActiveX를 이용하여 대리 설치 프로그램을 기동시키기 위하여 위와 같이 작성할 수도 있지만, 컴포넌트별로 Hook을 다르게 지정할 수도 있으니 참고하시기 바랍니다. Hook을 실행하기 위하여 %EXTRACT_DIR% 라는 지역 환경 변수를 지정한 것을 볼 수 있고 프로그램 매개 변수까지 지정이 가능한 것을 보실 수 있습니다.
Hook에서 지정한 프로그램의 경우 주의 사항이 한 가지 있다면, 프로그램의 실행 종료 코드가 0으로 끝날 필요가 있다는 것입니다. 그렇지 않으면 설치가 중간에 실패한 것으로 인지되어 브라우저에는 아무것도 표시되지 않는다고 합니다. 이를 미리 확인해보려면 패키징 하기 전에 Hook을 통해서 구동하려는 프로그램을 똑같이 명령 프롬프트에서 아래와 같이 실행하면 알 수 있습니다.
START /WAIT "실행할 프로그램 및 매개 변수들"
ECHO %ERRORLEVEL%
%ERRORLEVEL% 환경 변수의 값이 0이 아닌 것으로 나타나면 Hook 프로그램으로는 사용할 수 없을 것입니다.
2. PVK 파일과 SPC 인증서 파일을 PFX 파일로 변환하기
SIGNCODE 도구에서 SIGNTOOL 도구로 새롭게 바뀐 이후부터, ActiveX CAB 파일에 서명을 하거나 EXE 파일 위에 서명을 하는 방법이 조금 바뀌었습니다. 바로 PFX 파일을 생성하는 작업이 추가 된 것인데, 기존에 가지고 있는 인증서 파일 형식이 PVK 파일과 SPC 파일 두 가지로 구성된 경우 아래와 같이 변환해야 합니다.
PVK2PFX -PVK "PVK 파일의 경로" -SPC "SPC 파일의 경로" -PFX "PFX 파일을 만들 경로" -PI "기존 인증서의 Password" -F
PVK2PFX 유틸리티는 .NET Framework SDK v2.0 혹은 Windows SDK v6.0 이상을 설치하면 같이 따라오는 유틸리티입니다. 여기서 -PVK 스위치 다음에 PVK 파일의 경로를, -SPC 스위치 다음에 SPC 파일의 경로를 서술해주어야 하고, 그 다음 -PFX 스위치 다음에 새로 만들 PFX 파일의 경로를 서술해야 합니다. 추가적으로 인증서로부터 암호를 해독하고 PFX 파일에 암호를 새로 설정하기 위하여 -PI 스위치 뒤에 인증서 암호를 기술합니다. 기본 동작이 기존 파일이 있을 경우 실패로 처리되는데 편의상 -F 스위치를 지정하여 PFX 파일을 덮어쓰도록 실행합니다.
3. CAB 파일에 서명을 할 때에는 반드시 Spanning Space를 확보할 것
CAB 파일에 서명을 추가하기 위해서는 별도의 Spanning Space를 확보해야 하는데 이를 위해서는 CABARC 유틸리티로 압축해야 합니다. (다른 압축 유틸리티에서는 지원하지 않을 수도 있습니다.)
CABARC -S 6144 N "생성할 CAB 파일의 경로" "파일1" "파일2" ... "파일n"
-S 스위치가 Spanning Space 확보를 지시하는 스위치로 이 뒤에 Magic Constant 값 6144를 지정합니다. 이것이 인증서 크기에 관한 Magic Constant로 문서화된 수치이므로 그대로 사용하면 됩니다. 새로운 파일을 만들어야 하므로 N 스위치를 지정하여 모드를 변경하고, 그 다음에는 CAB 파일이 생성될 경로, 그리고 그 다음부터는 CAB 파일에 포함할 파일들을 하나씩 서술하면 됩니다. 와일드 카드도 지원하므로 편리합니다.
4. 실제로 서명하고 확인하기
SIGNCODE 프로그램보다 기능이 다양하고 정교해진 SIGNTOOL을 이용해서 서명을 하려면 다음의 스위치 설정을 활용합니다.
SIGNTOOL SIGN /F "PFX 파일 경로" /P "PFX 파일 암호" /T "타임스탬프 URL" "대상 파일 1" "대상 파일 2" ... "대상 파일 n"
SIGNTOOL 프로그램을 서명 모드로 실행하기 위하여 SIGN 스위치를 지정하고, /F 스위치에는 2단계에서 만든 PFX 파일, 그리고 /P 스위치에는 2단계에서 지정한 인증서 암호를 입력합니다. /T 스위치 뒤에는 실제로 접속 가능한 타임스탬프 URL을 지정해야 하는데 이는 인증서 발행 업체가 제공하는 고유 URL을 이용하면 됩니다. 마지막으로 대상 파일들을 지정하면 한꺼번에 동일한 인증서로 서명할 수 있습니다.
CAB 파일을 제외한 보통의 EXE, DLL, OCX 등에 직접 서명하는 것은 별도로 빌드할 때 설정해주어야 할 특별 옵션같은것들은 존재하지 않습니다.
publish.zip
