It's Myself

전에 Windows SharePoint Service 3.0 으로 협업을 해보자라는 글을 올린 적이 있다. 그 때 SharePoint 개발 회사에서 그만 두고 난 뒤 더 이상 쓰질 못했다. 물론 직접 돌려보면서 이런 저런 사용방법을 적을 수도 있지만, 너무 게으른 성품 때문에 결국 다 쓰지 못한 채 연재를 더 이상하지 못했다.

그 즈음 SharePoint 2010 이 나오고 있었고, 지금은 공식 판매 한지 벌써 1년 정도 지났다. 지금은 다시 회사를 옮기게 되었고, 어찌 어찌 하다 보니, 다시 SharePoint를 만지게 되었다. 오랜만에 SharePoint를 만지다 보니까, 예전 2007 시절에서 사용하던 방법은 더 이상 활용하기가 무리가 있다고 생각된다. 그래서 지금은 완전히 처음부터 다시 만진다는 느낌으로 하나씩 손 대보려고 한다.

그런데 지금 주 거래처가 미쿡이다 보니, 지금 사용하는 SharePoint는 영문판이다.
그래서 캡쳐되는 화면도 영문판으로 진행될 것 같다.

앞의 포스트(Verisign에서 인증서 받기)에서 Verisign 인증서를 받는 소개를 할 때, Windows Logo 프로그램을 통하면, $99로 받을 수 있다는 점을 언급했습니다.

그런데, 이 부분을 명확히 해야 할 점이 있는데요.

저 프로모션을 사용하는 조건은 바로 Windows Logo에서 사용하라고 하는 점입니다. Windows Logo에서는 단순히 회사 인증만 하면 되기 때문에, 1년 짜리를 한 개 받으면 평생 회사 인증용으로 사용할 수 있습니다. 그래서 이 프로모션을 통해서 얻을 수 있는 인증서는 오로지 Code Sign용 인증서고 그 유효기간이 딱 1년 짜리라는 것입니다.
그러므로 https를 위한 SSL 인증서나, 3~5년 짜리 인증서를 받을 때는 아무 소용이 없다는 점을 꼭 기억해주세요.

얻는 방법은 아래와 같습니다.

1. 먼저 http://winqual.microsoft.com 을 접속합니다.
   오른쪽에 있는 Digital IDs 부분에 “Offer details are avaliable here” 라는 문장이 있는데, 그 중 “here” 이라는 링크로 들어갑니다.
   
2. 그러면 Winqual 에 대한 도움말 페이지가 뜹니다. 스크롤을 내려 맨 아래쪽에 보면, “Verisign ‘Microsoft Authenticode’ Code Signing Digital Certificate” 라는 문장이 있는데, 이 링크를 클릭합니다.
   
3. 그러면 Verisign에서 Promotion 코드가 자동으로 들어간 페이지가 뜹니다. 여기서 One Year를 선택한 상태에서 계속 진행하시면 됩니다.
   
4. 나머지는 이전 Post 내용을 참고하세요.

예전 Windows App을 API 기반의 C 로 만들거나, MFC로 만들 때, 각종 Event 처리를 위해, 독자적인 ID를 만들었다. 그런데, 미처 인식을 못한 것이, 어떤 ID를 사용해서 운영을 해야 겹치는 경우 없이 제대로 되는지 정하지 않고 임의대로 했다.

그 중 WM_USER 값이다.
WM_USER는 사용자가 정의해서 쓸 수 있는 ID 정도로만 인식하고 있었다. 이 값으로 시작해서 최대 0x7c00 까지 정의해서 쓸 수 있다. 10진수로 한다면, 1024 ~ 31744 까지 정의해서 쓸 수 있다. 그래서 예전에는 사용할 ID 값을 아래와 같이 정의하곤 했다.

#define WM_CUSTOMUPDATE WM_USER + 100

즉 1024 + 100 = 1124 를 WM_CUSTOMUPDATE 라는 이벤트 ID로 사용한다는 의미.
하지만, 내가 안 쓰더라도, 별도로 사용되는 컨트롤이나, 3th-Party의 컨트롤의 경우 저 이벤트를 사용하는 경우가 종종 있어 자칫 종종 겹치는 경우가 있었다. 그래서 위 처럼 + 100 정도가 아닌, 5000 정도로 팍팍 띄워서 정의하기도 했다.

그런데, 알고 보니, WM_APP 라는 값이 있었다. 이 값은 최소한 컨트롤 같은 곳에서 사용하지 않는 완전 App 개발자 용으로 남겨놓은 영역이라고 한다. 이 값은 0x8000 ~ 0xBFFF 값이다. 10진수로 한다면 32768 ~ 49151 으로 볼 수 있다.

이번에 C#으로 이것저것 만들다가, 결국 unmanaged code들을 짜게 되었는데, 이 때 Windows Message를 주로 핸들링 하게 되었는데, 이벤트 ID를 대충 대충 정해서 구현한 것 같았다. 가급적 저 ID 정의 Rule에 맞추어서 정의해야 할 것 같다.

이 내용은 아래 링크에서 참고해  정리했다.(EUC-KR 이여서, 일부 Web Browser에서 종종 깨져 보인다.)

http://winapi.co.kr/reference/Message/WM_USER.htm

Google 에서 제공되는 서비스들은 거의 대부분 API를 제공하고 있다.
ATOM - 우리가 보통 말하는 SOAP과 같은 형태로 규격화된 XML로 구성된 형태와 JavaScript에서 쓰기 편한 JSON 형태들, 결과값도 다양한 형태로 제공한다.
(우리나라 포털은 이런 것과는 전혀 반대로 가고 있다. 뭐 다음이나, 네이버에는 개발자 들이 많으니, 외부 개발자들이 끼어들 필요가 없어서 그런듯... 애플 앱스토어 같은 성공 모델도, 이들에게는 큰 감흥이 없는 것 같다.)

이 중 Google Calendar 값을 가져와서 편집하려는 .NET 기반 툴을 만들려고 생각 중이였다.

 http://code.google.com/apis/calendar/data/2.0/developers_guide_protocol.html

난 맨처음 ATOM 기반의 데이터를 보았기 때문에, XMLDocument Reader로 읽어서 원하는 값들을 뽑으려고 했다.
하지만, 내용이 너무 방대하고 많아서 이 내용들을 정리할 생각에 뒷목이 뻣뻣함이 느껴졌는데,
알고보니까, 언어별로 이미 패키지화 해버렸다.
패키지는 다음 URL에서 받으면 된다.

http://code.google.com/p/google-gdata/downloads/list

MSI 파일로 설치를 하면 기본 경로로 C:\Program Files\Google\Google Data API SDK 위치에 설치된다.
Calendar 뿐만 아니라, Google 에서 제공하는 각종 기능들을 다룰 때 사용하는 대부분의 기능들을 담은 패키지를 제공한다.

그 중 완벽 정리된, .NET 코드로 작성하는 방법은 아래의 URL에서 참고하면 된다.

http://code.google.com/apis/calendar/data/2.0/developers_guide_dotnet.html

거의 완벽 정리. ( 문제는 언어 장벽! ㅠ.ㅠ )

각종 Open API 기반 서비스는 Google 기반으로 동작하게 할 수 밖에 없을 것 같다.
다음도, 네이버도 결국 이런 서비스를 제공하는 것은 요원한 일이 될테니..

구글 서비스나 잘 구성해서 써야 겠다.

Google Calendar 내용을 모두 열어 보는 코드를 간단하게 짜보면 아래와 같다.

저 코드면 맨 마지막에 나오는 값들로 표시를 하거나 정리를 할 수 있게 된다.

그런데 특이한 점은 일정에서 날짜와 시간이 반드시 들어갈 줄 알았는데, 알고 보니까,
외부에서 파일을 import 해서 넣은 일정들은 저 entry.Times 값이 없는 경우가 있다.
그래서 entry.Times 에서 갯수를 파악한 뒤 내용을 꺼냈다.  - 주의가 필요 -

로그 파일을 읽는 경우가 종종 있는데, 로그 중에 계속 쌓이는 로그를 연속으로 볼 때가 있다.
이 경우 tail viewer 혹은 log tail viewer 들이 있는데, 그 툴을 활용하면, 계속 쌓이는 로그를 실시간으로 볼 수 있다.
과거 떠돌이 프로젝트 수행 중에 받았던 파일이 있다. WinTail 이라는 프로그램 인데, 그 프로그램이 그런 역할을 수행해줬다. 속도도 빠르고 좋았던 기억.

문제는 한글이 깨져서 나온다. 한글로 적힌 로그가 나오면 그대로 깨져서 나온다는..
아마도 C++로 만든거 같은데, 과거 인코딩과 거리가 멀던 그 시절에 만들어진 프로그램 같다.
이번에 작성 중인 프로그램도 로그 파일을 쌓고 있는데, 문제는 로그 내용을 한글로 적었다는 것. 
결국 무슨 말인지 알 길이 없어서, 직접 만들어야 겠다는 생각이 들었다.

.NET Framework 2.0을 기반으로 하며, C#으로 짰다. 모든 Visual Studio 2010 에서 작업했다.

처음에는 ListBox를 사용하여 로그 파일을 열었다. 
최소한 내가 만드는 로그 보는데는 문제가 없었다.
그래서 자신만만(?)하게 지인인 호박양에게 전달했는데,
왠걸...IIS 로그를 넣어 봤는데, All Stop 이라고 Report 해줬다.

즉, NET 기본 컨트롤로는 로그 Viewer로 쓰기에는 너무나 부적합했다는 것이다. 결국 이렇게 저렇게 검색을 하다가 우연히 발견한 오픈소스 기반의 Text Viewer인 Scintilla 를 찾았다. 이 Viewer는 C++로 되어 있으며, Win32와 GTK+ 기반으로 되어 있다. 소스 코드 에디터 처럼 특정 문자에 색을 입히거나, 코드를 묶어서 접고 펼치기 등, 다양한 소스코드 관련 Editor Viewer로 활용되는 유명한 솔루션. (현재 2.27 버전이며, 2011년 6월 20일이 최종 수정)

그것을 .NET으로 포팅한 프로젝트가 있었으니, 그것이 ScintillaNET 이였다.
일단 ScinitillaNET의 코드를 특별히 수정할 필요는 없었고, Binary 파일( http://scintillanet.codeplex.com/releases/view/34393#DownloadId=88753 )을 직접 받았다. 이 구성요소를 가지고 프로그래밍을 하려면, 최소한 SciLexer.dll 파일이 System32 에 위치해야 한다. 그리고 ScintillaNet.dll 파일을 프로젝트에 Reference를 걸어주면 된다. 물론 배포 할 때는 저 두 개의 파일이 실행되는 파일과 같은 경로에만 있으면 된다.

그래서 한번 돌려봤더니..

특정 경로의 파일을 열고, Start 하면 된다. 중간에 화면 Clear가 필요하면 Clear 로그를, Log 파일 내용을 완전히 지우고 싶으면 Trunc 로그를 하면 된다.

사용법은 그렇게 어려운편은 아니니 Pass.

소스 파일과 실행파일 묶음은 첨부로 올린다.
아, 이거 돌릴려면 최소한 .NET Framework 2.0 이상이 설치되어 있어야 한다.

invalid-file

invalid-file

자동 빌드를 적용 중에 자주 설정을 바꾸게 되는데, 이상하게 다음과 같은 문제가 자주 발생된다.

특정 소스 위치가 이미 연결된 상태라며 문제가 발생하는 것 같다. 그래서 더 이상 빌드가 안된다. 이 문제는 아마도 빌드 전에 모든 Source를 Get Lasted Version을 하게 되는데, 그 연결이 남아 있는 상태로 다시 받으려니 문제가 발생되는 문제이다.

안그래도 이 내용을 구글을 통해서 찾아 보니까, 아래와 같은 URL을 찾을 수 있었다.

http://stackoverflow.com/questions/226288/team-build-error-the-path-is-already-mapped-to-workspace

TF.EXE 라는 Team Explorer 에서 제공하는 유틸리티를 이용해서 처리할 수 있다는 것이다.

처리 방법은 아래와 같다.

1. 먼저 Visual Studio 에서 제공하는 CMD창을 띄운다.
   
2. 다음은 다음 명령어를 넣는다. 그러면 현재 MAP 된 정보를 모두 보여준다.
   

   c:\>tf workspaces /owner:*

   
   
   맨 앞부분이 Workspace 이름이고, 그 다음이 Workspace를 생성한 계정. 그리고 그 다음이 Workspace가 생성된 PC 이름이다.
3. 위의 정보를 가지고 하나씩 삭제 한다. 삭제하는 방법은 CMD 창에 아래와 같이 입력한다.
   

   C:\>tf workspace /delete workspace_name

   만일 5_15_builder_pc 라는 Workspace를 삭제하려면 아래와 같이 입력하면 된다.
   

   C:\>tf workspace /delete 5_15_builder_pc

   혹시 현재 로그인 한 계정이 다르다면 아래와 같이 추가적으로 입력한다.
   

   C:\>tf workspace /delete 5_15_builder_pc /login:tfsadmin

   
   암호 입력은 별도로 띄우게 되는 NTLM 창이 뜨는데, 그 곳에다 넣으면 된다.

국내에서는 공인 인증서에 대해서 어느정도 익숙하게 접하는 편이다. 특히나 인터넷 은행 거래를 하려면 당연하게 공인 인증서를 쓰기 때문일 것이다. 하지만, 예전부터 Windows 안에서 다양한 형태로 공인인증서가 상당히 많이 활용되어 왔었다. HTTPS 로 시작되는 홈페이지들을 접속할 때도 활용되었고, 응용 프로그램을 설치할 때도 보게 되며, Active X 설치할 때 역시 사용한다.

이 인증서를 획득하는 방법에 대해서 간략하게 설명한다.

1. 인증서란.

Public key certificate 라는 것으로, 보통 Certificate 라고 언급한다. 자세한 설명은 위키피디아에서 “공인인증서”라는 항목을 검색하면 보다 더 자세하게 확인할 수 있다.

우리가 알아야 하는 것은 단지, Root 인증서와 인증서의 인증방법 만을 대략적으로만 알면 된다.
먼저 Windows 의 Run 창(실행창)에서 Certmgr.msc 라는 것을 치고 들어가면 인증서 관리 프로그램이 뜬다. Windows 안에 저장된 각종 인증서들을 관리하고 저장하는 곳인데, 여기서 “신뢰할 수 있는 루트 인증서” 라는 항목을 열어보도록 하자.

웹 브라우저 상에서 https 사이트에 접속하거나, 혹은 응용 프로그램을 설치할 때 인증서가 박혀 있는 경우 이 인증서가 정말 올바른 인증서인지 아닌지 판단할 때 중요한 역할을 하는 것이 바로 저 “신뢰할 수 있는 루트 인증서” 항목 안에 포함되어 있느냐 없는냐의 차이라고 볼 수 있다.

만일 인증서가 한 회사를 인증하는 인증서라면, 그 회사 이름이 knoie.com 이라면, knoie.com 이라는 인증서를 증명하기 위한 중간 인증서 정보가 담겨 있다. 그 중간 인증서 안에서는 이 인증서가 올바른 인증서 임을 증명하는 root 인증서가 있다. 그 root 인증서가 만료되거나 잘못된 것이 아닌지에 대한 정보를 바로 저 “신뢰할 수 있는 루트 인증서” 안에서 체크하게 된다.

“신뢰할 수 있는 루트 인증서”안을 보면 수많은 회사들을 볼 수 있는데, 그 중 Verisign도 쉽게 접할 수 있다.(알파벳 순서에 따라 맨 아래쪽에 위치해 있다.). 기묘하게도 MS에서는 Verisign을 많이 의존해서 인증서 처리를 한다. 최소한 Windows를 쓰면 Verisign은 빠지지 않고 들어가 있으며, 혹여 기간이 만료된 Root 인증서라도, Windows Update를 통해 만료된 인증서를 알아서 갈아치운다.

또, 이번에 Windows Logo 프로그램 가입작업을 했었는데, 그 때도 인증서 처리를 Verisign 으로 링크가 걸려 있었고, 사실 Verisign을 통해서 해야 정상적인 처리가 된다고 하니, 별 수 없이 Verisign으로 처리하게 되었다.

인증서 발급 부분도 결국 Verisign을 통해서 했기에 그 내용을 중심으로 설명한다.

2. 인증서 종류.

인증서의 분류를 하려면 한도 끝도 없지만, 여기서 언급할 인증서에서는 두 지로 나눌 수 있다.

2.1 SSL 인증서.

우리가 보통 HTTPS 라고 접속하는 방식이 있다. 암호화된 HTTP 방식인데, 보통 웹서버 인증서라고 부른다. 특정 웹서버에 특정 URL에 대해서 이 웹페이지들이 공식 인증된 사이트임을 알려줄 때 사용한다. 그리고 상호간 데이터를 송수신 할 때 사용되는 암호화 역시 이 인증서를 다리 삼아서 동작하게 된다.

여기서는 이 인증서와는 관계 없으므로 패스.

2.2 Code Signing 인증서

일반적으로 ActiveX 인증용 인증서라고 불린다. 정확히는 회사를 인증하기 위한 인증서인데, 공식 인증된 회사임을 표시하기 위해 회사명을 중심으로 나타내는 인증서이다. 여기서 만들어진 인증서를 통해 ActiveX의 OCX, DLL, CAP, MSI 등, 설치에 표시되는 인증서 이다.

배포자(Publisher) 라는 이름으로 붙는 내용 옆에 붙는 내용이 바로 그 내용인데, 특정 회사임을 증명하는 내용이다.
여기서는 이 Publisher에 인증된 회사임을 증명하는 인증서를 발급 받기 위한 작업을 보여준다.

3. Verisign 접속하기.

이곳에서 인증서를 구입하기 위해서는 Verisign 홈페이지에 접속해야 한다.
홈페이지 URL은 http://www.verisign.com 이다. 홈페이지에 접속하면 Front 화면에서 Code Signning 구입할 수 있는 링크가 있는데, 그 안으로 들어간다.

많은 종류의 Code Signning 종류들을 볼 수 있는데, 여기서 Code Signnig Certificate for Microsoft Authenticode를 선택한다.

인증서 계약 기간을 선택할 수 있다. 1년부터 3년까지. 발급 후 계약 기간에 벗어나면, 만료된 인증서라고 뜨게 되는데, 이 경우 갱신 처리를 하면 된다. 1년 짜리로 하는 경우 Code Signer Pro를 체크할 수 있는데, 긴급하게 Code Signing 하는건데, 굳이 필요는 없다. 마지막으로 Promotional Code 라고 있는데, 일종의 할인 쿠폰 같은 것이다.

MS의 Windows Logo 프로그램에서 제공하는 링크로 들어가면 상당히 저렴한 가격으로 1년 짜리 인증서를 $99 에 구입할 수 있다. ( 보통 $499 이다. ) Windows Logo 프로그램 사이트는 (http://winqual.microsoft.com 이다.)

그리고 Continue를 한다.

그러면, 전체적인 절차를 Overview 식으로 보여준다. 인지하고 Continue를 한다.

기술지원 담당자 정보를 넣는다. 이 인증서 발급 작업을 실제로 담당하는 사람의 인적정보를 넣는다. 해당 정보 중, 전화번호와 이메일 주소를 명확히 넣어야 한다. 그래야 연락 및 공지 등이 제대로 도착할 수 있다.

이제 코드 Signning을 하기 위한 중요한 정보를 넣는 창이 뜬다.

여기서 회사 이름 도시명 그리고 국가 등을 넣도록 한다. 이 정보들은 나중에 회사 인증을 할 때 사용되는 중요한 정보이다. 회사이름 등의 철자 등을 반드시 확인하고 넣도록 한다.
그리고 암호화 방식을 선택하는 창이 뜨는데, 대개는 기본값을 그대로 활용하도록 한다.

중간에 State/Province가 있는데, 서울 같은 곳은 별도의 “도” 단위의 값이 없으므로 Seoul로 반복해서 넣었다. 만일 경기도나, 충청남북도 인 경우 해당 “도”까지 넣어주면 된다.

입력 및 선택이 완료되었으면 Continue를 하도록 한다.

인증 받을 정보를 확인하는 창이다. 이 창을 다시 띄우는 목적 중 하나는 인증 받으려는 최종 정보가 올바른지 확인하는 것과 정보 변경을 할 때 사용되는 암호를 입력 받기 위한 부분이다. 인증 정보의 각 스펠링 및 위치 정보가 확실한지 확인하고, 틀리면 “Change Certificate Info”를 눌러 들어가서 수정하도록 한다.

Challenge phrase 부분에서는 중간에 인증 정보를 변경하려고 할 때, 확인용 암호를 넣는 부분인데, 처음 두 개의 칸 안에 적절한 암호를 넣도록 하고, 맨 아래 쪽에는 암호 분실 후 암호를 찾기 위한 질문의 값을 넣는다.

정상적으로 입력했으면 Continue를 클릭한다.

다음에 뜨는 창은 이 인증 정보의 조직의 대표자 정보를 넣는다. Verisign에서 회사 인증 할 때 맨 나중에 이 조직 대표자에게 연락을 해서 회사의 대표자 유무를 판단한다. 작은 회사면 그냥 사장님 정보를 넣을 수도 있지만, 큰 조직인 경우에는 대개 기술 담당자 정보를 그대로 활용하는 경우가 많다.

기술 담당자 정보와 동일하면 “ This contact is the same person as the Technical Contact” 라는 부분을 체크해주면 된다. 다르면 해당 정보를 앞의 기술 담당자 정보 넣듯이 넣어주면 된다. 역시 전화번호와 이메일 주소를 확실하게 확인하고 입력한다. 입력을 확인하면

다음은 결재 정보를 넣는다. 애석하게도 Verisign은 선불 방식이라 인증에 성공하든 실패하든 일단 지불부터 먼저 다. 나중에 문제가 발생하여 취소하는 경우 별도 고객센터에 연락해서 취소 요청을 해야 한다.’

지불 방법은 여러가지가 있지만, 국내에서 제대로 지불하는 방식은 신용카드 밖에는 마땅찮다. Credit Card를 선택하고, Card Type과 Card 번호, 그리고 카드 만료일 정도를 넣는다. 그리고 지불하는 사람에 대한 정보를 맨 아래 Enter Billing Contact Information에 넣는다. 지불 관련 문제가 있을 때 누구에게 연락을 할 것인지를 결정하는 부분인데, 대개 Technical Contact를 선택한다. 완료되었으면 Continue를 클릭한다.

이제 지불이 완료되면 최초 *.pvk 파일을 다운로드 받는다. 받고 싶은 위치를 결정해 저장하도록 한다.
이 파일은 인증서의 각종 변환 작업이나, 기타 인증 작업 때 반드시 필요한 파일이므로, 절대 분실하지 않도록 한다.
필요하면 USB 등을 통해 별도 보관해서 잃어버리는 일이 없도록 주의를 한다.

이제 Order Number를 크게 보여주면서, 결재 정보 및 인증에 사용된 각종 정보들을 볼 수 있는 창이 뜬다.Order Number를 적당한 메모장에 기록한다. 물론 Techincal Contact에 기록된 이메일로 해당 정보가 발송된다.
기록한 것이 분실되더라도, 이메일 등을 확인하면 표시해준다.

이제 http://www.verisign.com/status/ 페이지에 접속한다. 그리고 Order Number에 앞서 발급받은 Order Number를 넣는다. 그러면 현재 처리 내용에 대한 정보를 보여준다.

Payment를 제외한 나머지는 대부분 Pending에 있는데, 회사 인증을 위한 작업이 시간이 걸린다. 보통 Verisign에는 전세계 각 회사들에 대한 정보를 저장해 놓은 DB가 있는데, 그 안에 걸리면 대개 1~2일 후면 처리가 완료된다. 만일 처리하는데 시간이 걸리는 경우 kr-support@verisign.com 으로 메일을 보내도록 하자.

그러면 해당 담당자로 부터 메일이나 전화를 받을 수 있게 되는데, DB 정보가 없는 경우 다음과 같은 정보들이 준비되면 등록을 완료할 수 있다.

1. 사업자 등록증.

2. 3개월 이내 납부한 전화 요금 영수증(반드시 지로 납입용 영수증이여야 함).
    혹은 KT 114에 등록.
    주의할 점은 여기의 전화번호는 반드시 Organizational Contact에 있는 전화번호여야 한다.

사업자 등록증이나, 지로 영수증을 스캔해서 사본을 보내주면 대개 해결된다.
한국을 원하는 부서가 호주 혹은 미국에 있기 때문에, 팩스와 같은 방식으로 보내는 방법은 어려울 것 같다. 이 부분은 kr-support@verisign.com 으로 연락을 해서 증명할 수 있는 방법을 같이 고민하는 것이 좋다.

대개 처리가 완료될 즈음에 Organizational Contact 에 적힌 전화번호로 확인 전화가 온다. 대표자 명이 같은지 틀린지 등을 확인하게 되고, 간단한 질문을 한 뒤, 맞으면 처리가 완료된다.

모든 처리가 완료되면 메일을 통해 URL을 받을 수 있으며, 그 URL과 PIN 을 입력해서 들어가면 *.spc 파일을 다운로드 받을 수 있다.

앞 단계에서 받은 PVK 파일과 SPC 파일이 있으면 대부분의 Signning 처리를 수행할 수 있다.

4. 정리

별도로 캡처한 화면이 없어, 거짓으로 대충 입력한 화면을 캡처했고, 결재 이후 화면은 없다. 하지만 전반적인 설명은 어느 도 되었다고 생각된다.

Verisign에서 인증 받는 것은 생각보다 비용이 센 편인다. 물론 MS에서 제공하는 Promotion Code를 통해 $99에 살수도 있지만, 갱신하거나, Promotion Code 없이 사려면, 거의 4~50만원 돈이 된다. 더욱이 공식 인증된 서류인 사업자 등록증이 있어야 하고, 또한 일반전화까지 있어야 한다. 정식회사가 아닌 이상은 등록하기 무척 어렵다고 볼 수 있다.

하지만, 회사 차원에서 개발된 응용 프로그램을 설치할 때 Publisher 가 Unknown 으로 뜨거나, Active X가 설치 거부되는 문제가 있다면, 어차피 거쳐 지나가야 할 길이긴 하다.

이 Verisign 이라는 회사가 외국계라, 전체적인 처리가 힘든 부분도 있기는 하지만, 그런 부분이 있더라도 kr-support@verisign.com 을 통해 한국어로 문의를 주면 친절하게 답변을 준다.
이번 Microsoft Windows Logo 프로그램 처리 중에 제일 큰 애로사항이 바로 이 Verisign 처리였는데, 이번 기회에 많이 익힌 기분이다.

나중에 헷갈리는 일이 없도록 기록해 둔다.

.NET에서 Debug 관련해서 할 때, Visual Studo 를 사용하다 보면, 현재 실행 위치를 기반으로 실행 순서를 확인할 수 있습니다. Call Stack 이라는 이름의 창으로 그 안으로 보면, 어느 부분에서 어떻게 실행되었는지, 해당 코드는 어떤 파일이며, 몇번째 라인에서 실행했는지 등을 확인 할 수 있습니다.

그림에 있는 Call Stack 까지는 아니지만, 최소한 어떤 함수에서 어떤 함수로 불렸는지 확인하는 방법이 있습니다.이 때 사용하는 것이, System.Diagnostics.StackTrace 라는 클래스 입니다.

이 클래스를 생성한 뒤, GetFrames() 라는 함수를 부르면, 그 메소드를 호출한 위치의 Thread를 기준으로 Call Stack 내용을 끄집어 낼 수 있습니다. 이 때 가져오는 형태를 StackFrame이라고 하는데, 이것을 Array 형태로 가져옵니다.

이 Array를 열어 GetMethed() 한 뒤, Name을 끄집어 내면 해당 실행 모듈의 이름을 꺼낼 수 있습니다.
위의 Flow를 이용하여 간단한 소스를 나타내면 다음과 같습니다.

System.Diagnostics.StackTrace stacks = new System.Diagnostics.StackTrace(); 
System.Diagnostics.StackFrame[] frames = stacks.GetFrames(); 
foreach (System.Diagnostics.StackFrame frame in frames) 
{ 
      System.Diagnostics.Debug.Write(frame.GetMethod().Name); 
      System.Diagnostics.Debug.Write(" <- " ); 
} 
System.Diagnostics.Debug.WriteLine(" ");

그러면 현재 호출된 메소드를 기준으로 표시됩니다.
필요하면 Method에 개체를 이용해서 Assembly를 빼거나, 기타 소스 코드들을 따라 들어가면, 원하는 정보들을 쉽게 뽑아낼 수 있을 것입니다.