삽질
보통 땐 Windows XP x86에서 개발한다. 하지만 실제 서비스는 Windows 2003 Server x64에서 운영될 예정이다. 그러니 당연히 테스트용으로 지급된 서버가 있다. 문제는 64비트 운영체제가 조금 까탈스럽다는 것이다. 예를 들어, C:\Program Files\가 있는가 하면 C:\Program Files (x86)\가 있다. 이런 식으로 x86 호환용 구성요소가 따로 존재하기 때문에 빌드 스크립트나 프로그램 작성시에 함부로 하드코딩을 해선 나중에 곤란하게 된다.
어제는 x64 운영체제에 대해 한수 배웠다.
빌드 스크립트에 Test라는 타겟(Target)이 있다. 단위 테스트를 하는 명령인 것 같지만 사실은 로컬에 서버 애플리케이션과 테스트 애플리케이션 모두 띄워놓는 명령이다. 이 명령을 실행시키면 자기가 알아서 로컬 데이터베이스이나 설정 파일을 지우고 새로 생성하고, 모든 테스트 준비를 끝마쳐놓는다.
평소엔 로컬 컴퓨터에서 테스트를 진행하는데, 서버 애플리케이션을 여러 개 띄우면 메모리가 바닥나기 십상이라 테스트용으로 지급받은 x64에 서버를 띄워놓고, 로컬에서 테스트 프로그램을 실행시키려 했다. msbuild build.msbuild /t:Test를 치고 로컬에서처럼 원격 컴퓨터에서도 빌드 스크립트가 제 역할을 하는지 보려 했다. [제어판/관리도구/데이터 원본 (ODBC)] 창을 열었는데, 이게 웬 걸! 아무 것도 없었다.
ODBC DSN을 등록하는 VB 스크립트가 있었는데, 참 이상하게도 명령창에서 직접 스크립트를 실행시키면 DSN이 생성됐다. 하지만 빌드 스크립트에 <Exec command="register.vb" />를 써 넣고, msbuild build.msbuild /t:Test를 치면 DSN 목록이 텅비어 있었다.
윈도우 스크립트가 XP x86과 2003 Server x64에서 서로 다른 행동을 보였던 기억이 났다(Echo 명령을 실행시키면 XP x86에선 콘솔에 출력하지만, 2003 Server x64에선 메시지 박스를 띄운다). 그래서 VB 스크립트 대신 MSBuildTasks를 사용해서 ODBC 레지스트리를 조작했다. 하지만 역시 똑같은 일이 벌어졌다.
이때부터 뭔가 삽질하고 있다는 자각을 했고 열심히 관련 현상에 대해 구글링을 했다. 결국 문제의 해답을 찾았는데, 결론은 문제가 없었다!였다.
해답
Windows 2003 x64에서 32비트 빌드한 애플리케이션을 실행시킨 게 문제라면 문제였다. 32비트 애플리케이션이 레지스트리를 건드리려고 하면 운영체제가 32비트 레지스트리로 리다이렉트시킨다. 방금 32비트 레지스트리라고 했는가? 그렇다. 64비트 레지스트리와 32비트 레지스트리가 구분되어 있다.
다른 것도 마찬가지다. [제어판/관리도구/데이터 원본 (ODBC)]은 64비트용 ODBC 관리도구라서 64비트 레지스트리의 정보를 가져오고 조작한다. 그러니 32비트 레지스트리를 조작했다면 DSN이 보일리 만무하다. 32비트용 ODBC 관리도구는 C:\Windows\SysWOW64\odbcad32.exe인데, 이걸 실행시키니 비로소 그토록 보고 싶어했던 DSN이 있었다.
근본적인 문제는 크게 두 가지였다.
하나는 빌드 스크립트에 64비트 빌드 옵션을 안 넣어뒀다는 점이다. 그러니 64비트용 ODBC 관리도구를 열어서 아무리 찾아봐야 DSN이 보일리 없다. 또 다른 문제는 32비트용 MSBuild를 실행시켰다는 점이다. C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\MSBuild.exe가 아닌 C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\MSBuild.exe를 실행시켰어야 했다.
말은 쉽게 했지만, 실제로 이 문제를 깔끔하게 해결하려면 어떻게 해야 하는지 아직 고민 중이다. 생각보다 문제가 꼬여 있다. 오전 중으로 해결해내면 좋으련만…
