남정현의 Windows Azure 블로그

실제 Windows Azure 계정을 신청하기 이전에, Windows Azure 기반의 개발을 테스트하기 위하여 보통 Windows Azure SDK와 함께 제공되는 Development Fabric을 이용하여 주로 디버깅하실텐데요, 잘 동작하지 않아서 힘든 경우가 있습니다.

Windows Azure Development Fabric을 이용하여 프로그래밍할 때 경험할 수 있는 문제점 중 하나는, Development Fabric으로 디버거를 연결하거나, 응용프로그램 패키지를 Deploy할 때 실패할 가능성이 "종종" 있다는 점입니다. 이 부분에 대한 간단한 트러블슈팅 가이드를 써봅니다.

1. Development Fabric으로 프로그램을 배포하려고 할 때 경고 메시지가 여러번 나타난다?

관리자 모드로 Visual Studio를 시작하고, Development Fabric으로 디버깅을 시작하려고 할 때, 빌드 출력 창에 경고 메시지가 나타나는 경우가 있습니다. 경고 메시지의 내용은 아래와 같이 나타날 수 있습니다.

Windows Azure Tools: Warning: The Windows Azure development fabric and development storage are running on a 32-bit workstation. In the cloud, Windows Azure Hosted Services run in a 64-bit environment. The use of native code execution or .Net Full Trust features such as P/Invoke may require migration to 64-bit. See http://go.microsoft.com/fwlink/?LinkId=145047 for details.

Windows Azure 환경 위에서 실제로 운영되는 OS의 아키텍처는 32비트가 아닌 64비트 버전이기 때문에, Web Role이나 Worker Role에서 사용중인 Platform Invoke 시그니처 들이 실제 운영 환경에 배포되었을 때는 맞지 않을 수도 있으니 마이그레이션을 해야 한다는 안내 문구이며, 일반 출력 창에 나타나는 메시지이기 때문에 여러번 디버깅을 시작할 경우 여러줄에 걸쳐서 문구가 쌓여서 표시될 수 있으니 걱정하지 말고 디버깅하시면 됩니다.

2. Development Fabric으로 진입하는 도중에 Visual Studio가 응답 없음 - 또는 - 마우스/키보드 동작을 받아들이지 않고 경고음만을 낸다? / Development Fabric이 기동되는듯 하다가 한참 후에 Null Reference 오류가 발생한다?

실제 디버깅에 들어가지 못하고 Visual Studio가 먹통이 되는 경우 또한 간혹있을 수 있습니다. 이는 Development Fabric이 정상적으로 초기화되지 못하였을 경우 발생할 수 있는 문제이며, Windows Azure Development Fabric을 사용하실 때에는 아래의 내용을 숙지하셔서 Development Fabric이 정확히 초기화 작업을 처리할 수 있도록 하는 것이 좋습니다.

a. 한 번에 한 Windows Azure 응용프로그램에 대해서만 디버깅하실 것을 권합니다.

b. 디버깅이 끝나면, 작업표시줄의 트레이 아이콘 표시 영역에 나타난 Windows Azure Development Fabric 프로그램을 직접 종료하여 주십시오. 가급적, 디버깅이 끝나면 Windows Azure Simulation Service와 Storage Service는 함께 종료해야 하며, 프로그램을 직접 닫으려할 때, 기동 중인 서비스를 모두 중단시킬지 안내하는 창이 나타나면 중단하도록 선택하여 주십시오.

문제가 발생하였을 경우에는 다음과 같이 조치하실 수 있습니다.

a. 실행 중인 Visual Studio를 모두 종료하시고, Windows Azure SDK v1.1 프로그램 그룹에서 Development Fabric 아이콘을 더블 클릭하여 Standalone으로 Development Fabric을 시작합니다.

b. Storage 서비스의 기동 상태를 Windows Azure 아이콘을 오른쪽 버튼으로 클릭하여 확인하고, 시작되지 않았을 경우 강제로 시작을 시도합니다. 시작되지 않을 경우, SQL 서버 인스턴스가 시스템에서 실행 중인 것이 있는지 확인해 봅니다.

c. Show Development Storage UI 메뉴 항목을 클릭하고, 나타나는 화면에서 "Reset" 버튼을 클릭하여 스토리지 설정을 초기화하도록 예약합니다.

d. Windows Azure Development Fabric을 종료하며, 이 때 모든 서비스를 중단할지 묻는 메시지 박스에서 중단하도록 선택합니다.

e. Visual Studio를 열어서 빌드할 때, "정리" 기능을 이용하여 빌드 산출물들을 모두 제거하도록 한 후 다시 시도합니다.

3. Windows Azure로 응용프로그램을 개발하면서 인텔리센스 기능을 사용하려할 때 Visual Studio 2010이 갑자기 충돌을 일으키며 종료된다?

Visual Studio 2010 RC 패치 (KB980610)가 발표되었습니다.

위의 글에서 소개하는 KB980610 패치를 시스템에 설치하시기 바랍니다.

짧은 글이었지만, 도움이 되셨기를 바라며 글을 마무리해봅니다. 감사합니다. :-)

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

ASP.NET 프로그래밍을 하면서 전부터 항상 궁금했던 문제가 하나 있었는데 유독 Windows XP 서비스 팩 3 이후부터, 그리고 Windows Vista부터는 Firefox를 이용해서 Visual Studio ASP.NET 프로젝트를 디버깅하려고 하면 "극단적으로" 브라우징 속도가 급감하는 문제가 있었습니다. 내 컴퓨터만의 고유한 문제가 아닐까 싶어서 처음에는 무시했는데 해결이 될만한 조치 사항들을 모두 적용했어도 별다른 차도가 없어서 같은 문제점이 있는 사람이 있지는 않을까 구글을 통해서 검색해 보았습니다. 그리고 역시 같은 문제로 고민하고 있었고 이에 대한 해결책을 쉽게 찾을 수 있었습니다.

Firefox가 느려지는 이유는 다름이 아닌 IPv6에 관한 문제였습니다. Windows XP SP3 이후부터나 Windows Vista부터는 공식적으로 IPv4와 IPv6를 동시에 이용할 수 있게 되었는데 이에 관한 Firefox의 고유한 문제였던것으로 보입니다. Firefox의 고급 설정을 이용해서 IPv6 기반 탐색을 사용하지 않게 하여 문제를 해결할 수 있었습니다만, IPv6 서비스를 Firefox로 이용하는데는 불편함이 있을 듯 합니다.

• Firefox 주소 입력란에 about:config 이라고 입력하고 Enter키를 누릅니다.
• 고급 설정을 사용하겠느냐는 질문에 동의합니다.
• 주소 표시줄/도구모음 입력란 바로 아래의 필터 입력란에 network.dns.disableIPv6 를 입력합니다. 입력하다보면 위의 항목이 자동으로 필터링되어 하단에 나타나는 것도 볼 수 있습니다.
• 정확한 항목을 찾으면 값을 false에서 true로 바꾸고 그 상태에서 모든 Firefox 브라우저 창을 닫은 뒤 다시 엽니다.

출처: http://code.commongroove.com/archive/2007/10/27/fix-firefox-slowdown-on-vista-while-debugging-localhost.aspx

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

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

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

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

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

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

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

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

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.