[ClouDeveloper News – Azure Edition] 2017년 1월 5일

클라우드 컴퓨팅을 중심으로 관련된 여러 기술과 업계 소식을 매주 전하는 ClouDeveloper News를 시작합니다. 파일럿 프로그램으로 구상하여 운영 중에 있으며 추후 여러 피드백과 의견 수렴을 통하여 프로그램의 틀을 갖추어 나갈 예정이오니 많은 관심과 구독을 부탁드립니다.

이번주 포커스/주요 소식

Saturday Azure Live 1701 (등록 바로가기)

Saturday Azure Live 1701이 1월 14일(토) 오후 2시부터 서울 강남 토즈1호점에서 열립니다. Microsoft Azure Korea 페이스북 그룹에서 진행하는 Saturday Azure Live는 매월 둘째 주 토요일마다 진행하는 Microsoft Azure의 기술 정보를 함께 공유하는 정기 세미나입니다. Azure에 관해 정보를 얻을 수 있을 뿐 아니라, 발표하고 싶은 주제가 있다면 스피커로! 경험담을 공유하고 싶다면 라이트닝 토크까지! 함께 하실 수 있습니다.

Agenda
Overview – 세션 소개 (발표자: Azure MVP 남정현)
Session 1 – Microsoft Conversation as a Service 소개 (발표자: 한국 마이크로소프트, 오일석 에반젤리스트)
Session 2 – Azure WebApp 개념원리 (발표자: (주)바풀 CTO, Azure MVP 김영재)
Session 3 – DevOps와 Hybrid Cloud (발표자: 한국 Azure 사용자 그룹, 김세준)

Azure Functions deprecating preview versions – 구 버전의 Azure Function을 사용하시는 경우 2017년 2월 1일 전에 1.0 버전 이상으로 업그레이드해야 합니다.

General availability: Larger block blobs in Azure Storage – Azure Storage에 더 큰 크기의 Block BLOB 업로드가 지원됩니다. 195GB에서 최대 4.77TB까지 업로드가 가능하며, 모든 Azure 리젼에서 사용할 수 있습니다.

MSRT December 2016 addresses Clodaconas, which serves unsolicited ads through DNS hijacking – Microsoft 악성 코드 제거 도구의 새 버전이 업데이트되면서, DNS 하이재킹을 통한 MITM 공격을 유발할 가능성이 있는 악성 코드를 제거할 수 있는 기능이 새로 추가되었습니다.

Several New Azure Services now available in UK – 영국 Azure 리젼에서 다수의 Azure 서비스를 새롭게 사용할 수 있게 되었다는 소식입니다. 이 중에는 Azure Function, Power BI, Power BI Embedded, DocumentDB 도 포함되어있습니다.

Mark Russinovich Azure CTO에게 Sysinternals를 이용하여 성공적으로 문제를 해결했던 사례를 스크린샷과 로그를 포함하여 보내면, Sysinternals 책을 저자 서명과 함께 배송해주는 이벤트를 진행하고 있습니다. 트위터 전문

커뮤니티 소식

Azure 서비스 공지 사항

아티클, 기고

새로운 제품 및 서비스

활용 및 노하우

웹 캐스트

ClouDeveloper 페이스북 페이지에 댓글로 의견을 남겨주시면 뉴스 발행 및 각종 정보 전달에 반영하도록 하겠습니다. 고맙습니다.

의견 남기기: https://fb.com/cloudeveloper

[ClouDeveloper News – Azure Edition] 2016년 12월 1일

클라우드 컴퓨팅을 중심으로 관련된 여러 기술과 업계 소식을 매주 전하는 ClouDeveloper News를 시작합니다. 파일럿 프로그램으로 구상하여 운영 중에 있으며 추후 여러 피드백과 의견 수렴을 통하여 프로그램의 틀을 갖추어 나갈 예정이오니 많은 관심과 구독을 부탁드립니다.

Azure 서비스 공지 사항

새로운 제품 및 서비스

활용 및 노하우

웹 캐스트

  • Leverage the cloud for modern business: 무료 온디맨트 웹 캐스트로 기존 비즈니스에서 클라우드를 어떻게 접목할 수 있는지에 대한 일반론을 설명합니다.
  • Get started with Xamarin and Azure Webinar: 한국 시간으로 12월 3일 토요일 새벽 2시부터 진행되는 웹 캐스트로 Xamarin 개발 플랫폼과 Azure를 연동하는 자세한 방법을 설명합니다.
  • SQL Server on Linux: High availability and security: SQL Server on Linux가 Windows 버전과 같이 고가용성과 안정성, 그리고 보안을 준수할 수 있는지 궁금하기도하고 불확실하다는 생각을 가지고 계시다면 이 웹 캐스트를 확인해보실 것을 추천합니다.
  • Microsoft Ignite On-Demand: 지난 가을에 열린 Microsoft Ignite 2016의 모든 세션을 VOD로 시청할 수 있는 카탈로그 페이지가 열렸습니다.
  • Connect(); 2016 On-Demand: 지난 11월에 열린 Connect(); 2016의 모든 세션을 VOD로 시청할 수 있는 카탈로그 페이지가 열렸습니다.

서드파티 소식

  • Protect all of your public and hybrid cloud workloads on with Security: 엔드포인트 보안 및 침입 차단, VPN 등 다양한 보안 솔루션 포트폴리오를 제공하는 Fortinet이 Azure Platform의 각 영역에 대한 보안 솔루션을 제공합니다. https://www.fortinet.com/azure 에서 확인해보실 수 있습니다.

ClouDeveloper 페이스북 페이지에 댓글로 의견을 남겨주시면 뉴스 발행 및 각종 정보 전달에 반영하도록 하겠습니다. 고맙습니다.

의견 남기기: https://fb.com/cloudeveloper

ubuntu 14.04에서 asp.net vnext 설치하고 사용하기

업데이트: mono 3.8이 9월 초에 새로 릴리즈되었으며 이 내용을 기초로 새로 업데이트한 아티클을 올렸습니다.


이 블로그 포스트의 내용은 아래 두 블로그 포스트의 내용을 기초로 작성한 것임을 말씀드립니다.
•http://graemechristie.github.io/graemechristie/blog/2014/05/26/asp-dot-net-vnext-on-osx-and-linux/
•http://www.rocko.me/install-mono-3-4-ubuntu/


또한 이 블로그 포스트는 MS Azure Virtual Machine과 Ubuntu Server 14.04 버전을 최초 설치했을 때의 상태를 기준으로 작성된 것이며, 이 블로그 글을 작성하는 2014년 8월 현재 ASP.NET vNext가 정식 출시 전임을 말씀드립니다.


주의: 실제 배포 환경에서 이 블로그 포스트의 내용을 활용하시는 것은 매우 위험합니다.


 


 


ASP.NET vNext는 기존의 System.Web 기반의 레거시 웹 개발 프레임워크에서 탈피하고자 하는 MS의 강력한 의지의 결과물인듯 합니다. 이전에는 상상하기 어려웠고, MS의 손이 아닌 오픈 소스 그룹 (Mono의 System.Web 구현)이나 써드 파티 회사 (Grasshoper 같은)에 의한 제한적인 수준의 작업 결과물일 뿐이었던 ASP.NET의 이식성이 이제서야 완벽함을 기할 수 있게 되었습니다.


이 블로그 포스트에서는 ASP.NET vNext를 우분투 서버 14.04에서 설치해본 과정을 기록하여 그것을 토대로 작성하였습니다. ASP.NET vNext의 발전 가능성을 살펴보시고, 여러 이야기를 나눌 수 있지 않을까 하여 기록해봅니다.


사전 준비 작업


ASP.NET vNext는 Windows 서버 환경에서는 손수 기존에 설치된 .NET Framework를 대체하는 K Runtime을 사용하여, 어느 버전의 K Runtime을 사용할 것인지 패키지 레벨에서 정의할 수 있는 것이 특징이었는데, 리눅스의 경우 기본 실행 엔진은 현재는 Mono를 기반으로 하고 있는 것이 특징입니다. 그럼에도 불구하고 K Runtime이 가지는 영역이 엄연히 있고, 아마 핵심 실행 엔진만 현재는 Mono를 기반으로 실행되는 것 같습니다.


그런 이유로 Mono의 최신 버전을 시스템에 설치해야 하는데, 안타깝게도 Ubuntu 14.04에 등록된 Mono 패키지의 최신 버전은 ASP.NET vNext를 실행하기 위해 필요한 버전과 격차가 상당히 크고, 또한 지원되지 않습니다. 그래서 제일 먼저 해야 할 일은 github에 올라와있는 Mono 소스 코드를 내려 받아 컴파일하고 새 버전으로 바꾸는 작업입니다.


우선은 기존에 Mono 런타임을 설치했던 이력이 있을 경우를 고려하여 Mono와 관련된 모든 패키지를 제거해야 하는데, 아래 명령어로 간단히 제거할 수 있습니다.



sudo apt-get -y purge mono-*


그 다음, Mono를 설치하기 위하여 필요한 이미징 라이브러리 관련 종속성을 해결해주어야 하는데, 필요한 패키지들중 상당수는 Ubuntu 14.04에서 직접 지원하지 않거나 오래된 버전으로 취급하여 apt-get으로 직접 설치가 어려운 패키지들입니다. 따라서, 이들 패키지들을 수동으로 내려 받아 설치하는 작업이 필요한데, 아래 명령어를 복사하여 하나씩 실행하시면 되겠습니다.



wget http://security.ubuntu.com/ubuntu/pool/main/j/jbigkit/libjbig0_2.0-2ubuntu1.13.10.1_amd64.deb
 wget http://security.ubuntu.com/ubuntu/pool/main/libj/libjpeg-turbo/libjpeg-turbo8_1.3.0-0ubuntu1.1_amd64.deb
 wget http://mirrors.kernel.org/ubuntu/pool/main/libj/libjpeg8-empty/libjpeg8_8c-2ubuntu8_amd64.deb
 wget http://mirrors.kernel.org/ubuntu/pool/universe/t/tiff3/libtiff4_3.9.7-2ubuntu1_amd64.deb
 wget http://mirrors.kernel.org/ubuntu/pool/universe/t/tiff3/libtiffxx0c2_3.9.7-2ubuntu1_amd64.deb
 wget http://mirrors.kernel.org/ubuntu/pool/main/libj/libjpeg8-empty/libjpeg-dev_8c-2ubuntu8_amd64.deb
 wget http://security.ubuntu.com/ubuntu/pool/main/j/jbigkit/libjbig-dev_2.0-2ubuntu1.13.10.1_amd64.deb
 wget http://security.ubuntu.com/ubuntu/pool/main/libj/libjpeg-turbo/libjpeg-turbo8-dev_1.3.0-0ubuntu1.1_amd64.deb
 wget http://mirrors.kernel.org/ubuntu/pool/main/libj/libjpeg8-empty/libjpeg8-dev_8c-2ubuntu8_amd64.deb
 wget http://mirrors.kernel.org/ubuntu/pool/main/libj/libjpeg8-empty/libjpeg-dev_8c-2ubuntu8_amd64.deb
 wget http://mirrors.kernel.org/ubuntu/pool/universe/t/tiff3/libtiff4-dev_3.9.7-2ubuntu1_amd64.deb


sudo dpkg -i libjbig0_2.0-2ubuntu1.13.10.1_amd64.deb
 sudo dpkg -i libjpeg-turbo8_1.3.0-0ubuntu1.1_amd64.deb
 sudo dpkg -i libjpeg8_8c-2ubuntu8_amd64.deb
 sudo dpkg -i libtiff4_3.9.7-2ubuntu1_amd64.deb
 sudo dpkg -i libtiffxx0c2_3.9.7-2ubuntu1_amd64.deb
 sudo dpkg -i libjbig-dev_2.0-2ubuntu1.13.10.1_amd64.deb
 sudo dpkg -i libjpeg-turbo8-dev_1.3.0-0ubuntu1.1_amd64.deb
 sudo dpkg -i libjpeg8-dev_8c-2ubuntu8_amd64.deb
 sudo dpkg -i libjpeg-dev_8c-2ubuntu8_amd64.deb
 sudo dpkg -i libtiff4-dev_3.9.7-2ubuntu1_amd64.deb


Mono 최신 버전 설치하기


이제 기본 준비 작업은 끝났고, 필요한 패키지들을 한꺼번에 설치할 차례입니다. 아래 명령어를 입력하도록 합니다.



sudo apt-get -y install libpng3 libpng3-dev libtool libexif12 libexif-dev libgif4 libgif-dev libpango1.0-dev libatk1.0-dev libgtk-3-0 libgtk-3-dev bison automake autoconf make gcc gtk-sharp2 build-essential xorg-dev libfreetype6 libfontconfig libfontconfig-dev gettext libglib2.0-dev git libjpeg-dev libjpeg8-dev libjpeg-turbo8-dev g++ unzip


쉬운 설명을 위하여, 사용자 프로필 디렉터리에서 설치를 진행한다고 가정하겠습니다.



cd ~


설치가 모두 되고 나면, mono git 리포지터리에서 libgdiplus 소스를 복사합니다.



git clone https://github.com/mono/libgdiplus.git


받은 소스 디렉터리로 이동합니다.



cd ~/libgdiplus


그리고 각종 설정 검사 및 헤더 구성을 진행합니다. 주의할 것은 공식 가이드에서는 –prefix=/usr/local로 소개하고 있으나 우분투의 경우 아래와 같이 /usr을 기준으로 잡아야 합니다.



./autogen.sh –prefix=/usr


구성이 끝나면 컴파일을 하도록 합니다.



make


컴파일 중 특별한 오류 메시지가 없었다면 시스템에 설치하도록 합니다.



sudo make install


이제 다시 홈 디렉터리로 이동합니다.



cd ~


mono 소스를 컴파일하는 과정 중에는 재귀적으로 mcs 컴파일러가 필요합니다. 이를 위하여 mono-gmcs 패키지를 구 버전이지만 우선 설치해야 합니다.



sudo apt-get -y install mono-gmcs


설치가 끝나면, 이제 mono 소스를 복사하도록 합니다.



git clone git://github.com/mono/mono.git
 cd mono


libgdiplus 때와 마찬가지로 prefix 설정에 유의하여 자동 구성을 진행합니다. 자동 구성 중에 다른 git 리포지터리에서 추가로 관련된 소스를 내려받기도 합니다.



./autogen.sh –prefix=/usr


모든 구성이 끝나면 컴파일하고 설치하도록 합니다.



make
 sudo make install


모든 설치가 다 끝났다면, 새 버전 (2014년 8월 현재 3.8)으로 업데이트가 잘 되었는지 확인해보도록 합니다.



mono –version
 mcs –version


위의 명령어에서 새 버전으로 표시가 된다면 ASP.NET vNext를 설치할 준비가 다 끝난 것입니다. 이제 다시 홈 디렉터리로 이동합니다.



cd ~


계속 하기 전에, 라이브러리 경로에 관련된 환경 변수를 하나 설정해주는 것이 좋습니다. 아래 명령어를 실행하여 LD_LIBRARY_PATH 환경 변수를 설정하도록 합니다.



export LD_LIBRARY_PATH=/usr/lib:/usr/local/lib:$LD_LIBRARY_PATH


K Runtime과 ASP.NET vNext 설치하기


이제 중요한 부분이 남았습니다. K Runtime과 ASP.NET vNext를 설치하는 것이 남았는데, 앞의 과정보다 시간도 짧게 걸리고 비교적 쉽습니다.


ASP.NET vNext의 전체 소스 코드를 복사하지 않고 필요한 셸 스크립트 파일인 kvminstall.sh 파일만 가져오도록 합니다. 아래 명령어를 홈 디렉터리에서 실행합니다.



curl https://raw.githubusercontent.com/aspnet/Home/master/kvminstall.sh | sh


경로 설정을 맞추기 위하여, 아래 명령어를 실행합니다.



source ~/.kre/kvm/kvm.sh


이제 KVM을 사용자 프로필 디렉터리 아래의 .kre 폴더에 설치하기 위해, 다음 명령어를 실행합니다.



kvm upgrade


기본적인 실행 환경이 준비되었고, K Package Manager (달리 표현하면 K Package Manager의 실행을 담당하는 Mono)가 통신해야 할 사이트들의 HTTPS 인증서를 추가한 다음, 시스템에 설치된 루트 인증서를 가져올 수 있도록 하기 위하여 아래 명령어들을 실행합니다. 확인 프롬프트가 나타나면 여러번 yes를 입력하여 모든 필요한 인증서 및 인증서 체인을 가져오도록 합니다.



sudo certmgr -ssl -m https://go.microsoft.com
 sudo certmgr -ssl -m https://nugetgallery.blob.core.windows.net
 sudo certmgr -ssl -m https://nuget.org
 sudo certmgr -ssl -m https://myget.org
 mozroots –import –sync


Hello, World! 찍어보기


모든 설치가 끝났습니다. 예제 소스 코드를 가져와서 실행하기 위하여, David Fowler님의 github 리포지터리에 올라와있는 ASP.NET vNext 샘플을 이용하도록 하겠습니다. 공식 웹 사이트에 있는 샘플은 HTTPAPI를 기반으로 하는 것이어서 Nowin Factory로 교체하여 실행할 수 있지만 쉬운 설명을 위해 David Fowler님의 예제를 가져와서 대신 설명함을 말씀드립니다.


홈 디렉터리로 이동합니다.



cd ~


그리고 아래 명령어를 실행하여 콘솔 프로젝트 샘플 소스를 복사합니다.



git clone https://github.com/davidfowl/HelloWorldVNext.git


해당 디렉터리로 이동하여 다음 순서대로 명령어를 입력하여 Hello World! 메시지가 나타나는지 확인합니다.



cd ~/HelloWorldVNext/src/helloworld
 kpm restore
 k run


여기서 kpm restore 명령은 해당 예제를 실행하기 위하여 필요하다고 project.json에서 명시한 NuGet 패키지들을 전부 시스템에 설치하는 과정을 포함하며, 최초 한 번만 실행하면 됩니다. 그리고 k run 명령은 project.json 또는 그 상위에 정의되어있는 run 명령어를 실행한다는 의미이며, 보통 run 명령어는 재정의하지 않는 한 Main 메서드를 찾아 실행하는 것과 의미가 같습니다.


받은 프로젝트 디렉터리 상의 파일을 보면 흥미로운 것이, 이전처럼 mcs (gmcs)를 호출하여 exe 파일을 만들지 않았는데도 소스 상태에서 바로 k run이라는 명령어를 넣으면 프로그램이 시작된다는 점입니다. 이런 방식의 닷넷 응용프로그램은 웹 환경에서 큰 강점을 발휘하게 될 것입니다.


ASP.NET vNext 샘플 웹 프로젝트 띄워보기


이제 핵심입니다. ASP.NET vNext 샘플 웹 프로젝트를 띄워볼 차례인데, 다음과 같이 명령어를 입력하도록 합니다. 물론, 진행의 편의를 위해 홈 디렉터리에서 실행하는 것이 좋겠습니다.



git clone https://github.com/davidfowl/HelloWorldVNext.git
 cd ~/HelloWorldVNext/src/helloworldweb
 kpm restore
 k web


예제에 같이 들어있는 Nowin Factory 프로젝트의 코드를 보면 TCP/5000 포트를 웹 리스너 포트로 사용하고 있습니다. 밖에서 호스트 이름과 함께 5000번 포트로 접속하면 웹 페이지가 나타나는 것을 볼 수 있습니다. 그리고 서버를 종료하려면 콘솔에서 아무 키나 누르면 종료가 됩니다.


만약에 원격에서 좀 더 지속적으로 서버의 성능을 측정해보고 싶으시다면 screen 유틸리티를 사용하여 세션을 분리하신 상태에서 위의 명령어를 입력하고, 서버가 떠 있을 때 Ctrl 키를 누른 상태에서 빠르게 a, a, d 키를 누르면 세션이 분리되어 계속 살아있는 서버가 만들어집니다. 이 상태에서 Apache Bench (AB)등의 유틸리티를 사용하여 부하 테스트 등을 해보시는 것도 의미가 있을 것입니다.


참고로, NAT 환경이나 퍼블릭 클라우드 환경에서는 대표 IP 주소에 대한 외부 방화벽 설정을 열어주셔야 밖에서도 접속이 가능합니다.


마무리


아직 ASP.NET MVC 6나 다른 기술들이 완전히 준비된 것은 아니지만, 이 정도만 하더라도 ASP.NET은 더 이상 윈도 OS 안에서만 사용 가능한 기술이 아니라는 것을 증명하는데에는 손색이 없을 것입니다. 더 많은 가능성과 잠재력을 포함하는 최신 기술이 곧 나타나게 될 것이 무척 기대가 됩니다.


만약 기존에 ASP.NET 웹 사이트를 개발해 놓은 것이 있다면, ASP.NET vNext로 프로젝트를 마이그레이션하면서 플랫폼에 중립적으로 동작하는 코드로 업데이트하는 프로젝트를 한 번 진행함으로서 그리 어렵지 않게 멀티 플랫폼으로 ASP.NET 웹 응용프로그램을 포팅하실 수 있을 것입니다.


앞으로 더 자세한 정보와 상세한 내용들, 그리고 활용 방안들도 블로그 포스트로 전할 수 있도록 하겠습니다.

ASP.NET Custom Loader의 원리

ASP.NET Custom Loader (코드 네임 Helios)는 기존의 System.Web 기반의 전통적인 ASP.NET 프레임워크를 대체하는 기술로, IIS 파이프라인에 직접 관여하여 System.Web에 의존적이지 않은 최신 ASP.NET 개발 프레임워크들 (OWIN, Nancy, FubuMVC 같은)의 실행에 필요하지 않은 System.Web 및 관련 파이프라인을 생략하고 직접 이들 프레임워크를 중개할 수 있도록 도와주는 도우미입니다.


 


 


이 글을 작성 중인 2014년 8월 현재 최신 버전은 1.0 알파 버전으로, 조만간 출시될 ASP.NET vNext와 함께 릴리즈가 될 것으로 예상되는 기술입니다. 현재는 Windows Server 2008 R2 및 Windows 7 이상의 운영 체제를 정식으로 지원하며, IIS 및 IIS Express의 경우 7.5 버전 이상을 지원합니다. 정식 출시에 맞추어, Windows Server 2008과 Windows Vista, 그리고 IIS 7도 지원 대상에 포함될 것으로 예상됩니다.


ASP.NET Custom Loader의 실행 성능 개선 효과에 대해서는 여러 블로그 아티클이 있지만, http://blogs.msdn.com/b/webdev/archive/2014/02/18/introducing-asp-net-project-helios.aspx 의 내용을 살펴보실 것을 권합니다.


이 글에서는 ASP.NET Custom Loader의 동작 원리에 대해서 간단하게 설명을 하려고 합니다.


ASP.NET Custom Loader의 구성 파일 내역


ASP.NET Custom Loader는 다음과 같이 구성됩니다.
•AspNet.Loader.dll
•Microsoft.AspNet.Loader.IIS.dll
•Microsoft.AspNet.Loader.IIS.xml
•x86Microsoft.AspNet.Loader.IIS.Interop.dll
•amd64Microsoft.AspNet.Loader.IIS.Interop.dll


일단 위의 파일들이 bin 폴더에 복사되면, 특별히 web.config에서 수정하는 내용 없이 곧바로 기능이 활성화됩니다. 또한 이름에서도 알 수 있듯이, 지원 가능한 아키텍처는 x86과 amd64 아키텍처만 가능하며, 아이태니엄 및 ARM 아키텍처는 지원되지 않습니다.


실제 웹 프레임워크와의 연결


이제 중요한 것은 위의 Loader가 그 다음으로 주선할 웹 프레임워크를 지정하는 과정인데, 각 웹 프레임워크 별로 HttpApplicationAttribute를 어셈블리 수준에 적용하여 자신들의 웹 프레임워크 기술을 사용하는 개발자들을 위한 부트스트랩을 제공합니다. ASP.NET Web Loader는 이 정보를 찾아 연결을 시도하게 됩니다.


대강 아래와 같은 모양새를 가진 부트스트랩이 있어야 합니다. (물론 필요하다면 직접 만들 수도 있습니다.)


[assembly: HttpApplication(typeof(YourClass))]
 public class YourClass : HttpApplicationBase
 {
 }


이런 목적에 부합하는 기능과 관련된 종속 기능들을 OWIN에서는 아래 어셈블리들에 나누어 제공하고 있습니다.
•Microsoft.Owin.Host.IIS.dll
•Microsoft.Owin.Host.IIS.xml
•Microsoft.Owin.Host.IIS.Security.dll
•Microsoft.Owin.Host.IIS.Security.xml
•Microsoft.Owin.Hosting.dll
•Microsoft.Owin.Hosting.xml


기존에 OWIN 기반으로 배포한 응용프로그램이 있다면 ASP.NET Custom Loader를 배포한 다음 위의 어셈블리 파일들을 추가로 복사해야 ASP.NET Loader가 OWIN 시작 클래스를 연결해줄 수 있습니다.


주의 사항


이 글을 작성하는 현 시점에서 ASP.NET Custom Loader는 알파 버전을 릴리즈한 상태입니다. 그리고 이에 관하여 다음의 제약 사항들이 있습니다.
•Windows Server 2008과 Windows Vista, 즉 IIS 7의 경우 로더 실행 시 보안 알고리즘 관련 알 수 없는 HRESULT가 발생했다는 예외가 나타나면서 초기화가 이루어지지 않습니다. 공식 개발팀의 언급에 따르면, 정식 버전에서 해결할 예정이라고 합니다.
•Web.config에 configSource 애트리뷰트를 사용하여 나누어놓은 구성 파일이 있을 경우, 잘못된 경로 문자열이라면서 역시 Helios 초기화 도중 예외가 발생합니다. 불편하더라도 알파 버전의 테스트를 위해서는 구성 파일을 web.config 하나로 통합하셔야 테스트할 수 있습니다.


위와 같은 문제점에도 불구하고, 상당한 수준의 성능 개선은 개인적으로 만족스러웠습니다. 🙂

Visual Studio 2013에서 ASP.NET 프로젝트가 만들어지지 않는 경우

Visual Studio 2013에서는 One ASP.NET이라는 새로운 형태의 프로젝트 생성 방식을 제공하고 있습니다. 이전에는 ASP.NET MVC, Web Form, Web Page, Web API가 각기 다른 프로젝트로 분리되어있어서 구성하기에 불편한 점이 많았습니다만 2013부터는 한 위치에서 동시에 여러 ASP.NET 웹 스택을 선택하고 조합할 수 있게 되었으며, 인증 시나리오도 Windows Identity Foundation, 기본 인증, 소셜 네트워크 기반 인증 등을 지원할 수 있는 옵션이 추가되었습니다.


그런데 이러한 특성 때문에, 처음부터 NuGet 패키지 관리자에 대한 의존성이 필수가 되었습니다. 그래서 간혹 어떤 컴퓨터에서는 Visual Studio 2013으로 ASP.NET 프로젝트를 생성하려 할 때 다음과 같은 오류 메시지가 나타나기도 합니다.


지정된 파일을 찾을 수 없습니다. (예외가 발생한 HRESULT: 0x80070002) 



오류: 이 템플릿에서 구성 요소 어셈블리 ‘NuGet.VisualStudio.Interop, Version=1.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a’을(를) 로드하려고 했습니다. 이 문제에 대한 자세한 정보 및 이 템플릿을 활성화하는 방법에 대한 정보는 “프로젝트 템플릿 사용자 지정”의 설명서를 참조하십시오. 



위와 같은 오류 메시지가 나타나는 것은 NuGet Package Manager 애드인이 설치되어있지 않기 때문이며, ASP.NET 프로젝트 생성과 동시에 인터넷 상에서 NuGet Package Manager를 이용하여 프로젝트 구성에 필요한 각종 라이브러리들 (jQuery, ANTLRv3 등)을 내려받으려고 시도하기 때문입니다.


문제를 진단하기 위하여, Visual Studio에 현재 설치된 확장 및 업데이트 내역을 확인합니다. 메뉴에서 아래와 같이 실행하면 해당 항목을 찾을 수 있습니다.


도구(T) – 확장 및 업데이트(U) 클릭 



온라인 – Visual Studio 갤러리 선택 – 검색어에 nuget 입력 후 Enter 키 누름 – “NuGet Package Manager for Visual Studio” 선택 – 다운로드 버튼 클릭 



다운로드 진행 – EULA 동의 – 설치 – 아래와 같이 화면이 나타나면 하단의 “지금 다시 시작(R)” 버튼 클릭



이제 ASP.NET 프로젝트를 다시 생성하면 정상적으로 생성이 완료될 것입니다.

ASP.NET을 이용한 이식성 높은 클라우드 서비스 개발하기

요즈음은 Infrastructure as a Service를 이용하여 VM의 Mobility를 통한 클라우드 서비스 사업자 간 이동 및 이전이 요즈음 주목 받고 있습니다. 익히 잘 알려진대로, Windows Azure의 경우 사설 혹은 기업 데이터센터 구축을 위하여 사용하는 Hyper-V 환경의 가상 PC를 Windows Azure로 진출시키거나 역으로 가져오는 등의 기능은 상당히 잘 알려져 있어서 많이들 이용하고 계실 것 같습니다.


그런데 Platform as a Service는 이런 부분에서 확실한 이동성을 보장하기 많이 어렵다는 것이 문제가 됩니다. 특히 비즈니스 로직을 내부에 많이 포함하고 있는 클라우드 응용프로그램일 수록 해당 클라우드 서비스에 종속적이기 때문에 클라우드 사업자간 이동이 훨씬 더 어렵습니다. 물론, 이를 극복하기 위하여 Dependency Injection이나 Inversion of Control을 이용하여 클라우드 사업자들이 제공하는 SDK의 공통 분모를 추출하여 그 대상으로 삼는 것도 가능한 전략이기는 하겠습니다만 사실 쉽지 않습니다.


좀 더 현실적이고 직관적인 방법이 없을까 많이들 고민하시는 데에 어느정도 도움이 될까 하여 한 가지 방안을 제시해 보겠습니다. 바로 ASP.NET과 Web Deploy를 이용한 개발입니다.


왜 ASP.NET과 Web Deploy를 사용하는가 – ASP.NET을 사용할 수 있는 환경의 다양성


PHP, Node.js, Ruby on Rails 등 웹 세계에서 유명한 프레임워크나 개발 환경이 많이 있습니다만 상대적으로 ASP.NET은 늘 저평가되어있습니다. 특히 ASP.NET을 버전 1.0~2.0 시절의 Web Form과 연결하여 선입견을 가지는 경우가 무척 많습니다. 그렇지만 이전부터 필자가 계속 강조해왔던 NuGet, Web Developer Express 등 다양한 OSS에 친화적인 기술들과의 결합과 ASP.NET MVC의 등장은 이 선입견에 묻혀서 거의 알려지지 않은 경우가 많습니다. (특히 국내에서는 더욱 그렇지요.)


그러나 이런 와중에 생각보다 ASP.NET의 입지는 넓습니다. Microsoft 기술과 가장 친화적이지 않을 것 같은 Amazon의 BeansTalk가 ASP.NET Web Deploy 패키지를 사용한 PaaS 배포 기법을 전면에서 지원하고 있으며, 사용 중인 환경이 Linux인 경우 다양한 방법으로 Mono ASP.NET 런타임과 결합하여 ASP.NET 웹 사이트를 호스팅할 수 있습니다. 그리고 Windows Azure는 Web Site와 Cloud Service를 이용하여 각각 웹 사이트를 호스팅할 수 있는 방법을 제공합니다. 멀리 가지 않아도 시중에 나와있는 웹 호스팅 서비스는 모두 FTP를 통한 ASP.NET 웹 사이트 배포까지 지원합니다. 수단은 얼마든지 많고, 남는 것은 전략의 수립에 관한 부분만이 남는 셈입니다.


왜 ASP.NET과 Web Deploy를 사용하는가 – 단일 코드 베이스 유지


ASP.NET을 이용하여 독립적으로 실행할 수 있는 Web Application Project를 만들어두면, Public Cloud만을 이용해서 서비스를 구축하였을 때 간간히 문제가 발생하는 특정 데이터센터, 혹은 특정 클라우드 서비스의 장애로 인해서 전체 서비스가 중단되는 사고로부터 좀 더 자유로워질 수 있습니다.


여러 위치에 분산된 응용프로그램을 배포하는 것은 기본적으로 매우 어려운 작업입니다. 그리고 이 어려운 작업의 난해함을 지수승으로 더 복잡하게 만드는 것은 바로 클라우드 서비스 사업자 간의 고유한 기능 집합 때문입니다. 이 문제를 해결하기 위해서는 사업자 간 이해 관계가 비교적 덜 연결되어있으면서도 구성의 차이가 거의 없는 기술을 택하는 것이 바람직한데, 여기에 들 수 있는 후보로는 ASP.NET을 포함하여 다수의 기술들이 있습니다. 그 중에서도 오늘 소개하려는 ASP.NET은 수준 높은 IDE 지원과 다양한 OSS 프로젝트와의 연계가 가능하기 때문에 유용한 점이 많습니다.


왜 ASP.NET과 Web Deploy를 사용하는가 – 배포 시의 문제점을 최소화


기능 상의 유용함 이외에도, 스스로 스케줄링을 해야 하는 Daemon Type의 서비스 프로세스가 아닌 RPC나 REST 형태의 시스템일 경우 ASP.NET을 사용하여 프로그래밍하고 Visual Studio의 지원을 받을 때의 큰 이점이 하나 더 있습니다. 바로 배포 시의 문제점을 최소화할 수 있다는 것입니다.


ASP.NET Web Deploy 및 관련 프로세스들은 패키지로 만들 때, 종속성에 관련된 모든 문제를 예방할 수 있도록, 웹 프로젝트와 연관성이 있는 모든 종속성 관계 상의 파일을 자동으로 복사하여 패키지에 포함시키는 정책을 사용합니다. 이러한 특징 때문에, ASP.NET MVC나 Razor의 최신 버전이 처음 .NET Framework가 배포된 이후에 바뀌더라도 최신 기능을 사용하면서도 배포 상의 DLL 버전 차로 인한 문제가 발생할 가능성이 높지 않습니다.


클라우드 서비스 별 배포 방법 – Amazon BeansTalk


우선 Amazon BeansTalk의 경우를 예로 들어보도록 하겠습니다. Amazon BeansTalk는 Visual Studio에 추가 기능으로 설치할 수 있는 Toolkit을 통한 배포/모니터링과 Management Console (Web)를 통한 패키지 파일 업로드 방식의 배포를 모두 지원합니다.


웹 프로젝트를 만들고, 아래 화면과 같이 배포 프로필을 Web Deploy 패키지로 만드는 것으로 설정한 다음, 지정된 위치에 패키지 파일을 만들도록 합니다. 패키지 파일은 ZIP 파일입니다.



만들어진 파일을 AWS Management Console로 이동하여 다음과 같이 업로드를 시작합니다.



업로드 완료 후 배포 프로세스가 시작되면 다음과 같이 진행 상황이 표시됩니다.



잠시 기다리면 다음과 같이 정상 배포가 완료되었음을 알리는 화면이 표시됩니다.



그리고 로드 밸런서 앞으로 부여된 FQDN 앞으로 접속하면 다음과 같이 로컬 개발 환경에서 개발할 때와 비슷한 응용프로그램이 실제 클라우드 서비스에서 실행 중인 것을 볼 수 있습니다.



BeansTalk의 멤버 노드로 참여하는 VM 인스턴스들이 있다면 여느 PaaS 플랫폼들과 마찬가지로 모든 배포를 자동화하여 처리하므로 배포 프로세스의 상당 부분을 쉽게 완료할 수 있습니다.


클라우드 서비스 별 배포 방법 – Azure Web Site


이번에는 Azure Web Site를 위한 배포 방법을 살펴보도록 하겠습니다. Visual Studio에서 앞의 경우와 마찬가지로 웹 게시 대화 상자를 띄운 다음, 가져오기 버튼을 클릭합니다.


 



처음 이 기능을 실행하면 배포 프로필을 한 번도 사용한 적이 없으므로 아래와 같이 빈 목록이 나타나게 됩니다. Windows Azure 구독 추가 링크 (드롭 다운 상자 아래)를 클릭합니다.


 



Windows Azure 구독 가져오기 대화 상자가 나타나면 구독 파일 다운로드 링크를 클릭합니다.


 



로그인 페이지에서 로그인을 완료하면 로그인한 Microsoft ID와 연결된 모든 Windows Azure Web Site 프로필 정보를 취합한 통합 프로필 파일의 다운로드를 시작하게 됩니다.


 



앞의 대화 상자로 되돌아와서, publishsettings 파일을 다시 지정하고, 가져오기 버튼을 클릭합니다. 잠시 기다리면 지정한 Live ID로 만든 여러 가입 상의 여러 Azure Web Site에 대한 정보가 한번에 나타납니다. 관리자 권한만을 가지고 있었다고 할지라도 여기에 한번에 나타나므로 손쉽게 배포를 진행할 수 있고, 이 과정 이후에 따로 웹 사이트를 새로 만들더라도 다시 이 대화 상자만 띄우면 목록이 새로 업데이트됩니다.


 



이와 같이 설정을 마무리하고 연결에 이상이 없는지 유효성 검사 버튼을 클릭하여 녹색 체크 마크가 나타나면 배포를 위한 연결이 성립된 것으로, 계속 진행해도 좋습니다.


 



클라우드 서비스 별 배포 방법 – Azure Cloud Service / Web Role


기존에 만들어진 ASP.NET 웹 사이트 프로젝트를 Web Role로 변환하여 내보내는 작업은 생각보다 어렵지 않습니다. 기술적인 고려 사항을 제외하면, Web Role용 프로젝트는 Beans Talk의 경우와 마찬가지로 Azure Cloud Service만을 위해서 무언가 꼭 추가해야 하거나 심각하게 변경해야 할 것이 전혀 없습니다.


Windows Azure Tools 최신 버전을 설치한 다음, 클라우드 서비스 프로젝트를 생성할 때 아래와 같이 아무것도 추가하지 않은 상태로 확인 버튼을 클릭합니다. 기존 프로젝트를 가져오기 위해서입니다.


 



그러면 멤버 역할이 없는 상태의 빈 클라우드 서비스 프로젝트가 만들어지게 됩니다. 이제 솔루션 탐색기의 역할 폴더를 오른쪽 버튼으로 클릭하고 아래 그림과 같은 순서로 팝업 메뉴를 접근합니다.


 



그러면 아직 지금 클라우드 서비스와 연결된 적이 없는 프로젝트의 목록이 나타나게 됩니다. 항목을 선택하여 클라우드 서비스 프로젝트로 가져옵니다.


 



정상적으로 가져오게 되면 다음과 같이 솔루션 탐색기의 클라우드 서비스 프로젝트 아래의 역할 폴더에 프로젝트 이름이 나타나면서 클라우드 서비스의 웹 역할로 등록됩니다.


 



이제 Azure Cloud Service로 배포하기 위하여 패키지를 만들 차례입니다. 패키지를 만들어서 Azure Management Portal을 이용하여 업로드를 해도 좋고, 사전에 인증서 및 계정 연동을 미리 구성하여 Visual Studio에서 진행해도 상관 없습니다. 여기서는 패키지 만들기 기능으로 배포를 해보겠습니다. 클라우드 서비스 프로젝트를 오른쪽 버튼으로 클릭한 다음 패키지 메뉴를 클릭합니다.


 



그러면 배포 대화 상자가 나타나게 됩니다. 각각의 드롭 다운 상자의 의미는 어렵지 않습니다. 서비스 구성이란 클라우드 서비스의 구성을 의미하는 것이고, 빌드 구성은 각 역할과 연결된 C#이나 VB.NET 프로젝트들의 빌드 구성을 의미하는 것으로 양쪽은 서로 독립적인 관계이므로 적절한 옵션을 선택합니다. 설정을 확인한 다음 패키지 버튼을 클릭합니다.


 


빌드 상의 오류가 없으면 탐색기 창이 열리면서 .CSCFG 파일과 .CSPKG 파일이 표시됩니다. 이 파일을 다루기 쉬운 위치로 이동시켜 Windows Azure Management Portal에서 클라우드 서비스를 만든 다음 게시합니다.


 



 

고려할 사항들


전통적인 웹 응용프로그램들과는 달리 클라우드 서비스들은 단일 인스턴스에서 실행하는 것 보다는 로드 밸런싱을 전제로 여러 인스턴스에서 실행하는 것을 기준으로 생각합니다. 그렇기 때문에, 전통적인 웹 기반 응용프로그램을 그대로 전환하는 것은 생각보다 쉽지 않습니다. 특히, 컴퓨터 자체적으로 업로드한 파일을 보관하거나, 서버 컴퓨터의 상태에 의존적인 웹 응용프로그램은 클라우드 기반의 서비스로 이동하기 전에 적절한 보완이 반드시 필요합니다.


그리고 여러 위치에 클라우드 서비스를 배포하고 관리하기 위해서는 자동화된 빌드, 배포, 모니터링 도구가 필요합니다. 각각의 개별 클라우드 서비스들이 제공하는 REST API를 이용하는 도구를 직접 만들 수도 있지만, 재미있는 것은 대다수의 클라우드 서비스 공급자들이 Windows에서는 PowerShell에 대응하는 모듈을 개발하여 배포하고 있다는 것이고, Unix나 Linux에서는 node.js의 클라이언트 기반 런타임을 개발하여 배포하는 일이 많다는 점입니다.


이러한 특징들을 이용하여, 여러 클라우드 서비스를 손쉽게 관리할 수 있는 노하우를 개발하여 여러분의 개발 및 운영 프로세스에 자연스럽게 통합시킬 수 있을 것으로 기대합니다.

Visual Studio 2012 Express 출시

안녕하세요. Windows Azure MVP 남정현입니다. 오늘은 Visual Studio 2012 출시와 더불어서 Express Edition의 업그레이드에 대한 이야기를 전해드리려고 합니다.



개인적으로 매우 좋아하고 아끼는 Visual Studio 제품 라인 업 중에 Express Edition이 있습니다. 무료로 제공되는 개발 도구임에도 기능에서나 활용 면에서 부족함이 전혀 없고, 제 스스로에게 있어서 작업 시간을 줄여주고 시행 착오를 최소화하는데에 지대한 공헌을 하는 멋진 개발 툴입니다.


이번 2012 라인 업에서는 아래와 같이 구성이 변경되었습니다.



  • Visual Studio 2012 Express for Web: 기존의 Visual Web Developer 2010을 이어서 업그레이드된 버전으로 ASP.NET 4.5와 Windows Azure 최신 개발 툴킷, Silverlight 개발 환경등을 포함하고 있습니다.

  • Visual Studio 2012 Express for Desktop: 기존의 Visual C# Express 2010, Visual Basic .NET Express 2010, Visual C++ Express 2010을 통합하여 데스크탑 응용프로그램 개발에 최적화된 버전으로 업그레이드되었습니다.

  • Visual Studio 2012 Express for Windows 8: Windows 8에서 새로 추가된 Windows Store 앱을 만들기 위하여 필요한 개발 도구로 동시에 Expression Blend for Windows 8이 같이 설치됩니다.

  • Visual Studio Team Foundation Server 2012 Express: 고가의 상용 버전 제품으로만 알려져있었던 Team Foundation Server도 Express 버전을 새로 출시하게 되었습니다. 소규모 개발 팀을 운영 중인 경우 한 번즈음 고려해볼 수 있는 형상 관리, 작업 관리, 빌드 자동화를 제공합니다.

언어 별로 나누어져 있었기 때문에 장점이자 단점으로 동시에 작용하던 작고 가벼움은 아쉽게도 더 이상 존재하지는 않습니다. 그렇지만 Express Edition 특유의 한계를 극복하고 더 강력한 기능을 더하고 단순히 학습용이 아닌 소규모 개발 팀을 위한 배려를 모두 포함하고 있다는 것은 매우 기쁜 일입니다.


그리고 실제로 Visual Studio 2012 전체 버전을 구입하시기 전에 제품의 표면적인 기능만을 제한된 시간 내에 평가해야 하는 트라이얼 버전 대신, 실제 업무에도 자연스럽게 반영해볼 수 있는 Express Edition을 통해서 충분한 시간을 가지면서 활용하시면 좀 더 좋은 부분을 많이 보실 수 있을 것이라고 기대합니다.


Web과 Desktop 버전은 Windows 운영 체제 버전과 관계없이 사용이 가능하며, Windows 8 버전의 경우에는 실제로 Windows 8 운영 체제 위에서 실행되어야만 개발 환경 구축이 가능합니다. 그리고 이전과 마찬가지로, 무료로 사용이 가능하고 상용으로도 활용이 가능하지만 설치 후 기간 내에 Microsoft 등록 페이지에 가서 제품에 대한 25자리 등록 번호를 받아서 등록해야 하는 절차는 변함 없습니다.


2012 Express Edition과 2010 Express Edition을 다운로드하시려면 http://www.microsoft.com/visualstudio/kor/downloads 페이지로 가시면 됩니다. 🙂

무료 Microsoft eBook 컬렉션

안녕하세요. Windows Azure MVP 남정현입니다.


오늘 소개해드리려고 하는 것은 Microsoft Press에서 그동안 출간된 eBook, 백서, 가이드 문서 등을 eBook 형태로 집대성해서 다운로드할 수 있도록 공개한 내용인데요, 상당히 많은 자료들이 있지만 그 중에서도 개발자나 IT 엔지니어에게 도움이 될 만한 부분들만 따로 간추려서 블로그 포스팅을 해 봅니다. 제공되는 모든 eBook은 영어로 작성되어있습니다.


여기서 소개하지 않은 백서나 가이드 문서, 트레이닝 킷 혹은 PDF 이외의 다른 포맷의 다운로드 컨텐츠를 찾으시려면 아래 웹 사이트에 방문하셔서 더 찾아보실 수 있습니다. 🙂



제품 별로 자료들을 분류한 것으로 적절한 카테고리의 항목을 찾아 검색하시면 쉽게 다운로드하실 수 있습니다.


클라우드 기술 관련



프로그래밍 관련



Office 365 및 Office 2010 관련



Windows Server 관련



일반 사용자



출처: http://blogs.msdn.com/b/jspark/archive/2012/08/06/ebook-windows-azure-windows-8-windows-phone-7.aspx

ASP.NET Universal Provider 소개

ASP.NET 환경에서 사용자 멤버십, 프로파일, 역할과 세션 상태 관련 기능은 별도의 공급자 클래스에 의하여 구현되는 경우가 많은데, 이러한 공급자 클래스들은 개발자 스스로 원한다면 별도로 정의하여 각자의 서버 및 네트워크 인프라에 맞추어 다시 작성할 수 있습니다. 하지만 이렇게 작업하기에는 녹록치 않은 면들이 많고, 또 실제로 많은 테스트와 검증 과정이 뒷받침되어야 할 필요가 있습니다.


최근에는 SQL Server Compact Edition이나 SQL Server 2012에서 소개된 SqlExpress 또는 SQL Azure와 같이 전통적인 SQL Server 환경이 아닌 곳을 기반으로 택해야 하는 일도 자주 있습니다. 이러한 경우 많은 시행 착오와 오류를 경험할 수 밖에 없는데, 이러한 문제를 크게 덜어줄 유용한 기술이 하나 있습니다. 바로 ASP.NET Universal Provider이며, 향후 Microsoft가 언급하는 Hybrid Cloud Computing 환경에서의 단일 프로그래밍 모델을 구현하기 위한 초석으로 자리매김할 것으로 예상됩니다. 🙂


ASP.NET Universal Provider의 구성


ASP.NET Universal Provider는 다음과 같은 구성을 가지고 있습니다.



  • System.Web.Providers.DefaultMembershipProvider
    (기존의 System.Web.Security.SqlMembershipProvider에 대응)

  • System.Web.Providers.DefaultProfileProvider
    (기존의 System.Web.Profile.SqlProfileProvider에 대응)

  • System.Web.Providers.DefaultRoleProvider
    (기존의 System.Web.Security.SqlRoleProvider에 대응)

  • System.Web.Providers.DefaultSessionStateProvider
    (내장된 세션 상태 관리 공급자를 대체)

ASP.NET Universal Provider를 Visual Studio의 확장 패키지 갤러리 (NuGet 갤러리)를 통하여 설치하게되면 위의 각 공급자에 대한 설정을 현재 ASP.NET 프로젝트 상의 web.config 파일에 지정하게되고, 데이터 소스를 어떻게 선택하는지에 따라서 미리 구성된 데이터 스키마에 맞추어 관련된 서비스 기능을 수행할 수 있도록 맞추게 됩니다.


ASP.NET Universal Provider 설치하기


ASP.NET Universal Provider는 Nuget Package Install Site에서 손쉽게 asp.net 프로젝트에 추가할 수 있습니다. Visual Studio나 Visual Web Developer를 설치한 경우 Nuget Console에서 아래 패키지 이름을 검색하여 기존 프로젝트에 추가하시면 됩니다. 



패키지 설치가 끝나면 web.config 파일에 아래와 같이 Membership, Role, Profile, Session State에 대한 설정을 Universal Provider로 업데이트합니다.


<configuration>
    <connectionStrings>
        <add name=”DefaultConnection” connectionString=”Data Source=.SQLEXPRESS;AttachDbFilename=|DataDirectory|aspnet.mdf;Initial Catalog=aspnet;Integrated Security=True;User Instance=True;MultipleActiveResultSets=True” providerName=”System.Data.SqlClient”/>
    </connectionStrings>
    <system.web>
      <profile defaultProvider=”DefaultProfileProvider” >
        <providers>
          <add name=”DefaultProfileProvider” type=”System.Web.Providers.DefaultProfileProvider” connectionStringName=”DefaultConnection” applicationName=”/”/>
        </providers>
      </profile>
      <membership defaultProvider=”DefaultMembershipProvider”>
        <providers>
           <add name=”DefaultMembershipProvider” type=”System.Web.Providers.DefaultMembershipProvider” connectionStringName=”DefaultConnection”
             enablePasswordRetrieval=”false” enablePasswordReset=”true” requiresQuestionAndAnswer=”false” requiresUniqueEmail=”false”
             maxInvalidPasswordAttempts=”5″ minRequiredPasswordLength=”6″ minRequiredNonalphanumericCharacters=”0″ passwordAttemptWindow=”10″
             applicationName=”/” />
        </providers>
      </membership>
      <roleManager defaultProvider=”DefaultRoleProvider”>
        <providers>
           <add name=”DefaultRoleProvider” type=”System.Web.Providers.DefaultRoleProvider” connectionStringName=”DefaultConnection” applicationName=”/” />
        </providers>
      </roleManager>
      <sessionState mode=”Custom” customProvider=”DefaultSessionProvider”>
        <providers>
          <add name=”DefaultSessionProvider” type=”System.Web.Providers.DefaultSessionStateProvider” connectionStringName=”DefaultConnection” applicationName=”/”/>
        </providers>
      </sessionState>
    </system.web>


위의 설정에서 DefaultConnection에 적절한 연결 문자열과 함께 정확한 providerName을 기재하면 Universal Provider가 정확한 ADO.NET Connection Driver를 사용하여 필요한 서비스들을 제공하게 됩니다. 이렇게 만듦으로서 SQL Azure는 물론 기존 SQL Server, SQL Server CE를 데이터 원본으로 선택할 수도 있습니다.


좀 더 자세한 정보 알아보기


패키지의 최신 업데이트 정보와 설치 방법은 아래 웹 사이트에서 확인할 것을 권합니다.


http://nuget.org/packages/System.Web.Providers/1.0.1


구체적인 사용 방법과 시나리오에 대해서는 Scott Hanselman의 블로그 아티클을 참고하시기 바랍니다.

http://www.hanselman.com/blog/IntroducingSystemWebProvidersASPNETUniversalProvidersForSessionMembershipRolesAndUserProfileOnSQLCompactAndSQLAzure.aspx

 

Phalanger와 PHP의 차이점들

지난 아티클에서는 Phalanger와 PHP 사이에 차이점들이 있다고 말씀드렸습니다. 구체적으로 어떤 차이점들이 있을까요? 여러 프로그래밍 언어를 지원한다는 사실이 가장 큰 차이점이고 닷넷 기반 위에서 실행된다는 것이 구분되는 점이겠지만 이런 점을 차치하고 PHP 관점에서 차이점을 살펴본다면 지금 이야기하려는 토픽들에 대한 이야기가 빠질 수 없을 것입니다.


App_Code 폴더의 사용


Phalanger가 ASP.NET을 기반으로 하고 있기 때문에 자동으로 이어받는 특성으로, App_Code 폴더의 사용에 관한 부분이 있습니다. ASP.NET에서는 App_Code 폴더 안에 낱개 코드 파일들을 넣어두면 이것을 자동으로 웹 페이지의 서버 런타임에서 자유롭게 가져다쓸 수 있다고 하였는데, Phalanger도 마찬가지입니다. 웹 페이지를 렌더링하기 위한 목적이 아닌 공통이 되는 PHP 코드를 이 폴더에 넣어두기만 하면 자동으로 이 폴더에 속한 모든 PHP 코드들이 글로벌 문맥 상에서 사용 가능하게 활성화됩니다.


단, 조심해야 할 부작용이 하나 있다면 여기에 지나치게 많은 코드를 배치할 경우 컴파일 시간이 늘어나서 처음 사이트를 시작할 때 시간이 오래 걸리게 될 가능성이 있습니다. 안타깝게도 C나 C++처럼 병렬 컴파일은 아직 지원되지 않기 때문에 컴파일 시간이 오래 걸릴 경우 다양한 문제를 야기할 가능성이 있습니다.


php.ini와 같은 Global Configuration이 아닌 web.config에 의한 설정


PHP의 경우 설정을 변경하기 위해서는 PHP 전체의 설정을 주관하는 php.ini 파일을 업데이트하거나, PHP를 다시 컴파일하여 설치하는 번거로운 과정을 거쳐야만 모듈에 대한 설정이나 추가/제거가 가능했습니다. 하지만 Phalanger의 경우 현재 만들어진 응용프로그램 풀마다 다른 설정을 가지도록 구성할 수 있으므로 좀 더 자유도 높은 설정이 가능합니다. 이를 위해서 web.config 파일을 수정하고 저장하기만 하면 됩니다.


이러한 설정을 다루기 위해서는 phpNet이라는 XML 요소를 web.config에 지정해야 하는데, 그냥 지정할 수는 없고 반드시 적절한 처리기를 연결해주어야 합니다. web.config은 단순한 XML 파일이 아니라 닷넷 프레임워크가 직접 내용을 검사하고 분석하는 프로그램 코드의 일부이기 때문에 규칙을 준수하는 것이 매우 중요합니다.


phpNet 요소를 추가하려면 web.config에서 <configuration> 요소의 제일 첫 번째 노드로 아래 XML 조각이 배치되어야 합니다.



<configSections>
<section name=”phpNet” type=”PHP.Core.ConfigurationSectionHandler, PhpNetCore, Version=3.0.0.0, Culture=neutral, PublicKeyToken=0a8e8c4c76728c71″ />
</configSections>


그 다음, 보기에 편리한 위치에 phpNet 요소를 추가합니다. 보통 아래의 코드 조각으로 최초 설정을 시작하면 무난합니다.



<phpNet>
<classLibrary>
  <add assembly=”PhpNetClassLibrary, Version=3.0.0.0, Culture=neutral, PublicKeyToken=4af37afe3cde05fb” section=”bcl” />
  <add assembly=”PhpNetXmlDom, Version=3.0.0.0, Culture=neutral, PublicKeyToken=2771987119c16a03″ section=”dom”/>
</classLibrary>   
</phpNet>


php.ini 파일의 샘플 사본을 복사하여 php.ini 파일로 사용하던 것과 비슷한 접근 방법이지만 각 사이트 혹은 도메인 별로 따로 사용하는 web.config 파일 안에서 이러한 설정을 다루는 것이 중요한 차이점입니다. 그리고 무엇보다도 안심해도 좋은 것은 INI 파일처럼 프로그램이 잘못 다루게 될 가능성이 있는 파일이 아니라, XML의 형태로 설정 파일이 관리되므로 web.config 파일을 건드리는 다른 써드 파티 어플리케이션 때문에 Phalanger의 설정이 깨지거나 변형될 일이 거의 없다는 점입니다.


위의 기본 설정을 지정하면 Phalanger에서 기본적인 PHP API를 사용할 수 있으며, PHP5부터 기본으로 제공되는 SimpleXMLElement도 위의 설정으로 기본으로 활성화됩니다.


PHP/CLR의 사용


이제 위의 설정을 토대로 PHP/CLR을 활성화하여 닷넷 프레임워크의 기본 API를 Phalanger에서 즉시 호출하여 사용할 수 있습니다. 위의 <phpNet> 요소 아래에 다음의 XML 요소를 추가하면 됩니다.


<compiler>
  <set name=”LanguageFeatures”>
    <add value=”PhpClr” />
  </set>
</compiler>

그리고 <classLibrary> 요소 아래에 .NET Framework 기본 어셈블리에 대한 레퍼런스를 추가합니다.


<classLibrary>
  <add assembly=”mscorlib” />
  <add assembly=”System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ />
  <add assembly=”System.Drawing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a” />
  <add assembly=”PhpNetClassLibrary, Version=3.0.0.0, Culture=neutral, PublicKeyToken=4af37afe3cde05fb” section=”bcl” />
  <add assembly=”PhpNetXmlDom, Version=3.0.0.0, Culture=neutral, PublicKeyToken=2771987119c16a03″ section=”dom”/>
</classLibrary>

이제 새로 추가한 코드가 의도한대로 잘 작동하는지 살펴보기 위하여, 이미지 리사이징을 수행하는 샘플 코드를 Phalanger 위에서 실행하도록 PHP/CLR 기반으로 코드를 만들어보도록 하겠습니다. 이 코드는 http://wiki.php-compiler.net/Code_Samples/Resize_image 의 예제를 발췌하여 조금 변형한 것입니다.



<?php
use SystemDrawingBitmap;
use SystemDrawingGraphics;
use SystemDrawingGraphicsUnit;
use SystemDrawingRectangle;
use SystemWebHttpContext;


function resize_imageSysDraw($from,$wid,$hgt)
{
  $bmp = Bitmap::FromFile($from);
  $fmt = $bmp->RawFormat;
  $new = new Bitmap($wid, $hgt);
  $gr = Graphics::FromImage($new);
  $gr->DrawImage($bmp,
    new Rectangle(0,0,$wid,$hgt),
    new Rectangle(0,0,$bmp->Width, $bmp->Height),
    GraphicsUnit::Pixel);
  $gr->Dispose();
  $new->Save(HttpContext::$Current->Response->OutputStream, $fmt);
  $new->Dispose();
}


resize_imageSysDraw(realpath(‘Penguins.jpg’), 320, 240);
?>


PHP/CLR의 경우 여느 닷넷 언어들과 마찬가지로 네임스페이스에 속한 클래스에 대한 참조를 use 명령어로 지정하고 있으며, 정적 멤버에 대해서는 :: 연산자를, 객체 생성은 new 연산자를 사용하였습니다. resize_imageSysDraw 함수에서는 ASP.NET의 HttpContext를 가져와서 기본 출력 대신 비트맵 이미지를 내보내도록 만들었고 그 결과 아래와 같이 축소된 이미지가 렌더링되서 나타나게 됩니다.



Phalanger의 LINQ 지원


이제 마지막으로 PHP/CLR의 하이라이트라고 할 수 있는 LINQ 지원에 대해서 살펴보겠습니다. LINQ는 Microsoft Research에서 C# 언어의 확장 사양인 C-omega 언어의 일부로 개발 중이던 사양을 정규화하여 Production Spec으로 만든 것으로, C# 이외에 VB.NET에도 영향을 주었으며 Prism이나 지금 소개하는 Phalanger에서도 개념을 적극 채택하여 정규 사양으로 활용 중입니다. 그리고 F#은 이러한 접근을 더욱 드라마틱하게 활용하여 함수형 언어로 발전시키기도 하였습니다.


LINQ에 대해서 이야기하려면 책을 한 권 따로 만들어야할 만큼 방대합니다. 그래서 자세한 이야기는 하지 않고, LINQ 자체에 대해서 진지하게 학습하기 원한다면 LINQ 관련 국내외 도서들을 검토하기 바랍니다. 개인적으로는 “생각하는 C# LINQ”라는 책을 추천합니다. 🙂


http://kangcom.com/sub/view.asp?sku=200809180001&mcd=571


LINQ는 한 마디로 이야기하면, 프로그래밍 코드를 한 방향에서만 바라보도록 뷰 포인트의 시각을 고정한 것과 같습니다. 본디, 어떤 연관성이 있는 데이터 집합을 접근하는 방법에는 여러 가지 방법이 있을 수 있지만 LINQ는 데이터가 어떤 순서로 들어있든, 어떤 형태로 연결되어있든 관계없이 데이터를 꺼내올 수 있도록 도와주는 Iterator 패턴의 한 형태인 Enumerator를 조금 독특하게 해석하였습니다.


Enumerator가 열거할 대상을 미리 정할 수 있도록 만들고, 열거할 때 조건을 지정하여 필요없는 데이터는 건너뛸 수 있게 해준다던지 이런 취지에서 해석을 한 것이 LINQ입니다. 그리고 Enumerator를 수정하게 되는 시점이 이미 메모리 상에 저장된 데이터 셋에 대한 작업인지, 아니면 아직 수신되지 않은 미지의 데이터 셋에 대한 작업인지에 따라서도 지연 실행이냐 즉시 실행이냐 이렇게 구분하기도 하구요. 그러면서도 항상 잃지 않는 것은 핵심은 Enumerator라는 사실이며, 이에 입각하여 배열이나 리스트같은 정규화된 자료 구조로 변환할 수 있는 길을 항상 열어놓아 최대한의 유연성을 부여하기도 합니다.


어렵게 들릴 수도 있지만 Enumerator를 수정할 수 있게 해준다는 컨셉은 생각보다 활용 폭이 넓은데, 가장 가까이 있는 예로는 SQL 쿼리가 될 수 있습니다. 처음의 아이디어는 SQL 쿼리를 이용하여 전체 데이터 셋보다 가능한 적게 데이터를 반환하여 네트워크 트래픽을 줄이고 빠르게 데이터를 검색할 수 있도록 최적화하자는 것에 있었을 것이며, 이것을 좀 더 프로그래밍 언어와 친화적으로 만들 방법을 모색한 끝에 LINQ to SQL이 나타나게 된 셈입니다. 그리고 이를 필두로 접근할 수 있는 모든 유형의 컬렉션에 대해서 이런 아이디어를 대입하여 현재는 오픈 소스를 찾아보면 정말 엄청나게 많은 LINQ provider들을 발견할 수 있을 정도입니다.


이렇게 독창적이고 전례없던 기술을 Phalanger에서도 이용할 수 있다는 것은 매우 좋은 일입니다. <phpNet> 요소에 대해 PHP-CLR을 활성화하도록 설정을 수정한 후 아래 코드를 테스트해보기 바랍니다.



<?php
$myarray = json_decode(‘[
    {“label”:”foo”,”name”:”baz”},
    {“label”:”boop”,”name”:”beep2″},
    {“label”:”foo”,”name”:”baz1″},
    {“label”:”boop”,”name”:”beep3″},
    {“label”:”foo”,”name”:”baz2″},
    {“label”:”boop”,”name”:”beep1″}
]’, true);


$result =
from $myarray as $x
where $x[‘label’] == ‘foo’
select $x[‘name’];


foreach ($result as $x) {
    print($x.'<br />’);
}


print_r($result);


?>


json_decode라는 기본 PHP 함수를 이용하여 JSON을 PHP 연관 배열로 바꾸고, 이것을 LINQ로 조회한 다음, 그 결과를 foreach 문을 통해서 출력하도록 만들었습니다. C#이나 VB.NET의 LINQ와 약간 다른 점은, from 절에서 in 연산자 대신 as 연산자를 사용하고 in 연산자와는 도치되는 좌/우항 관계를 가집니다. 즉, [나열 변수] in [데이터 소스] 에서 [데이터 소스] as [나열 변수]로 바뀝니다. 그리고 이것은 foreach 문에도 동일하게 적용됩니다. 아래는 실행 결과입니다.



PHP, JSON, 그리고 LINQ가 한 자리에 모여 매우 재미있는 상호 작용을 이룬 것을 볼 수 있습니다. 이 정도면 닷넷에서의 웹 프로그래밍이 이전과는 제법 많이 달라질 수 있다는 것을 체감할 수 있을 것입니다.


다음번에는 Phalanger가 기존 PHP의 모듈들을 어떻게 다루고 관리하는지에 대한 상세한 내용을 살펴보도록 하겠습니다. 긴 글 읽어주셔서 감사합니다. 🙂