PaaS2014. 8. 24. 09:37

번역: 남정현


날짜: 2014-08-24


이 문서에 대하여

이 문서는 2014년 8월 19일에 작성된 https://github.com/aspnet/Home/wiki/Project.json-file 의 내용을 한국어로 번역한 것으로, 원본 문서 작성자는 ASP.NET vNext 팀입니다. 오역, 어색한 부분, 매끄럽지 않은 부분이 있을 경우 알려주시면 적극적으로 반영하도록 하겠습니다.

스키마

http://json.schemastore.org/project

의존성

 

 

의존성 섹션은 여러분의 애플리케이션이 사용하는 모든 의존성들을 열거합니다. 이름과 버전으로 정의할 수 있으며, 런타임 로더가 어떤 것을 반드시 로드해야 할지 결정합니다. NuGet 패키지, 소스 코드 등이 될 수 있습니다.

[json]
 {

“dependencies”: {

“Microsoft.AspNet.ConfigurationModel”: “0.1-alpha-*”,

“SomeProject”: “”

}

}
 [/json]

여기서 사용할 수 있는 또 다른 기능으로 아래와 같이 더 구체적으로 의존성 설정을 지정하는 것이 가능합니다.

[json]
 {

“dependencies”: {

“Microsoft.AspNet.ConfigurationModel”: { “version”: “0.1-alpha-*”, “options”: “private” },

“FakeToolingPackage” : {“version”: “0.1”, “options”: “dev”},

“SomeProject”: “”

}

}
 [/json]

참조에는 여러 가지 다른 종류들이 있을 수 있습니다.

•Private – 의존성을 인텔리센스나 혹은 컴필레이션에 노출하지 않도록 할 수 있습니다.

 

•Bago (Build and go away) – 이 참조를 컴파일한 후에 대상 프로젝트 안으로 같이 컴파일됩니다.

 

어떻게 의존성 버전이 선택되는지에 대한 더 상세한 정보는 https://github.com/aspnet/Home/wiki/Dependency-Resolution 에서 자세히 확인할 수 있습니다.

Configurations 섹션

Configurations는 컴필레이션 설정에 대한 이름이 붙여진 그룹 항목들입니다. 실행 시점에는 기본으로 주어지는 설정 두 가지가 있는데, 바로 Debug와 Release입니다. 이들 설정을 project.json에 필요에 따라 다시 설정하거나 새로운 설정을 더 추가하는 것도 가능합니다.

[json]
 {

“configurations”: {

“Debug”: {

“compilationOptions”: {

“define”: ["DEBUG", "TRACE"],

“debugSymbols”: “full”

}

},

“Release”: {

“compilationOptions”: {

“define”: ["RELEASE", "TRACE"],

“optimize”: true,

“debugSymbols”: “pdbOnly”

}

}

}

}
 [/json]

Frameworks 섹션

어느 프레임워크를 대상으로 개발된 프로그램인지 정의하고, 해당 구성에서 참조하는 의존성들을 dependencies에서 정의할 수 있습니다. 아래 코드 조각에서는 데스크톱 (net45) 또는 Core CLR (k10) 중 하나를 사용할 것입니다. Core CLR은 BCL을 만들기 위해서 더 많은 참조들에 대한 의존성을 가집니다.

[json]
 {

“frameworks”: {

“net45″: {},

“k10″: {

“dependencies”: {

“System.Collections”: “4.0.0.0”,

“System.Collections.Concurrent”: “4.0.0.0”,

“System.ComponentModel”: “4.0.0.0”,

“System.Linq”: “4.0.0.0”,

“System.Reflection”: “4.0.10.0”,

“System.Runtime”: “4.0.20.0”,

“System.Runtime.InteropServices”: “4.0.10.0”,

“System.Threading”: “4.0.0.0”,

“System.Threading.Tasks”: “4.0.0.0”

}

}

}

}
 [/json]

Sources 섹션

sources 섹션은 컴파일해야 할 소스 코드들을 지정합니다.

[json]
 {

“code”: “*.cs”,

“exclude”: “buggy/**/*.cs”,

“resources”: “embed/**/*.*”

}
 [/json]

공유 파일 섹션

여러 프로젝트에서 의존하는 코드를 공유할 수 있습니다. 공유 어셈블리 정보 같은 내용을 담고 있는 코드를 공유하기 위해서, 공통 프로젝트를 만들고, 이 프로젝트에서 공유 파일 섹션을 포함하도록 공유할 코드를 참조하게 하면 됩니다. 그 후에는 새로 만든 공통 프로젝트를 참조하는 프로젝트라면 항상 프로젝트에 해당 파일들이 같이 포함되어 컴파일이 이루어지게 됩니다.

[json]
 {

“shared”: “*.cs”

}
 [/json]

컴파일 옵션

컴파일 옵션에서는 Roslyn으로 전달할 설정을 지정할 수 있습니다. 여기서 언어의 버전을 선택할 수 있습니다.

[json]
 {

“compilationOptions”: {

“define”: ["SOMETHING"],

“allowUnsafe”: true,

“warningsAsErrors” : true,

“languageVersion”: “experimental”

}

}
 [/json]

명령

K.cmd를 실행할 때에는 실행하려는 명령의 이름을 지정할 수 있습니다. 아래 코드 조각은 K web이라는 명령어를 실행할 때 셀프 호스트를 시작하도록 하고 있고, K test라는 명령어를 실행할 때에는 모든 단위 테스트를 실행하도록 하고 있습니다.

[json]
 {

“commands”: {

“web”: “Microsoft.AspNet.Hosting server.name=Microsoft.AspNet.Server.WebListener server.urls=http://localhost:5001″,

“test”: “Xunit.KRunner”

}

}
 [/json]

스크립트

KPM에서 어떤 일을 수행하기 전과 후에 발생하는 이벤트에 간섭하여 추가 작업을 지시할 수 있습니다.

[json]
 {

“scripts”: {

“prebuild”: “echo before building”,

“postbuild”: “echo after building”,

“prepack”: “echo before packing”,

“postpack”: “echo after packing”,

“prerestore”: “echo before restoring packages”,

“postrestore”: “echo after restoring packages”

}

}
 [/json]

그리고 사용 가능한 변수들은 다음과 같습니다.
</p><p>%project:Directory% - 프로젝트 디렉터리 경로
</p><p>%project:Name% - 프로젝트 이름
</p><p>%project:Version% - 프로젝트 버전<br />

메타데이터

프로젝트에 대한 메타데이터를 기록할 수 있습니다.

[json]
 {

“version”: “0.1-alpha”,

“authors”: ["John Doe"],

“description”: “A wonderful library that does nice stuff”

}
 [/json]

Entity Framework 프로젝트에서 가져온 project.json 파일의 한 예시

[json]
 {

“version”: “0.1-alpha-*”,

“compilationOptions”: {

“warningsAsErrors”: true

},

“dependencies”: {

“Microsoft.Bcl.Immutable”: “1.1.18-beta-*”,

“Microsoft.AspNet.ConfigurationModel”: “0.1-alpha-*”,

“Microsoft.AspNet.DependencyInjection”: “0.1-alpha-*”,

“Microsoft.AspNet.Logging”: “0.1-alpha-*”,

“System.Data.Common”: “0.1-alpha-*”

},

“code”: “**\\*.cs;..\\Shared\\*.cs”,

“frameworks”: {

“net45″: {

“dependencies”: {

“System.Runtime”: “”,

“System.Collections”: “”

}

},

“k10″: {

“dependencies”: {

“System.Collections”: “4.0.0.0”,

“System.Collections.Concurrent”: “4.0.0.0”,

“System.ComponentModel”: “4.0.0.0”,

“System.Console”: “4.0.0.0”,

“System.Diagnostics.Contracts”: “4.0.0.0”,

“System.Diagnostics.Debug”: “4.0.10.0”,

“System.Globalization”: “4.0.10.0”,

“System.Linq”: “4.0.0.0”,

“System.Linq.Expressions”: “4.0.0.0”,

“System.Linq.Queryable”: “4.0.0.0”,

“System.Reflection”: “4.0.10.0”,

“System.Reflection.Extensions”: “4.0.0.0”,

“System.Resources.ResourceManager”: “4.0.0.0”,

“System.Runtime”: “4.0.20.0”,

“System.Runtime.Extensions”: “4.0.10.0”,

“System.Threading”: “4.0.0.0”,

“System.Threading.Tasks”: “4.0.10.0”

}

}

}

}
 [/json]

 

Posted by Cloud Developer 남정현 (rkttu.com)

댓글을 달아 주세요

Windows + .NET2014. 8. 17. 09:36

.NET은 문자열을 다루는 데 있어서 C, C++, 혹은 파스칼과 비슷한 듯 다른 면이 있습니다. 그리고 이번 아티클에서는 사소하지만 큰 오류를 내포하게 될 가능성이 있는 부분을 잠시 소개하려고 합니다.

http://msdn.microsoft.com/ko-kr/library/ms228362.aspx 에서는 .NET의 String에 대해 이렇게 소개하고 있습니다.

 

 


문자열은 값이 텍스트인 String 형식의 개체입니다. 내부적으로 텍스트는 Char 개체의 순차적 읽기 전용 컬렉션으로 저장됩니다. C# 문자열 끝에는 null 종결 문자가 없습니다. 따라서 C# 문자열은 포함된 null 문자(‘\0′)를 제한 없이 포함할 수 있습니다. 문자열의 Length 속성은 유니코드 문자의 수가 아니라 포함된 Char 개체의 수를 나타냅니다. 문자열에서 개별 유니코드 코드 포인트에 액세스하려면 StringInfo 개체를 사용합니다.

굵게 강조 표시한 부분의 내용에 오늘 아티클의 핵심 내용이 모두 들어있습니다. 하지만 꼼꼼하게 기억해두지 않으면 허술하게 다루어질 가능성도 있는 부분이라고 생각합니다.

위의 내용을 상기하면서, 아래의 코드들이 각각 어떻게 실행될지 예상해보면 흥미롭습니다.
string a = "'abc'".Replace('\'', default(char));
Console.WriteLine("a: {0} (Length: {1})", a, a.Length);
string b = "'abc'".Replace('\'', Char.MinValue);
Console.WriteLine("b: {0} (Length: {1})", b, b.Length);
string c = "'abc'".Replace('\'', (char)0);
Console.WriteLine("c: {0} (Length: {1})", c, c.Length);
string d = "'abc'".Replace('\'', '\0');
Console.WriteLine("d: {0} (Length: {1})", d, d.Length);


 

 

Replace로 한 글자만 제거하고 싶어서 위와 같은 코드를 작성하기 쉬운데, 위의 결과에서 원래 의도는 ‘abc’ 라는 다섯 글자를 abc라는 세 글자로 만드는 것이지만, 실제로는 여전히 다섯 글자가 됩니다. 그런데 여기서 한 가지 더 중요한 것은, Trim() 메서드가 앞 뒤로 붙는 null character를 제거해 주지는 않는다는 점입니다.
string a = "'abc'".Replace('\'', default(char)).Trim();
Console.WriteLine("a: {0} (Length: {1})", a, a.Length);
string b = "'abc'".Replace('\'', Char.MinValue).Trim();
Console.WriteLine("b: {0} (Length: {1})", b, b.Length);
string c = "'abc'".Replace('\'', (char)0).Trim();
Console.WriteLine("c: {0} (Length: {1})", c, c.Length);
string d = "'abc'".Replace('\'', '\0').Trim();
Console.WriteLine("d: {0} (Length: {1})", d, d.Length);


 

앞/뒤로 붙은 null character를 제거하려면 null character를 명시하는 작업이 필요합니다. 그리고 이것은 Replace 메서드에 대해서도 동일하게 적용됩니다.
</pre>
<pre>string a = "'abc'".Replace('\'', default(char)).Trim('\0');
Console.WriteLine("a: {0} (Length: {1})", a, a.Length);
string b = "'abc'".Replace('\'', Char.MinValue).Trim('\0');
Console.WriteLine("b: {0} (Length: {1})", b, b.Length);
string c = "'abc'".Replace('\'', (char)0).Trim('\0');
Console.WriteLine("c: {0} (Length: {1})", c, c.Length);
string d = "'abc'".Replace('\'', '\0').Trim('\0');
Console.WriteLine("d: {0} (Length: {1})", d, d.Length);


이런 맥락에서 보았을 때, 외부로부터 들어오는 입력 문자열에 대해 엄격하게 이야기하자면, null character에 대한 것을 String.Empty로 치환하는 작업도 필요할 수 있다고 볼 수 있겠습니다.

 

Posted by Cloud Developer 남정현 (rkttu.com)

댓글을 달아 주세요

Linux + .NET2014. 8. 11. 09:35

업데이트: 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 웹 응용프로그램을 포팅하실 수 있을 것입니다.

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

Posted by Cloud Developer 남정현 (rkttu.com)

댓글을 달아 주세요

PaaS2014. 8. 10. 09:34

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
•x86\Microsoft.AspNet.Loader.IIS.Interop.dll
•amd64\Microsoft.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 하나로 통합하셔야 테스트할 수 있습니다.

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

Posted by Cloud Developer 남정현 (rkttu.com)

댓글을 달아 주세요

PaaS2014. 8. 3. 09:33

OWIN과 미들웨어

OWIN은 .NET Framework를 이용하여 코드를 실행할 수 있는 서버 환경이면 어디서든 사용이 가능한 이식이 편리한 코어 웹 프레임워크입니다. 기본적으로 OWIN은 웹 요청을 받아들이면 주어진 순서대로 구성된 미들웨어 체인을 따라 응답을 만들어내게 됩니다.

.NET Framework를 이용한 웹 응용프로그램 개발도 요즈음에는 다양한 프레임워크를 결합하여 개발하는 것이 요구 사항으로 자리잡고 있으며, 초창기의 .NET과는 달리 더 이상 System.Web 기반의 기술만으로 모든 것을 구현하지는 않습니다.

 

 

대표적으로, 최근 소개된 비동기 양방향 웹 소켓 호환 통신을 지원하는 SignalR의 경우 버전 2.0부터는 System.Web과 독립적으로 움직일 수 있도록 OWIN 위에서 실행되는 구조를 취하게 되었습니다. SignalR을 도입하는데 뜬금없이 OWIN Startup이라던지 하는 코드를 보면서 생소하다는 느낌을 받으셨다면 그게 바로 이것입니다.

재미있는 것은 OWIN 스택 전체는 기존에 ASP.NET을 실행하던 환경과 독립적인 관계를 가집니다. 기존 ASP.NET 환경 위에서 호스팅하는 경우 ASP.NET 환경보다 가장 먼저 앞서서 실행되는 형태로 되어있습니다. 이전처럼 Visual Studio 도구에 종속적인 방식으로 프로그래밍하는 것이 아니라, 내가 어떤 웹 기술을 사용할 것인지 Startup 클래스에서 정하여 선택적으로 사용할 수 있게 됩니다.

OWIN 기반의 응용프로그램 처음 만들어보기

앞에서 잠시 이야기한 것처럼 OWIN은 흔히 콘솔이나 클라이언트 응용프로그램처럼 시작점이 존재합니다. ASP.NET 기반의 응용프로그램으로 말할 것 같으면 Global.asax 같은 역할을 담당한다고 할 수 있습니다. 이것을 OWIN Startup 클래스라고 하며, OWIN Startup 클래스에서 내가 어떤 미들웨어를 사용하여 웹 요청을 처리할 것인지 프로그래밍할 수 있습니다.

빠르게 예제를 만들어보기 위하여, Visual Studio에서 비어있는 ASP.NET 프로젝트를 하나 만들어보도록 하겠습니다. (MVC나 Web Form 등은 일절 필요하지 않습니다.)

참고로, 이번 아티클에서 사용하는 Visual Studio 버전은 2013 버전이지만 2012로도 큰 차이 없이 작업할 수 있습니다.

새 웹 프로젝트를 만들면서 아래와 같이 One ASP.NET 프로젝트 대화 상자가 나타나는데, 빈 템플릿으로 하나 만들도록 합니다.

 

그러면 아래와 같이 최소 수준으로 구성된 웹 프로젝트가 만들어지게 됩니다.

 

프로젝트 항목 (위 그림 기준으로 OwinExample)을 마우스 오른쪽 버튼으로 클릭하고 NUGET 패키지 관리 메뉴를 클릭하면 아래와 같이 패키지 설치 대화 상자가 나타납니다. 우측 항목들 중 온라인 항목을 선택하고, 검색어에 “system.web owin”이라고 입력하여 검색합니다.

만약 이 기능을 찾을 수 없는 경우 Visual Studio에 NuGet 패키지 관리자가 설치되어있지 않은 것이므로, http://visualstudiogallery.msdn.microsoft.com/27077b70-9dad-4c64-adcf-c7cf6bc9970c 에서 익스텐션을 내려 받아 설치하시면 됩니다.

 

나타나는 검색 결과 항목들 중 Microsoft.Owin.Host.SystemWeb 항목을 클릭하고 Install 버튼을 클릭하면, 종속성 관계에 따라 추가 설치가 필요한 패키지에 대한 정보나 라이선스 동의 등의 추가 확인 대화 상자가 나타날 수 있고, 여기에 모두 승인하시면 ASP.NET 프로젝트에서 OWIN을 사용할 수 있게 준비가 완료됩니다.

설치가 마무리되면 새 클래스를 만듭니다. 아래와 같이 클래스의 내용을 작성하도록 합니다. 혹은 Visual Studio 2013을 사용하는 경우 새 파일 템플릿 중에 OWIN 시작 클래스라는 항목도 있는데 이 항목을 대신 사용해도 됩니다.
using System;
using System.Threading.Tasks;
using Microsoft.Owin;
using Owin;

[assembly: OwinStartup(typeof(OwinExample.Startup1))]

namespace OwinExample
{
    public class Startup1
    {
        public void Configuration(IAppBuilder app)
        {
        }
    }
}


위에 보시는 것이 처음 OWIN 프로그램을 시작할 때 사용되는 시작 클래스입니다. 여기서 Configuration 부분에 OWIN에서 사용할 미들웨어 등에 대한 구성을 추가하면 됩니다.

OWIN 패키지로 설치되는 라이브러리에 대한 이해

엄격하게 말해서 OWIN 어셈블리는 IAppBuilder라고 불리는 인터페이스 하나만을 가지고 있습니다.

 

보시는 것처럼 정말 IAppBuilder라는 인터페이스를 하나만 가지고 있을 뿐입니다. 그런데 이 인터페이스가 OWIN 기반의 응용프로그램을 만들기 위한 여러 가지 기본 사항들을 정의하고 있습니다. 각 멤버들에 대해서 간단히 살펴보면 다음과 같습니다.

•Build(System.Type): 이 인터페이스를 구현하는 클래스의 재량이며, 주어진 Type 형식에 대응되는 객체의 참조를 반환합니다. Microsoft OWIN 구현체의 경우, Map과 MapWhen 관련 기능을 소화하기 위한 목적으로 이 메서드를 활용합니다.

 

•New(): 역시 인터페이스를 구현하는 클래스의 재량이며, 또 다른 IAppBuilder 인터페이스 형식의 객체의 참조를 반환합니다. Microsoft OWIN 구현체의 경우, Map과 MapWhen 관련 기능을 소화하기 위한 목적으로 이 메서드를 활용합니다.

 

•Use(object, params object[]): OWIN 초기 구성에 있어서 가장 중요한 메서드입니다. 요청을 처리하고자 하는 미들웨어를 필요한 만큼 추가할 수 있으며, Use 메서드를 구성 과정에서 부른 순서대로 내부적으로 배열이나 리스트 안에 Use 메서드를 통해 전달받은 미들웨어 진입점들을 보관하고 순서대로 호출이 이루어질 수 있게 합니다.

 

OWIN 기반으로 프로그램을 만드는 과정에서 가장 첫 단추는 바로 이 IAppBuilder의 Use 메서드를 적절하게 활용하는 것입니다.

하지만 이 인터페이스 만으로 프로그래밍을 한다는 것은 정말 최소한의 수준을 만족하는 프로그래밍 기법을 사용하는 것으로, 실제 우리가 관심을 가져야 할 부분과는 거리가 상당히 멀리 떨어져 있습니다. 호스팅 환경이나 웹 프로그래밍에서 응당 필요한 요청과 응답 과정에서의 파이프라인 처리 등 필요한 것이 많습니다. 이런 부분들을 적절히 제공하는 것이 바로 Microsoft가 제안하는 Katana 프로젝트를 통한 프로그래밍입니다. Microsoft.Owin 이라는 이름으로 시작하는 어셈블리들의 시리즈이며, 이것을 사용하여 좀 더 웹 프로그래밍 다운 웹 프로그래밍을 할 수 있게 됩니다.

지금 여러분이 만든 ASP.NET 프로젝트에서 OWIN을 실행할 수 있도록 해준다는 것은 Katana 프로젝트의 일부인 System.Web Loader 프로젝트의 기능입니다. 어떻게 해서 이 클래스가 별다른 설정도 없이 자동으로 모든 요청을 받아들일 수 있는 시작점이 되는가에 대해서는 지금은 자세히 알지 못해도 괜찮습니다.

Hello World 미들웨어 작성

이제 본격적으로 Hello World 메시지를 출력하는 간단한 미들웨어를 하나 작성해보도록 하겠습니다.

Configuration 메서드 안에 다음과 같이 코드를 작성합니다.
app.Run(async (context) =&gt;
{
    await context.Response.WriteAsync("Hello, World!");
});

앞에서 살펴본 Use 메서드를 응용하는 도우미 메서드로 Run 메서드를 Katana에서 제공하고 있습니다. 이 메서드를 사용하면 다른 미들웨어를 실행하지 않고 자기 선에서 요청에 대한 응답을 끝낼 수 있는 미들웨어를 간단한 코드로 쉽게 작성할 수 있게 해줍니다. 여기서는 Hello World라는 문자열을 HTTP 응답으로 내보내도록 하는 코드를 작성해보았습니다.

이 코드를 실행하면 다음과 같이 웹 브라우저에 Hello, World! 라는 문구가 나타날 것입니다.

 

HTTP Query String 받아서 처리하기

Response 속성을 통해 응답을 내보내는 것 말고, 조금 더 나가보기로 하겠습니다. 이번에는 Query String을 입력으로 받아들여 이름을 출력하는 코드를 조금 더 작성해보기로 하겠습니다.

문자열을 다루는 코드를 조금 추가할 것이므로 네임스페이스에 대한 참조가 다음과 같이 추가되어야 합니다.


using Microsoft.Owin;
using Owin;
using System;
using System.Globalization;

 


그리고 앞에서 작성한 Hello, World! 메시지를 내보내는 미들웨어의 코드를 다음과 같이 변경하겠습니다.


var query = context.Request.Query;
var name = query.Get("name");

if (name == null)
    name = "Stranger";

var message = String.Format(
    CultureInfo.InvariantCulture,
    "Hello, {0}!",
    name);

await context.Response.WriteAsync(message);

 


Query 속성의 Get 메서드를 사용하여 Query String 형태로 전달되는 매개 변수의 값을 가져오도록 할 수 있는데, 만약 값을 가져오지 못한다면 NULL 참조를 대신 반환합니다. 이 경우 기본값으로 Stranger로 설정하도록 코드를 작성하였습니다. 그 다음은 익히 잘 아시는 String.Format 메서드를 사용하여 문구를 완성하는 것이고, 응답에 이를 사용하게 됩니다.

그럼 이제 다시 한 번 코드를 실행해보겠습니다. 이름을 지정하지 않은 상태에서는 다음과 같이 실행될 것입니다.

 

그리고 주소 뒤에 ?name=David 라고 입력해봅니다.

 

그런데 여기서 한 가지 궁금한 점이 생깁니다. 보통 웹 프로그래밍을 할 때 흔히 어떤 파일에 대해서 작업을 하고 그 파일을 열어보면 실행된다는 식인데 지금 이 화면을 띄우기까지 어떤 파일 위에서 작업한 것이 아니라 그냥 프로그래밍을 했을 뿐입니다. 다시 말해, 어떤 URL을 경유해서 들어오든 지금 보는 화면과 동작이 적용됨을 뜻합니다. 임의로 아무렇게나 주소를 한 번 넣어보시면 어떤 의미인지 금방 알 수 있습니다. 예를 들어, http://localhost:37339/askbvkkewr?name=David 라고 없는 주소를 임의로 써봅니다.

 

그렇습니다. 어디서 어떻게 들어오든 모든 웹 요청을 전부 방금 만든 미들웨어가 소화를 하도록 되어있는 것입니다. 전통적인 ASP.NET 또는 웹 프로그래밍 환경과는 다르게, OWIN 안에서는 HTTP 서비스 전체를 자유자재로 통제할 수 있습니다.

HTTP POST URL Encoded Form 다루기

마지막으로 한 가지 더 살펴보도록 하겠습니다. Query String도 쉽게 처리할 수 있었는데, 그렇다면 POST로 보내는 요청들도 Katana에서 쉽게 처리할 수 있을까요?

간단하게 요약하면, Katana가 제공하는 Request에 대한 처리는 Request Body를 실시간으로 읽을 수 있는 System.IO.Stream 구현체를 사용하거나, ReadFormAsync() 메서드를 사용하여 URL Encoded Form을 받아들이는 정도를 우선 활용할 수 있습니다. 그러나 흔히 사용하는 Multipart 데이터는 자체적으로 소화할 수 있는 방법은 따로 없고, ASP.NET MVC Web API v2의 도우미 클래스를 사용하여 처리하는 방법을 사용할 수 있습니다. 일단 여기서는 URL Encoded Form의 형태로 받아서 처리할 수 있는 예를 한 번 다루어보도록 하겠습니다.

URL Encoded Form으로 들어오는 요청을 손쉽게 만들기 위하여, 아래와 같이 간단한 웹 페이지를 하나 만들어보도록 하겠습니다. <FORM> 태그의 ACTION 속성 값에 들어갈 URL은 현재 여러분이 만든 OWIN 응용프로그램의 웹 주소로 적절하게 치환하셔야 정상적으로 전송이 됩니다. 이 주소를 확인하는 방법은 방금 만든 프로젝트의 속성을 연 다음, 웹 탭을 클릭하는 것입니다. 참고로 이 주소는 프로젝트 생성 시점에 동적으로 할당되어 프로젝트 설정으로 저장되는 값으로, 개발 과정 중에는 계속 같은 포트 값을 유지할 수 있습니다.

 

위의 주소를 확인하여 아래와 같이 HTML 페이지를 작성하도록 합니다.

<!DOCTYPE html>

<html lang="en" xmlns="http://www.w3.org/1999/xhtml">
<head>
    <meta charset="utf-8" />
    <title>Hello, World!</title>
</head>
<body>
    <form action="http://localhost:37339/" method="post"
          enctype="text/plain">
        <label for="name">Your Name: </label>
        <input type="text" name="name" id="name" />
        <input type="submit" value="Hello?" />
    </form>
</body>
</html>

 

여기서 중요한 것은 <FORM> 태그의 METHOD 속성의 값이 POST라는 것과 ENCTYPE 속성이 “application/x-www-form-urlencoded”로 지정된 것입니다. 이렇게 지정해야 OWIN에서 데이터를 가져올 수 있습니다.

그리고 Form 데이터를 받아서 처리할 수 있도록 아래와 같이 수정합니다.

//var query = context.Request.Query;
var form = await context.Request.ReadFormAsync();
var name = form.Get("name");

 


특별히 바뀐 것은 없습니다. context.Request.Query 속성 대신 context.Request.ReadFormAsync() 비동기 메서드를 호출하여 얻은 결과로 나오는 객체를 활용하도록 하는 것이고 그 이후는 동일한 로직을 사용합니다.

테스트를 위해서 앞에서 만든 HTML 페이지를 브라우저로 열어봅니다. 텍스트 상자 안에 임의의 이름을 넣고 Hello? 버튼을 클릭하면 다음과 같이 입력한 문자열이 반영된 응답이 나오게 됩니다.

 

만약 HTML 폼에서 “application/x-www-form-urlencoded” 대신 “multipart/form-data”를 지정할 경우 ReadFormAsync() 비동기 메서드는 비어있는 컬렉션을 반환합니다.

다음 아티클에서는

다음 아티클에서는 이 특성을 사용하여 좀 더 세밀하고 다양한 미들웨어 프로그래밍을 다루어보도록 하겠습니다.

Posted by Cloud Developer 남정현 (rkttu.com)

댓글을 달아 주세요