전제사항

제일 먼저 서버군에 대한 지식을 어느 정도 알고 있어야 합니다. Active Directory가 무엇인지, Join 이란 무엇인지, IIS 설정은 어떻게 들어가야 하는지 등등. 이에 대한 배경 지식을 쌓기가 쉽지는 않겠지만, Windows Server 2008 R2에 대한 서적을 찾아보고, 직접 Windows Server 2008 R2를 설치해서 사용하다 보면 어느 정도 파악할 수 있을 것입니다. 일부 기본적으로 파악해야 된다고 생각되는 사항은 넘어갔습니다. 가급적이면 기본적인 서버 인프라에 대한 이해는 어느정도 하셔야 할 것 같습니다.

준비 사항.

먼저 환경을 구성하기 위한 서버 제품들을 확보해야 해야 합니다. 최소한 MSDN에 가입되어 있어야 여기서 제시하는 설치방법을 진행할 수 있습니다. (단독 제품으로 구매했다면, 제약이 많거나, 예제와 달라질 수 있습니다.)

필요한 서버 제품들은 다음과 같습니다.

• Windows Server 2008 x64 이상
• MS SQL 2008 이상.
• Windows SharePoint Service 3.0 이상

물론 TFS 안에는 MS SQL Express 2008과 WSS 3.0 설치 파일을 가지고 있습니다. 그래서 Standalone으로 설치하면다면 자동으로 해당 제품들을 기준으로 자동 구성됩니다. 하지만 운영하는데 제약점이 될 수 있기 때문에, 가급적 Database와 SharePoint를 각기 설치하는 것이 좋습니다.

여기서 예제로 구성할 땐, Windows Server 2008 R2 Standard 1 Copy, Team Foundation Server 2010  1 Copy,  MS SQL 2008 Standard Edition, SharePoint Foudnation 2010 정도로 구성할 예정입니다.

그리고 인증 서버가 반드시 필요합니다. 여기서 사용되는 인증 서버는 Active Directory 라는 환경을 사용하게 됩니다.  서버간의 인증에서 부터, 사용자 관리, 권한 설정까지 모두 Active Directory를 이용하는 것입니다. 단, 주의할 점은 한 대의 서버에 모든 서비스를 담는다고 TFS가 설치될 서버에 ActiveDirectory를 얹어서는 안됩니다. 반드시 별도의 PC를 마련해 별도의 PC 내에 Active Directory 서버를 구축하고, TFS와 완전히 물리적으로 분리되어 있어야 합니다.

이 예제에서는 사내에서 사용되는 AD에 붙어서 작업할 예정입니다.

서버 설치

운영체제 설치

MS Windows Server 2008 R2를 설치합니다. 근래 MS에서의 서버 제품 군 대부분은 x64로 동작하다 보니, 자연스럽게 운영체제 역시 x64로 설치됩니다.. 2008 R2도 별다른 표기가 안되어 있지만, 실제로 설치해보면 x64 입니다. 운영체제 설치는 여기 범위에서 벗어나므로 일단 넘어갈 예정입니다. 기본적인 설치 과정에서 벗어나는 것이 없기 때문입니다. 다만, 설치한 후 몇 가지 추가적인 설정이 있습니다.

1. 컴퓨터 이름을 설정한다.
   최초 설치할 때 설정할 수 있지만, 자동으로 설치 진행하는 경우 자동으로 만들어진 서버이름을 그대로 쓰는 경우가 있습니다. 물론 그대로 서버이름 변경없이 사용할 수도 있지만, 그 때마다 암호문 같은 이름 ( 예를들면 WIN-798FXE112  같은 이름)으로 사용한다는 것도 문제가 있다고 봅니다. 물론 사용 중에 중간에 바꿀 수 있지만, 그 경우 이미 설치된 제품들이 제대로 동작되지 않는 경우가 발생될 수 있습니다. 그러므로, 구성하기 전에 컴퓨터 이름을 적절하게 설정합니다.
   여기서는 TFSTest 라는 이름으로 설정했읍니다.
2. IE 보안 정책을 끈다.
   서버 내에서 Internet Explorer를 거의 쓸 일이 없기 때문에, 직접 서버 내에서 IE를 안전하게 쓰라고 보호막을 구성했고, 기본적으로 활성화 되어 있습니다. 하지만, 굳이 보안에 민감한 사항이 아니라면 아예 이 부분을 꺼버리는게 사용하는데 불편함이 없습니다.
   서버 관리 콘솔에서 “Configure IE ESC” 라는 항목에 들어가서 모두 Off 해 버리면 됩니다. 나중에 실제 운영할 때, On 시켜두셔도 무방합니다.
   
3. .NET Framework 3.0 Feautre 설치.
   Windows Server 2008 R2를 설치하였다면, 자체적으로 Windows 구성요소 중 .NET Framework를 가지고 있읍니다. 하지만, 보안 정책 상 자동으로 설치되어 있지 않고, 별도 패키지처럼 일일히 따로 설치해야 합니다.
   서버 콘솔 창에서 “Features”를 클릭해서 연 뒤, “Add Features”를 클릭하면 설치 가능한 Feature들이 나옵니다.  그 중 .NET Framework 3.5.1 Features를 선택하고 설치하도록 합니다. 그러면 자동으로 연관된 Feature인 IIS(Internet Information Service)가 같이 설치된다고 나오는데, 그대로 같이 설치해주기만 하면 됩니다.
   
      

Active Directory로 Join

제일 먼저 Active Directory 서버에 Join을 수행합니다.

서버간의 인증문제나, 사용자 계정 처리 문제를 해결하기 위해서라도, 반드시 Active Directory는 있어야 합니다. 그러므로 따로 구축한 Active Directory에 Join 하여 구성하도록 합니다.Active Directory로 Join 하는 방법은 간단하므로, 넘어갑니다.

여기서는 tfsadmin 이라는 계정을 Active Directory 상에 만들었으며, 이 계정을 TFS 서버에서는 Admin으로 동작하게 끔 수정했읍니다. tfsadmin 이라는 계정으로 TFS에 로그인을 합니다.

SQL 서버 구축

본격적인 서버 설치 작업입니다.

TFS 뿐만 아니라, UI 역할을 하는 SharePoint 역시 이 SQL의 존재가 제일 중요합니다. 모든 데이터의 저장 뿐만 아니라, 심지어 설정 값 까지 대부분의 정보는 DB 내에 보관되게 됩니다. 그러므로 가장 기반이 되는 정보 장치로써 설치를 하도록 합니다.
현재 MS SQL은 2008 R2 까지 출시되었으며, 탑재된 기능 및 범위 별로 제품 Scue도 나뉘었읍니다. Express라는 무료 버전에서 Datacenter 라는 대규모 버전까지 있읍니다. Express로도 사용은 가능하지만, 내부적으로 최대 DB 크기 4G라는 제한의 벽은 나중에 운영하는데 큰 지장을 초래하므로, 가급적 Standard 버전 이상을 설치하는 것을 권장합니다.

여기서는 MS SQL 2008 R2 Standard Edition x64 를 설치합니다.

맨 처음 SQL Server Installation Center가 뜨는데, 여기서 “Installation”  -> “New installation or add features to an existing installation”를 선택하도록 합니다

자동으로 제품 설치 전 작업을 수행합니다. 간단한 내부적인 검사 및 제품 키, 라이센스 동의 그 밖에 설치용 지원 파일 설치 작업을 순서대로 수행하게 되는데 거의 Next 만 해도 진행이 됩니다. 기본적인 설치 전 단계의 작업이 완료되면, 이제 실질 적인 설치 작업이 실행되게 됩니다.

이제부터 실제적인 설치 화면이 나오게 됩니다. 왼편에 보이는 항목들이 각 단계인데, 각 단계별 설명을 넣었습니다.

[Setup Support Rules] 맨 처음 뜨는 설치 단계는 SQL 에 필수적으로 필요로 하는 구성요소가 제대로 있는지, 아니면 운영체제 환경이 제대로 맞는지 등을 전체적으로 검사하는 작업을 합니다. Error 만 안뜨면 큰 문제는 없지만, 최대한 모든 항목이 Pass가 나오도록 운영체제에 대한 설정을 해주는 것이 좋습니다. (예제에서는 Firewall 관련 Warning이 나왔지만, 큰 문제는 없어서 이 부분은 넘어갑니다. )

[Setup Role] 다음으로는 설치 유형입니다. “SQL Server Feature Installation”과 “All Feature With Default”가 있는데, 굳이 번역을 하자면, “사용자 정의 설치”와 “빠른 전체 설치”로 보시면 됩니다. 즉 하나는 하나씩 설정해주는 작업이고, 다른 하나는 기본 값으로 설치를 하는 것이죠. 어느 쪽이든 상관 없지만, 여기서는 “SQL Server Feature Installation”을 선택했습니다.

[Feature Selection] 그러면 설치 할 제품 기능들이 나오는데, 필요한 기능들을 선택하시면 됩니다. 전체를 다 선택해도 되고, 설명을 읽어보시고 꼭 필요한 것만 설치하셔도 됩니다. 하지만, 반드시 Database Engine Service, Client Tools Connectivity와 Management Tools는 꼭 설치하시기 바랍니다. 예제는 아래와 같이 선택했습니다.

아래에서는 Report Service를 넣기는 했지만, 반드시 필요한 경우가 아니면 빼도 상관 없습니다. 여기서는 Report Service를 사용하지 않는 형태로 구축할 예정입니다.

그러면 이제 자동으로 기능간의 의존관계들을 체크하는 화면입니다. 여기서는 자동으로 기능간에 빠진 기능이나, 잘못된 선택이 있는지 자동으로 판단합니다. 여기서 오류가 있다면 이전 화면에서 기능들을 다시 선택하시고 진행하시면 됩니다.

[Instance Configuration] 다음은 인스턴스 설정하는 화면입니다. 변경할 사항이 있다면 변경하겠지만, 대개의 경우 특별한 설정은 필요 없습니다. 여기서도 별다른 설정 없이 넘어갑니다.

[Disk Space Requirements] 저장된 곳의 용량에 대한 리포트가 뜹니다. 역시 큰 문제가 없으면 넘어갑니다.

[Server Configuration] 서버 구성입니다. 각 서비스들의 동작 계정과 정렬용 기준 언어 등을 설정합니다. 예제에서는 AD 계정인 tfsadmin이 있는데, 이 계정을 서버 동작 계정으로 사용합니다. 그리고 정렬용 언어로는 Korean-Wansung-CI_AS로 설정했습니다. 각 설정은 상단 Tab에서 변경하면 설정 화면이 각기 나옵니다.

[Database Enginee Configuration] 다음은 Database Engine 설정 화면인데, 인증 방식, 관리자 권한을 가진 계정을 설정하거나, 데이터 위치, FILESTREAM에 대한 설정이 나옵니다. 각기 원하는 설정을 해주시면 됩니다. 여기서는 계정 관련해서만 수정했는데, SQL 인증방식과 Windows 인증 방식을 동시에 사용하며, 관리자 계정을 tfsadmin 으로 설정했습니다. 그 외는 기본값으로 두었습니다.

[Reporting Service Configuration] 그 다음은 Report Service 설정인데, 특별히 아는 설정이 있으면 구성하시기 바랍니다. 여기서는 기본값으로 해서 넘깁니다.

[Error Reporting] 서버 내 오류가 발생하였을 때, MS 쪽에 자동으로 에러 보고를 하는 기능에 대한 일종의 동의서 처리인데, 그냥 넘깁니다.

[Installation Configuration Rules]지금까지 설정한 내용에 오류가 있는지 체크합니다. 큰 문제가 없으면 계속 진행합니다.

[Ready to Install] 이제 전체 설정된 사항들을 모두 보여주는 요약화면입니다. 트리 형태로 표시되어 한눈에 전체 설정 내용을 모두 보여줍니다. 이제 “Install” 버튼을 클릭하면 실제 설치 화면이 나오게 됩니다.

[Installation Progress] 이제 진행율을 보여주면서 실제 파일 복사 및 자동적인 설정 작업을 수행하게 됩니다. 모두 설치가 되면 Complete가 되고 “Finish”를 클릭하면 모두 종료됩니다.

설치가 완료되면 이제 데이터베이스가 준비가 되었다고 판단하셔도 됩니다.

SharePoint Foundation 2010 설치

이 부분이 반드시 필요한 것은 아니지만, Team Foundation Server의 Web 기반 UI의 존재가 필요한 경우 설치를 해주는 것이 좋다. 자체적으로 문서 관리를 해줄 뿐만 아니라, TFS에서 발생되는 각종 값들( 버그 리포트, 작업 스케쥴 등등) Visual Studio 없이 직접 Web 상으로 볼 때는 이 부분이 꼭 필요로 합니다.

기본적으로 Windows SharePoint Service 3.0 이면 되지만, 유려한 UI와 기능 업그레이드가 잘 된, SharePoint Foundation 2010으로 진행할 예정입니다.

SharePoint Foundation 2010은 MS 사이트 등에서 무료로 다운로드 받을 수 있습니다. 최소한 Windows Server 2008 이상 서버에 대해서 자체적인 라이센스를 가지고 있다고 보시면 됩니다. 그래서 무료로 다운받아 사용이 가능합니다. 또 x64 버전 밖에 없기 때문에, x64 버전의 운영체제 에서만 동작합니다.

다운 받은 실행 파일을 실행하면 자동 압축을 풀고 아래와 같은 화면이 뜹니다.

2010부터는 SharePoint에 필요한 환경을 자동으로 검사해서 추가적으로 필요한 구성요소들을 자동으로 구성해주는 기능이 있습니다. Windows에 탑재되어 있으면 자동으로 활성화 해주고, 없으면 외부에서 다운로드까지 해서라도 설치해주는 기능입니다. 이 기능을 실행하려면 "Install software prerequisites"를 클릭하면 됩니다.

그럼 자동으로 어떠한 제품들이 추가 되야 되는지를 찾아서 해당하는 패키지들을 설치합니다. 운영체제 기능에서부터 Windows Hotfix 까지 자동으로 기능을 검색하고 꼭 필요한 사항들을 완전 자동으로 설치하게 됩니다. 그냥 기다리기만 하면 됩니다.

심각한 오류가 발생되지 않는 다면 위와 같은 화면으로 대략 5~10분 정도 구성하게 됩니다. 단, 이 때, 모든 패키지를 이 설치 파일에 담겨 있지 않아, 간혹 필요한 사항들을 인터넷을 통해 다운로드 받게 됩니다. 그러므로 이 기능을 이용해 설치하는 동안에는 반드시 인터넷이 연결되어 있어야 합니다.

정상적으로 완료되면 Complete라고 뜨고 요약화면이 나옵니다. “Finish”를 클릭해 종료합니다.

이제 준비 작업은 끝났고, SharePoint Foundation을 본격적으로 설치합니다.

SharePoint Foundation의 설치 방법은 크게 두 가지가 있읍니다. 하나는 Standalone 이고, 다른 하나는 Server Farm 방식입니다. Standalone은 자동으로 SQL Server(내장된 Express 버전)를 설치하고 자동으로 팀 사이트까지 만들어주는 방식입니다. Server Farm은 사용자가 Server 구성요소에 대한 적절한 설정을 직접하여 설치하는 방식입니다.

여기서 수행할 방법은 Server Farm 방식으로 진행할 것입니다.

맨 처음 “Install SharePoint Foundation”을 시작하면 License Agreement가 뜹니다. 체크하고 Continue 합니다.

다음에는 “Server Farm:을 선택합니다.

Server Type에서는 Complete를 선택한다. SharePoint Foundation의 모든 기술들을 설치하도록 하는 것입니다. 그래야 원하는 형태로 구성하는 작업을 수행합니다. 만일 Standalone으로 하면, 자동적으로 SQL을 설치하고 자동으로 사이트를 구축해 버립니다.

그러면 설치가 들어갑니다. 하지만, 여기서는 설정 작업 없이, SharePoint Foundation을 복사하는 정도의 역할만 수행하게 됩니다.

완료되는 다음과 같은 화면이 뜨는데, “Run the SharePoint Products Configuration Wizard now”를 체크해놓은 상태 그대로 Finish를 클릭합니다. 그러면 자동으로 SharePoint Foundation 설정 화면으로 넘어갑니다.

기존 설치 프로그램이 종료되고 이제 설정을 위한 프로그램이 시작 되면 아래와 같은 환영 메시지가 보입니다.

여기서는 기존에 존재하는 SharePoint가 있다면 그 SharePoint에 연결할지 여부를 결정하는 부분입니다. 지금 하는 작업은 기존 SharePoint에 연결하는 것이 아니므로, "Create a new server farm”을 선택합니다.

이제 Database 설정에 들어갑니다. SharePoint의 모든 설정 내용은 모두 DB에 기록되므로 이 DB 설정이 무척 중요합니다. 하지만, 중요도에 비해 크게 설정할 내용은 없읍니다. 대부분은 자동으로 수행되기 때문이죠. 그래서 DB 접속에 필요한 일부 정보만 넣으면 됩니다.

다음을 참고하여 적절한 값을 넣습니다.

• Database server : MS SQL이 설치된 컴퓨터 이름을 넣으면 됩니다. 여기서는 TFS 설치용 PC안에 MS SQL도 깔았으므로 현재 구축하려는 PC 이름을 넣으면 됩니다.
• Database name : SharePoint 설정 저장용 DB 이름인데, 굳이 변경할 필요는 없습니다.
• Username : MS SQL에 접속이 가능하고, DB를 생성할 수 있는 권한을 가진 계정을 넣으면 됩니다. 반드시 AD 상의 계정만 들어갑니다. 
• Password : 위의 계정에 대한 암호를 넣습니다.

입력한 정보로 Database에 연결되고, 설정 데이터용 데이터베이스가 생성되면, 정상적으로 Next가 됩니다. 만일 위의 정보로 제대로 진행되지 않는다면, 계정이 Database에 접근할 수 없는 권한이거나, Database server 이름이 잘못되었을 가능성도 있습니다. 혹여 이전에 SharePoint가 설치되었던 PC라면 Database name을 변경해야 할 수도 있습니다.

정상적으로 넘어갔다면, 이번에는  SharePoint 끼리 연결될 때 사용되는 암호를 넣는다. 중요하지 않으므로 적절히 넣습니다.

마지막으로 관리자 페이지 접근용 포트 번호 설정과 로그인시 사용하는 방법들을 선택하는데, 그대로 두고 Next를 합니다. 만일 관리자용 사이트 페이지에 종종 접속하는 경우가 있다면, 포트 번호를 적당히 기록해두시면 이용하는데 도움이 됩니다. 필요하면 Port 번호를 변경해도 됩니다.

모든 설정이 완료되었으면 요약화면이 뜹니다.이제 Next를 하면 자동으로 설정하기 시작합니다.

본격적으로 Database도 만들고, 구성하기 시작합니다.

모든 설정이 정상적으로 끝나면 설정 요약 내용이 나오는데, 이제 Finish를 클릭하면 됩니다.

그럼 자동으로 SharePoint 관리자 페이지가 뜹니다. 여기서 간단한 사이트만 만들면 됩니다. 만드는 방법은 Wizard를 따라가면 쉽게 만들 수 있습니다.

Team Foundation Server 설치

TFS 2010 설치용 DVD를 넣고 동작시키면 다른 서버 제품과는 다르게, 자동 실행 자체가 없습니다.(물론 업데이트되면 바뀔 수 있습니다.)

그래서 폴더 안에 위치한 설치 파일을 직접 실행해야 합니다. ( DVD 위치가 X:\ 라고 가정 )
X:\TFS-x64 위치에 있는 setup.exe를 실행한다. 그러면 Visual Studio 와 같은 Installer 화면이 뜹니다.

첫 화면에서는 특별한 동작이 없으므로 다음을 클릭합니다.

License Agreement를 하고 다음을 클릭 합니다.

앞서 언급했듯이 이 단계의 설치 작업에서는 별도 설정 작업이 없습니다. 오직 파일 복사처럼 필수적으로 필요한 패키지의 메인 프로그램의 복사레벨로 생각하시면 됩니다. 실제적인 설정 작업은 이 모든 설치 프로그램이 종료되면 자동으로 실행됩니다,.그러므로, 여기에 설치한 기본적인 패키지를 설치하면 됩니다.

위의 화면처럼 두 가지의 패키지를 설치하시면 됩니다. 하나는 Team Foundation Server 이고, 다른 하나는 Extentions for SharePoint Products and Technology 입니다. Team Foundation Server는 TFS를 구성하는 메인 프로그램이므로 당연히 설치를 해야 하고, 그 뒤에 따르는 Extentions for SharePoint Products and Technology는 TFS와 SharePoint와 연결할 때 사용되는 각종 웹파트, 사이트 템플릿 등을 적용할 때 필요한 패키지 입니다.

이처럼 패키지를 나눈 이유는 물리적으로 서버를 분리하여 구축할 때 그 역할에 맞추어 설치할 수 있도록 하기 위함입니다. 그래서 나머지 Team Foundation Server Proxy와 Team Foundation Build Service는 나중에 다른 PC에 설치하시기 바랍니다. 만일 현재 TFS 안에 Build까지 구축하겠다고 하면 굳이 말리지는 않겠지만, 권장하지 않는다. 여러 팀원들이 동시에 접속해서 다루어야 할 서버인데, 프로그램을 빌드하기 위한 컴포넌트를 설치해 주고, 더욱이 빌드하면서 발생되는 자원 소모(빌드 할 때, CPU, RAM 등의 소요가 큰 편이다.)로 인해 서버가 원활하게 동작하지 않을 수 있기 때문입니다.

2가지를 선택하고 Install 버튼을 클릭하면 자동으로 설치하게 됩니다.

설치가 완료되면 요약화면이 뜨는데, 여기서 “Configure” 버튼을 클릭해주시기 바랍니다. 수동으로 직접 각종 서버 설정을 할 수 있지만, 여기서는 설치 후 뜨는 마법사 화면을 이용해 작업을 설명할 예정입니다.

설정 프로그램 – Configuration Center –이 뜨면, 이제 TFS에 대한 본격적인 설정을 시작하게 됩니다.

Team Foundation Server 구성

설치 완료 후, 설정 프로그램이 자동으로 뜨면 아래와 같은 화면이 뜹니다. 설정을 통합적으로 제공하는 기능인데, 메시지 기반의 Wizard를 제공합니다. 처음에는 낯설지만, 아이콘과 그림 남발 Wizard와는 다른 심플함을 주어 개인적으로 마음에 들긴 합니다.

자 아래와 같은 화면으로 들어왔으면 맨 먼저 “Advanced”를 선택합니다.
그 이유 중 하나는 우리가 설치할 때, 제품별로 따로 따로 설치하는 부분도 있었고, 일부 사용하지 않는 서비스들도 있기 때문입니다. 즉 입맛에 맞게 수정하기 위해서는 Advanced 로 진행하는 것이 답일 것입니다.

Advanced Configuration Wizard가 시작되면 이제 각각 설정해야 하는 항목들이 나오기 시작합니다.왼쪽 Navigation 영역 부분이 일종의 Wizard 단계 메뉴로 생각하셔도 됩니다. 실제 왼쪽 Navigation 쪽에 나타난 경고표시()만 해결하면 실제적인 설치가 되기는 합니다. 하지만, 차근차근 설정 하나하나 체크하시기 바랍니다.

[Welcome] 환영 메시지 부분입니다. 그대로 Next를 해주시면 됩니다. 체크 버튼이 있지만, MS에서 제공하는 Support를 원활하게 받을 수 없다면 의미 없죠.

[Database]  TFS와 연결할 Database 서버를 구성하는 부분입니다. 역시 기본값을 두시면 됩니다. 만일 SQL이 기본 인스턴스를 사용할 수 없는 경우라면, SQL Server Instance 부분에 적절하게 인스턴스를 넣어주시기 바랍니다.(예 : SQLSVR001\TFSDB ) 여기서는 기본값을 그대로 사용합니다.

[Account] TFS Service를 동작시키기 위한 계정 정보 및 인증 방식을 결정하는 부분입니다. 특별히 변경해야 할 이유가 없다면 기본값으로 두시면 됩니다. 보안상의 이유라도 NETWORK SERIVCE라는 계정을 그대로 유지하시는게 좋으며, 인증방식도 Kerberos 와 같은 고급 인증 방식을 쓰지 않는 이상 NTLM 이 제일 편하기 때문입니다.

[Application Tier] TFS 서버와 접속하기 위한 인터페이스 설정 부분입니다. 외부에서 TFS를 접속할 때, Web을 통해서 처리하게 되는데, 그 경로를 의미하는 것입니다. 여기서는 기존에 구축된 TFS 서버와 구분하기 위해 9000 번으로 변경한 것 외에는 크게 변경한 것은 없습니다. 기본값은 8080 입니다.

[Reporting ~ ] Reporting 부분은 Reporting과 함께, Reporting Services, Analysis Service, Report Reader Account 등 세 가지를 추가적으로 설정해야 합니다. 하지만, 여기서는 Reporting 관련 설정을 하지 않을 예정입니다. 그래서 Report 관련 체크를 끈 상태로 진행합니다. 만일 Reporting 관련 서비스를 활성화 하고 싶다면, SQL 2008 R2를 설치할 때, Report와 Analysis 서비스 관련한 설치를 반드시 해야 합니다.

[SharePoint Products] 여기서는 SharePoint와 TFS 간의 연결관계를 구축하기 위한 구성을 합니다. 연결이라고 해도, 별도 연결을 위한 설정이 있는 것이 아니고, SharePoint에 Site Template나, WebPart 등을 설치하고 준비하는 정도의 작업으로 보시면 됩니다. “Configure SharePoint for use with Team Foundation Server”를 체크해 놓은 상태에서 Next를 하시면 됩니다.

[SharePoint Products – Settings ] SharePoint Products 의 하위 설정으로 TFS와 연결할 SharePoint URL을 설정합니다. 대개 기본값으로 두시면 됩니다. “Next”를 누르면 자동으로 연결 테스트를 하지만, 혹시 모르니 반드시 “Test” 링크를 클릭해서 체크 버튼을 받도록 합니다.
다만, 여기서는 기존에 구축한 SharePoint와 겹치지 않기 위해서 포트 번호만 변경(8888로 변경)해서 진행합니다.

[Project Collection] 최초 서비스가 구축될 때 만들어질 Project Collection을 구축할 것인지 여부와 구축한다면 그 이름은 무엇으로 할 지를 결정하는 부분입니다. 물론 아예 시작을 아무런 구축없이 진행할 수 있지만, 가급적이면 자동으로 설정이 될 수 있게 하는 것도 편하게 프로젝트를 구성할 수 있게 됩니다.
최초 만들어질 때, 기본 이름은 “DefaultCollection” 인데, 자신의 프로젝트에 맞게 수정하시면 좋겠습니다. 그리고 Collection 이름이기 때문에, 안에 공백은 넣지 않도록 합니다.
여기서는 “TestProject”라는 이름으로 구성합니다.

[Review] 이제 지금까지 설정한 내용에 대한 전체 요약화면이 나옵니다. 혹시 모르니, 꼭 한번 전체 내용을 체크해보고, 설정이 맞는지 확인하시기 바랍니다.

이제 Verify 버튼을 클릭하시면 전체 설정을 체크하게 됩니다.

모든 체크가 Pass를 했다면 이제 Configure를 클릭하시면 자동으로 설정하기 시작합니다. 중간에 큰 문제(메모리 부족, 디스크 부족, 네트워크 단절 등등)가 없다면 자연스럽게 설정을 하게 됩니다.

최종적으로 모든 설치가 Sucess가 뜨면 끝납니다.

일단, 기본적인 Team Foundation Server 구축은 여기까지 입니다. 이제 만들어진 URL(위의 예제로 나타낸 것을 기준으로 한다면, http://tfstest:9000/tfs 가 됩니다. )로 Visual Studio 로 연결하면 됩니다. 최소한 소스 버전관리로 이용할 수 있을 것입니다.

그럼 다음으로는 구축된 TFS에서 기본 제공하는 Team Foundation Server Administration Console을 활용한 기타 설정이나 구성 작업들을 간단하게 살펴 보도록 하겠습니다.

배경

MS Windows Platform 기반으로 개발을 한다면 필연적으로 Visual Studio라는 제품을 사용하게 된다. 이 제품으로 개발할 때 사용되는 언어는 C/C++, Visual Basic, C# 등 다양하게 사용할 수 있다. 또 Windows Platform에 맞게 Native 한 어셈블리 계열에서 부터 .NET Framework 까지 다양한 기반 기술 및 API를 쉽게 사용할 수 있다. 또 Visual이라는 이름에 걸맞게 GUI 기반의 IDE 도구이다. 그래서 자체적으로 소스 에디터를 보유하고 있으며, 간단한 조작만으로 만들어진 소스를 빌드 하고, 디버깅 까지 복합적인 모든 형태의 기능을 하나의 도구로 만들었다.
이 Visual Studio는 Windows Platform의 변화에 맞추어 변화해 왔고, 발전하여, 현재 2010 버전까지 나왔다.

도구와 Platform의 발전도 발전이지만, 진정 발전을 한 것은 소프트웨어 개발 자체이다. 처음에는 까만 도스창에 실행파일 몇개와 동적 라이브러리 몇개로 구성된 단순한 Application 만으로도 충분히 동작하고, 사용했지만, 지금은 상당히 많은 기능과 동작하고, 크기 조차 엄청나게 커버렸다. 이처럼 단순한 Application 에서부터 서버 레벨의 비지니스 개발까지, 그 개발의 범위와 폭은 너무 커져갔고, 개발의 양 역시 상상의 범위를 넘을 정도로 개발됐다.
그러다 보니, 홀로 일당백 개발하는 시대는 저물고, 어느새 여러 사람이 협업을 하면서 개발해야 하는 단계에 이르게 되었다. 여러 사람이 하나의 목표(소프트웨어 제품)를 두고, 작은 조직을 만들어 꾸리게 되는데, 보통 이런 단위를 팀이라고 부르고, 자연스럽게 개발자들의 작은 그룹이 팀이 되어 그 팀 단위 개발을 수행하게 되었다.

공장에서야 컨베인벨트 위의 작업 형태와 작업 양에 맞춰 반복적인 작업을 위한 최초 교육을 거친 뒤, 원하는 인원을 투입해 생산 공정을 구성한다. 물론 인력 비용이라는 부분도 있기는 하지만, 최소한 인력 비용을 무시한다면, 확실히 인력 투입대비 생산량이 거의 동일하게 나오게 된다. 인력 투입 대비 생산력이 나온다는 이야기는 바로 인력을 최대한 투입하면, 투입된 만큼 제품이 나올 수 있다는 의미다. 
하지만, 소프트웨어 개발은 단순 공장 노무와는 다르게 사람을 무작정 투입한다고 되지 않는다. 단순히 몇가지 반복적인 작업을 교육한 뒤 투입한다고 바로 무언가를 만들 수 있는 것이 아니기 때문이다. 위의 컨베인 벨트를 기준으로 이야기 한다면, 이 소프트웨어 개발이라는 것은 그 컨베인 벨트 자체를 만드는 공정이기 때문에 그게 쉽지만은 않다. 어떻게 컨베인벨트를 배치해야 최소 인력으로 최대의 효과로 제품을 생산할 수 있을까? 와 같은 고민을 소프트웨어 개발에서 수행하는 것이다. 이렇다보니, 무작정 인력만 우겨넣는다고 그 답이 나올리가 없다.
또 예전 같이 규모라도 작고 변수라도 적으면, 똑똑한 사람 몇명이면 그만이였지만, 규모가 규모인 만큼, 똑똑한 사람 몇 사람으로 해결 할 수 조차 없다. 자연스럽게 사람들은 건축, 공장화 그 모든 것들을 소프트웨어 개발에 맞춰보려 노력했지만, 그 결과가 그리 좋지 않았고, 결론적으로는 소프트웨어 개발은 다른 식으로 접근해야 되겠다고 생각하였으며, 그 결과 작은 생산 조직의 형태가 되었고, 이 역시 팀이 만들어지게 된다.

팀이라는 조직을 이용해 과연 어떻게 명확한 목표와 서로간의 협력을 만들어야 할까?
이 부분에 대한 많은 의견이 분분했다. 앞서 이야기 한 것 처럼, 건축 방법론을 가져와 설명하고 적용해보기도 했다. 그 덕에 건축에서 사용되는 개념의 일부를 소프트웨어 개발과정에서도 활용된다. 하지만, 무언가 어색한 옷인 마냥 잘 맞지 않았다. 그를 대체할 것 처럼 나타는 공장형태도 자연스럽게 등장했다. 공장에서 처럼 표준화된 부품을 통해 생산된다면 어떨까? 물론 개념도 훌륭했으며, 많은 소프트웨어들이 그에 맞게 해보려 했지만, 사람 생각이 100이면 100 틀리다 보니, 이 역시 어색한 옷이 되어버렸다. 그러다 보니, 요즘은 누가 옳다 그르다를 따지기 자연스럽게 스스로의 맞는 스타일을 찾아 가기 시작했고, 자연스럽게 Agile에서 제시하는 실천 방법과 같은 형태를 갖추기 시작했다.
Agile에 대한 이야기는 다른 Agile 관련 서적이나, 사이트 등에서 참고하면 된다.

이와 같은 복잡다단한 소프트웨어 개발 환경이라는 배경 속에서 MS는 Visual Studio를 제시했고, 그 제품을 이용해 팀 단위 업무를 원활하게 수행할 수 있는 환경을 제공했다. 개발자들 각자에게 제공되는 Visual Studio와 바로 연결될 수 있는 팀 협업 환경 - 서버 -를 또 하나의 제품으로 제시하였고, 그 환경이 바로 Team Foundation Server 라는 제품이다.

왜?

그럼 왜 Team Foundation Server 일까?
사실 이 부분의 당위성은 위의 배경에서 어느 정도 설명하기는 했다. 그렇지만 꼭 Team Foundation Server를 쓸 필요는 없다. 이미 위의 배경과 같은 문제점을 해결하기 위해 많은 소프트웨어 개발자와 설계자들은 고민했고, 그에 맞는 솔루션들을 다양하게 만들어 제시했고, Open Source로 공개적으로 제공하는 무료 솔루션도 다양하다.소스 버젼 관리라면, Subversion 이나, CVS 정도, 요구사항 및 형상관리레벨 이라면 Redmine 도 좋다. 자동 빌드라면 Hudson 정도 써주면 딱 일듯 싶다. 가격도 없다. 원하는 대로 쓰고 수정하고, 제안만 하면 된다. 
그런데 굳이 왜 Team Foundation Server 일까? 구구절절한 당위성에 대해서는 MS에서 제시하는 개발 방법론이나, 다양한 보고서, 광고 만으로도 충분히 나온다. 그런 구차한 변명을 걷어낸다면, 그 모든 것의 결론은 MS Platform 기반으로 개발하고, Visual Studio를 쓰기 때문일 것이다. Visual Studio에 딱 달라 붙어서 아주 유연하게 쓸 수 있다는 것! 바로 그 점일 것이다.

또 전산 관리자 측면을 바라본다면, 유지보수를 위해서라도, 역시 한 벤더에서 그냥 한번에 모든 연계 제품을 묶는게 더 편하지 않나 싶다.

무엇을 할 수 있나?

팀 협력 작업이라면 대부분의 작업을 할 수 있다.

버전 관리

과거 SourceSafe 라는 약간은 원시적인 동작을 했지만, 그럭저럭 쓸만했던 제품이 있다. Visual Studio에 딱하니 붙기도 하고, 소스 DB도 단순한 형태라 백업하기도 그만이였다. 이 TFS에는 그 원시적인 도구를 조금 더 세련된 UI와 내부적인 DB를 MS SQL이라는 DBMS에 담고, Brench 같은 다른 버전관리도구에서나 제공했던 기능들도 넣었다. 애초 TFS를 쓰는 대부분의 사용자는 바로 이 소스 버전관리 하나만으로도 모든 것을 만족한다.

작업 관리

어설프지만, Redmind 같은 요구사항 관리나, 형상관리를 처리할 수 있는 기능이 있다. 요청 사항들을 관리하기도 하고, 작업을 관리하며, 버그 이력을 남길 수 있다. 이 모든 작업을 Visual Studio 안에서 처리할 수 있다. 입력을 Form에서 하고, 그 결과 값을 Grid 형태로 보기도 하고, Excel로 뽑아볼 수 있으며, MS Project를 통해서 관리 할 수 있다.

자동 빌드

자체적으로 빌드 서버를 구축할 수 있다. 자동으로 최신 소스를 받아 사용자의 별다른 도움 없이 자동으로 빌드 결과물을 만들어 낼 수 있다. MS Build를 사용하는 솔루션 파일만 있으면, 그 솔루션 파일에 설정된 내용대로 자동으로 빌드하게 된다. 최초 구축이 힘들어서 그렇지 한번 구성하면 나름 쓸만한 도구 이다. 내부적으로 Test DLL이 있으면, Test까지 수행해준다.

그 외의 기능

SharePoint와 연동해 문서들을 올리고 관리할 수 있으며, 다양한 형태의 프로젝트 관련 Report 들을 만들어 주기도 한다. 생산성이나, 버그 경향 등을 일목 요연하게 볼 수 있다.

여기서는?

현재 저 위의 기능을 100% 완벽하게 구축해서 다 사용해 본 적은 없다. 하지만, 회사에서 사용되는 목적에 맞는 기능들을 어떻게 구축하고 사용하는지를 정리하기 위해 여기다가, 키보드로 끄적여 본다.

방향

시간이 허락되는데 까지, 서버의 구축에서부터 사용법까지만 나열할 예정이다. 예전에 SourceSafe에 대한 어설픈 글 올린 것처럼 완결될 것 같지는 않지만, 기록이나마 남기기 위해서 적어본다. 회사의 환경을 그대로 소개하면서 설명하면 쉽겠지만, 내부 보안이라는 부분도 있으므로 별도 Virtual Machine에 구축하면서 설명할 것이다.

InstallSheild로 여러가지 형태의 Installer를 만들지만, 대부분은 MSI 기반의 인스톨러로 만들게 됩니다.

이 MSI 형식으로 만들게 되면, .NET Framework 역시 지원하며, .NET Framework를 통해 설치용 Custom Action을 만들어 추가할 수 있습니다. 하지만, Custom Action을 이해하려면, MSI 설치 순서와 그 사이 사이의 특성을 어느정도 파악해야 합니다.

만일 단순히 파일을 삭제하거나, 검사하는 간단한 로직을 넣을 정도의 요량이라면, 굳이 Custom Action을 사용해 만들 필요는 없다고 생각합니다.

InstallSheild에서는 특정 DLL에 포함된 특정 기능을 도출해서 쓸 수 있습니다. .NET이든, Native ( VC++ 등을 사용한 ..)든 어떠한 형태든, 표준 DLL 규칙을 가지고 있다면 어떤 형태가 되었든 사용 가능합니다. 물론 이 기능에도 수많은 기능들이 있고, 다양한 조건으로 다양한 상태에서 사용할 수 있지만, InstallSheild의 특성을 무시해서라도, 일단 설치나 제대로 되게 끔 하려하고 있다면, 필자처럼 하면 될 것입니다.

1. 일단 DLL 만든다.

일단 DLL 부터 만듭니다.  C#의 프로젝트 추가를 하시고, 프로젝트 종류를 Class Library로 하면 됩니다.

만일 설치될 PC에 .NET Framework의 버전도 꼭 설정해주시기 바랍니다. Visual Studio 2010을 사용한다면, 기본적으로 .NET Framework 4.0으로 되게 되는데, 대상 PC에 .NET Framework 4.0이 설치될 가능성이 없는 경우 2.0 정도로 맞춰주시면 최신 Windows Update를 받는다면 거의 다 동작할 것입니다.

만들어진 DLL 프로젝트에서 그냥 public class에 public method를 만들기만 하면 됩니다. 적당히 이름을 붙이시기 바랍니다. 물론 InstallSheild와 쌍방 통신(InstallSheild 내의 데이터를 사용하거나, 실행 결과물을 InstallSheild에게 전달해야 되는 경우)가 필요하다면, 약간은 다르게 구성해야 겠지만, 만일 그럴 필요가 없다면, 그냥 class와 method를 public으로 만들기만 합니다.

여기 예제에서는 ClearOldProducts 라는 클래스의 CleanOldProductInfo 라는 함수를 만들었습니다.

적당히 안에 로직을 짜고, 컴파일 합니다. 만들어진 DLL을 이제 ISM 파일 수정에 들어가 추가해줍니다.

일단 적용할 ISM 파일을 엽니다.
그리고 트리 메뉴에서 Custom Actions and Sequence를 엽니다.

UI 혹은 CustomAction들이 보이는데, 그 중 Root Tree Item에서 오른쪽 버튼을 클릭합니다.
무척 많은 메뉴 내용이 보이는데, 그 중 "New Managed Code -> Stored in Binary table"을 선택합니다.
이미지 대상 PC에 설치되어 있거나, 이미 존재하는 파일을 가지고 하는 거면, 다른 옵션들을 활용할 수 있지만, 새롭게 설치하는 PC를 기준으로 본다면, MSI 인스톨러 안에 해당 DLL을 담고 있어야 하므로, "Store in Binary table"을 선택하는 것입니다.

그러면 새로운 Custom Action이 생기는데, 그 위치에서 오른쪽 버튼을 클릭 한 뒤, "Custom Action Wizard..."를 띄웁니다.

Wizard가 뜨면 맨 처음 최초의 창은 넘어가시고...

Custom Action의 설명을 추가할 것이 있으면 쓰지만, 그냥 넘어가도 됩니다.

Custom Action을 호출하는 방법인데, 그대로 두면 됩니다.

이제 그 대상이 되는 DLL을 찾아서 선택하면 된다. Browse 버튼을 클릭해서 특정 DLL을 선택해주면 됩니다.

DLL 선택이 되었으면, 이제 그 DLL 안에 있는 특정 함수를 선택 합니다.직접 입력해도 되지만, Browse를 클릭해서 해당 하는 클래스와 메소드를 선택하면 됩니다.

동작 방식인데, 비동기식으로 하면 인스톨 단계가 그대로 진행되면서 동작하므로, 가급적 Synchronous를 선택합니다. 그리고 exit code를 별도 제공할 예정이면 exit code를 선택하지만, 만일 없다면 Ignores exit code를 꼭 선택해야 합니다. 안그러면 종료 오류로 더 이상 처리 안되는 경우도 있습니다.

실행 조건인데, 그대로 두시면 됩니다. 즉시 실행이므로, 특정 조건이 되면 바로 실행되게 끔하는 것입니다.

마지막으로 이 스크립트가 실행되는 시점입니다. UI 가 있는 MSI면 Install UI Sequence에서, 없으면 Install Execute Sequence를 선택하여, 이벤트를 고릅니다. 그리고 Condition에 1이라고 넣습니다.

C++ 처럼 TRUE면 1, FALSE 면 0 입니다. 만일 특정 조건(Windows 2000 이상일때 라든가, x86 CPU라든가, 별도 조건이 있는 경우)가 있다면 만들어서 넣어도 되지만, 조건에 상관없이 무조건 실행되는 거라면, 1이라고 넣어주시면 됩니다.

요약 창이 뜨고 종료됩니다.

이제 빌드 하고 동작시켜 보시면 됩니다.

'
' WMI Script - ChangeVLKey.vbs
'
' This script changes the product key on the computer
'
'***************************************************************************

ON ERROR RESUME NEXT


if Wscript.arguments.count<1 then
   Wscript.echo "Script can't run without VolumeProductKey argument"
   Wscript.echo "Correct usage: Cscript ChangeVLKey.vbs ABCDE-FGHIJ-KLMNO-PRSTU-WYQZX"
   Wscript.quit
end if

Dim VOL_PROD_KEY
VOL_PROD_KEY = Wscript.arguments.Item(0)
VOL_PROD_KEY = Replace(VOL_PROD_KEY,"-","") 'remove hyphens if any

for each Obj in GetObject("winmgmts:{impersonationLevel=impersonate}").InstancesOf ("win32_WindowsProductActivation")

   result = Obj.SetProductKey (VOL_PROD_KEY)

   if err <> 0 then
      WScript.Echo Err.Description, "0x" & Hex(Err.Number)
      Err.Clear
   end if

Next
Wscript.echo "Windows XP의 제품 키 변경이 완료되었습니다."

C#에서는 Listener 패턴을 구현하기 쉽다. 특히 event라는 예약어를 제공하고 있어서, Callback 형태의 구현이 어렵지 않다.

class Test 
{ 
        int m_nCurrentIndex = 0; 
        public delegate void IndexChangedEventHandler(); 
        public event IndexChangedEventHandler ChangeCurrentIndex; 
        public void ChangePage(int nIndex) 
        { 
               m_nCurrentIndex = nIndex; 
               ChangeCurrentIndex(); 
               m_nCurrentIndex = m_nCurrentIndex + 1; 
        } 
}

위의 코드는 바로 그 event 형태로 어떻게 구현하는지를 나타낸다.

이를 사용하는 로직은 아래와 같다.

class Program 
{ 
        [STAThread] 
        static void Main() 
        { 
             Test test = new Test();

             test.ChangeCurrentIndex 
                 +=  new IndexChangedEventHandler(test_ChangeCurrentIndex); 
             test.ChangePage(1);

             Console.WriteLine(“Complete!”); 
        }

        private void test_ChangeCurrentIndex() 
        { 
               Console.WriteLine(“event!”); 
        } 
}

“test.ChangeCurrentIndex” 이렇게 쓰고 “+=” 만 추가하면, 자동으로 코드가 생성되면서 아래에 함수가 하나 생긴다.
이것이 바로 event 구현 작업이다. 즉 test 내부에서 “ChangeCurrentIndex()” 이 함수가 불리는 순간, 이벤트 구독한 함수로 호출을 하게 된다.

즉 역으로 함수를 부르는 일종의 Callback  함수로 생각하면 된다.

위의 작업을 한 줄씩 실행되는 순서를 보면 아래와 같은 순서로 진행된다.

1. Test test = new Test(); –> Test 클래스의 인스턴스를 만든다.
2. test.ChangeCurrentIndex +=  new IndexChangedEventHandler(test_ChangeCurrentIndex); –> 이벤트를 구독한다.
3. test.ChangePage(1); –> Test 클래스의 ChangePage 함수를 호출한다.
4. m_nCurrentIndex = nIndex;   -> TestClass 내부 : m_nCurrentIndex에 nIndex 값을 대입한다.
5. ChangeCurrentIndex();   -> Event를 발생시킨다.
6. Console.WriteLine(“event!”)  -> Main 쪽의 이벤트 구독할 때 등록한 함수(test_ChangeCurrentIndex)로 들어가서 “event!” 라는 문자열을 찍는다.
7. m_nCurrentIndex = m_nCurrentIndex + 1; –> +1 를 한다. 그리고 ChangePage 함수를 종료한다.
8. Console.WriteLine(“Complete!”);   -> Main 으로 돌아와서 Complete를 찍고 종료한다.

이것을 실행하는 순서를 다이어그램으로 나타내면 아래와 같다.

Test라는 클래스와 Program이라는 클래스가 서로 통신을 한다고 했을 때, 위와 같은 Listen 구조가 안된다면, 결국 Program 이라는 클래스에서 호출하는 작업이 없다면 Test가 Program으로 데이터를 보낼 방법이 없다. 만일 저 위와 같은 형태가 안되는 구조라면, Test 클래스 안에는 Program 개체의 레퍼런스를 들고 있어야 한다.

class Test
{

        Program m_parent = null;
        int m_nCurrentIndex = 0;

        ~~~~~~~~~
}

그리고 Program 클래스 안에는 Test를 통해 처리해야 할 함수 부분에서 private를 public 으로 바꿔야된다.

        public void test_ChangeCurrentIndex()
        {
               Console.WriteLine(“event!”);
        }

호출할 때는 기존에 함수형태로 된 것을 Program을 통해서 부르도록 해야 된다.

        public void ChangePage(int nIndex)
        {
               ~~~~~~~~~~~
               m_parent .test_ChangeCurrentIndex();
               ~~~~~~~~~~~
        }

서로 인스턴스를 주고 받아야 저런 통신이 가능하게 되는 것이다.

하지만 위와 같이 하게 되는 경우 같은 DLL 이나 EXE 의 경우면 어차피 같은 프로젝트 안에 있는 내용이니 큰 문제가 없지만, 만일 서로 다른 프로젝트로 되어 구성된 경우라면, 서로 인스턴스를 주고 받으려면 상당히 난감해 질 수 밖에 없다.

이렇게 훌륭한 event 구성에도 심각한 문제가 있다.

그건 바로 실행되는 순서에 있다. 실행되는 순서 중 5~7 사이를 보도록 하자.
만일 5->7->6 의 순서로 실행하고 싶다면 어떻게 해야 할까? 즉, ChangePage 함수가 종료되면 자동으로 test_ChangeCurrentIndex 가 실행되고 싶을 때라는 것이다. 간단한 구조의 프로그램이나, 구성의 경우에는 이런 부분을 신경 쓰지 않지만, Multi Thread 나 Windows UI 응용 프로그램인 경우 문제가 발생한다.

왜 문제가 발생할까?

만일 저 Event 구조가 연달아 실행되는 형태라면? 이라는 가정으로 시작해보자.

만일 저런 형태라면, E에서 부터 시작해서 A까지 모든 작업이 끝나야 실제 동작이 끝나게 된다. 이 경우 함수를 연달아 부른 구조와 별 다를게 없다. 그래서 간혹 중간에 시간이 오래 걸리는 작업이 있는 경우, 메인 프로그램의 UI가 마치 다운된 것과 같다.

UI가 다운되지 않은 것처럼 하기 위해서는 E 가 완전히 끝난 뒤, D가 실행되고, 다음에는 D가 완전히 다 실행한 뒤, C가 실행되는 형태가 되어야 한다.

즉 맨 위의 예제 코드를 기준으로 보면, 1->2->3->4->5->6->7->8 이 아니라, 1->2->3->4->5->7->6->8 또는 1->2->3->4->5->7->8->6 순으로 실행되면 되는 것이다. 어찌되었던 간에, ChangePage 메소드가 종료 된 뒤에, 실행을 요청한 코드가 실행되어야 한다는 것이다.

이렇게 하려면 어떻게 해야 할까?

1가지 방법은 Windows Message를 사용하는 것이다. SendMessage 나, PostMessage 같은 것으로 호출하는 방법이다. 최소한 SendMessage나 PostMessage는 Windows Message Queue에다 던지는 형식이기 때문에, Windows Message Queue에서 해당 메시지가 나올 때 까지 나머지 부분을 계속 실행하게 된다. 즉 5 번 단계의 실행에서 바로 7단계로 넘어 간 뒤에, Windows Message Queue에서 Message 가 언제 나오는지에 따라, 6 번은 그에 맞게 실행되는 것이다.

이 작업은 .NET에서 Windows Message를 다루는 방법이므로 일단 이 방법은 넘어가도록 하자.

순수 .NET 코드에서는 어떻게 해야 할까?

바로 Invoke 라는 함수를 쓰는 것이다.

Invoke의 정확한 목적은 해당 개체에 있는 함수를 강제적으로 동작하게 하는 것인데, 이것은 상대 클래스내의 함수를 무조건 실행하는 것이다. public 이든, protected 든, 심지어 private 일지라도 강제적으로 실행하는 방법이다.

이 때, 중요한 것은 Invoke 명령어는 System.Windows.Form 네임스페이스에 있는 Control 기반의 Windows 개체만 동작한다는 것이다.  위의 예제 코드는 다음과 같이 다시 작성을 해야 한다. 먼저 Windows Form 기반 응용 프로그램이여야 할 것이다.

public partial class Form1 : Form 
{ 
        Test m_test = null; 
        public Form1() 
        { 
            InitializeComponent(); 
            m_test = new Test(this); 
            m_test.ChangeCurrentIndex 
              +=  new IndexChangedEventHandler(m_test_ChangeCurrentIndex); 
            test.ChangePage(1); 
            Console.WriteLine(“Complete!”); 
        }

        private void m_test_ChangeCurrentIndex() 
        { 
               Console.WriteLine(“event!”); 
        } 
} 

class Test 
{ 
        Form m_parent = null; 
        int m_nCurrentIndex = 0; 
        public delegate void IndexChangedEventHandler(); 
        public event IndexChangedEventHandler ChangeCurrentIndex; 
        public Test(Form parent) 
        { 
             m_parent = parent; 
        } 
        public void ChangePage(int nIndex) 
        { 
               m_nCurrentIndex = nIndex; 
               ChangeCurrentIndex(); 
               m_nCurrentIndex = m_nCurrentIndex + 1; 
        } 
}

앞서 event 기반의 Listen 패턴 관련해서 상호간 인스턴스가 필요없다고 했는데, 이번에는 필요하다. 왜냐면, event를 호출하는 로직을 할 때, Invoke를 해야 하는데, 그 Invoke를 당하는 대상의 인스턴스가 필요하기 때문이다.

다음 로직을 보자. 이제 ChangePage 라는 함수를 수정해야 하기 때문이다.

public void ChangePage(int nIndex) 
{ 
      m_nCurrentIndex = nIndex; 
      m_parent.Invoke(ChangeCurrentIndex); 
      m_nCurrentIndex = m_nCurrentIndex + 1; 
 } 

앞에서는 ChageCurrentIndex 라는 이벤트를 직접 함수처럼 실행했지만, 이번에는 Invoke 라는 것을 사용해서 실행하기 때문이다. 즉 Windows개체.Invoke(delegation함수) 형태로 실행하는 것이다.

m_parent.Invoke(ChangeCurrentIndex)라는 문구가 올 때, ChageCurrentIndex 에 연결된 함수가 실행되지 않고, 일단 m_parent 한테 실행하라고 지시만 한 상태가 된다. 일단 저 안의 함수 내용이 완료될 때까지는 저 Invoke가 실행되지 않는다. 그러므로 ChangeCurrentIndex에 구독한 부분은 나중에 실행되게 되고, 바로 그 아래에 있는 코드가 실행되게 된다. 그리고 그 함수가 완전히 종료되면, 그제서야 Invoke 한 함수를 실행하게 되는 것이다.

이 모든 작업은 COM Component 기반의 동작이 가능한 System.Windows.Form 계열의 Windows Form, Control 등만이 가능한 기능인 것이다.

TFS 2010에 Work Item을 등록하는 기능이 있다. 여기서의 WorkItem은 일종의 “작업” 같은 개념이다.

처음 사용하다 보면, 이 Work Item을 테스트 식으로 등록하기도 하고, 혹은 중복해서 등록하기도 한다. 또 가끔은 중복해서 올리기도 한다. 그럴 때, 늘 윈도우 프로그램 사용하던 방식대로 지우려고 하면 지워지지 않는데, 오른쪽 버튼을 눌러 컨텍스트 메뉴를 띄워도 Delete는 보이지 않고, 그렇다고 Delete 키를 눌러도 안된다. Toolbar에서는 아예 지원이 안된다. 결국 상태 변경을 해서 “완료” 혹은 “닫힘” 그런 것으로 변경해서 쿼리에서 안 나오게 정도 밖에는 못한다.

이를 확실하게 지우는 방법이 있었다.

먼저 Visual Studio 2010 이나, TFS Client 가 PC 내에서 설치되어 있어야 한다.(여기서는 Visual Studio 2010을 기준으로 설명)

이제 Cmmand Line 창을 띄워야 한다. 보통 Visual Studio가 설치되어 있으면 전용 Command Line 창이 있는데, 그것을 띄워도 된다.

Command Line 창이 뜨면 일단, 다음 명령을 입력한다.

cd ..\Common7\IDE

아이템을 삭제하기 위한 도구는 Visual Studio 2010이 설치된 폴더를 기준으로 Common7\IDE에 있다. 그래서 저 Command Line 창 최초 위치를 기준으로 해당하는 폴더로 이동하기 위한 것이다.

이제 본격적인 아이템 지우기. 아이템을 관리하는 모든 처리는 바로 witadmin.exe 이라는 프로그램이다. Command Line 명령이다. 그 형태는 아래와 같다.

witadmin destroywi /collection:{tfs 주소} /noprompt /id:{workitem id}

저기서 {tfs 주소}는 TFS 의 경로를 넣어준다.

TFS 서버 주소가 tfs.knoie.net 이고, 프로젝트 이름이 MyProject 라고 한다면,

http://tfs.knoie.net:8080/tfs/MyProject

가 된다. 이 주소 값은 TFS 연결할 때, 연결 정보를 열어보면 쉽게 알 수 있다.

{workitem ID}는 지우려는 workitem이 가진 고유 ID 값을 넣는다. 보통 이 아이디 값은 1 부터 시작하는 단순한 번호 나열이므로, 쉽게 찾을 수 있다. 쿼리를 하면 나열 되는데, 아래 그림의 붉은 색 상자 안의 ID 값을 의미한다.

저 안의 내용 중 367 번을 지운다면,

witadmin destroywi /collection:http://tfs.knoie.net:8080/tfs/MyProject /noprompt /id:367

이라고 입력하면 된다.

실행하면 아래처럼 표시된다.

이 설치는 SharePoint Foundation을 간략하게 설치하거나, 개발 환경 정도로 구성할 때 사용한다. 실제 운영하거나, SharePoint Server 2010 Standard 이상 버전의 서버 군 설치와는 다르다.

이 작업을 위해 필요한 환경은 아래와 같다.

Hardware

• x64를 지원하는 PC 혹은 가상 머신
• RAM 4G 이상.
• HDD 80G 이상.
• 인터넷이 연결 가능한 네트워크

Software

• MS Windows Server 2008 R2 Standard 혹은 Enterprise Edition.
• SharePoint Foundation 2010 ( http://download.microsoft.com 에서 다운 가능 )
• MS SQL 2008 R2 Express with Tools ( http://download.microsoft.com 에서 다운 가능 )
  - 그냥 Express 버전은 Management Tool 이 없어서, DB 설정이나, 구성을 할 때 사용하는 도구가 없다.

Overview

전체적인 설치 순서는 다음과 같다. 이 순서대로 캡쳐 화면과 함께 소개할 예정이다.

1. MS Windows Server 2008 R2 설치.
2. Windows 관련 설정.
3. SharePoint Foundation 설치.
4. SQL 2008 R2 로 업그레이드 및 DB 관리도구 설치.
5. SharePoint Foundation 구성.
6. 기타..

이제 위의 순서대로 설치하는 방법을 나열할 것이다.
캡쳐된 화면은 1024 * 768의 화면을 캡쳐했는데, 블로그의 표시 해상도 상 사이즈를 많이 줄였다.
만일 제대로 확인이 불가능하면, 해당 그림을 클릭해서 확대해서 보면 된다. 

MS Windows Server 2008 R2 설치

Windows Server 2008 R2 미디어를 준비한다. 그리고 필요하면 CD-Key 정도는 확보해야 한다. 정품인증을 하지 않아도  대략 30일 정도는 사용할 수 있지만, 그 이후에는 여러 가지 문제가 발생할 수 있다. 또한 Windows Update 부분에서도 일부 불이익을 받을 수 있다.  만일 단순 테스트 용도라면 굳이 정품 인증이 필요 없다.

먼저 일반적인 Windows 설치와 마찬가지로, 미디어를 넣고 시작한다. Windows Server 2008 R2는 Windows 7 기반과 동일한 비슷한 구조로 되어 있어 시작화면도 Windows 7과 비슷하다.

본격적인 서버 설치 화면은 다음과 같다.

로딩이 완료되면 제품을 선택하는 화면이 나온다. 이 중, Standard 혹은 Enterprise를 선택한다. 또한 주의할 점이 (Server Core Installation) 이라는 항목들이 있는데, 이것은 피하도록 하자. 반드시 (Full Installation)을 선택한다. (Server Core Installation)은 진짜 Server의 핵심적인 모듈만 설치하기 때문에, UI가 전혀 없고, 도스 창 하나만 달랑 나오기 때문에, 진짜 운영용 서버를 만드는게 아니면 피하는게 상책이다.

만일 HDD Disk가 여러 개인 경우나, 파티션이 나눠져 있거나, 혹은 기존에 설치된 운영체제가 있는 경우에는 디스크 관련 도구가 뜬다. 그 부분은 상황에 맞춰서 적절하게 설치위치를 잡아준다.

설치가 본격적으로 진행되면 다음과 같은 화면이 나타나면서 자동으로 설치가 진행된다.

설치가 완료되면 Administrator의 암호가 설정되지 않았다고 나오면서 암호를 넣어달라고 한다. 이 암호를 만든 후에, 그 암호로 로그인을 하도록 한다. 그러면 Windows Server 설치는 완료된다.

Windows Server 설정

반드시 필요하다고 하면 필요하고 필요 없다고 하면 필요 없지만, 일단 간단한 설정을 해주도록 한다.

먼저 Internet Explorer의 보안설정을 끄도록 한다. 여기서는 약자로 IE ESC 라고 하는데, 이 항목들을 모두 Off로 해줘야 한다. 안 그러면 보안 설정으로 인해 웹사이트 접속이 어렵기도 하고, SharePoint 내의 검색 엔진이 정상적으로 동작하지 않게 된다.

서버 관리자를 띄우면 바로 볼 수 있다. 아래의 그림에서 왼편에 있는 Configure IE ESC링크를 누르면 창이 뜨는데, 그 안의 내용에 모든 Off 부분에 설정하면 된다.

다음 작업들은 반드시 필요한 것은 아니지만, 관리 및 작업의 편의상 해주면 좋은 정도이다.

Windows Update 비활성화.

MS의 Windows Update 설정은 대부분 완전 자동으로 하는 것을 추천한다. 하지만, 서버 제품 군은 가급적 이 설정을 끄는 것이 좋다. 특히 예상치 못한 시점에 갑자기 꺼지는 경우도 있기 때문이다.

설정 방법은 간단하다.먼저 제어판에 들어간다.

다음은 System and Security에 들어간다.

Windows Update 항목에 들어간 뒤,

왼편에 조그만하게 있는 Chnage Settings에 들어간다.

선택상자에서 Never check for updates를 선택하고 OK를 클릭한다.

User Account Control 비활성화

UAC(User Account Control) 이란, Windows에서 동작하게 되는 중요한 자원(시스템 파일 혹은 레지스트리 정보, 설치된 프로그램 파일 등등)이 자동적으로 프로그램에서 손대게 될 때, 사용자에게 확인 작업을 하는 보안 기능이다. 특히 트로이의 목마 같이 사용자 몰래 동작해서 Windows의 주요 파일들을 멋대로 변조하거나, 시스템 감시를 하는 짓과 같은 것을 원천 차단하게 된다. 이 기능은 Windows의 최 중심부인 Kernel 레벨에서 원천 차단하기 때문에, 화면이 완전히 멈추고, 사용자 확인을 요청하는 확인, 취소 버튼만 보이게 된다. 그래서 보안 설정 상 이 부분을 그래도 두는것을 권장한다.

하지만, 매번 작업할 때마다, 화면이 잠기게 되면 매번 확인을 눌러주는 것도 일이 되는데다가, 원격에서 작업하는데 미묘하게 화면이 잠겨서 더이상애로사항이 꽃피게 된다. 가급적 이 옵션을 설정하는게 편하다. 물론 화면이 잠겨도 아무런 문제가 없다면 켜 놓는게 좋다.

먼저 제어판에 들어간다.

제어판 항목 중, User Account 항목을 선택한다.

User Accounts 안의 User Account를 선택한다.

User Account 안에 맨 아래에 위치한 Change User Account Control Settings 를 클릭한다.

그러면 UAC(User Account Control) 설정화면이 나오는데, 여기서 맨 아래 단계로 맞추고 OK를 클릭한다

SharePoint Foundation 설치.

이제 본격적인 SharePoint 설치가 되겠다. SharePoint 에서 설치 작업은 크게 파일 자체 설치와 DB 구성 설치로 나눌 수 있다. 그에 맞추어 설명한다.

먼저 SharePoint Foundation 설치 파일을 실행한다. 대개 http://download.microsoft.com 에서 SharePoint Foundation 이라고 치면 설치파일을 쉽게 찾을 수 있다. 이 파일을 받아 설치를 하면 된다. 더블 클릭하면, 자동으로 압축을 풀고 설치진행이 시작된다.

이 SharePoint Foundation도 나름 서버 제품이기 때문에, 서버 제품 특유의 Autorun 화면이 나온다.
그 중 “Install software prerequisites” 라는 항목을 클릭해서 실행한다. (Install 바로 다음에 있는 항목)

예전에는 설치를 진행할 때, 설치에 필요한 필수 항목들을 설치해 달라고 오류가 나거나, 별도 메시지 창을 제공했는데, 이번에는 별도 도구를 제공해서 한번에 필요한 요소들을 모조리 설정해주는 편리한 도구가 생겼는데, 바로 그것이 “Install software prerequisites”  이다.

실행하면 다음과 같은 항목들을 알아서 구성해준다.

• Application Server Role, Web Server (IIS) Role
• Microsoft SQL Server 2008 Native Client
• Hotfix for Microsoft Windows (KB976462)
• Windows Identity Foundation (KB974405)
• Microsoft Sync Framework Runtime v1.0 (x64)
• Microsoft Chart Controls for Microsoft .NET Framework 3.5
• Microsoft Filter Pack 2.0
• Microsoft SQL Server 2008 Analysis Services ADOMD.NET
• Microsoft Server Speech Platform Runtime (x64)
• Microsoft Server Speech Recognition Language - TELE(en-US)
• SQL 2008 R2 Reporting Services SharePoint 2010 Add-in

먼저 설치되어 있으면 건너뛰고, 없으면 설치하도록 되어 있다.
이 모든 진행은 마법사 화면으로 되어 있으며, Next만 누르면 거의 완료된다.

설치 중간에 재 시작이 될 수 있는데, 로그인만 하면 자동으로 실행되므로, 반드시 설치했던 계정으로 계속 로그인 하도록 한다. (대개 특별한 계정을 만들지 않으면 Administrator 계정일 것이다. )

모든 설치가 완료되면 다음과 같은 요약화면이 뜬다.

완료가 되었으면 이제 SharePoint 자체를 설치한다. 
아래와 같은 초기 화면이 닫혔다면 다시 설치파일을 실행해서 화면에 나오게 한다.

이제 앞서 클릭했던 “Install software prerequisites” 다음 항목인 “Install SharePoint Foundation”을 선택하도록 한다.

자동으로 새로운 설치 진행 준비가 완료되면 다음과 같이 설치 종류를 물어본다. 하나는 Standalone 설치이고 다른 하나는 Server Farm 설치이다. SQL DB를 별도로 구성하려면 Server Farm을 해야 되지만, 이를 위해서는 Active Directory 까지 준비가 되어 있어야 한다. 그 정도 되면 여기서 설명하는 범위가 벗어나므로 그냥 Standalone으로 구성한다. 자동으로 SQL DB와 SharePoint 모듈이 모두 설치되며, 심지어는 자동으로 팀 사이트까지 만들어 놓게 된다.

여튼 Standalone을 선택한다.

모든 설치는 자동으로 진행된다, 끝날 때까지 기다리면 된다.

완료가 되면, 체크 박스와 함께 Finish 버튼이 나오는데, 체크 박스를 끄고 Finish를 한다. 다음 단계는 SharePoint 구성인데, 이 체크 박스의 체크의 의미가 그 SharePoint 구성 도구를 자동으로 띄울 것인지를 묻는 것이다.

우리는 SharePoint 구성 전에 , SQL Server 2008 R2에 대한 업데이트를 먼저 진행할 것이다.

SQL 2008 R2로 업그레이드 및 DB 관리도구 설치

SharePoint 가 2010이 되면서 SQL Server 2008 R2를 지원하게 되었는데, 이를 통해 업데이트 된 사항이 바로, FILESTREAM이라는 기능이다. 이 기능은 BLOB 즉 대용량 바이너리 파일을 DB에 직접 넣지 않고, 공유 폴더 같은 곳에 넣어주는 기능이다. SharePoint의 최대의 단점이 바로 이 바이너리 파일을 직접 DB에 넣는 문제라고 볼 수 있는데, 이 부분을 상당 부분 개선할 수 있다.

그렇지만, 이 FILESTREAM 기능을 사용하려면, SQL DB 자체의 설정 변경이 반드시 필요하다. 그 작업을 위해서는 당연한 것이지만, SQL Server가 2008 R2 이여야 하며, 또한 SQL Management Studio 가 필요하다.

이제부터 그 작업이라고 보면 된다.

먼저 MS SQL Server 2008 R2 Express with Tools 라는 것을 받는다. 반드시 With Tools 버전을 받는다. 다른 Express 버전과는 다르게, 이 버전은 SQL Managment Studio가 탑재되어 있다. 물론 별도로 받아 설치할 수 있지만, 한번에 받는 것이 더 편하다.

먼저 SQL Server 2008 R2로 업그레이드부터 한다.

SQL Server 2008 R2로 업그레이드

이 작업도 많이 애매한 편인데, 요즘 등록된 SharePoint Foundation 2010 에는 2008 R2 버전이 탑재되어 있다. 예전에 받아놓았던 SharePoint Foundation 설치 파일에는 그냥 2008만 담겨 있다.여튼 R2든 그냥 2008이든, 업그레이드 과정을 먼저 시도한다.

설치용 실행파일을 실행하면 Server 설치도구가 뜬다.

좀 메뉴가 복잡하게 되어 있는데, 왼편 Installation 항목을 클릭해서 화면을 전환한 뒤, 3가지 항목 중에 가운데에 위치한, Upgrade from SQL Server 2000, SQL Server 2005 or SQL Server 2008 을 클릭하도록 한다.

그러면 EUL 승인 화면이 뜨는데, 적당히 하고 Next를 하면, 대부분의 화면에서는 자동으로 넘어간다.

완료되면 정리된 요약 화면이 뜬다. 해당 서버 설정에 따라 Reboot를 요청하기도 하는데, Reboot를 해주도록 한다.

다시 서버 설치용 도우미 화면으로 돌아가도록 한다. 그리고 난 뒤, 이번에는 “New Insatllation or add features to an existing installation” 항목을 클릭한다.

무언가 자동으로 설정을 체크하고 자동으로 휙휙 넘어간다. EUL 화면이 뜨면 반드시 승인하고 넘어가도록 한다.

그러면 아래와 같은 선택화면이 나오는데, 모두 선택하도록 하자. 굳이 분리해서 구성할 정도로 옵션이 많지도 않기 때문에, 체크 박스 모두 선택한 뒤 Next를 클릭한다.

다음은 SQL의 인스턴스를 선택하는 부분인데, 여기서는 기존에 있는 인스턴스에 덧붙이는 형태로 한다. 그래서 선택 버튼에서도 Named Instance로 선택되어 있다. 특별히 변경하지 않고 그대로 진행한다.

다음은 서비스 동작 계정인데, 이 부분 역시 기본값으로 둔다.

이부분은 SQL 인증 방식인데, 만일 원격에서(다른 PC에서)해당 SQL DB를 열여볼 일이 있다면,반드시 아래 화면과 같이 설정한다. Windows authentication mode는 AD 계정이 아닌 이상 내부에서 밖에는 열 수가 없다. 그러므로 반드시 Mixed Mode를 선택하도록 한다. 그리고 암호를 설정한다.

같은 화면의 탭에서 FILESTREAM을 선택하는데, 여기 안의 모든 항목을 체크하도록 한다.

Next를 클릭하면, 역시 오류 사항 자동 보고 인데 역시 그냥 두고 Next

자동으로 구성되면서 무엇인가 열심히 설치된다.

완료되면 완료 보고 페이지가 뜬다.

SharePoint Foundation 구성

이제 본격적인 SharePoint 구성이다. 원래 이 부분은 Server Farm 인 경우 복잡다단하게 되지만, Standalone으로 하는 경우에는 대부분의 설정이 자동으로 구성되기 때문에, 지켜 바라만 봐도 된다.

실행 방법은 Start –> All Programs –> Microsoft SharePoint 2010 Product 에 있는 SharePoint 2010 Products Configuration Wizard 를 실행하면 된다.

간단한 형태의 마법사가 뜬다.

Next를 누르면 경고 메시지가 뜨는데, 그냥 Yes를 클릭한다. 이 작업에서 자동으로 설정되고, 자동으로 껏다가 켜지는 항목들을 나열하는 부분인데, 운영 중이 아닌 경우에는 무시해도 되는 항목들이다.

이제 설치를 가만히 지켜본다.

완료되면 Finish를 클릭한다. 그러면 자동으로 만들어진 웹사이트가 뜬다. 웹사이트 주소는 http://컴퓨터이름 이다.

현재 로그인한 계정의 ID와 암호로 로그인하면 된다.

간단하게 구성한 SharePoint는 여기까지. 설치 작업은 예전 WSS 3.0 보다 훨씬 간단해지고, 단순해진 것 같다.
더욱이 자동적으로 설치 환경을 꾸며주는 기능은 칭찬을 주고 싶다.

이 외에도 실제로 활용하려면, 몇몇 부분을 손봐야 겠지만, 당장 사용하는데에는 큰 문제가 없을 것이다.

예전 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 )