기본 콘텐츠로 건너뛰기

[VSIX] Visual Studio 확장에 대해서... #3 Command 추가

이전 글에서 단순한 설정 파일을 추가하는 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 파일을 지정하고 있는 요소를 찾으면 아래의 그림과 같이 설정되어 있는 것을 확인할 수 있다.


위의 구조를 아래의 구조와 같이 변경하도록 한다.


위의 구성은 다음과 같은 의미를 갖는다.
  • VSCTCompile - VSCT 컴파일러를 통해서 해당 파일이 컴파일 되어야 한다는 것을 설정한다.
  • ResourceName - 위에서 패키지 클래스에 지정한 특성인 "ProvideMenuResource" 에 지정한 리소스 명을 똑같이 지정하여 사용할 수 있도록 설정한다.

Create the menu

이제 다시 솔루션을 열고 패키지 프로젝트에 생성해 놓았던 vsct 파일을 구성하여야 하는데 아래의 개념적인 구조를 알아보고 진행하도록 하자.


위의 내용을 보면 뭔가 굉장히 복잡(?)스럽다. 그러나 몇 가지 규칙을 정리하면 그나마 위안이 된다.
  • guid - 그룹 또는 메뉴 그룹을 식별하기 위한 식별 코드라고 이해하면 된다. 즉, 부모의 guid를 자식 요소들에서 같이 사용한다는 뜻이다.
    • Commands, Groups, Menus, Buttons, Symbols 와 같이 그룹으로 처리하고 싶은 경우에 설정한다.
    • 설정한 guid 는 반드시 이후에 확인할 Symbols 섹션에 정의가 되어 있어야 한다.
    • 위의 예제에서는 패키지 내부에서 사용할 모든 요소들이 guidFDTWorksToolCmdSet 이라는 guid 값으로 묶여서 사용된다.
  • id - 각 항목을 식별하기 위한 코드라고 생각하면 된다.
    • guid로 묶인 항목들 중에서 개별 항목을 식별할 수 있는 값으로 반드시 특정 GuidSymbol 값들 중에 하나로 지정되어야 한다.
    • 설정한 id 는 이후에 확인할 GuidSymbol 섹션에 IDSymbol 태그로 정의가 되어있어야 한다.
이제 개념적인 것을 확인해 보았으니 아래와 같이 완전한 vsct 파일을 구성해 보도록 한다.



    
    
    
    
<!-- 패키지 Command 정의 -->
<Commands package="guidFDTWorksToolPkg">
    <Menus>
 <!-- Main Item Menu Group 밑으로 표시될 서브 메뉴 정의 -->
 <Menu guid="guidFDTWorksToolCmdSet"
id="FDTWorksToolSubMenu"
priority="0x0000"
type="Menu">

FDTWorks

<Symbols>
    <!-- 패키지 식별 GUID (Guids.cs 연계) -->

<!-- 그룹과 메뉴 명령 식별 GUID (Guids.cs 연계) -->


위의 내용을 보면 우선 가장 아래 부분에 사용할 Symbols 섹션을 통해서 guid 와 id 로 사용될 값들이 지정된 것을 볼 수 있다.
  • GuidSymbol / FDTWorksToolPkg - 패키지 자체의 guid 를 의미한다. 값은 패키지가 생성될 때 자동으로 생성된 Guids.cs 파일에 상수로 저장된 값을 사용한다.
  • GuidSymbol / FDTWorksToolCmdSet - 메뉴 및 명령 처리에 사용할 guid를 의미한다. 값은 패키지가 생성될 때 자동으로 생성된 Guids.cs 파일에 상수로 저장된 값을 사용한다.
그리고 IDSymbol 중에서 vsct 파일에 내부적으로 정의되지 않고 사용된 cmdidGenerateIni 의 값인 0x0100 은 위에서 만들었던 PkgCmdID.cs 파일에 정의된 값을 사용하는 것이다.

나머지 Menus, Groups, Buttons 는 각각 Parent 요소를 가지고 있고, 이를 통해서 자신이 누구의 밑으로 위치해야 하는지를 연결하게 된다. 위의 vsct 파일에서는 가장 최상위가 guidSHLMainMenu 로 IDM_VS_CTXT_ITEMNODE (Visual Studio 가 제공하는 항목 처리용 Context 메뉴) 가 되고 그 밑으로 패키지에서 사용하는 Group 과 Menu, Button 이 연결되어 표시되게 된다.

guidSHLMainMenu 값은 vsct 파일의 상단에 정의한 두 개의 헤더 파일 내에 정의되어 있는 값이다. 이와 관련해서 좀 더 상셍한 정보는 MSDN을 통해서 확인하면 된다.

여기까지 작업을 하고 F5 나 Ctrl + F5 로 실행을 해 보면 아래의 그림과 같이 프로젝트 내의 특정 항목을 선택하고 마우스 오른쪽 버튼을 눌러 나오는 컨텍스트 메뉴에 패키지에서 구성한 메뉴가 보이는 것을 확인할 수 있다.


위의 그림에서 확인되는 것과 같이 프로젝트 내에서 특정한 항목 (여기서는 Programs.cs) 을 선택하고 컨텍스트 메뉴를 호출하면 "FDTWorks" 와 "Generate Ini" 메뉴가 보이는 것을 확인할 수 있다.

Connecting the action

현재까지는 단순히 눈에만 보이는 메뉴 구조가 완성되었을 뿐이다. 실제 메뉴를 통해서 연계되어 동작할 코드는 없으므로 처리를 추가하여야 한다.

우선 패키지 클래스 (FDTWorksToolPackage.cs) 의 Initialize 메서드에 아래의 그림과 같이 Command 를 생성하고 등록하는 코드를 구성하도록 한다.


메뉴 서비스와 연동되는 작업은 위의 코드로 구성되었기 때문에 위의 코드에서 지정한 것과 같이 메뉴가 눌렸을 때 호출될 이벤트 콜백 메서드를 작성하여야 한다.

이 콜백 메서드에서는 EnvDTE (Visual Studio IDE) 에서 선택된 항목 (컨텍스트 메뉴를 보여주기 위해서) 의 이름과 전체 경로를 메시지 박스로 처리하는 것을 샘플로 사용할 것이다. 따라서 이 기능을 위해서는 다음과 같은 작업이 진행되어야 한다.

  • GetService 메서드를 통해서 DTE 인스턴스를 가져온다.
  • 인스턴스를 통해서 현재 선택된 항목 (Multiple 선택 가능) 들을 가져온다.
  • 해당 항목의 프로젝트 구성항목 (ProjectItem) 을 가져온다.
  • 만일 null 이라면 제외하고 그렇지 않다면 전체 경로를 제공하는 속성을 가져온다.
  • 속성이 null 이 아니라면 경로를 가져와서 메시지 박스를 처리한다.
위의 처리를 구현한 코드는 아래의 그림과 같다.


다시 실행을 해서 패키지에서 추가한 메뉴를 클릭하면 아래의 그림과 같이 콜백이 실행된 결과를 확인할 수 있다.



단순하지만 패키지를 운영할 때 기능들을 특정 메뉴 밑으로 구성하는 처리 등을 할 경우는 위와 같이 설정을 조정해서 운영하면 된다.

댓글

이 블로그의 인기 게시물

OData 에 대해서 알아보자.

얼마 전에 어떤 회사에 인터뷰를 하러 간 적이 있었다. 당시 그 회사는 자체 솔루션을 개발할 기술인력을 찾고 있었고 내부적으로 OData를 사용한다고 했다. 좀 창피한 이야기일 수도 있지만 나름 기술적인 부분에서는 많은 정보를 가지고 있다고 했던 것이 무색하게 OData란 단어를 그 회사 사장님에게서 처음 들었다. 작고, 단순한 사이트들만을 계속해서 작업을 하다 보니 어느덧 큰 줄기들을 잃어버린 것을 느끼기 시작했다. 명색이 개발이 좋고, 기술적인 기반을 만들려고 하는 인간이 단어조차도 모른다는 것은 있을 수 없는 것이라서 다시 새로운 단어들과 개념들을 알아보는 시간을 가지려고 한다. OData (Open Data Protocol) 란? 간단히 정리하면 웹 상에서 손쉽게 데이터를 조회하거나 수정할 수 있도록 주고 받는 웹(프로토콜)을 말한다. 서비스 제공자 입장에서는 웹으로 데이터를 제공하는 방식으로 각 포탈 사이트들이 제공하는 OPEN API 포맷을 독자적인 형식이 아니라 오픈된 공통규약으로 제공 가능하며, 개발자는 이 정보를 다양한 언어의 클라이언트 라이브러리로 어플리케이션에서 소비할 수 있도록 사용하면 된다. 공식 사이트는 www.odata.org 이며 많은 언어들을 지원하고 있다. 좀더 상세하게 정의를 해 보면 OData는 Atom Publishing Protocol  (RFC4287) 의 확장 형식이고 REST (REpresentational State Transfer) Protocol 이다. 따라서 웹 브라우저에서 OData 서비스로 노출된 데이터를 볼 수 있다. 그리고 AtomPub 의 확장이라고 했듯이 데이터의 조회만으로 한정되는 것이 아니라 CRUD 작업이 모두 가능하다. Example 웹 브라우저에서 http://services.odata.org/website/odata.svc 를 열어 보도록 하자. This XML file does not appear to have any style in...

C# 에서 Timer 사용할 때 주의할 점.

예전에 알고 지내시던 분의 질문을 받았다. Windows Forms 개발을 하는데, 주기적 (대략 1분)으로 데이터 요청을 하는 프로그램을 작성하기 위해서 Timer 를 사용하는데, 어떤 기능을 처리해야 하기 때문에 Sleep 을 같이 사용했다고 한다. 여기서 발생하는 문제는 Sleep 5초를 주었더니, Timer 까지 5초 동안 멈춘다는 것이다. Timer 라는 것은 기본적으로 시간의 흐름을 측정하는 기능이기 때문에 Sleep 을 했다고 해서 Timer 가 멈추는 일은 생겨서는 안된다. 그러나 실제 샘플을 만들어 보면 ... Timer 가 Sleep 만큼 동작이 멈추는 것을 확인할 수 있다. Windows Forms 는 UI Thread 를 사용하는 것으로 최적화 되어 있으며 여기서 Timer 를 쓰면 UI Thread 에 최적화된 System.Windows.Forms.Timer 가 사용된다. 여기서 문제의 발생이 시작되는 것이다. Sleep 을 사용하게 되면 UI Thread 가 Sleep 이 걸리기 때문에 여기에 속한 Timer 까지도 멈추는 것이다. 이런 문제를 해결하기 위해서는 System.Threading.Timer 를 사용해야 한다. 이 Timer 는 별도의 Thread 에서 동작하기 때문에 Sleep 의 영향을 받지 않는다. 언뜻 보면 쉬운 해결 방법인 것 같지만 Thread 가 분리되었기 때문에 Timer 가 돌아가는 Thread 에서 UI Thread 의 메서드나 컨트롤에 접근하기 위해서는 별도의 명령을 사용해야 하는 문제가 존재한다. 자~ 그럼 여기서 Timer 에 대해서 다시 한번 정리해 보도록 하자. .NET 에서 제공하는 Timer 들 .NET 에서는 기본적으로 3가지 Timer를 제공하고 있다. (MSDN) System.Windows.Forms.Timer - 사용자가 지정한 간격마다 이벤트를 발생시키며 Windows Forms 응용 프로그램에서 사용할 수 있도록 최적화 되어 있다. System...

[Logging] NLog 사용법 정리...

SCSF 에는 기본적으로 Enterprise Library가 사용된다. 예전에도 그랬지만 기능은 훌륭하고 많은 부분에서 최적화(?)된 것일지도 모르지만, 역시나 사용하기에는 뭔가 모르게 무겁고, 사용하지 않는 기능이 더 많다라는 느낌을 지울수가 없다. 이번 프로젝트도 SCSF를 기반으로 하고 있지만, Enterprise Library를 걷어내고 각 부분에 전문화된 오픈 소스를 사용하기로 하였다. 예전에는 Log4Net을 사용했지만, 대량 사용자 환경에서는 메모리 누수와 기타 문제점이 존재한다는 MS 컨설턴트(?)의 전해진 말을 들은 후로는 사용하지 않는다. 대안으로 사용하는 것이 NLog 이다. 조금 후에는 3.0 버전도 나온다고 홈 페이지에 기재되어 있지만, 그 때가 되면 프로젝트는 끝나기 때문에 현재 2.1.0 버전을 사용하기로 했다. [원본 출처] http://cloverink.net/most-useful-nlog-configurations-closed/ 위의 참조 자료에는 다양한 정보들이 존재하므로 꼭 링크를 통해서 관련된 정보를 확인하고 이해하는 것이 좋을 듯 하다. 여기서는 당장 필요한 부분만을 정리하도록 한다. [ Logger 찾기 ] 기본적으로 Logger가 존재하는 클래스를 기반으로 Logger 정보를 구성한다. Logger logger = LogManager.GetCurrentClassLogger(); 주로 Namespace 기반으로 Logger를 설정하는 경우에 유연하게 사용할 수 있다. 또 다른 방법으로는 지정한 문자열로 특정 Logger를 직접 선택하는 방법도 제공된다. 이를 혼용해서 Namespace와 직접 지정 방식을 같이 사용할 수도 있다. 물론 Logger 환경 설정에서 Wildcard (*)를 지정할 수도 있다. Logger logger = LogManager.GetLogger("Database.Connect"); Logger logger = LogManager.Get...