Ubuntu on Windows 10으로 GTK# 응용프로그램 개발해보기

Windows 10의 대규모 업데이트에서 개발자들에게 주목을 받고 있는 기능들이 여러가지가 있습니다. 그중에서도 Ubuntu on Windows 10에 대한 관심이 많이들 있으실텐데, 이번 아티클에서는 저 나름대로 찾아본 Ubuntu on Windows 10을 이용한 GTK# 기반의 클라이언트 응용프로그램 개발 방법을 소개해보려고 합니다.

왜 Ubuntu on Windows 10인가?

VM을 사용할 때의 이점은 완전히 독립된 환경을 만들 수 있다는 것이지만, 달리 표현하면 관리해야 할 컴퓨터의 숫자가 늘어난다는 것을 의미하기도 합니다. Ubuntu on Windows 10이 돋보이는 이유는 바로 간편성에 있습니다.

Ubuntu on Windows 10은 Subsystem for Linux 라는 새로운 기능 위에서 작동합니다. 과거에 서버용으로는 Subsystem for Unix라는 기술이 있었는데, 이 때와는 다르게 Windows 운영 체제의 환경과는 분리된 샌드박스된 환경 위에서 실행되고, 바이너리 수준의 호환성을 보장한다는 것이 차이점입니다. 그렇기에 실용적으로 기능을 활용할 수 있고, 호스트로 실행되는 Windows 운영 체제의 안정성을 해칠 만한 상황을 최소화할 수 있어 마음놓고 사용할 수 있습니다.

Ubuntu on Windows 10으로 할 수 있는 일

Ubuntu on Windows 10은 실제 Ubuntu Linux와는 다릅니다. 어디까지나 User Mode에서 실행되는 바이너리 파일에 대한 실행 환경만을 보장할 뿐, 프로덕션 환경에서 실행될 서버를 띄우거나, Windows Shell을 대체하기 위한 목적, 혹은 커널 드라이버 개발 등의 목표를 가지고서는 사용이 쉽지 않고 불편합니다.

VM 없이 Ubuntu Linux에서 실행해볼 필요가 있는 응용프로그램을 사용하거나 테스트하기 위한 용도로만 초점이 맞추어져야 하며, 아티클에서 다루는 모든 내용은 “개발과 테스트”를 전제로 합니다.

준비할 사항

Ubuntu on Windows 10을 시스템에 이미 설치하셨다는 것을 전제로 이 아티클을 참조하여 주십시오. 자세한 설치 방법은 이곳을 참조하여 주십시오.

이 글을 작성한 2016년 8월 현재, Windows 10의 1주년 업데이트가 정식으로 나온 현 시점까지도 Ubuntu on Windows 10과 서브 시스템은 베타 상태에 있습니다. 그리고 이와 관하여 한국어 지원 역시 완전하지 않습니다.

Subsystem을 설치한 후에 Ubuntu on Windows 10을 lxrun으로 처음 설치하실 때에는 Windows 사용자 계정 이름이 영어로 되어있는 것을 춴합니다. 또한 콘솔에서 한국어 출력이 자연스럽지 않은데, 개인적으로는 로캘 설정을 시스템 기본 설정 대신 영어와 UTF-8 인코딩 셋으로 변경하시는 것을 권해드립니다. 변경하려면 bash 셸을 실행한 다음 아래 명령어를 입력합니다.

입력한 다음 bash 셸을 종료하고 다시 시작하면 모든 표시 언어가 미국 영어로 변경되어 나타나게 될 것입니다.

Mono 설치하기

.NET Core의 런타임이 RTM이 출시되었지만 그동안 크로스플랫폼 기반 .NET 개발의 중추적인 역할을 담당하고 있었던 것은 Mono 프레임워크였습니다. 현재까지도 우리가 필요로 하는 대다수의 기능은 .NET Core가 아니라 여전히 Mono 기반이며, .NET Core에서도 자체 런타임 대신 전체 버전의 .NET Framework가 필요한 경우 Mono을 사용하므로 여기서는 Mono의 설치를 먼저 다루도록 하겠습니다.

Ubuntu on Windows 10에 제공되는 Ubuntu Linux는 14.04 (trusty) 버전이며, 버전을 확인해보면 다음과 같습니다.

14.04 버전을 기준으로 Mono를 설치하는 과정을 진행해보도록 하겠습니다. Mono 최신 버전은 운영 체제가 제공하는 패키지 저장소가 아닌 자체 저장소를 통해서 다운로드해야 설치가 가능한데, Ubuntu 계열 운영 체제를 위한 저장소를 사용한 설치 방법 안내 페이지는 이곳을 참조합니다.

아래 명령어를 실행하여 외부 패키지 저장소를 시스템에 등록합니다.

그 다음, mono-complete, referenceassemblies-pcl, monodevelop 그리고 xinit 패키지를 아래 명령어를 실행하여 설치합니다. X-Windows 환경도 이 과정에서 종속성 체인에 의하여 모두 설치가 이루어지므로 디스크 공간 사용량이 크게 늘어나니 주의해야 합니다.

긴 설치 과정이 모두 끝나면 다음 명령어를 실행하여 mono와 mcs 컴파일러가 최신 버전으로 설치되었는지 확인합니다.

MonoDevelop 실행을 위한 설정

이제 개발 환경의 준비는 모두 마무리했고, X Window를 실행하기 위한 준비를 해야 합니다. Windows OS에서는 Xming 서버라는 X Window 호환 서버를 설치할 수 있으며 Ubuntu on Windows에서 쉽게 연결할 수 있습니다.

https://sourceforge.net/projects/xming/ 에서 최신 버전의 Xming 서버를 우선 설치하도록 합니다. 설치 후에는 직접 Xming 서버를 한 번 실행하여 아래 그림과 같이 트레이에 실행 중인 모습을 확인해야 합니다.

Xming 서버와 연결하는 설정을 현재 세션에서만 사용하려면 터미널에서 다음 명령어를 입력하면 됩니다.

그리고 위의 명령어를 현재 로그인한 사용자에 대해서만 항상 적용하려면 아래 명령어를 실행하여 bashrc 파일에 내용을 저장하고 bash 셸을 다시 시작합니다.

설정을 적용한 다음에는 아래 명령어를 실행합니다.

잠시 기다리면 아래 그림과 같이 Windows 10에서 리눅스 버전으로 실행되는 MonoDevelop의 화면이 보입니다.

계속하기 전에, 사용 상의 편의를 위하여 단축 키 바인딩과 글꼴을 Visual Studio에 가깝게 변경해보겠습니다. Edit – Preference 메뉴를 선택한 다음, Environment – Key Binding에 가서 Visual Studio 템플릿을 선택하고, Font에서 원하는 서체와 크기를 지정합니다.

만약 나눔고딕코딩 같은 서체가 필요하다면 다음의 명령어를 실행하고 MonoDevelop을 다시 실행하여 서체 목록을 보면 목록에 표시될 것입니다. D2Coding과 같은 서체는 수동으로 OTF나 TTF 파일을 설치하는 방법을 설명하는 가이드를 참고하시면 되겠습니다.

첫 GTK# 프로젝트 만들고 실행해보기

MonoDevelop이 실행되었으니 GTK# 프로젝트를 한 번 만들어보겠습니다. Visual Studio를 사용하시는 것이 어느정도 익숙하다는 전제에서 출발하겠습니다.

새 솔루션 만들기 메뉴를 선택하면 다음과 같이 화면이 나타날 것입니다. GTK# 2.0 프로젝트 템플릿을 선택합니다. (VB.NET 언어는 제대로 지원되지 않습니다.)

프로젝트 생성 시 Location에서 사용자 홈 디렉터리 아래로 경로를 한 번 선택해주는 것이 좋습니다.

프로젝트를 만든 다음에는 User Interface 트리 아래의 MainWindow를 더블 클릭하여 엽니다.

그러면 디자이너가 열립니다. 여기서 화면 오른쪽의 Toolbox 탭을 더블 클릭하면 우리가 아는 Windows Forms나 WPF 디자이너와 마찬가지로 팔레트가 나타납니다.

GTK#은 Windows Forms와는 다르게, 혹은 WPF처럼 컨테이너라는 부모가 있는 것을 전제로 하며, Windows Forms 처럼 디자인하려면 우선 Fixed 컨테이너가 배치되야 합니다. Fixed 컨테이너를 배치하고 그 위에 버튼을 올려보면 위의 그림과 비슷하게 됩니다.

버튼을 선택하고, Properties 탭을 더블 클릭한 후, Signals 탭을 선택하면 버튼에 대해 지정할 수 있는 이벤트들이 표시됩니다. Button Signals를 펼치고 Clicked 항목을 더블 클릭하면 코드 비하인드에 자동으로 지금 선택한 버튼에 대한 처리기 메서드가 추가됩니다.

이제 디자이너 하단의 Sources 버튼을 클릭하고, 방금 추가했던 이벤트 처리기에 코드를 작성합니다. (메서드 이름은 상황에 따라 다를 수 있습니다.)

이제 F5키를 눌러 프로젝트를 빌드하고 디버거에 연결합니다. 화면이 나타나면 버튼을 클릭했을 때 다음과 같이 표시될 것입니다.

덤으로, 지금 이 상태가 작업 관리자에서는 어떻게 표현되고 있을까요? Mono 4.x 이후부터 공식적으로 채택된 SGEN을 런타임으로 사용하기 때문에 macOS에서 mono 기반 응용프로그램을 돌릴 때와 마찬가지로 mono-sgen 프로세스가 실행 중인 상태인 것을 볼 수 있습니다.

결론

Windows 10에 Linux 서브 시스템이 도입되었다는 것은 시사하는 바가 무척 많으며, 보신 것과 같이, GTK#을 Windows OS로 포팅하지 않고, 네이티브 리눅스와 유사한 환경에서, MonoDevelop으로 쉽게 개발할 수 있는 상태가 되었습니다.

MonoDevelop은 GTK# 만이 아니라 콘솔 프로그램, 그리고 ASP.NET 개발 환경도 지원합니다. 애석하게도 XSP4는 지금 이 아티클을 작성하는 시점에서 제대로 작동하지 않고 있지만 곧 업데이트가 이루어질 것이라고 생각합니다.

또한 MonoDevelop은 NuGet 패키지 설치도 지원하므로 필요한 패키지가 있으면 쉽게 설치할 수 있습니다.

이후에 TCP Listener를 기반으로 하는 서버 애플리케이션이나 ASP.NET Core 실행 사례도 추가 아티클 상에서 살펴보겠습니다.

2016년 6월 24일 모각코 모임 스터디 후기

금요일 저녁임에도 불구하고 모임을 위하여 나와주신 모각코 회원 여러분들께 먼저 감사의 인사를 드립니다.

당일 제가 모임의 주최를 맡고 있긴 했지만 개인사가 있어 8시 가까이에 도착하게 되었습니다. 아마 그때까지만 해도 다들 모여서 서먹서먹하게 인사를 나누시던 정도였던 것 같은데, 그 뒤로 이야기 꽃을 피우고 즐거운 시간을 보냈습니다.

특히 이날 행사에는 GS SHOP에서 근무 중이신 김헌기님, 신승우님, 고은산님과 함께 서문래 프로젝트에 대한 이야기를 나누면서 프로젝트의 취지와, 개발자들의 커뮤니티 참여 확대 방안에 대해 논의할 수 있는 뜻깊은 시간이었습니다.

단상

1.저녁에 모여서 각자 코딩하는 모임 일명 “모각코” 서부지부 모임에 참석하였습니다.

처음에는 인사만 하고 다들 진짜 각자 코딩만 하셔서 아~ 원래 이런 모임이구나 하는 생각을 했습니다.

모임 주최자이신 남정현 님이 조금 늦게 오셨는데 오셔서 말씀을 나누자 언제 각자 코딩했다는 듯이 기술토론의 꽃을 피웠습니다.

재미도 있었지만 제가 아침 단상 때 안드로이드 앱을 처음 개발했다고 적었는데 다들 헬로 들어온 것을 환영하다고 하셔서 무슨 말인지 몰랐는데 안드로이드 파편화를 잘 말씀해 주셔서 이제야 이해했습니다.

개발자들은 진솔한 대화만 나눌 수 밖에 없는 것을 축복이라 생각합니다.

다음에 서문래에 오시면 격렬히 환영해 드리겠습니다.

새턴과 에스코도 좋은 말씀을 많이 해주셔서 더더욱 즐거웠습니다.

한주를 보람차게 마무리 짓습니다.^^

마이크로소프트 멜팅팟 프로젝트를 통하여 계속해서 이와 같은 뜻깊은 개발자들간의 커뮤니케이션과 만남을 꽃피워나갈 수 있도록 하겠습니다.

고맙습니다.

Electron으로 크로스 플랫폼 데스크톱 앱 만들기 #1 – 프로젝트 스캐폴딩

요즈음 모바일 앱은 Xamarin, Cordova 등 다양한 프레임워크를 이용하여 개발하는 사례가 매우 많습니다. 하지만 상대적으로 Desktop App은 이제 막 크로스플랫폼 앱 개발에 대한 논의가 시작되는 단계여서 상대적으로 정보가 많이 적고, 사용할 수 있는 리소스가 모바일 크로스플랫폼 개발에 비해서는 적은 편입니다.

연속되는 아티클 시리즈를 통하여 데스크톱 앱을 크로스플랫폼으로 개발하려고 할 때 시작할 수 있는 유용한 선택지인 Electron과 EdgeJS의 결합 시나리오에 대해 살펴보려고 합니다. 이번에는 그 중 가장 기초가 되는 처음 Electron 프로젝트를 만드는 과정을 살펴보려고 합니다.

Electron에 대하여

Electron은 Github의 크로스플랫폼 에디터인 Atom을 위하여 처음 개발되었고, 그 이후로 많은 발전을 거쳐 여러 애플리케이션의 기반 프레임워크로 현재는 널리 사용되고 있습니다. 최근 큰 주목을 받고 있는 Visual Studio Code는 물론, Slack, 잔디 등 국내외 여러 최신 소프트웨어들이 Electron을 기반으로 하이브리드 + 크로스플랫폼 소프트웨어를 개발하고 있습니다.

Electron의 생태계

Electron은 기술적으로 NodeJS의 기능과 Chromium의 렌더링 엔진을 모두 사용할 수 있습니다. 이 덕분에 Node Package Manager (NPM)과 Bower의 기능을 모두 사용할 수 있어 UI는 익숙하게 사용할 수 있는 jQuery, jQuery UI 및 jQuery Mobile이나 최근 유행하고 있는 Angular 2, React 등을 택할 수 있고, 비즈니스 로직 부분은 TypeScript나 CoffeeScript 등을 활용하여 개발할 수 있습니다.

Electron의 확장성은 여기서 그치지 않고 .NET과의 상호 운용 기능을 제공하는 EdgeJS와도 연동도 제공하고 있습니다. EdgeJS는 Windows에서는 .NET Framework 4.5 이상, Linux와 macOS에서는 Mono 4.x 이상의 프레임워크와 연동되며, C#, F# 등 다양한 언어와의 바인딩과 기존 클래스 라이브러리의 재사용을 모두 소화할 수 있습니다. 기존에 개발했던 Windows Forms나 WPF 기반의 Desktop App을 크로스플랫폼으로 전환하는 것을 염두에 두고 계시다면 현실적인 선택지 중 하나가 될 수 있습니다.

마지막으로, 데스크톱 앱을 수익화하기 위한 방법에서도 Electron은 이제 완벽한 선택지라고 할 수 있습니다. Windows의 경우 이 글을 작성하는 현재 2016년 여름에 Windows 10 Anniversary Update를 통하여 Native App을 스토어에 공식적으로 게시할 수 있게 됨에 따라 Electron App을 스토어에 등록할 수 있고, Linux의 경우 다양한 경우의 수가 있겠지만 데스크톱에서 가장 널리 쓰이는 Ubuntu Software Store에 등록할 수 있으며, Mac App Store로의 Electron App 등록은 이전부터 계속 가능했습니다.

이러한 생태계 아래에서 기존의 Native Application이나 .NET Managed Application을 Electron을 기반으로 리뉴얼을 고려해보실 수 있습니다.

첫 Electron 프로그램 만들기

Electron 기반의 개발 환경은 Windows, Linux, macOS 플랫폼이면 쉽게 구축이 가능합니다. 그 중에서도 이번 아티클에서는 Visual Studio Code를 기반으로 구축하는 예를 들어보려고 합니다.

Visual Studio Code, NodeJS, NPM, Bower를 시스템에 이미 설치한 상태임을 가정하고 진행해보도록 하겠습니다.

작업 디렉터리를 새로 하나 만들고, 해당 디렉터리에서 아래 명령을 실행하여 package.json과 bower.json을 만들어 프로젝트 기준점을 잡도록 합니다.

그 다음, electron-prebuilt 패키지를 개발 종속성 패키지로 설치하여 개발 과정 중에 Electron에 연동하여 사용할 수 있게 합니다.

Bower를 이용하여 jQuery Mobile 패키지를 설치하겠습니다. 패키지 이름이 jquery-mobile-bower인 것을 설치해야 즉시 사용 가능한 jQuery Mobile 패키지가 설치되니 이름에 주의하여 주십시오.

이제 Electron 엔진을 사용하여 창을 띄우고 첫 UI를 표시하도록 코드를 조금 추가해보겠습니다.

package.json 파일을 만들 때, 시작점이 되는 JavaScript 파일의 이름을 따서 새 JavaScript 파일을 만듭니다. 예를 들어, package.json 파일이 아래와 같이 되어있다면 index.js 파일을 새로 만듭니다.

index.js 파일을 다음과 같이 만듭니다.

위의 코드에서 index.html 파일을 로드하도록 하였으므로, index.html 파일을 아래 코드와 같이 만듭니다. 아래 코드의 자세한 내용은 jQuery Mobile 튜토리얼을 참고하시면 이해하기 쉽습니다. (맥락을 정확하게 유지하기 위하여 jQuery Mobile에 대한 내용은 다루지 않겠습니다.)

앞의 단락에서 이야기한 것처럼, Electron은 NodeJS와 통합된 실행 환경을 사용하고 있습니다. 이렇게 하면서 module 프로퍼티가 일반 웹 브라우저와는 다르게 미리 정의가 되는데, 이 때문에 jQuery가 전역 객체로 설정되지 않습니다. (https://blog.outsider.ne.kr/1170 아티클의 내용을 보고 도움을 얻을 수 있었습니다.)
이런 동작은 버그가 아니고 By-Design 사항입니다. 물론 필요에 따라 Chromium의 JavaScript 컨텍스트만 사용하도록 제한할 수 있지만 이렇게 할 경우 Electron의 강력한 기능을 활용할 수 없으므로 이 방법 대신 아래 코드를 compat.js로 저장하여 HTML 페이지에서 먼저 참조하고 그 다음에 jQuery를 로드하도록 수정하여 jQuery와 NodeJS 모듈을 동시에 사용할 수 있게 하려고 합니다.

위의 코드를 사용하여 require, exports, module 프로퍼티를 nodeRequire, nodeExports, nodeModule로 이동시키고, jQuery가 정상적으로 초기화될 수 있게 합니다. 나중에 electron과 연동을 할 때에는 새 이름으로 정의된 객체를 사용하도록 하여 어렵지 않게 연동이 가능하게 됩니다.
이렇게 코드를 구성하고, 아래와 같이 명령을 작업 디렉터리 내에서 실행하면 앱이 실행됩니다.

001
Production 버전으로 패키지를 만든 것이 아니고, 메뉴 등이 그대로 표시되므로 Developer Tool을 이용할 수 있습니다. Developer Tool을 View – Toggle Developer Tool 메뉴로 켜고 끌 수 있으며, 실행하면 창 하단/우측에 붙어서 나오거나 아래 그림처럼 별도의 창으로 띄울 수도 있습니다.
002

다음 아티클에서는

다음 아티클에서는 Visual Studio Code와 통합 디버깅 환경을 설정하는 방법과 JavaScript 디버깅을 손쉽게 수행할 수 있는 방안을 살펴볼 에정입니다.

[팁] MySQL Workbench에서 닫은 탭이 다음번에 다시 열리는 현상 해결하기

MySQL 서버를 사용하신다면 MySQL Workbench를 통해서 MySQL 서버 관리를 하거나 데이터베이스 응용프로그램 개발에 활용하는 등 여러모로 자주 사용하시게 될텐데요, 특이하게도 작업 중에 닫았던 탭의 내용이 지워지지 않고 나중에 그대로 복원되는 문제가 보입니다.

이 현상은 MySQL Workbench의 작업 공간 데이터 파일이 탭 닫기 기능을 통해서 정상적으로 삭제되지 않아서 발생하는 것으로 보입니다. 따라서 문제를 해결하려면 수동으로 작업 공간 데이터 파일을 백업하여 다른 곳으로 이동시키거나 필요하지 않은 파일을 삭제하는 해결 방법을 적용해야 합니다.

작업 공간 데이터 파일의 위치는 Windows의 경우 아래 폴더 경로에 있습니다.

%userprofile%AppDataRoamingMySQLWorkbenchsql_workspaces

이 폴더에 들어가면 접속했던 서버 별로 폴더가 나뉘어져있으며 각 폴더에는 쿼리를 수행했었던 데이터 파일들이 남아있습니다. Workbench 프로그램을 종료한 다음 각 데이터 파일을 백업하거나 삭제하는 등의 작업을 수행한다음 다시 접속하면 데이터 파일들에 의해서 모든 탭들이 다시 열리는 문제가 해결됩니다.

Azure에서 NAS (SMB, CIFS) 사용하기

Azure의 초창기부터 제공되어오던 핵심 서비스 중에서 저장소가 있습니다. 저장소는 Amazon Web Service 등과 마찬가지로 BLOB 저장소, 큐 저장소, 테이블 저장소로 구성되어있습니다. Azure 가상 컴퓨터는 VHD 파일을 BLOB 저장소 상에 만들어 가상 컴퓨터를 부팅하고 실행 중 일어나는 데이터 읽기와 쓰기 작업을 BLOB 저장소 상의 VHD 파일과 동기화합니다.

높은 수준의 가용성을 보장받고, CDN 과의 연동 등을 생각하면 BLOB 저장소를 이용하여 파일을 관리하는 것은 여러모로 이상적입니다. 하지만 모든 경우에 대해 사용 가능한 옵션이 아니고, 기존에 SMB (CIFS) 형태로 개발해서 사용해왔던 온 프레미스 애플리케이션들은 이런 방법을 사용할 경우 완전히 애플리케이션을 새로 개발해야 하기 때문에 적절한 선택지가 되기 어렵습니다.

지금 소개해드릴 방법은 SMB (CIFS) 형태의 저장소를 사용하는 기존 애플리케이션을 손쉽게 Azure로 마이그레이션할 수 있는 방법입니다.

Azure 파일 저장소의 이해

Azure 파일 저장소는 BLOB 저장소와 다른 개념을 가지고 있습니다. BLOB 저장소는 “컨테이너”라고 불리는 파티션 안에 많은 갯수의 파일을 저장할 수 있으며, 파일의 이름에 경로 구분 문자인 ‘/’를 지정할 수 있어 Prefix Match 방식으로 계층적인 접근을 다룰 수 있었습니다. 그리고 모든 입출력은 HTTP 프로토콜만을 사용한다는 것이 특징이었습니다.

반면 파일 저장소는 “공유”라고 불리는 파티션을 할당하며, 이 파티션 내에 전통적인 파일 시스템의 디렉터리와 파일을 저장할 수 있습니다. 하나의 공유를 만들게 되면 최대 크기를 지정하게 되며, Azure 저장소 이름을 사용자 ID, 기본 액세스 키를 비밀 번호로 하는 계정이 자동으로 부여됩니다.

files-concepts

Azure 파일 저장소가 도입되기 이전에 이와 같은 컨셉을 구현하기 위해서는 Azure VM을 만들고, 추가 디스크를 부착한 다음, VM 간의 가상 네트워크를 만드는 등의 추가 절차를 거쳐 SMB (CIFS) 공유를 형성할 수 있었습니다. 하지만 설명에서도 대강 열거되어있듯이 많은 리소스를 투여해서 복잡하게 구성해야 했기 때문에 시간, 확장성, 경제적인 면에서 모두 비효율적이었습니다.

하지만 Azure 파일 저장소가 정식으로 릴리스됨에 따라 별도의 추가 VM이나 가상 네트워크 구성 없이 더 확실하고 견고하면서도 직관적인 SMB (CIFS) 서비스를 사용할 수 있게 되었습니다.

무엇이 더 좋아지는가?

Azure 파일 저장소를 사용하면 다음의 이점이 있습니다.

  • 적어도 LRS (로컬 중복 저장)와 GRS (지역 중복 저장) 복제 정책 중 하나의 혜택을 볼 수 있어 장애 대응에 탁월한 선택지가 될 수 있습니다. 최소 수준으로 LRS만을 택하더라도 세 벌 이상의 복제본이 동시에 관리되며, GRS는 LRS를 기반으로 지역 내 데이터센터간 비동기 복제도 같이 겸하게 됩니다.
    • 이 부분에 대한 자세한 내용은 https://azure.microsoft.com/ko-kr/documentation/articles/storage-redundancy/ 페이지를 참고하시면 좋습니다.
  • 관리 도구와 웹 API를 활용하여 파일 저장소 상에 파일을 다운로드하거나 업로드하거나 관리할 수 있습니다.
    • Cloudberry Azure Storage Explorer 등의 서드 파티 도구를 사용하면 VM 밖에서도 편리하게 웹 API를 사용하여 파일을 업로드하거나 다운로드할 수 있습니다.
    • 다만 파일 공유의 특성 상 VM 내에서 파일을 열고 있어 잠기는 경우 웹 API에도 동일한 상황이 나타나게 됩니다. 동시성에 민감하다면 이 부분은 주의를 요합니다.
  • ISP가 TCP/445 아웃바운드 연결을 차단하지 않는다는 전제 하에 (혹은 Azure 데이터센터로 VPN 연결을 만든 다음에) 클라우드 외부에서 SMB (CIFS) 방식으로 직접 접근하는 것도 가능합니다.
  • 리눅스 VM에서도 파일 저장소를 사용할 수 있습니다.
    • 이 부분에 대한 자세한 내용은 https://azure.microsoft.com/ko-kr/documentation/articles/storage-how-to-use-files-linux/ 페이지를 참고하시면 좋습니다.

Azure 파일 저장소를 실제로 사용해보기

Windows 가상 컴퓨터를 기준으로 Azure 파일 저장소를 실제로 사용해보도록 하겠습니다.

1단계: 저장소 계정과 공유 만들기

portal.azure.com으로 이동하여 저장소 계정을 새로 만들거나 기존 저장소 계정에 대한 블레이드를 다음과 같이 열고, 액세스 키 메뉴를 클릭합니다.

001

그 다음 저장소 계정 이름과 KEY 1의 값을 잘 기록해둡니다. 이이서 서비스 섹션의 파일 버튼을 클릭합니다.

002

도구 모음의 공유 추가 버튼을 누르면 새 공유 볼륨을 만들 수 있습니다. 적절한 이름과 크기를 지정하면 새로운 공유 볼륨이 만들어집니다.

003

2단계: VM에서 공유 폴더 접근 테스트하기

1단계에서 메모한 정보를 참고하여 접속을 테스트합니다.

  • 파일 저장소의 경로는 \<저장소 계정 이름>.file.core.windows.net<공유 이름> 으로 바꿉니다.
  • 접속 시 사용자 ID는 <저장소 계정 이름>을 사용합니다.
  • 접속 시 사용자 비밀 번호는 <KEY 1의 값>을 사용합니다.

그러면 VM 내에서 다음과 같이 폴더 창을 열고 파일 입출력을 테스트해볼 수 있습니다.

004

3단계: 사용자 계정을 추가하고 서비스 등에 연결하기

파일 저장소에 접근이 잘 되는 것을 확인하였다면 Windows 사용자 계정을 만들어 서비스 등의 시작 계정으로 지정하면 편리하게 사용할 수 있습니다.

정리

운영 중인 레거시 애플리케이션을 Azure 기반으로 마이그레이션하게 된다면, 여러 가지 고려 사항이 있을 수 있겠지만, 그 중에서 스토리지에 관한 부분은 다음과 같이 정리할 수 있습니다.

  • 파일 저장소의 경로는 \<저장소 계정 이름>.file.core.windows.net<공유 이름> 으로 바꿉니다.
  • 접속 시 사용자 ID는 <저장소 계정 이름>을 사용합니다.
  • 접속 시 사용자 비밀 번호는 <KEY 1의 값>을 사용합니다.
  • IIS나 NT 서비스 등에서 사용하기 위한 Windows 계정을 만들고 새로 지정합니다.

그리고 다음의 제약 사항은 마이그레이션 이전에 검토해야 할 수 있습니다.

  • 공유 볼륨을 열거하는 기능은 2016년 4월 현재 제공되지 않습니다. 즉, \<저장소 계정 이름>.file.core.windows.net 으로 접근해서는 경로가 잘못되었다는 오류 메시지만 보게 됩니다.
    • 이와 관련하여, IIS에서 Azure 저장소 공유 볼륨에 대해 가상 디렉터리를 만들고 권한 체크를 하려고 시도하면 경로가 존재하지 않는다는 오류 메시지가 나타나게 되지만, 무시하셔도 됩니다.

IDisposable 패턴의 올바른 구현 방법

.NET Framework에서 새로운 클래스를 만들 때 여러가지 메모리 관리 디자인 패턴과 기법을 적용할 수 있지만, 한시적으로 사용해야 할 필요가 있는 자원들을 묶어서 관리할 때에는 IDisposable 패턴을 적극적으로 활용하는 것이 매우 유용합니다.

하지만 생각보다 IDisposable 패턴을 제대로 구현해서 사용하는 것은 쉽지 않으며 잘못 구현하기 쉽습니다.

이 아티클에서는 IDisposable 패턴을 구현하는 몇 가지 일반적인 전략들을 소개합니다. 잘못 설명된 부분이 있거나 보충이 필요한 부분은 댓글로 피드백을 자세히 남겨주시면 적극 반영하겠습니다.

IDisposable 인터페이스에 대한 이해

IDisposable 인터페이스가 제공하는 Dispose 메서드는 명시적이고 코드 작성자가 직접 호출할 수 있는 finalizer로, 이 메서드가 불리면 가비지 컬렉터에 의하여 나중에 호출되는 finalizer의 역할을 대체하도록 되어있습니다. 물론, 메모리 상에 할당된 메모리 블록의 해제까지 건너뛴다는 의미는 아닙니다.

그리고 무엇을 Dispose 메서드에서 제거해야 하는지 기준을 세운다면 객체에 대한 소유 권한을 정의하는 것이 필요합니다. 적어도 다음의 경우에는 확실히 Dispose 메서드 내에서 정리가 되어야 합니다.

  • 해당 객체를 Dispose 하게 되면 외부에서 더 이상 사용하는 것이 의미가 없는 객체 (예를 들어 클래스 내부에서 사용하던 파일 입출력 관련 객체, 비동기 작업을 위하여 만들어 놓은 스레드 관련 객체)
  • 외부에서 전달받은 객체이지만 객체의 생명 주기를 위탁하여 관리하도록 지정한 객체 (예를 들어 StreamReader나 StreamWriter가 객체 생성 시 인자로 Stream을 받는 사례)

가장 기본이 되는 IDisposable 구현 패턴

.NET 은 finalizer에 해당되는 멤버를 재정의할 수 있습니다. 하지만 finalizer가 언제 호출이 될 것인지 기약할 수 없으므로 이 finalizer를 대신하여 좀 더 이른 시기에 명시적으로 소멸자와 동등한 효과를 낼 수 있도록 만든 것이 바로 IDisposable.Dispose 메서드가 되겠습니다.

IDisposable 패턴을 처음 구현할 때에는 다음의 사항들이 핵심이 됩니다.

  • protected virtual void Dispose(bool disposing) 메서드를 추가합니다. sealed 클래스에 대해서는 private void Dispose(bool disposing)으로 바꾸어 정의합니다.
  • 객체가 dispose 처리가 이루어진 상태인지를 관리할 수 있는 boolean 필드를 하나 추가하고 이 필드는 기본값을 false로 설정합니다.
  • Dispose(bool disposing) 호출 시 다음의 로직을 구현합니다.
    • 만약 객체가 dispose 상태인 경우에는 함수를 종료합니다.
    • 객체가 dispose 상태임을 필드에 지정합니다. (true로 설정)
    • disposing 매개 변수의 상태와 관계없이 P/Invoke 등을 활용하여 메모리 할당을 받은 나머지 모든 리소스들에 대해 할당을 해제하는 코드를 추가합니다.
    • disposing 매개 변수가 true로 전달되는 경우는 명시적으로 Dispose 메서드를 호출한 경우이며, 이 때에 다른 모든 IDisposable을 구현하는 객체들을 Dispose 처리합니다.
  • IDisposable.Dispose 메서드 구현 시 Dispose(true)를 호출하고 finalizer 호출을 건너뛰기 위하여 GC.SuppressFinalize(this)를 호출합니다.
  • 소멸자에서는 Dispose(false)를 호출합니다.

다음은 코드 예시입니다.

IDisposable 객체의 컬렉션에 대한 소거

소켓, 스레드 풀, 혹은 커넥션 풀 같은 컬렉션을 객체 내부에 보관해야 하는 경우도 있습니다. 이러한 경우에도 컬렉션 내의 모든 IDisposable 객체에 대해서 정리를 하는 것이 필요합니다.

  • 컬 렉션 내의 모든 요소가 IDisposable 인터페이스를 구현하고 있다면 Dispose(bool disposing) 메서드에서 disposing이 true일 때 정리를 하면 됩니다. 그렇지 않은 경우, disposing 매개 변수의 상태에 무관하게 정리합니다.
  • Dispose 작업 도중 새로운 항목이 추가되는 것을 방지하기 위하여 disposed 필드를 확인하도록 하는 코드를 추가해야 할 수 있습니다.
  • 컬렉션 내의 모든 요소를 배열에 복사하여 Immutable Collection으로 변환한 다음 하나씩 방문하여 Dispose를 진행하고, 최종적으로 컬렉션의 요소들을 모두 제거합니다.

다음은 코드 예시입니다.

Dispose 메서드 내의 예외 처리

만약 Dispose 메서드를 실행하는 도중에 예외가 발생한다면, CA1065의 지침에 따라 명시적인 Dispose 호출이었든 아니었든 예외를 전파하지 않도록 처리하는 것이 필요합니다. 다만 명시적으로 Dispose를 호출하면서 예외가 발생했다면 예외를 전파하지 않는 대신 적절한 예외 처리는 필요합니다.

이 부분에 대한 자세한 내용은 https://msdn.microsoft.com/ko-kr/library/bb386039.aspx 페이지의 내용을 참고하시면 도움이 될 것입니다.

컬렉션 내의 모든 요소들을 Dispose 하는 코드를 조금 더 보강하면 다음과 같이 고쳐쓸 수 있겠습니다.

소유하고 있는 객체들에 대한 Dispose 또는 정리 작업들을 각각 try, catch, finally 블록안에 두어 예외가 발생하면 적절한 예외 처리를 할 수 있게 하고, Dispose 메서드 전체에 대해서 try, finally 블록 안에 두어 예외가 전파되지 않도록 하였습니다.

결론

.NET Framework 기반의 응용프로그램이 안정적으로 장시간 실행될 수 있게 만들어야 할 때 고려해야 할 요소들 가운데에서 가장 비중있게 다루어야 할 부분이 바로 메모리 관리입니다. IDisposable 인터페이스를 통한 명시적인 finalizer 호출은 적절하게 활용하면 응용프로그램의 메모리 관리를 단순하게 만드는데 큰 도움을 줍니다.

구관이 명관 – 어느 위치에서 실행하든 경로를 유지하는 배치 파일 만들기

오랫만에 구관이 명관 시리즈를 업데이트해봅니다. 이번 아티클은 작지만 확실히 유용한 팁 하나를 소개해볼까 합니다. 배치 파일을 작성하고 배포할 때 가장 큰 문제가 되는 것이, 배치 파일이 의도하지 않은 디렉터리 경로 상에서 실행된다는 점일 것입니다.


 


 


예를 들면 배치 파일을 명령어나 다른 프로그램을 이용하여 실행하면 배치 파일이 있는 경로가 아닌 호출한 프로그램의 현재 디렉터리 경로 위에서 실행되어서 문제가 될 때가 있습니다. 물론 배치 파일의 이런 특성을 활용해야 하는 경우도 있겠습니다만, 보통은 배치 파일을 실행할 때 정확히 해당 경로 상에서 어떤 작업을 하도록 의도한 것이 많으므로 이런 특성은 불편할 수 있습니다.


이 문제를 수정하려면 배치 파일의 경로를 항상 정확하게 알 수 있어야 하는데, 이럴 때 %~dp0 환경 변수를 사용하면 쉽게 문제를 해결할 수 있습니다. 하지만 무작정 cd 명령을 사용하면 배치파일이 끝나고 난 다음에 디렉터리 위치가 원래대로 돌아오지 않는 문제가 남습니다.


이런 문제를 해결하기 위하여, 새로 작성하는 배치 파일의 시작과 끝을 아래의 코드처럼 작성하도록 하면 편리할 것입니다.
@echo off
pushd “%~dp0”


rem 여기에 배치 파일 본문을 작성합니다.


:exit
popd
@echo on



 


내용은 단순합니다. 실행하는 명령줄이 보이지 않게 @echo off로 감추고, pushd 명령을 사용하여 스택에 현재 디렉터리 경로를 push하고 새 위치로 이동한 다음 원하는 일을 하는 것입니다. 그리고 나중에 종료할 때에는 popd 명령을 사용하여 직전에 저장한 디렉터리 경로를 꺼내와 그 위치로 다시 이동하고 @echo on으로 (심미성을 위하여 @echo on이라고 썼습니다.) echo 상태를 복원합니다. 여기서 :exit 라벨은 프로그램 내에서 탈출 조건을 만났을 때 편리하게 활용할 수 있도록 하기 위한 것입니다.


위의 예제를 활용하면 다음과 같이 응용할 수 있습니다.


@echo off
pushd “%~dp0”



if not exist %windir%system32runas.exe. (
    echo RUNAS.EXE 프로그램을 찾을 수 없습니다.
    pause
    goto exit
)


for /r “%~dp0” %%v in (test.cmd) do (
    if exist “%%v” (
        echo %%v 진행 중…
        call “%%v”
        rem 다른 배치 파일을 호출하고나면 echo on 상태가 되므로 다시 @echo off로 꺼줍니다.
        @echo off
    )
)


:exit
popd
@echo on



 


위와 같이 활용한다면 배치 파일을 어디서 실행하든 원하는 경로로 들어갔다가 다시 쉽게 원래 위치로 되돌아올 수 있으므로 일반 프로그램처럼 배치 파일을 작성하는 것이 좀 더 쉬워집니다.

ubuntu 14.04에서 asp.net vnext 설치하고 사용하기, mono 3.8 업데이트

NOTE: 지난 번에 올렸던 글 이후로 mono 3.8이 빠르게 추석 연휴를 사이로 업데이트가 되었는데, mono의 최신 버전을 설치하는 과정이 무척 복잡하고 까다로웠던 점이었던게 상당히 아쉬웠습니다. 그런데 이 부분이 잘 해결된 듯 하여 업데이트된 내용을 더해 글을 더 보강하여 다시 게시합니다.


 


 


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


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


사전 준비 작업


중요: 이 아티클에서 소개하는 내용은 Ubuntu 14.04에서 작동하며, Ubuntu 12 버전에서는 패키지 버전 불일치 등으로 인하여 mono 3.8이 정상적으로 설치가 되지 않아 실행할 수 없습니다.


최근들어 변경된 사항으로, Mono의 최신 버전 릴리즈는 Xamarin이 독자적으로 운영하는 패키지 리포지터리를 통하여 좀 더 빠르게 받아보실 수 있습니다. 하지만 2014년 9월 현재 모든 배포판에 대해 완전하게 설치를 보장하는 것이 아닌 것으로 보입니다.


Mono 3.8 및 그 이후 버전을 설치하기 위하여 우선 해야 할 일은 Xamarin 리포지터리를 시스템에 추가하는 일입니다.


단순한 설명을 위하여, 현재 로그인한 사용자의 홈 디렉터리로 일단 디렉터리 변경을 하겠습니다.



cd ~


Xamarin 리포지터리의 GPG Key를 내려받도록 합니다.



wget http://download.mono-project.com/repo/xamarin.gpg


그리고 내려받은 GPG 키를 저장합니다.



sudo apt-key add xamarin.gpg


/etc/apt/sources.list 파일을 편리한 텍스트 편집기로 열고, 가장 마지막에 다음의 줄을 추가한 후 저장하고 닫습니다.



deb http://origin-download.mono-project.com/repo/debian/ wheezy main


패키지 캐시를 업데이트하기 위하여 아래 명령어를 실행합니다.



sudo apt-get update


이제 Mono 3.8을 설치할 준비가 다 되었습니다. 아래 명령어만 실행하면 됩니다.



sudo apt-get -y install mono-complete


설치가 다 끝나면 mono의 버전을 확인해봅니다.



mono –version


K Runtime과 ASP.NET vNext 설치하기


Mono 3.8이 9월에 릴리즈하고 나서 K Runtime과 ASP.NET vNext를 테스트하는 방법에도 조금 변화가 생겨서 그 내용을 같이 말씀드립니다.


HTTPS/SSL 인증서들을 추가하고 Mono에서 사용할 수 있도록 동기화하는 작업을 반드시 실행합니다.



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


ASP.NET vNext를 실행하기 위해서는 unzip 패키지가 필요합니다.



sudo apt-get install unzip


그리고 ASP.NET vNext 설치 스크립트를 내려 받습니다.



curl https://raw.githubusercontent.com/aspnet/Home/master/kvminstall.sh | sh && source ~/.kre/kvm/kvm.sh


source 명령을 사용하여 K runtime을 쉽게 실행할 수 있도록 설정합니다.



source ~/.kre/kvm/kvm.sh


2014년 9월 23일 현재 최신 버전은 1.0.0-alpha4-10353입니다. 이 버전을 내려 받기 위하여 KRE_FEED 환경 변수에 Feed URL을 설정하고 해당 버전을 설치합니다.



export KRE_FEED=https://www.myget.org/F/aspnetvnext/api/v2
 kvm install 1.0.0-alpha4-10353


예제 소스 받아서 테스트해보기


이전 아티클에서 이야기했던 내용을 좀 더 보강하면, 현재 ASP.NET vNext의 k web 명령은 아직 Windows 환경에서만 실행이 가능한 상태입니다. Mono를 통하여 웹 서버를 시작하고 ASP.NET vNext를 호스팅할 수 있게 하려면 project.json에 별도의 명령어를 추가해주어야 합니다. 물론 이는 추후에 정식 버전이 릴리즈가 될 때 당연히 해결될 문제이므로 걱정하지 않으셔도 됩니다.


git 패키지를 설치하도록 합니다.



sudo apt-get install git


ASP.NET vNext Home 리포지터리에서 예제 소스를 체크아웃합니다.



git clone https://github.com/aspnet/Home.git


늘 그렇듯이, 콘솔 프로젝트를 시작점으로 잡아봅니다. 🙂



cd ~/Home/samples/ConsoleApp/
 kpm restore
 k run


그리고 현재 알파 버전의 ASP.NET vNext 기준으로 리눅스에서 웹 서비스를 실행해보기 위해서는 NOWIN 팩토리 패키지를 구성해야 할 필요가 있습니다.



cd ~/Home/samples/
 mkdir Nowin.vNext
 cd Nowin.vNext
 wget https://github.com/davidfowl/HelloWorldVNext/raw/master/src/Nowin.vNext/NowinServerFactory.cs
 wget https://github.com/davidfowl/HelloWorldVNext/raw/master/src/Nowin.vNext/project.json


위와 같이 준비되면, HelloWeb 프로젝트의 project.json에 들어있는 dependencies 섹션과 commands 섹션을 편집기로 조금 수정하여 앞서 만든 NOWIN 팩토리로 서버를 띄울 수 있게 해야 합니다. project.json에 대한 자세한 내용은 Project.json 파일 을 참고하십시오.



cd ~/Home/samples/HelloWeb/


project.json 파일을 편집기로 열고 각각 다음의 사항을 반영하도록 합니다.
•dependencies에 다음을 추가합니다.
“Nowin.vNext”: “”,
•commands에 다음을 추가합니다.
“nowin”: “Microsoft.AspNet.Hosting –server Nowin.vNext”,


project.json 파일을 저장하고, 다음의 명령어를 실행합니다.



kpm restore
 k nowin


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


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


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


마무리


ASP.NET vNext는 계속 업데이트가 이루어지고 있는 상태이며, Mono 런타임의 개선에 따라 리눅스와 맥 OS X에서 ASP.NET vNext를 사용하는 것이 좀 더 쉬워지고 간편해질 전망입니다. 더 많은 기대를 해도 좋지 않을까 생각합니다. 🙂


 

Project.json 파일

번역: 남정현



날짜: 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]


 

.NET에서의 String과 Null Character에 대한 이야기

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


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


 


 



문자열은 값이 텍스트인 String 형식의 개체입니다. 내부적으로 텍스트는 Char 개체의 순차적 읽기 전용 컬렉션으로 저장됩니다. C# 문자열 끝에는 null 종결 문자가 없습니다. 따라서 C# 문자열은 포함된 null 문자(‘′)를 제한 없이 포함할 수 있습니다. 문자열의 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(”’, ”);
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(”’, ”).Trim();
Console.WriteLine(“d: {0} (Length: {1})”, d, d.Length);



 


앞/뒤로 붙은 null character를 제거하려면 null character를 명시하는 작업이 필요합니다. 그리고 이것은 Replace 메서드에 대해서도 동일하게 적용됩니다.
</pre>
<pre>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(”’, ”).Trim(”);
Console.WriteLine(“d: {0} (Length: {1})”, d, d.Length);



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