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 등에 직접 서명하는 것은 별도로 빌드할 때 설정해주어야 할 특별 옵션같은것들은 존재하지 않습니다.
약 3개월만의 작업 기록 포스팅입니다. Core Runtime에 대한 테스트를 강화하고 코딩할 때 불편한 부분을 최소화하면서 실제 C 프로그래밍 언어와 비슷한 환경을 나타낼 수 있도록 만드는데에 많은 노력을 들였습니다.
Buffer, String 계열 클래스의 확장 및 개선
[Test] publicvoid memchrTest()
{ int ch = 'r';
GlobalHeapAnsiString str = new GlobalHeapAnsiString("lazy");
GlobalHeapAnsiString @string = new GlobalHeapAnsiString("The quick brown dog jumps over the lazy fox");
GlobalHeapAnsiString fmt1 = new GlobalHeapAnsiString(" 1 2 3 4 5");
GlobalHeapAnsiString fmt2 = new GlobalHeapAnsiString("12345678901234567890123456789012345678901234567890");
SBytePointer pdest; int result;
Console.Write("String to be searched:\n {0}\n", @string.ToString());
Console.Write(" {0}\n {1}\n\n", fmt1.ToString(), fmt2.ToString());
위의 코드에서 보시는것처럼 String Buffer 클래스에 직접 Add / Subtract 연산자 오버로드를 추가하여 실제 포인터 연산의 결과를 재현합니다. 형식화된 Pointer 클래스와 다른점이 있다면 자기 자신에 대한 주소 설정은 허용하지 않습니다. 이것은 비관리 메모리 영역의 주소가 변경됨으로 인하여 발생할 수 있는 할당 해지 실패로 인한 메모리 누수를 예방하기 위한 디자인입니다.
총 20여종의 주요 값 형식에 대한 형식화된 포인터 제공 (Typed Pointer)
형식화된 포인터에 세부적인 기능 조절을 더하고 제거하는 노력을 통하여 총 20여종의 주요 값 형식에 대한 형식화된 포인터를 제공하게 되었습니다. 이들 포인터 형식 모두는 외관상 CLS 표준 사양을 만족하도록 만들어졌으며 포인터 개념이 없는 프로그래밍 언어 (예: Visual Basic .NET, Visual J# 등)에서도 포인터 연산을 간접적으로 사용할 수 있게 디자인되어있습니다.
AutoCharPointer
BooleanPointer
BytePointer
DateTimePointer
DecimalPointer
DoublePointer
GuidPointer
Int16Pointer
Int32Pointer
Int64Pointer
IntPtrPointer
Pointer<T>
SBytePointer
SinglePointer
TimeSpanPointer
UInt16Pointer
UInt32Pointer
UInt64Pointer
UIntPtrPointer
WideCharPointer
사용 빈도가 높을 것으로 추정되거나 기본 형식들에 대한 형식화된 포인터는 모두 제공하고 있습니다. 하지만 특정한 목적으로 직접 추가한 구조체에 대한 지원도 필요했고 경우에 따라서는 제네릭에 대응되는 가변 포인터에 대한 구현을 필요로 하였기 때문에 Pointer<T> 형식을 새로 추가하였습니다. 전용 포인터를 이용하여 계산하는것보다는 연산 횟수가 많다는것이 단점입니다.
실제 메모리 구조의 크기를 조사해주는 unsafe sizeof() 연산자의 Managed 버전 제공
위의 테스트 코드에서 나열한 형식들에 대한 sizeof 연산자의 결과를 반환해주는것이 NativeSizeOf 메서드입니다. 그 외의 형식들에 대해서는 Marshal.SizeOf의 결과를 반환합니다.
NUnit 테스트 코드 프로젝트 시작
프로젝트에 대한 검증을 수행하기 위하여 NUnit 프로젝트를 생성하고 테스트하면서 조금씩 진척을 시켜나가고 있습니다. NUnit 테스트 코드의 내용은 실제 적용에 많은 도움이 되는 예제 코드로도 활용이 가능하니 한번 살펴보시길 권합니다.
향후 계획
조만간 공식 릴리즈를 0.1 버전으로 런칭할 계획을 세우고 있습니다. 그리고 준비가 되는대로 Windows CE, Windows Mobile에 관한 API도 수집하여 데이터베이스화를 수행할 예정이니 관심있으신 분들은 블로그나 데브피아 등을 통하여 연락주시면 언제든 채널이 열려있으니 함께 하실 수 있습니다.
