최근 진행 중인 한국씨티은행 내 프로젝트에서 개인적으로 Visual Studio의 기본 기능들에 대해 많은 것을 다시 보게 되었습니다. 그 중에서도, 가장 뜻깊은 발견을 하나 한 것이 있는데, 환경 변수에 관한 내용이었습니다.

 

Visual Studio의 빌드 후 이벤트에서는 DOS 명령어를 사용하여 빌드 전이나 빌드 후의 이벤트를 사용자 정의하는 것이 가능하여 Visual Studio가 기본으로 제공하지 않는 기능들 (예: Sandcastle을 통한 코드 문서화)을 한 번에 완성할 수 있도록 할 수 있습니다. 더 나아가서는, 프로젝트 자체에 별다른 컴파일 대상 없이 빌드 순서에 따라 빌드 전 / 빌드 후 이벤트에 대한 스크립트만을 포함하는 프로젝트도 구성할 수 있을 것입니다.

 

그러나, 빌드 전 / 빌드 후 이벤트에는 한 가지 크게 아쉬움이 남는 부분이 있는데, 바로 명령줄 인터프리터의 환경 변수를 사용하는데 제약이 있다는 점입니다. (예를 들어 %WINDIR% 같은 변수가 되겠습니다.) 프로세스 수준, 로컬 사용자 수준, 시스템 수준 등 환경 변수로 사용할 수 있는 내용들이 많음에도 불구하고 이런 혜택을 누리지 못한다는 것은 많이 아쉬운 부분이었고, 제가 진행중인 프로젝트에 있어서는 곤란한 부분이었습니다. 그러던 중, 좋은 방법을 하나 찾게 되어 소개합니다.

 

빌드 후 이벤트 기능을 확장하려는 프로젝트에 대해서, 솔루션 탐색기에 해당 프로젝트에 일반 텍스트 파일을 하나 추가합니다. 그리고, 여기에 명령줄 인터프리터의 명령을 작성하고 저장한 뒤, 파일의 이름에서 확장자 부분을 .txt 대신 .cmd로 변경합니다.

 

 

변경 후에는 해당 항목의 속성으로 이동하여, "Copy to Output Directory" (한국어 명칭의 경우 출력 디렉터리로 복사) 항목을 True로 설정하여 빌드 도중에 명령줄 인터프리터 스크립트 파일이 빌드 대상 디렉터리에 복사될 수 있도록 합니다.

 

 

마지막으로, 프로젝트 속성에서, 빌드 후 이벤트 스크립트에 다음과 같이 지정하면, Visual Studio가 아닌 Windows의 명령줄 인터프리터 기준으로 수행되는 빌드 후 이벤트 처리 시스템을 완성할 수 있습니다.

 

 

$(TargetDir)은 MSBUILD에서 제공하는 환경 변수로, '\' (Back Slash) 기호가 값 내에 가장 끝에 붙어있어서 경로 구분 기호 없이 이어서 파일의 이름을 서술한다는 점을 유의하여, call 명령을 우리가 만든 CMD 파일을 가리키도록 호출한 것입니다.

 

만약 MSBUILD의 환경 변수를 CMD 파일 내에서 사용하기를 원할 경우, set 명령을 사용하여 변수를 공유하거나, 매개 변수를 전달하면 CMD 파일 내에서는 %0 ~ %9 까지의 예약 변수를 사용하여 MSBUILD의 환경 변수 값을 수신할 수 있습니다.

 

크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by Windows Azure MVP 남정현 (rkttu.com)

Windows Server 2003 SP1 이상에서 Visual Studio 2005 SP1을 설치하면 예상하지 못한 오류를 만나게 되는데, 정확한 설명 없이 오류 로그를 보면 단지 0x643 오류 코드만을 반환하고 설치가 종료되어 당황스러운데요, 여기에 대한 정확한 해결법이 있어서 소개해 봅니다. (이 가이드는 Microsoft Update를 통해서 Visual Studio 2005 SP1을 설치하려다 실패하신 분들에게도 적용됩니다.)

1. 시작 메뉴를 클릭하고 실행을 클릭한 후 secpol.msc를 입력하고 확인 버튼을 클릭합니다. 또는 시작 메뉴를 클릭하고 (모든) 프로그램의 관리 도구의 로컬 보안 정책을 클릭합니다. 시작 메뉴에서 관리 도구 그룹을 찾을 수 없을 경우에는 제어판을 이용하여 관리 도구 폴더를 찾을 수 있습니다.

2. 로컬 보안 설정 관리 콘솔이 나타나면 좌측의 트리 영역에 나열된 항목들 중 소프트웨어 제한 정책을 클릭합니다. 그러면 오른쪽 창에는 "정의된 소프트웨어 제한 정책 없음"을 안내하는 메시지가 나타날 것입니다. (만약 이러한 메시지 없이 어떤 항목들이 표시된다면 3단계는 건너 뜁니다.)

3. 좌측의 트리 영역에 나열된 항목들 중 소프트웨어 제한 정책을 오른쪽 버튼으로 클릭하여 나타나는 팝업 메뉴에서 "새 소프트웨어 제한 정책"을 클릭합니다.

4. 오른쪽 창에 보안 수준, 추가 규칙, 강요 등의 항목이 나타나게 되는데, 이 중에서 강요를 더블 클릭합니다.

5. "다음 항목에 소프트웨어 제한 정책 적용:" 란에 "라이브러리(예: DLL)를 제외한 모든 소프트웨어 파일" 라디오 버튼이 선택되어있는지 확인합니다. 선택되어있지 않을 경우 변경합니다.

6. "다음 사용자에게 소프트웨어 제한 정책 적용: "란에 "로컬 관리자를 제외한 모든 사용자" 라디오 버튼이 선택되어있는지 확인합니다. 선택되어있지 않을 경우 변경합니다.

7. 확인 버튼을 클릭하고, 로컬 보안 설정 관리 콘솔 창을 닫습니다.

8. 작업 중인 모든 문서와 자료들을 저장하고 컴퓨터를 다시 시작한 뒤 Visual Studio 2005 SP1 설치를 다시 시도합니다.

출처: http://blogs.msdn.com/michael_howard/archive/2007/01/01/visual-studio-2005-service-pack-1-update-for-windows-vista-beta-available.aspx

크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by Windows Azure MVP 남정현 (rkttu.com)

종전의 Delphi 7.0 기반 프로젝트를 Delphi 2007으로 마이그레이션하면서 드디어 Delphi 2007에서 개인적으로 가장 쓰고 싶었던 기능인 msbuild 지원을 시험해보았다. msbuild는 .NET Framework 2.0때부터 추가된 기능으로 Unix의 make나 Java의 Ant와 같은 통합 빌드 도구이다.

마이그레이션했던 프로젝트의 규모가 상당히 크고 프로젝트의 수가 많았던 터라 "한번에 빌드하는 것"의 중요성이 참으로 크다. Delphi 2007 이전 버전의 경우에는 이런 일괄 빌드를 위하여 make 유틸리티 등을 도입하여야만 했지만 Delphi 2007은 프로젝트 파일 자체를 msbuild와 호환될 수 있게 생성하므로 바로 이용할 수 있다.

무엇보다도 Delphi 2007의 MSBUILD 지원은 Visual Studio 2005/2008 기반의 프로젝트와 같이 운용될 수 있기 때문에 그 의미가 더 크다. IDE 자체적으로 프로젝트 파일을 공유한다거나 하는 것은 아니지만 MSBUILD라는 단일 도구를 사용할 수 있다는 점이 참으로 즐거운 일이다.

크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by Windows Azure MVP 남정현 (rkttu.com)

Visual Studio 2005에서 가장 획기적인 기능으로 표현되었던 것들 중 하나는 Object Test Bench라고 불리는 창이다. 사실 이것은 수동적인 의미이기는 하나 디버깅과 단위 테스팅에 대한 또 하나의 방법으로 충분한 가치가 있다. 하지만 이 Object Test Bench와 짝이 잘 맞는 또 하나의 옛 파트너가 있다는 사실을 사람들은 잘 모르는듯 하다. Visual C++의 어셈블리 코드/메모리 상태 등을 조회함은 물론 Visual Basic 6.0 시절부터 인터프리팅 언어이기 때문에 지원해왔던 간단한 커맨드 라인까지 다양한 모습으로 우리에게 선을 보여왔던 '직접 실행 창'을 아는가? 오늘 이 글에서는 '직접 실행 창'이 Visual Studio 2005에서 어떻게 유용하게 쓰일 수 있는지를 보고자 한다. (닷넷 프레임워크 밖의 영역에 대해서는 다루지 않는 글임을 주지하기 바란다.)

이 직접 실행 창이 가지는 의미는 실로 크다. 직접 실행 창은 꼭 디버거가 돌고 있는 상태가 아니라도 닷넷 프로젝트나 닷넷 솔루션이 열려있는 시점이라면 언제나 사용이 가능하다는 것이 중요하다. 또한, 직접 실행 창의 내용이 정말 실행이 되는가 역시 문제일텐데, 이것을 어떻게 보증할까? 그렇다. 체크섬을 비교, 언제곧 내용이 바뀌면 스스로 컴파일러를 호출하여 직접 실행 창의 결과가 유효할 수 있도록 맞춘다. 코드 체크섬의 생성에 관해서 궁금하다면 C# 2.0의 새로운 지시자 기호인 #pragma를 참조하라.

직접 실행 창이 확실히 동작할 것이라는 점에 대해서는 직접 다루어보면 안다. 그렇다면 직접 실행 창에다가 대고 뭐라고 이야기를 해야 할까? 의외로 간단하다. 현재 프로젝트에서 사용하는 언어를 가지고 대화를 시작하면 된다. (컴파일 언어가 갑자기 인터프리팅 언어가 되버린다는게 달갑지 않을 수도 있지만 참고 해보기 바란다.

몇 가지 예를 들어보기로 하겠다. 여기서 사용하는 언어는 C#이 되겠다. (사실 C#에 대해서 전혀 모르는 개발자라도 냉큼 이해하기 쉬울정도로 극명한 구문이다.

* 특정 형식에 대한 정보 보기: 특정 형식의 상수, 정적 필드, 정적 프로퍼티, 부모 형식을 확인할 수 있는데 네임스페이스 이름을 포함하여 형식 이름을 써주면 대강의 정보를 나열해준다. 인터페이스의 경우 이런 정보를 명시적으로 출력해주지는 않는다. 만약 제네릭 기반의 형식이라면 형식 인수를 기입해주어야 한다. (형식 인수에 대해서도 네임스페이스 이름이 필요하다. 이런 면은 꽤 거추장스럽다.

System.String
System.Console
System.Windows.Forms.Form
System.Text.StringBuilder

* 특정 형식에 대한 인스턴스 생성하기: 역시 이것이 핵심이다. 하지만 이렇게 생성된 인스턴스를 어떻게 사용할 것인가? 그것이 바로 Object Test Bench가 되겠다. (물론 이름을 잘 알고 있다면 직접 실행 창에서 매개 변수로 전달하는 등의 일은 얼마든지 가능하다.)

다음의 스크린 샷을 참고하기 바란다. (스트링을 더하고 이것을 직접 실행 창 콘솔에 출력하는 방법까지 같이 설명하고 있다. System.Diagnostics.Debug 클래스의 WriteLine이라는 정적 메서드는 이럴 때 사용한다.)

사용자 삽입 이미지

크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by Windows Azure MVP 남정현 (rkttu.com)

Mono 1.1.x 빌드에서 C# 2.0 문법을 사용하기 위해서는 "반드시" 참고하셔야 합니다. mcs 컴파일러는 C# 1.x 문법을 다루는 컴파일러입니다. 당연히 아래의 세 강좌를 mcs 컴파일러로 구동하려고 한다면 오류를 만납니다. gmcs 컴파일러를 사용하여 컴파일하셔야 합니다.

Mono 1.1.x 빌드는 Microsoft .NET Framework 2.x와 마찬가지로 ASP .NET 2.0을 지원합니다. ASP .NET 2.0에 관한 간단한 기능 시험을 해보시려면 우선 XSP 웹 서버로 테스트해보시길 권장하고 싶습니다. ASP .NET 1.x 만을 지원하는 웹 서버는 xsp 이며, ASP .NET 2.0까지 지원하는 웹 서버는 xsp2 입니다.

최신 기술에 대한 개념 이해는 Visual Studio 2005를 활용해보시는 것이 좋을 것이라 권장하고 싶습니다. Visual Studio 2005의 무료 버전인 Express Edition 버전이 MSDN에서 배포중이니 Windows 플랫폼에서 한번 사용해 보십시오. 인터넷을 통하여 다운로드하므로 프록시에 대한 설정이 필요할 수 있고 시간이 오래 걸릴 수 있습니다. 전화 접속 모뎀에서는 권장하지 않습니다.

Visual Studio 2005 Express Edition 다운로드 페이지

http://msdn.microsoft.com/express/

좋은 하루 되십시오. ^^

크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by Windows Azure MVP 남정현 (rkttu.com)