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

* update
  Vista나 XP에 설치하고 나면 C:\program files\Common files\WindowsLiveInstaller\MsiSources 위치에 MSI 파일들이 위치해 있군요. 그 파일들만 있으면 MSI 설정만 변경하여 설치가 가능하다고 하군요.
자세한 내용은 http://extremeperformance.blogspot.com/2007/12/windows-live-writer-xp-x64.html 를 참조하세요~

* update
 위의 버전을 설치하게 되면 사용하는데는 문제 없었지만, 문제가 있었다. 특히 플러그 인과 같은 것이 제대로 설치되지 않았다. 게다가 이 프로그램의 버전업은 새로운 버전을 받아 설치하는 것인데, 이 후버전은 설치가 안되니, 업그레이드는 안되는 것이라고 보면 될 것 같다. 게다가 묘하게 자주 깜빡 거리는게 좀 거슬린다.

Windows 2003에서는 이상하게 공식 Windows Live Writer가 설치되지 않는다.

그래서 언제나 다운로드를 받아 놓고서는 집에서는 설치도 못해보고 발을 뺐다.

그렇다고 기껏 설치한 Windows 2003을 버리고 XP를 설치하기엔 왠지 억울 했다.

(개인적으로 성능은 2003이 더 낫다고 생각됨)

그래서 Microsoft 에서 제공되는 Application Verifier 라는 도구까지 동원해서 운영체제

호환성까지 속여 보려 했는데... 실패 했다.

그러던 어느날.. 브라우징 끝에, Google에서 Windows Live Writer install to windows 2003 이라는

검색어로 찾던 도중, 포스팅 된 좋은 글을 하나 발견, 그 링크를 따라 들어가다가,

마침 Windows Live Writer 개발 팀 블로그로 보이는 곳 까지 갔다.

( 근데, 이 웹페이지는 독일에서 만들었는지 .de 로 끝난다. )

그 곳에서 MSI 파일로 된 설치 본이 있었고, 난 그것을 낼름 받아 설치했다.

WLinstaller.exe 라는 파일을 받아 설치하면 영원하게 설치할 수 없고, 최신 버전인 MSI를 받아 설치하면,
아무런 호환성 테스트 없이 즉시 설치 들어가 준다.

일단, 그 덕에 설치했고 간단하게 세팅 완료~

다양한 Blogging desktop tool 들이 있긴 하지만, 유료거나, 한글 미숙지원 뿐인데,
이건 꽤 잘 만들어진 것 같다.

저녁에 퇴근하면서 조금씩 포스팅을 해야 겠다.

지지 난주에는 거의 매일 포스팅을 했었는데, 근좌 묘하게 바쁘고, 혼잡하게 지내다 보니,

포스팅은 커녕 일조차 제대로 하지 못한 느낌이다.

조금씩 정리하듯 글쓰면서 생각의 정리라는 것을 해봐야 겠다.

MOSS 2007 기술에 대한 정리가 이제 시작된듯 싶고, 그에 관련된 수많은 글들이

포스팅 되고 있어, 읽고만 있어도 할 것이 너무 많아 보인다.

일단, 그들의 글들을 읽고 나만의 생각들을 정리해서 담아봐야 겠다.

SPUser를 등록하는 방법은 사실 간단하다.

SPWeb.SiteUsers.Add("계정ID", "이메일주소", "보여줄 이름", "기타 메모")

위의 방법으로 사용하게 되면, 사용자 목록에 등록이 된다. 그러나 이렇게 등록하는 것으로는 해당 사용자가 사이트 내에서 제대로 활용할 수 없을 뿐더러 로그인 해봐야, 액세스 거부 창이나 팍팍 뜬다.

그러면 그 즈음 되서 권한 부분을 체크해 보게 된다.

게임은 지금 부터다.
그렇다면 이 권한 등록하는 방법들이 어떻게 있을까?

하나는 MOSS 2007에서 제공되는 그룹에 추가하는 방법이 있고, 다른 하나는 한사람 자체에 따로 권한을 주는 방식이다.

1. MOSS 2007에서 제공되는 그룹에 추가하는 방법
보통 그룹은 기본적으로 "사이트이름"+" 구성원", "사이트이름" + " 관리자" 형식으로 생성되어 진다.
그래서 보통 아래와 같은 형태로 짜기도 한다.

    SPGroup group = web.Groups["Members"];
    SPUser user = web.SiteUsers["KNOIE\\neohind"];
    group.AddUser(user);

그런데 그 그룹 이름이라는게 로컬라이즈 된 이름이라서 만일 "테스트 사이트" 라는 이름의 사이트에는 "테스트 사이트 구성원" 이런 식의 이름이 그룹이름이 된다. 객관적으로 좀 너무한 이름이지 않을까 싶다. 예제와 같은 이름이라면 위의 코드가 아래처럼 되어야 할 것이다.

   SPGroup group = web.Groups["테스트 사이트 구성원"];
   SPUser user = web.SiteUsers["KNOIE\\neohind"];
   group.AddUser(user);

좀... 너무 하지 않을까? 왠지 하드 코딩하는 기분을 지울 수 없고, 만일 어디에 포팅된다면.. 왠지 대박이지 않을까?
(저 같이 유지보수나 남아서 X 치우다 보면, 우울해집니다.)

그렇다면 어떻게 하면 좋을까?
이를 위해서 SPWeb에는 아래와 같이 관련 그룹에 대한 개체를 바로 꺼내 쓸 수 있는 부분이 있다

SPWeb.AssociatedOwnderGroup // ( 관리자 )

SPWeb.AssociatedMemberGroup  // ( 구성원 )

SPWeb.AssociatedVistorGroup // ( 방문자 )

즉 위의 예를 기준으로 변경해 보면 아래와 같은 코드가 된다.

  SPGroup group = web.AssociatedMemberGroup;
  SPUser user = web.SiteUsers["KNOIE\\neohind"];
  group.AddUser(user);

그 외 그룹(디자이너, 계층 구조 관리자)들은 알아서....

여튼 저 그룹에 Users 항목에 SPUser 형태로 더해 주면 된다. 그러면 자동으로 해당 권한을 할당해 줄 수 있다.

2. 개별 계정별 개별로 권한 매기기.

여기서 부터는 조금 복잡하게 돌아간다. 아마도 SPGroup에 특정 권한 쎄우려고 할 떄 사용하곤하는데, 이 또한 개별적으로 처리할 수 있다.

SPUser user = web.SiteUsers["KNOIE\\neohind"];
// 만일 관리자, 구성원, 방문자 단위가 아닌 기능별로 Roledefinition을 만드는 방법을 별도로 더 파악해야 함.
// 범위를 넘어가므로 여기서는 Contributor 즉, 구성원으로 권한을 설정.
SPRoleDefinition defContribute = web.RoleDefinitions.GetByType(SPRoleType.Contributor);
SPRoleAssignment roleContribute = new SPRoleAssignment(user as SPPrincipal);
roleContribute.RoleDefinitionBinding.Add(defContribute);
Web.RoleAssignments.Add(roleContribute);

위의  순서대로 보면 먼저 SPRoleDefinition을 생성 한다.
그리고 난 뒤 SPRoleAssignment를 생성한다. 여기서 생성할 때는 권한을 설정하려는 대상(보통 SPUser나 SPGroup)을 넣는다.
그리고 SPRoleAssgignment 내에 RoleDefinitionBinding에 앞서 만든 SPRoleDefinition을 추가한다.
맨 마지막으로 만들어진 SPRoleAssignment를 실제 권한을 설정하려는 Web, List, ListItem에 추가한다.

대부분의 MOSS 2007 개발자들은 이 사이트와 웹 간의 차이를 명확히 모르거나 어렴풋이 알아도 그게 그거가 아닌가 라는 어조로 표현하곤 한다.
하지만 개념적으로 명확히 틀린 구조이며 그 차이는 명확히 틀리다.

다음 그림을 보면 대략적으로 왜 사이트와 웹이 틀린지 알 수 있다.

즉 사이트 여기서는 SPSite인데, 최상위의 일종의 거대한 상자라고 보면 될 것이다. 이 안에 무수한 SPWeb을 붙여서 하나의 사이트를 만드는 것이다. 즉 사용자들은 SPWeb을 보는 것이지 SPSite를 보는 것은 아니다. 실제 사용자가 보기 위한 페이지, 리스트들의 모든 정보들은 바로 저 SPWeb에서 나오고, 그 외에 전체 검색이나, 차이점 분석 결과 등 전체 사이트에 대한 설정, 구성, 정보들은 SPSite에서 다루게 된다.
우리가 보통 새끼까기 하듯이 사이트 아래에 사이트를 만든다고 하는데, 그건 SPSite를 만든 것이 아니고 바로 저 SPWeb을 만드는 작업이라고 보면 된다.

보통 개발자들이 혼돈을 느끼는 부분이 바로 여긴데, MOSS 관리자 페이지에 가면 사이트 만드는 부분의 명칭이 "사이트 모음 만들기" 라고 적혀 있고, 해당 사이트의 페이지에 가서 사이트 관리 도구에 들어가면 하위 사이트 만들기 라고 적혀 있으니, 사이트 모음 = SPSiteCollection, 사이트 = SPSite 라고 생각하는 우리의 입장에서는 이 또한 무슨 망발이냐!!! 라는 의문을 바로 제기할 수 있다. 

그.러.나. SDK를 보면 우리를 또 한번 더 햇갈리게 한다. 양키 말을 들어보면 Web, Site 구분없이 막지껄이고 떠든다. 뭐가 Web이냐, Site냐.. 최소한 난 이것 때문에 상당한 혼란을 일으켰다. 그러면 저 SPSite와 SPWeb은 1:1로 하나씩 묶여서 구성된 건가... 했다.

그러나 진실은 SPSite는 무조건 한개, 그 하위의 모든 사이트들은 SPWeb이다. 그를 증명하는 부분은 바로 컨텐츠 DB. 만일 사이트 모음을 한개 만들어 놓고, 그 안에 새끼 까듯이 계속 사이트들을 만들어 99개를 만들었다고 하자. 그 때 컨텐츠 DB안에 사이트는 몇개 일까?
    1개다.
궁금하신 분은 테스트 해보시면 알 수 있다.
즉 사이트 모음은 SPSite를 의미하기 때문에, 그 SPSite 갯수인 1개가 들어가고 그 이후에는 어차피 SPSite 내에 포함된 하위 SPWeb들이기 때문에, 컨텐츠 DB 입장에서는 사이트 갯수에 포함 안되고, 단지 1개의 SPSite가 좀 커졌구나... 정도로 인식할 뿐이다.
(즉 늘어나는건 컨텐츠 DB의 사이즈 뿐이다.)

이런 개체들의 관계를 따라, 각 개체를 참조 할 때는 아래와 같이 찾아 들어가면 된다.

Microsoft.SharePoint.Administrator.SPWebApplication 로 가는 방법

  [SPSite 개체].WebApplication

Microsoft.SharePoint.SPWeb로 가는 방법

  [SPSite 개체].OpenWeb("url")

그리고 만일 위의 그림에서 1번 사이트를 연 뒤 (new SPSite("1번 사이트 URL")) 한 뒤, 저 OpenWeb을 써서 2번 사이트 아래의 웹을 찾으려면 당연하게 오류를 뿜는다. 저렇게 그림으로 보면 당연하거 아녀? 라고 되묻겠지만, 간혹 어떤 분들이 1번 사이트 열어놓고, 2번 사이트 내의 웹이 안 열린다고 투덜 댄다. MOSS 2007 버그니 뭐니.. 하는데... 한번 즈음 소스 검사 해보심이 ...

그리고 만일 특정 SPSite 및의 모든 하위 사이트(절대 SPSite가 아니다, SPWeb 이다.)에 대해 세팅을 동일하게 적용한다고 했을 때는 해당 SPSite를 열고 RootWeb을 연 뒤, 그 RootWeb에서 Webs를 이용하여 트리 탐색하듯이 찾아 들어가야 한다. 1번 사이트를 보면 그 아래의 SPWeb 아래 SPWeb들을 뒤져야 된다.
그 검색로직은 트리를 찾는 방법대로 진행되어야 할 것이다.

아침을 좀 빠르게 일어나 앉았다.
사실 MP3 찾는 거라든가, 어제밤에 챙겨 놓지 않은 노트북등 정리안된 부분을아침으로 미루었기에 당연히 일찍 일어나야 하는데, 문제는 내가 보통 때 그 시간에 잘 일어나지 못한다는게 핵심이다. 어쨌던 일찍 일어난 아침 덕에, 그간 찾지 못해 못들었던 모차르트 K183 알레그로 콘 브리오를 다시 듣기 위해 뒤적였고, 못챙겼던 출근 가방 챙겼다. 그리고 여유 있는 아침과 함께 너무 일찍 일어나 생긴 현기증을 동시에 느끼면서 따듯한 방바닥을 바로 비비며 미묘한 유혹에 져볼까 말까 하는 아슬아슬한 도전도 즐겼다.

그리고 옷 챙겨 입고 나서는 순간 온 세상은 잿빛 속 흰색으로 가득찼다.
우중충한 하늘에서 무수하게 떨어지는 눈은 한가득 내려 우리집 앞쪽의 모든 지붕들을 감싸버렸다.
길가에는 덩어리 진 흰 눈덩이들이 나돌아 다니고, 사람들은 우산 챙겨 들고 이리저리 바쁘게 지나가고 했다.
나도 그 속에 파묻혀 회사로 향하다, 문득 이른 아침의 시간을 보고 사진기를 꺼내들었다.

집 앞쪽에 위치한 공원도 아닌 조그만한 휴식처에 소복히 쌓인 눈이 이뻐보였다고나 할까.
가끔은 이런 여유도 즐겨 볼만 한 것 같다.

예전에 매일 매일 포스팅을 목적으로 잡글들을 올리고, 또 올리고 올리다가,

까먹고 한참 동안 안올리고.

바빠서 안올리고.

핑계의 핑계를 계속 하다가, 일주일에 한번? 심지어는 한달에 2~3번 포스팅에 마치는 경우도 있었다.

(대표적인 예로 10월달, 11월 달? 그 때 한창 프로젝트 말기에 치닫다 보니....)

이번에 한번 내가 생각난 것들에 대해 조금이라도 짬을 내서 포스팅에 포스팅을 계속해온 결과,

근 한주 연속 포스팅을 기록했다. 스스로 축하(自祝)

아마도 오늘 이후에도 계속 포스팅이 이어질지는 모르겠지만,

가급적 자주 포스팅을 해야 겠다.

한 10여년 전.
아무도 없는 곳이라도, 컴퓨터와 게임만 있으면 그다지 심심하지 않게 살 수 있으리라 믿었다.
그런데, 조금 열악한 환경에서 네트워크 안되고, 사람없는 곳에서 게임은 아니지만,
이런저런 놀이 도구들이 있었지만, 무척이나 심심했다.

지금.
다른 건 모르겠지만, 인터넷만 되면 그다지 심심할 것 같진 않다. 각종 잡다한 자료들을 다운로드 받아서 공부하고 보고 즐기며, 커뮤니티 사이트에서 서로간의 공감대를 찾아보고, 관심을 가지고 이야기하고 채팅을 하며 글을 남기는 것으로 충분하리라 생각된다.

하지만, 역시 직접 사람을 만나 얼굴 맞대고 이야기하고 떠들고 먹는 것.
그리워지지 않을까?

어떻게 흘러갈진 알 수 없는 듯.

기본 제공하는 Field 중 User 필드가 있다.  이 안의 값을 가져오면 다음과 같은 형식으로 저장되어 있다.

WebID#;사용자이름.

만일 해당 SPWeb 내에 Users 내에 강냥이 라는 사용자가 등록되어 있을때,

44#;강냥이

이런 식으로 기록된다. 물론 저 44라는 것은 SPUser의 ID를 의미한다. ( 무슨 숫자가 될지는 SPWeb 이 알아서 결정한다. )
예전에 이 필드 내에 있는 값을 참조할 때는 #;를 구분자로 나누어 44로 SPUser를 찾아 값을 처리하고 그 뒤의 문자열로 값을 처리했다. 언제나 저 문자열에 대해 SPlit 로 해서 배열 짜서, 하나씩 대응 했다.

이 작업이 쉽다고 하면 쉬울 수 있겠지만, 은근히 짜증나는 작업이 아닐 수 없다. 그렇다고, 이 작업을 위한 별도의 Static 함수 만들기도 애매모호 할 때 가 있다. ( Utility 함수들이 담긴 별도의 DLL을 만든다고 할 때, 그 DLL을 모든 프로젝트에 포함시켜줘야 할 것이다.)

이 때 해결해주는 구세주가 있으니 바로 SPFieldUserValue 라는 클래스 이다.
이 클래스를 사용하면 모두 끝난다고 보면 된다.
사용방법은 간단하다.

SPList list = web.GetList(http://wataru/Lists/Test);
SPListItem item = list.Items[0];
string sAuthorContext = item["Author"] as string;
SPFieldUserValue authorValue = new SPFieldUserValue(list.ParentWeb, sAuthorContext);
if(authorValue.User != null)
{
    String sLoginName = authorValue.User.LoginName;
}
else
{
      // 웹 내에 사용자가 없음
}

즉 SPFieldUserValue 클래스를 new로 생성할 때, 해당 SPWeb 개체와 User 필드내의 값 String만 넣으면 그 결과값을 바로 확인 할 수 있다.

.......

이 내용은 http://www.sharepoint-tips.com/2007/10/another-simple-code-snippet-using-user.html 에서 본 뒤 쇼크 받고 올린다.