MSFL :: 모리스 소프트웨어 공작소

NPM Install 도중에 node-gyp 빌드 오류가 발생하는 경우 Node 기반의 프로그램을 작성하면서 필요한 패키지들을 설정하고 npm install 명령으로 설치를 하다보면 패키지 설정에 의해서 설치 후 빌드 작업이 진행되는 경우가 있다. 이런 경우에 빌드 환경이 제대로 구성되지 않아서 오류가 발생하는 경우가 있어서 정리해 본다. Warning 이 문서에서 모든 환경을 다루는 것이 아니고 msbuild 처리 환경에 대해서만 검토 한 내용이므로 다른 환경인 경우는 적용되지 않는다. 오류 상황 Node 기반에서 돌아가는 어플리케이션을 Github에서 다운로드 받아서 테스트를 위해서 npm install 명령을 했을 때 뜬금없이 msbuild 관련한 환경설정이 부족해서 오류가 발생했다. Python 2.5 이상 3.0 이하 설치 해야 한다는 오류 설치 했더니 .NET Framework 2.0 이상을 설치 해야 한다는 오류 설치 했더니 VCBuil.exe 가 존재하지 않으니 .NET Framework 2.0 SDK 나 Visual Studio 2005를 설치 해야 한다는 오류 기타 등등... 상기의 상태에서 더 이상 진행 불가!!! 물론 전부를 설치하면 되겠지만 그렇다고 쓰지도 않는 툴들을 설치하는 것은 문제가 있어 보인다. 오류 원인 오류의 원인은 간단하다. 해당 어플리케이션 패키지에 정의된 의존성 패키지들 중에 설치과정에서 빌드를 거쳐야 하는 것이 존재하며 Python 으로 구현된 것들과 VC 로 구현된 것을 MSBuild를 이용해서 처리하기 때문이다. 일반적으로 Node 기반의 개발에서는 VSCode 나 Atom 등의 도구와 NodeJS, Git 등의 툴들만 사용하기 때문에 관련된 다른 언어나 IDE 환경이 존재하지 않기 때문이다. 오류 해결 방법 가장 쉬운 방법은 모든 언어와 IDE 개발 환경을 맞춰주면 전혀 문제가 없겠지만, 쓰지도 않는 환경을 단지 설치 상의 빌드 때문에 설치하고 지우는 것도 웃기다. 역시 구글링을 하다보니 이런

  아직 명확하게 DSL 특정 지우기에는 시기상조이기는 하지만 Visual Studio 에서 제공하는 DSL Tools 기능을 이용해서 솔루션을 만들어서 아주 간단하게 실체를 확인해 보도록 하자. DSL Authoring Solution   DSL 을 사용할 수 있도록 DSL 자체를 구성하는 작업을 "DSL Authoring" 이라고 한다. 즉, 배포된 DSL을 이용할 수 있도록 DSL 의 Shape, Connector 등의 기본 요소들을 구성하는 단계라고 보면 된다.   이 작업을 위해서는 사용할 Visual Studio 버전에 맞는 " Visual Studio SDK " 가 미리 설치되어 있어야 한다. 설치가 되어 있다면 Visual Studio에서 새 프로젝트를 추가할 때 아래의 그림과 같이 "확장성" 부분이 있는 것을 볼 수 있다.   "Domain-Specific Language Designer" 는 DSL 구성을 위한 프로젝트들로 구성된 솔루션을 만드는 템플릿이다. 프로젝트 이름과 위치를 설정한 후에 확인 버튼을 눌러서 계속 진행하면 프로젝트를 구성하기 위한 마법사가 진행된다.   DSL 에 대한 Template 은 "Minimal"을 선택하고, DSL 이름은 "IssueStateModels" 라고 지정하도록 한다.   위의 그림과 같이 DSL 을 구성하기 위한 여러 개의 템플릿들이 존재하는 것을 볼 수 있다. MSDN 에는 템플릿들에 대해서 아래의 표와 같이 설명하고 있다. Template Features Description Class Diagrams Compartment shapes Class inheritance Relationship inheritance Shape inheritance Relationship properties Use this sol

  이번에는 프레임워크 구성의 실질적인 중심이 될 수 있는 DSL 에 대해서 여러 가지 자료를 검색해 본 결과를 기준으로 나름대로 하나씩 정리를 해 나가도록 한다. 이 글을 정리하고 있는 현재도 아직 뚜렷한 대상이나 구분이 명확하게 인식된 것이 아니기 때문에 좀 더 많은 글들과 사례들을 확인해 볼 필요가 있다. DSL 이란?   Domain Specific Language (DSL) 은 특정한 도메인(산업, 분야등 특정 영역)에서 발생하는 문제점을 해결하는 것에 중점을 두고 도메인을 기준으로 모든 것을 풀어나가기 위해서 제공되는 언어라고 생각하면 된다. 즉, 특정 영역의 해결에는 그 영역에 맞는 특화된 도구를 사용하자는 의미다. 이와 연관되어 나오는 단어는 DDD (Domain Driven Design) 이라는 것으로 모두 처음 발표된지 이미 최소한 10년 정도의 시간이 경과한 기술이며 정의이다.   현실에서도 많이 구현되어 사용되고 있지만 아직도 DSL 에 대한 정의 자체부터 논란이 있다. 단어 자체로는 "특정 문제에 맞는 언어"라고 볼 수 있지만, 보는 입장에 따라서, 그리고 구현되는 방식에 따라서 다양한 형태로 정의될 수 있기 때문일 것이다.   DSL 에 대해서 가장 잘 정리된 글은 마틴 파울러의 글 을 참고하면 된다. 외부 OOPSLA 컨퍼런스에서 Domain-Specific Modeling 에 대한 워크샾등으로 많은 논의가 되었던 것으로 알고 있다.   DSL 이 도메인 전문자 (Domain Expert) 의 입장에서 작성이 되려면 High-Level 언어로 작성이 되고, 이를 Code Generator를 통해서 일반 언어로 변환이 되어야 한다. 그러나 이런 경우에 코드의 최적화가 어렵고, 프로그래머가 작성하는 DSL 에 비해서 유연성이 떨어질 수 밖에는 없다. 그리고 프로그래머가 작성하는 DSL 도 Internal 과 External 에 따라서 테스트 용이성이나 통합 비용 등에 차이가 날 수 있다.   DS

Events and Commands 이전 게시글 에서 Wizard를 활용하는 방법을 정리해 보았다. 이번에는 추가된 INI 파일을 변경하고 저장하는 시점을 알아내서 관련된 처리를 수행할 수 있도록 처리하는 방법을 정리해 보도록 한다. 이 과정에서 필요한 것들이 Visual Stuidio에서 발생하는 이벤트들을 처리하는 것이며, 관련된 처리를 하기 위해서 Commands 를 호출하는 방법에 대해서 검토하게 된다. Visual Studio Events 가장 먼저 처리해야 하는 부분이 DTE 와 Events 에 관련된 부분을 패키지에서 설정하는 부분이다. 아래의 그림과 같이 패키지 클래스에 관련된 정보를 설정할 수 있도록 코드를 구성한다. 1: private DTE dte; 2: private Events dteEvents; 3: private DocumentEvents documentEvents; 4:   5: private void setupEvents() { 6: this .dte = (DTE) this .GetService( typeof (SDTE)); 7: this .dteEvents = this .dte.Events; 8: this .documentEvents = this .dteEvents.DocumentEvents; 9: this .documentEvents.DocumentSaved += onDocumentSaved; 10: } 위의 코드에서 확인할 수 있는 것처럼 많은 이벤트들이 제공되지만, 그 중에서도 INI 파일이 저장되는 경우에 처리를 수행할 것이기 때문에 “DocumentSaved” 이벤트를 사용하도록 한다. 이 이벤트에 전달되는 파라미터는 “Document” 로 내용이 수정된 문서 개체이다. 이 문서가 *.tini 파일인 경우에 한해서 자식으로 연결되어 있는 *.cs 파일을 찾아서 필요한 처리를 지정한다.

Add a wizard on template 이전 게시글 에서 메뉴와 명령 처리를 설정해서 검증하였다. 이번에는 INI 파일을 단순히 추가하던 기능에 추가하는 과정에서 Culture 정보를 선택할 수 있는 화면을 제공하고 이 화면에서 선택된 Culture를 추가된 파일에 적용하는 구성을 알아보도록 한다. 즉, 쉽게 이야기를 하면 기존 템플릿 처리는 Visual Studio의 내장 마법사를 통해서 처리를 했지만, 이번에는 사용자 정의 마법사 (Custom Wizard)를 구동시켜서 템플릿에 추가적인 정보를 제공할 수 있도록 한다는 것이다. Add a library project Wizard 는 Visual Studio 에서 호출이 되기 때문에 관련된 정보가 vstemplate 파일에 지정되어야 한다. 따라서 별도의 클래스 라이브러리 프로젝트를 추가하여 작업을 하도록 한다. 프로젝트 생성은 따로 설명을 하지 않고 순차적인 처리를 정리해 놓도록 한다. FDTWorksTool.Library 라는 이름의 클래스 라이브러리 프로젝트 (나중에 WPF UI 를 추가할 것이다) 를 생성한다. 자동으로 생성된 클래스 파일은 지운다. 프로젝트를 선택하고 "기존 항목 추가"를 선택하여 서명할 키 파일을 앞에서 생성했던 FDTWorksTool 패키지 프로젝트 경로를 이동하여 "*.snk" 파일을 링크로 추가한다. 프로젝트 속성 창을 열고 "서명" 섹션에서 방금 등록한 snk 파일을 지정하도록 한다. 참조에 "Microsoft.VisualStudio.TemplateWizardInterface" 어셈블리를 추가한다. 아래의 그림은 생성된 클래스 라이브러리 프로젝트를 보여주고 있다. Modify package project 패키지 프로젝트에서는 Wizard를 사용할 수 있도록 위에서 만든 Library 를 추가해 주어야 한다. 참조에 Library Projec

이전 글 에서 단순한 설정 파일을 추가하는 ItemTemplate 프로젝트를 구성해 보았다. 이번에는 이와 연관되어 INI 파일을 처리할 수 있도록 MENU 를 추가하고 MENU에 따른 Command 를 구성해 보도록 한다. Add a simple command with menu Command 를 추가하기 위해서는 Visual Studio와 연계할 수 있는 Command ID를 설정하는 작업을 처리하여야 한다. 패키지 프로젝트를 선택하고 "PkgCmdID.cs" 라는 이름의 클래스 파일을 추가하고 내부의 내용을 아래의 그림과 같이 설정하도록 한다. 클래스의 이름은 PkgCmdIDList 라고 지정한다. 그리고 패키지 클래스 (예제에서는 FDTWorksToolPackage.cs) 에 아래와 같이 특성을 지정해 준다. 위의 특성은 다음과 같은 의미를 가지고 있다. ProvideMenuResource - 이 패키지가 어떤 메뉴 리소스로 표현될 것인지를 Shell에서 알려주는 역할을 담당한다. ProvideAutoLoad - 패키지가 솔루션이 존재하고 모두 완전히 로드된 후에 로드되어야 한다는 것을 알려주는 역할을 담당한다. 이제 Menu 와 Command 를 연결하기 위한 파일을 또 하나 추가하여야 한다. 파일의 이름은 패키지 이름을 사용하여 "FDTWorksTool.vsct" 라고 추가하도록 한다. 그리고 아래의 그림과 같이 기본적인 구성을 하도록 한다. 이제 솔루션을 닫고 일반 텍스트 에디터에서 패키지 프로젝트 파일 (FDTWorksTool.csproj) 을 열고 위에서 추가한 FDTWorksTool.vsct 파일을 지정하고 있는 <ItemGroup> 요소를 찾으면 아래의 그림과 같이 설정되어 있는 것을 확인할 수 있다. 위의 구조를 아래의 구조와 같이 변경하도록 한다. 위의 구성은 다음과 같은 의미를 갖는다. VSCTCompil