팀 탐색기(Team Explorer)난 쉐어포인트 사이트를 통해 특정 파일 타입(예를 들어 .chm, .vbs)을 업로드할 때 실패하는 경우가 있네요.

보안 관계상 막는 게 당연한 파일들이 대부분인데요, chm의 경우 매뉴얼 등을 공유할 때 필요한거라 풀어줄 필요가 있었어요.
방법은 매우 간단.

1. 쉐어 포인트 중앙 관리 사이트에 접속
   http://TFS:관리port 또는 서버에서 직접 [시작]->[관리 도구]->[쉐어 포인트 3.0 중앙 관리]
2. 로그인 하고 [작업]->[차단된 파일 형식]
3. 목록에서 업로드를 허용할 파일 확장자를 삭제

자세한 것은 다음 기술 자료를 참고.
http://support.microsoft.com/?kbid=920785 
저작자 표시 동일 조건 변경 허락
신고
Posted by gongdo
TFS를 도입한 이후로 SharePoint로 구성된 팀 사이트에도 나름 익숙해져서 자료를 공유하는데 큰 불편은 없었는데요, 딱 한 가지 꼽아보자면 문서 라이브러리에 올려놓은 자료를 한꺼번에 다운로드가 불가능 하다는 문제가 있었어요.
특히 이미지 시안 작업 같은 것은 여러 개의 파일로 구성되어서 하나씩 다운받으려면 한 세월이 걸렸죠 -_-;
그래서 보통은 zip으로 묶어서 올리곤 했는데 또 그럴 경우는 하나만 보고 싶을 때 불편하고요.

뭐, 아니나 다를까 이 문제에 대한 솔루션이 코드 플렉스에 올라와 있더군요.
http://www.codeplex.com/MZakiCustomActions
이것은 문서 라이브러리에서 [작업]에 아이템들을 ZIP으로 묶어서 받을 수 있게 해주는 쉐어포인트 확장이에요.

릴리즈를 받아 보면 설치를 도와주는 인스톨러도 포함되어 있어서 저 처럼 SharePoint 전문가가 아니더라도 쉽게 설치할 수 있어요. 워낙 스크린 샷까지 잘 나와 있어서 자세한 설명은 생략.

한가지 주의할 점은 서버에서 설치에 사용하는 계정이 각 팀 사이트의 모든 권한을 가지고 있어야 한다는 점이에요.(이 부분은 정확한 건 아니고 전에 해봤을 때에는 권한이 없을 경우 실패했던 걸로 기억해요)

한줄 요약.
선검색후삽질.
저작자 표시 동일 조건 변경 허락
신고
Posted by gongdo
후우... 몇 일간 일도 못하고 이게 무슨 캐삽질이여...
그놈의 샘X 하드에 물리 배드가 생기는 바람에 그간 작업했던 TFS의 피같은 Work Item들을 다 날렸습니다.
진짜 하늘 노래지네요. 그나마 소스 코드 최종본들은 각자의 PC에 남아 있어서 프로젝트 완수에는 큰 지장이 없을 것 같지만...

언제나 백업은 소 잃고 외양간 고치기.
다음엔 나아질까...

여튼 기왕 다시 까는 김에 마이크로소프트의 2008 삼총사가 모두 정식 릴리즈도 되었겠다 그간 TFS 설치엔 나름 노하우가 생겼겠다해서 과감하게 2008 삼총사로 TFS를 구축해봤어요. 바로...
  • Windows Server 2008 (with IIS7)
  • SQL Server 2008
  • Visual Studio Team Foundation Server 2008 SP1
  • Windows SharePoint Service 3.0 SP1
진짜 과감하다 못해 파격적이지 않습니까! 네!? 진짜 그랬다고요!

이게 TFS 설치는 정말 순조로웠어요. 이 전하고 다르게 http://go.microsoft.com/fwlink/?LinkId=79226 이 링크에서 받을 수 있는 TFS 설치 가이드 문서가 가리키는 순서대로만 설치하면 문제 없이 잘 깔려요.

한 방에 설치를 끝내고 정말 기분 좋게(그러나 남은 노가다에 난감하게) 기존 프로젝트 들을 새로 만들고 세팅을 하고 있는데...

An error has occurred during report processing. (rsProcessingAborted)
Query execution failed for dataset 'IterationParam'. (rsErrorExecutingCommand)
For more information about this error navigate to the report server on the local server machine, or enable remote errors

리포팅 서버에서 이런 에러가 떡!하고 나오더군요.

게다가 뒤에 붙어있는 도움말 링크를 클릭해보면...
미안하지만 아직 문서가 준비 안됐거든? 나중에 해볼려? 이딴 소리나 하고... 아오!!!

그래서 또 다시 MSDN 포럼의 바다로 다이브.
딥 다이브.
    답은 2005에서나 쓰이던 방법
아직도 다이브.
    답은 TFS 2008 Beta에서나 쓰이던 방법
언제까지나 다이브.

그렇게 몇 시간인가 헤매다 겨우 답을 찾았네요.

문제 핵심을 요약해 보자면 SQL Server에 대한 접근 권한 문제로 발생하는 건데요, TfsWarehouse라는 데이터 베이스에 접근할 때 SQL Server의 기본 사용자인 NetworkService 계정에 권한이 없었던거죠.
이게 버그인지 뭔지 모르겠고 어쨌든 TFS 설치가이드 문서만 믿고 가다가 뒤통수를 제대로 강타 당했죠.

또 한번.
다시 한번.

거의 반쯤 정신 나간 상태로 포스팅하는거라 자세한 정리는 못하겠고, 여튼 http://social.msdn.microsoft.com/forums/en-US/tfssetup/thread/6d1d89c6-d167-4e2c-85d6-8a2e330a1041/ 
여기에서 DeChrist 이 사람이 쓴 답글을 참고하면 대략 해결 책을 찾을 수 있을 거에요.
잊지말고 꼭 찾아보길 바래... ㅠ.ㅜ

저작자 표시 동일 조건 변경 허락
신고
Posted by gongdo
푸하... 세상에 이렇게나 복잡한 설치 과정을 가진 서비스는 Linux from scratch 이후로 처음이네요.
단순히 복잡한게 문제가 아니라 중간에 설정 뭐 하나 잘못하면 그거 원인 찾아서 고치느니 처음부터 다시 까는게 나을 정도... 물론 이게 다 시스템 기반을 이해하지 못하고 설치해서 그런것이긴 하지만 다들 인정하듯이 마이크로소프트 제품군의 최대 장점은 관리하기가 더럽게 쉽다! 아니겠어요?

여튼 서버에 관한 지식이 조금만 있으면 관리할 수 있는 IIS(웹기능만 한정하자면)나 여타 다른 서버군에 비해 Team Foundation Server는 정말이지 지옥과도 같았어요.

약 1주일에 걸친 삽질을 정리한 결과물을 공개합니다. (ㅠ.ㅜ)


설치 환경은 다음과 같아요.
  • 서버 한대에 모든 서비스를 설치
  • Windows 2008 Server
  • 로컬 계정 사용(Active Directory를 사용하지 않습니다.)
  • .NET Framework 3.5
  • IIS 7.0
  • Team Foundation Server 2008
  • SQL Server 2005
  • SharePoint 3.0 SP1

뭔가 복잡해 보이죠? 예, 복잡해요 -_-;
Team Foundation Server라는 것이 단일 제품으로 설치될 수 있는게 아니고 IIS와 SharePoint Service 및 SQL Server에 대한 의존성을 가지고 있죠. 또한 SharePoint Service역시 IIS와 SQL Server에 대한 의존성을 가지고 있고요. 게다가 각 서버/서비스의 제품 버전에 따라 서로 설치 옵션과 호환성이 달라서 제대로 하려면 정말 빡세게 돌려야 하더군요. 더군다나 저처럼 SharePoint를 한번도 안써본 사람에겐 더욱 힘들것 같아요.

여튼 이렇게까지 고생해서 할 가치가 있느냐? 하면 아직은 잘 모르겠어요. 그렇지만 전에 CodePlex를 통해 잠깐 경험해본 TFS는 정말이지 매력적이었거든요. 다소 불편한 부분도 익숙해지면 프로젝트 관리에 큰 도움이 될거라고 생각해요.

참고로 위의 자료는 어디까지나 '야매' 시술이니 제대로, 정석대로 익힐 분은 다음의 최신 문서들을 참고하세요.


신고
Posted by gongdo

일반적으로 ATL 기반의 ActiveX COM 개체들은 이벤트를 개체가 생성된 스레드 내에서 발생(Firing)시켜야 합니다.
그런데 프로젝트를 해보면 대체로 이벤트라는건 어떤 작업을 비동기적으로 수행하고 그 작업이 완료 되었을 때 발생하는 경우가 많아서 같은 스레드 내에서 윈도를 생성하여 메시지 펌프를 돌리지 않는 이상 보통은 스레드를 사용하게 되죠.

특히, ATL로 만든 COM 개체를 VB에서 쓸때 다른 스레드에서 이벤트 발생을 요청하면 VB 디버깅 모드에서는 잘 되다가도 컴파일하고 실행해보면 잘못된 페이지 오류(IPF : Invalid Page Fault)나 보호 모드 오류(GPF : General Protection Fault)가 발생하면서 런타임 오류 트랩의 기회도 없이 애플리케이션이 다운되어버리는데요, 역시나 MSDN에 답이 있네요.

<참고 링크>
[Q196026] PRB: Firing Event in Second Thread Causes IPF or GPF
[Q280512] SAMPLE : ATLCPImplMT encapsulates ATL event firing across COM apartments
[Donwload] http://download.microsoft.com/download/a/5/5/a552e657-1ecb-453d-9bae-17d0db333337/atlcpimplmt.exe

Q196026에 의하면 VB에서의 IPF, GPF 오류를 방지하기 위해 ATL 프로젝트내에 메시지용 윈도를 하나 생성하고 어떤 이벤트 발생을 윈도 메시지를 통하여 비동기적으로 수행하도록 합니다.

이 방법은 전달할 이벤트가 단순한 통지의 성격을 가질때 매우 편리합니다. 귀찮은 메시지 큐를 만들지 않아도 윈도가 알아서 다 해주고 개발자가 만드는 것보다는 훨씬 신뢰성이 있지요. 하지만 비동기 수행을 요하는 작업이 끝났을 때 어떤 복잡한 데이터를 전달해야 하거나 전달할 이벤트의 종류가 다양할 경우 윈도 프로시져에서 해야할 일이 너무 많아지고 무엇보다 그냥 스레드를 만들어 쓰는 경우가 많다는거죠.

Q280512를 보면 cross apartments, (정확하진 않지만) 쉽게 말해 스레드를 넘어 이벤트를 전달하기 위해 새로운 클래스를 제공합니다.
[Download]를 받아서 압축을 해제하면 ATLCPImplMT.h 라는 파일이 덜렁 나옵니다.
이 파일은 IConnectionPointImplMT 인터페이스를 제공하는데 ATL 프로젝트에 적용하는 방법은 다음과 같습니다.
※참고로 아래의 코드는 VC6기준입니다. .Net을 사용하신다면 위의 참고 링크 본문에 나와있으니 확인하시면 됩니다. 구성의 거의 같으니 어렵지 않게 고칠 수 있습니다.

1. 이 파일을 ATL 프로젝트 폴더에 복사하여 프로젝트에 포함하거나 ATL Include 경로에 복사합니다.
2. ATL 프로젝트의 이벤트 발생을 위한 프록시 클래스-보통 위저드가 생성한 경우 CProxy_이벤트인터페이스명-를 열고 윗부분에 include 합니다.

#include "ATLCPImplMT.h"

3. 프록시 클래스의 상속을 다음과 같이 수정합니다. (붉은색 부분만 바뀝니다.)

<수정전>
class CProxy_IEventFirerName : public IConnectionPointImpl<T, &DIID__IEventFirerName, CComDynamicUnkArray>
<수정후>
class CProxy_IEventFirerName : public IConnectionPointImplMT<T, &DIID__IEventFirerName, CComDynamicUnkArray>

4.  프록시 클래스의 위저드가 생성한 Fire_이벤트이름 함수에서 다음 코드를 찾아 수정합니다.

<수정전>
pT->Lock();
CComPtr<IUnknown> sp = m_vec.GetAt(nConnectionIndex);
pT->Unlock();

<수정후>
CComPtr<IUnknown> sp;
sp.Attach (GetInterfaceAt(nConnectionIndex));
5. 이제 Fire_이벤트이름 함수는 다른 COM 스레드(다른 apartment)에서 호출될 수 있습니다.

아직 끝이 아닙니다. :(
위와 같은 코드를 사용하기 위해서 ATL 프로젝트는 반드시 multi-threaded apartment(MTA) 옵션으로 작성되어야 합니다. 이 옵션은 ATL 프로젝트를 생성할 때 꼭 체크해야 하죠.

그리고 어떤 작업 스레드 내에서 Fire_이벤트이름 함수를 호출할 때 일종의 락을 걸어준다는 기분으로 다음과 같은 코드를 사용해야 합니다.
DWORD WINAPI someWorkerThread(LPVOID lpParameter)
{
   // MTA 작업 스레드를 위한 COM 초기화
   HRESULT hRes = CoInitializeEx(NULL, COINIT_MULTITHREADED);

   //...작업...

   // 이벤트 발생!
   Fire_이벤트이름();

   // COM 해제
   ::CoUninitialize();
}
이제 VB에서 작성한 이벤트를 받아봅니다.
잘되네요 :)
신고
Posted by gongdo
TAG atl, com, thread, vb
아, 정말이지 MS는 기술 지원 하나만으로도 먹고 살 것 같습니다.
VB에서 사용할 C DLL을 만들때마다 자료 찾느라 귀찮았는데 정리도 잘 되어있고 아주 심플하면서도 사용하기 편리하게 되어있습니다.

링크 : KB189133

VB 프로그래머들은 C/C++로 만들어진 소스나 라이브러리를 받게 되면 고민을 하게 됩니다.
소스나 static library일 경우에 _stdcall 방식의 함수 export를 제공하는 DLL 작성하면 그만이라 고민이 좀 적겠지만 컴파일된 dynamic library인데다가 _stdcall 호출 방식을 사용하지 않는 일반 C DLL이면 참 사용하기 애매하죠.

이걸 무식하게 다시 _stdcall을 사용한 dll을 만든다면
C DLL -> (_stdcall) C DLL -> VB declare Module -> VB code...
이런 과정을 거치는데 VB에서 Declare문을 사용하여 일일이 선언해야 하는 것도 참 귀찮습니다. 게다가 내부적으로 enum과 같은 편리한 도구를 지원하지 않으니 보통 C DLL을 래핑하는 VB 모듈을 또 만들게 되죠.

이왕 한다리 거치는 김에! ATL을 사용하여 COM DLL로 래핑하자니 ATL이란게 만만치가 않은 작업이라 배보다 배꼽이 커지는 꼴이 될 수 있습니다. 게다가 라이브러리 내부적으로 스레드가 필요한 경우라면 COM 마샬링 관련해서 머리에 쥐나게 되죠. -ㅅ-

사실 VB를 쓰는게 쉽고 빠르게 하기 위해서인데 라이브러리좀 쓰자고 저런 삽질을 해서야 되겠습니까?
그런 점에서 KB189133 문서는 정말 좋은 팁이죠.

이 문서를 참조해서 만든다면,
C DLL -> (_stdcall) C DLL + Type Library -> VB code...
이런식으로 과정을 하나 줄일 수 있을 뿐만 아니라 C DLL 내에 Type Library(TLB)를 내장하여 미리 필요한 Enum이나 공용 모듈을 등록해놓을 수 있으므로 지저분하게 VB에 Declare하고 래핑하는 과정이 필요 없어집니다.

이미 VS5 시절에 나왔던 문서인 것 같은데 이제서야 보게 되다니 그간의 삽질이 눈물겨울 뿐이지요. 후우...

이 문서 덕분에 어지간한 C 라이브러리를 VB에서 사용할때 어렵게 ATL DLL을 만들지 않고도 잘 써먹을 수 있을 것 같습니다. 덤으로 TLB를 만들고 활용하는 요령도 얻을 수 있구요.
신고
Posted by gongdo
TAG dll, TLB, vb


티스토리 툴바