'분류 전체보기'에 해당되는 글 1251건

예전 2007 시절에는 asmx 파일을 적당히 올려서 웹서비스를 구축했다. 특히 javascript를 이용해서 데이터를 전달할 때는 aspx 파일로 적당히 만들어 JSON으로 Return 하는 식으로 만들곤 했다. 그런데, 이번에 SharePoint 2010으로 넘어오면서 기존에 Copy&Paste 식의 배포가 아닌 SharePoint 솔루션 방식으로 하다 보니, 위의 방식으로 하기에는 왠지 폼이 나지 않았다. 게다가 WCF 라는 나름 유연한 통신 방식을 활용하고 싶다는 생각도 들었다.

그래서 WCF 인터페이스를 어떻게 WSP로 싸서 업로드 하고 그 내용을 Client를 통해 제어를 하는지 살펴보려고 한다.

이 모든 작업은 SharePoint 2010 을 기준으로 하며, 개발 도구는 Visual Studio 2010 으로 한다.

1. SharePoint Project 만들기.

새 SharePoint Project를 만든다. 템플릿 트리에서는 Visual C# –> SharePoint –> 2010 을 선택하고, 목록에서는 Empty SharePoint Project 를 선택한다. 적당한 위치에 프로젝트 이름과 위치를 결정하고 생성한다.

그리고 난 뒤, 배포 위치를 설정한다.
URL이 있는데, 이 URL은 디버그를 하기 위한 URL이다. 가급적 로컬로 잡는 것이 작업하는데 편하다. 굳이 이 부분의 URL에 연연하지 않아도 된다. 그리고 그 밑에 솔루션 유형을 선택하는 부분이 있는데, 그 중 “Deploy as a farm solution”을 선택한다.

WCF를 설치하는 작업은 _vti_bin 과 같은 시스템 쪽 위치의 가상 디렉터리를 활용할 예정이기 때문에, 제한된 형태로 구성되는 Sandboxed solution 으로는 무리가 있다. 그러므로 farm solution 으로 선택한다.

다 구성되면 다음과 같은 솔루션 구성을 보여준다.

2. WCF 파일 구성.

먼저 WCF 파일을 담을 위치를 구성한다. 구성하는 방법은 배포용 폴더 위치를 추가해주면 된다. 웹 서비스나, WCF와 같은 외부 노출된 실행 모듈은 대부분 /_vti_bin 에 위치해 있다. 이 폴더는 SharePoint 설정 및 도구가 있는 14 폴더 중 ISAPI 이다. ( 예 C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\ISAPI )

배포 도구에서 해당 위치에 파일을 하기 위해서는 해당 배포 위치를 구성해줘야 하는데, 배포 폴더를 하나 추가해줘야 한다. 추가하려면, 프로젝트 위에서 오른쪽 클릭을 해서 Context Menu를 띄운다. 그리고, Add –> SharePoint Mapped Folder... 를 선택한다.

SharePoint Mapped Folder를 클릭하면, Add SharePoint Mapped Folder 창이 뜨면, 그 중에 ISAPI를 선택한다.

이제 WCF용 파일들을 만들어야 된다. 이 파일들을 직접 cs 파일들과 svc 파일을 만들어도 되지만, WCF 프로젝트를 잠시 추가해서 템플릿을 받아 사용하는 것이 좋다.

솔루션에서 새로운 프로젝트를 추가하고, 프로젝트 중에서 WCF Service Library를 선택한다.
 

템플릿을 통해 만들어진 다음 2개의 파일을 SharePoint의 프로젝트에 복사한다.

• Service1.cs
• IService.cs

적당한 폴더를 만들어 구성할 수도 있고, 아니면 프로젝트 루트에 복사할 수도 있다.

이 파일은 WCF를 구성하기 위한 구성요소들로 IService.cs는 Contract를 담당하는 Interface 파일과 다른 하나는 그 Contract를 구현하는 구현 코드가 담기는 파일이다. 그 내용은 다음과 같다.

적당한 위치에 추가하면 다음과 같은 솔루션 구성을 볼 수 있다.

지금까지 구성한 내용은 WCF의 알맹이 부분이라면, 이제 외부에 노출되는 페이지를 만들어야 한다. 즉 ASMX나 ASPX 파일을 만들어야 되는 것이다. WCF에서는 이런 역할을 하는 파일이 SVC 파일이다. 그러나 현재 SharePoint 템플릿에서는 SVC 파일을 독자적으로 추가할 수 없으므로, 텍스트 파일로 추가하여 확장자를 SVC로 변경하는 것이다.

이제 새롭게 열린 파일 안에 다음과 같은 항목을 추가한다.

위의 내용을 추가할 때, Service 항목 내에 위에서 추가한 WCF 메인 모듈의 네임스페이스와 클래스이름을 연결해서 구성한다. (필자는 특별히 바꾼게 없으므로 위와 같이 적었다.)

3. 참조(References) 구성

지금까지 파일들을 추가했으면, 이제 WCF를 구성하기 위해 필요한 DLL 참조를 구성해야 한다.

1. System.ServiceModel
2. System.ServiceModel.Web
3. System.Runtime.Serialization
4. Micosoft.SharePoint.Client.ServerRuntime

1, 2, 3번은 Add Reference를 한 뒤, .NET 탭에서 찾으면 금방 찾을 수 있다. 그런데, 문제는 4번 Assembly다. 저 Assembly는 .NET이나, COM에서 절대 찾을 수 없다. 직접 Folder를 따라가는 수 밖에 없다. 이를 위해서는 Browse 탭으로 넘어간다.

그리고 난 뒤, C:\ –> Windows –> Assembly –> GAC_MSIL –> Micosoft.SharePoint.Client.ServerRuntime –> 14.0.0.0__71e9bce111e9429c –> Microsoft.SharePoint.Client.ServerRuntime.dll 로 들어가서 Microsoft.SharePoint.Client.ServerRuntime.dll을 선택한다.

4. Attribute 설정하기.

원래 WCF에서 Address 설정부터, Binding, 인증 처리 등을 설정하기 위해서는 web.config를 통해서 설정하게 된다. 그런데, 현재 구성하려는 SharePoint 패키지 프로젝트에서는 특정 web.config 부분을 일일히 수정할 수 없다. 그것을 .NET Attribute 기능을 이용해서 적용할 수 있다.

이 부분은 구현하는 CS 파일( 위의 예제로 보면, Service1.cs 파일 )에서 적용한다.
여기서 사용하는 Attribute는 BasicHttpBindingServiceMetadataExchangeEndpointAttribute 와 AspNetCompatibilityRequirements 를 사용한다.

적용하는 코드 부분만을 보면 아래와 같다.

using으로 세가지를 추가하고, class 위에 attribute로 두 개를 추가해주면 된다.

5. 프로젝트 파일 설정 변경.

프로젝트 자체가 SharePoint 구성요소에 대한 설정만 자동으로 추가된다. 그래서 WCF의 svc 파일 처리가 불가능하다. 이를 위해서는 수동적인 방법을 통해서 처리해야 한다.

먼저 SharePoint 프로젝트를 Text 파일로 열어 그 안의 XML 파일을 연다. csproj 파일을 메모장 같은 도구로 열면 된다. 그리고 Project –>PropertyGroup 엘리멘트 안에 <TokenReplacementFileExtensions>svc</TokenReplacementFileExtensions> 라는 엘리멘트를 추가하면 된다.

저장한 뒤에 해당 프로젝트를 다시 로드 한다.

6. 배포 하고 테스트.

SharePoint 프로젝트의 특징은 역시 자동으로 .WSP라는 SharePoint 솔루션으로 만들어 주고 그것을 Debug로 설정한 사이트로 자동으로 업로드 해준다.

배포가 성공적으로 되면 웹사이트에서 http://localhost/_vti_bin/WCFTest.svc/MEX 를 입력한다.(꼭 맨 뒤에 /MEX가 있어야 정상적으로 접속이 가능하다.)

정상적으로 읽어오면 아래와 같은 화면이 뜬다.

7. 정리

이 연결하는 작업을 전부 수동으로 만들면 그리 문제 없이 설정하고 구성할 수 있다. 하지만, SharePoint의 솔루션으로 포함시켜서 만들려면 몇 가지 씩 손봐야 된다. 그런데도 굳이 SharePoint의 솔루션으로 작업하는 이유는 나중에 Uninstall이나 업그레이드를 보다 간단하게 수행할 수 있기 때문이다.

위의 글들은 아래의 문서들을 참고로 직접 적용 후 정리했다.

• Creating a Custom WCF Service in SharePoint Foundation
  ( http://msdn.microsoft.com/en-us/library/ff521581.aspx )
• SharePoint 2010: Create Custom WCF Service
  ( http://ranaictiu-technicalblog.blogspot.com/2011/03/sharepoint-2010-create-custom-wcf.html )
• Customizing WCF Services in SharePoint 2010
  ( http://answers.oreilly.com/topic/1404-how-to-customize-wcf-services-in-sharepoint-2010/ )
• WCF 확장
  ( http://msdn.microsoft.com/ko-kr/library/ms733848(VS.90).aspx )

전에 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 Calendar의 기념일 관리도구를 하나 만들려고 한다.
다만, 음력으로 된 기념일을 등록/수정/삭제가 가능한 도구이라는 것.

전에 ical 파일을 만들어 이 파일을 Google Calendar에 등록하는 방법이 있어 해봤다.
원리는 음력의 기념일을 기준으로 매년 양력일자를 ical 내에 미리 넣어주는 방법.
그래서 해당 양력일자의 일정을 Google Calendar에 우겨 넣는 것이다.

다 좋은데, 문제는 일정 수정이나 삭제할 때, 우겨 넣은 모든 일정을 일일히 찾아 지워야 한다는 점이다.

예를 들어 음력 6월 1일이라고 하면, 그에 맞는 양력 일자를 2011년, 2012년, 2013년... 2020년 양력 날짜가 쫙 생긴다. 11년에서 20년까지면 무려 9개. 그 9개의 날짜가 조금만 틀려도 매년 달력으로 넘어가서 수정/삭제를 해줘야 한다.
기념일이 한 개정도면 귀찮아서 그렇지 그냥 그냥 하면 되지만, 이게 20개 정도만 되면, 슬슬 머리가 아파오기 시작한다.

그래서 이것을 Windows 기반의 어플리케이션으로 만들어 관리하려고 한다. 그리고 그 관리도구를 만들기 위한 장소를 네이버 개발자에 넣었고, 네이버 개발자 사이트에서 제공하는 SVN에 등록하려고 한다.

사이트는 http://dev.naver.com/projects/googlecalendarm 이며, 틈 나는 대로 적용하려고 한다.

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 에서 갯수를 파악한 뒤 내용을 꺼냈다.  - 주의가 필요 -

어제 우연히 웹 검색을 하다가, Gsong's Blog에 방문하게 되었는데, 아주 재미있는 포스팅을 보았다.

URL은 http://www.gsong.pe.kr/wp/?p=3959 인데, 제목이 SFE Prezi sildes 라는 포스팅.

시나리오 기반 개발이라는 내용의 프리젠테이션인데, Play 버튼을 클릭하면(한번 누르면 계속 진행되는게 아니고, 계속 눌러줘야 한다.) 이야기가 시작되는데, 자신이 원하는 포인트에 줌인 하고, 이동할 때는 줌 아웃하다가, 다음 위치에서 줌인 되는 스타일.

말로 설명을 하면 좀 이상하긴 한데, 뭔가 역동적인 슬라이드라고나 할까?

기반은 Flash 기반으로 되어 있다.

http://prezi.com/ dp 에 가면 나오는데, 여기서 자신의 슬라이드를 그릴 수 있다.

나중에 내 생각을 이런 곳에다 그려보는것도 즐거울듯.

무료로 사용하면, 이 Prezi 슬라이드 파일이 무조건 공개되고, 해당 파일은 반드시 Prezi 서버에 저장된다. 그것도 100Mb 한도로.

나중에 Professional 서비스를 신청하면, 오프라인 버전도 쓸 수 있다는데.. 모르겠다.

잘 쓸 수나 있는지 체크해보고. 생각해 봐야 할듯.

예제 Prezi 가 아래와 같다.

전에 미국 쪽에 계시는 이사님과의 원활한 자료 송수신을 위해 DropBox를 사용했다. 일단 DropBox 자체가 미국에 있는 서버다 보니, 파일 송수신을 할 때, 미국에서 그나마 접근하기 쉽다는 이유 때문일듯.

DropBox의 기본 개념은 하나의 폴더를 동기화라는 개념으로 자동적으로 서버와 동기화를 한다. 그래서 다른 위치의 다른 컴퓨터에서 DropBox를 설치하면, 최소한 서버와 동기화를 갖춘 파일들은 모조리 동기화를 한다. 파일이 변하거나, 파일이 추가되거나, 삭제되면 그 즉시 Dropbox가 설치된 컴퓨터에서는 동일한 반응을 보인다.
더욱이 이 DropBox의 훌륭한 점은 다양한 플랫폼의 지원이다. PC는 물론이고, MAC도 지원을 하며, 안드로이드 폰에 아이폰까지 다방면의 미디어로 사용할 수 있다. 보통 이 DropBox의 최대 활용점은 스마트폰에 파일을 송수신 하는 것. PC나 MAC에서 생산된 자료들을 동기화 설정된 폴더에 옮겨만 놓으면, 원하는 스마트폰 장치에서 쉽게 접근하여 받을 수 있다. (물론 스마트폰과 같은 용량적/통신적 제약이 있는데서는 파일이 변했다고해서 반드시 변경사항이 적용된 파일을 그 즉시 받지는 않는다.). 역으로 스마트폰 장치에서 만들어진 파일 ( 특히 사진 )들을 DropBox에 얹으면, 그 즉시 DropBox가 설치/연결된 PC와 MAC에서도 볼 수 있다.

하지만, 최대의 단점이 있으니, 바로 속도. 짐작컨데, 미국으로 연결되는 경우 그 속도는 가히 환상적으로 환장하게 만드는 경우가 있다. 얼마 크지도 않은 파일이 동기화를 하는데 최대 10분 이상 소요되는 경우도 발생한다. (물론 요즘은 즉시 즉시 반영되기도 한다.) 또 하나는 용량. 기본적으로 주는 용량이, 2G 이다. 사실 상당히 큰 용량이라고 볼 수도 있지만, 최소한 국내 클라우드 업체들이 제공하는 기본 용량에 비하면 턱없이 부족한 양이다. 광고에도 나오지 않는가? 50G.....

그래서 뒤적 뒤적 찾던 중, UCloud 를 설치해봤는데, Dropbox의 개념이 아닌, Backup&Restore 개념에 가까웠다. 원하는 PC의 특정 폴더들(기본적으로 내 문서, 내 음악, 내 사진 등등)을 설정하면, 그 PC에 대해서 파일이 변하면 자동으로 동기화를 한다. 위급한 상황이 닥치거나 아무 생각 없이 Format 한 이후에 원상복귀할 때는 좋을 것 같다.
하지만, 위에서 언급한 Dropbox 처럼 쓰기가, 참 애매했다. 스마트폰에서 파일 접근하기도 수월치 않고, 파일을 서로 동기화 시켜서 정리할 수도 없었다.

그러던 중 다음 클라우드를 보았고, 잠시 사용해봤다. 완전히 한국형 DropBox. 동일한 기능에 무려 50G. 서버는 당근 한국에 있으니 속도적인 우위도 차지할 듯.

자세한 찌라시는 http://daummail.tistory.com/319 를 보면 된다.

중요 개념 설명용 이미지는 이런 것!

처음에 내가 잘못 본 건지, 처음에는 Windows만 지원하는 것으로 알고 있었는데, 오늘 들어가보니, MAC와 Linux까지 지원. 훌륭했다.

그래서 지금 낼름 설치하고, 기존에 Dropbox를 통해서 송수신했던 파일들을 정리하고 있다.

만족 만족!!

50G의 여유는 쉽게 소진될 것 같지만, 지금 내가 가진 넥서스S자체가 16G 밖에 안되기에, 굳이 큰 용량이 필요로 하지않는다. 또 서버에 올리는 파일도 대부분은 10M 안쪽이고..훗훗.

일단, 파일들을 완존 정리를 해봐야 겠다.