TFS 2010 설치 하기

Team Foundation Server 2010. 1. 26. 09:00 Posted by POWERUMC

Team Foundation Server 2010 은 기존의 2008 버전에 비해 굉장히 설치가 간단해 졌습니다.  

사실 설치과 구성 패키지 자체는 TFS 2008 이 간단하긴 했지만, 구성이 올바르게 완료되어야만 설치가 가능했었습니다. 이런 문제로 인해서 초기 설정이 유효하지 않을 경우 설치를 완료한들 다시 제거를 하고 재설정을 했던 경우가 많았습니다. 그리고 TFS 2008 에서는 설정 정보가 IIS 의 TFS Web Service 의 web.config 와 데이터베이스의 특정 필드를 직정 수정해야 하는 관리상의 불편함이 많았습니다.

하지만 이번 Team Foundation Server 2010 는 이런 면에서 초기 설치 단계에서 구성하는 단계까지 많이 편리해졌습니다. 설치와 구성을 따로 따로 하도록 말이죠.  

아래는 Team Foundation Server 2010 을 설치하고, Team Foundation Server Administration Console 을 이용하여 TFS 환경을 구성하는 방법입니다. 

아래의 설치 과정은 3-tier 로 구성된 서버에 TFS 2010 을 설치하는 단계입니다.

  • 서버 1 : Active Directory, DNS 서버
  • 서버 2 : MSSQL 2008
  • 서버 3 : Team Foundation Server 2010

   

Team Foundation Server Administrator Console 을 실행하여 Configure Installed Features 를 클릭합니다.

   

다중 Tier 환경으로 설치할 예정이므로, Advanced 를 선택하고 Start Wizard 를 클릭합니다.

   

Wizard 안내 페이지입니다. 그냥 다음으로 넘어 갑니다.

   

SQL Server 의 인스턴스를 입력하고 Test 를 클릭합니다. 인스턴스가 유효하면 푸른색 V 표시가 나타나고, 다음으로 넘어 갑니다.

   

Service Account 계정을 입력하고 Test 를 클릭해보고, 계정이 유효하면 다음으로 넘어갑니다.

   

Team Foundation Server 2010 의 웹 서비스의 설정을 합니다. 그냥 기본 구성 그대로 다음으로 넘어갑니다.

   

보고서를 구성하는 페이지의 안내입니다. 필자는 보고서를 구성할 것이므로, Configure Reporting for use with Team Foundation Server 항목 체크 박스를 체크 한 후에 다음으로 넘어갑니다.

   

Reporting Service 인스턴스를 입력하고 Populate URLs 를 클릭하면 유효한 보고서 서비스를 찾아줍니다. 그리고 다음으로 넘어갑니다.

   

TFS Report 서비스의 실행 계정을 지정해 줍니다. 필자는 기본 계정인 NETWORK SERVICE 계정을 사용합니다.

   

아래는 Sharepoint 를 설치를 안내하는 페이지 입니다. 다음으로 넘어갑니다.

   

Sharepoint 서버의 계정을 입력하고 Test 를 클릭하여 유효성을 검사합니다. 그리고 다음으로 넘어갑니다.

   

기본적으로 Team Project Collection 이 체크되어 있습니다. 그대로 다음으로 넘어갑니다.

   

모든 설정이 완료 되었습니다. Verify 를 클릭하여 최종 점검을 진행합니다.

   

Verify 결과가 양호할 경우 설치를 진행하도록 합니다. Configure 를 클릭하여 설치를 진행합니다.

   

아래는 Team Foundation Server 2010 이 설치가 완료되었습니다.

   

   

이제 설치가 완료되었고, Team Foundation Server 관리를 위하여 관리 권한을 지정합니다.

Application Tier 의 Administer Group Membership 을 클릭합니다.

   

Team Foundation Administrators 그룹을 더블 클릭(또는 Properties 클릭) 하고, 관리자 계정을 지정해 줍니다.

   

   

이제 모든 설치와 구성을 마쳤습니다. 아래의 그림은 Visual Studio 2010 으로 Team Foundation Server 2010 에 연결된 모습입니다.

   


WCF의 기본 <Contract> - Service Contract

WCF 2010. 1. 26. 09:00 Posted by 알 수 없는 사용자
지금까지 세번의 포스팅으로 WCF의 기초에 대해 알아보았습니다.
기초를 뗏으니, 이제 기본으로 넘어가야죠~ ^^

WCF의 기본 중에서 가장 먼저 알려드리고 싶어 꺼내 든 주제는 Contract 입니다.

Contract의 사전적 의미는,, "계약" 이죠.
(네이X 사전에서 찾아보니 계약이란 의미 외에 살인 청부, 줄어들다, 수축하다,, 등의 의미가 있군요,,)

그럼, "계약"의 사전적 의미는 무엇일까요? (약간 글이 엉뚱한 방향으로 흐르는 것 같지만,, ^^;;)
역시, 네이X 국어 사전에서 찾아본 결과,, 
"관련되는 사람이나 조직체 사이에서 서로 지켜야 할 의무에 대하여 글이나 말로 정하여 둠" 이라고 합니다.

잘 아시겠지만 계약은 약속이랑 비슷하지만 약속 보다는 좀 더 강력한 의미로 쓰입니다.(법적 효력도 있죠,,)

다시, 본론으로 돌아와서,, 그럼, WCF 에서의 Contract 는 무엇을 말하는 걸까요?
네,, 다들 예상 하셨겠지만, WCF 에서의 Contrat 역시 사전적 의미와 비슷하게 쓰이며, WCF 서비스와 클라어언트 사이에 어떤 계약을 정의할 때 사용하는 것을 말합니다.

좀 더 자세하게 설명을 하자면, 이 Contract 라는 것은 서비스와 클라이언트가 서로 통신할 때 사용하는 메세지의 명세(specification)를 정의하는 것을 말합니다.

WCF 는 총 세가지 타입의 Contract가 있으며, 다음은 이 타입들에 대한 정의입니다.

  • Service contract : 서비스에 의해 구현되는 기능들에 대해 설명하며, 서비스 계약(service contract)으로 정의 된 .NET 타입의 클래스는 WSDL의 services, port types의 엘리먼트로 매핑됩니다. 서비스 계약과 함께 Operation contract는 서비스 계약 내에서 정의되며, 서비스의 동작(operation)을 설명합니다.

  • Data contract : 서비스가 통신(communication)을 하는데 사용하는 데이터 구조를 나타냅니다. 이는 CLR 타입을 XSD(XML Schema Definitions) 로 매핑해주는 역할을 수행하는데, WCF 가 통신할 때 사용되어지는 데이터들을 어떻게 직렬화(serialization) 또는 역직렬화(deserialization)를 수행하는지를 설명합니다.

  • Message contract : 메세지 계약은 CLR 타입을 SOAP 메세지로 매핑해주며, SOAP 메세지의 포맷을 설명합니다. 메세지 계약은 SOAP 헤더에서 바디까지 컨트롤할 수 있게 해줍니다.

예전 포스팅에서 몇 번 언급한 점이기 때문에 다들 아실거라 생각하는데,, WCF 서비스는 많은 시스템과의 상호 운용성(interoperability)을 높이기 위해 WSDL을 사용합니다. 위에서 설명한 세 가지의 Contract 들은 WCF 서비스나 서비스에서 사용하는 여러 데이터들을 WSDL 또는 SOAP의 요소들로 매핑 시키는 역할을 수행합니다. 이 말은 곧, 서비스와 통신하기 위한 메세지의 포맷을 정의한다는 말이기도 하지요.(앞에서 언급했듯이,,)

이제 Contract의 정의에 대해선 조금 이해가 가시지요? ^^

그럼, 이러한 Contract들이 어떻게 쓰이는지 하나씩 살펴보겠습니다.
우선, Service Contract 와 Operation Contract에 대해 알아보구요, 한 두번에 걸쳐서 Data Contract와 Message Contract에 대해서도 알아보도록 하겠습니다.

서비스 계약은 지금까지 몇번 언급했던 것 같습니다.
다시 한번 더 얘기하자면, 서비스 계약은 서비스가 제공하는 여러 기능(동작)들을 정의하는 인터페이스이며, 서비스 자체를 정의한다고 생각하면 될듯 합니다. 
그리고, 서비스에서 제공하는 기능들을 외부로 노출(?)하기 위해 사용하는 Operation Contract가 있습니다. 이는 Service Contract 내부에서 정의됩니다.

백문이 불여일견이니, 코드를 한번 보도록 하죠. 음,, 예전에 만들었던 코드를 다시 살펴 보면서 이해하는게 좋을 것 같네요 ^^

[ServiceContract]
interface IProductService
{
    [OperationContract]
    string GetFirstName(string empID);
}


우리가 만들었던 첫 WCF 서비스의 코드 중 일부입니다.
서비스는 ServiceContract 특성을 인터페이스에서 선언하고, 그 메소드에 OperationContract 특성을 선언해줌으로써, 서비스 계약을 정의해주었습니다.
기억하시겠지만, 실제 구체적인 서비스의 기능은 Service Contract가 선언된 인터페이스를 상속 받아 구현해야 했었죠.

그럼, 이렇게 서비스가 정의됐을 때 WSDL이 어떻게 만들어지는지 살펴보겠습니다.
우리가 작성했었던 첫 WCF 서비스를 동작시킨 상태에서 웹 브라우저를 이용해 http://localhost:8000/ProductService?wsdl 로 접근해 보면 다음과 같은 화면을 확인할 수 있습니다.


이것이 바로 WCF 서비스가 제공하는 WSDL입니다.
앞에서 언급했듯이 Service Contract로 정의 되어진 정보는 WSDL의 "service", "port type" 엘리먼트로 매핑된다고 하였습니다. 또한 Operation Contract로 정의된 부분은 "operation" 엘리먼트로 매핑된다고 했었죠,, 
이것 역시 다음과 같이 확인할 수 있었습니다.





이렇게 WCF를 이용하여 만들어진 서비스는 WSDL로 제공되어지며, 클라이언트에서 서비스를 사용할 수 있게 되는 것입니다.

그리고, ServiceContract 특성 클래스에는 Namespace 속성을 제공합니다. 이 속성은 WSDL과 SOAP 메세지의 Namespace의 값을 명시적으로 설정할 수 있게 합니다.

다음과 같이 기존의 서비스를 조금 수정해 보았습니다.

[ServiceContract(Namespace="http://RuAAService.co.kr/")]
interface IProductService
{
    [OperationContract]
    string GetFirstName(string empID);
}


그리고, 다시 이 서비스의 WSDL을 확인해보면, 서비스의 네임스페이스가 다음과 같이 바뀌어져있는 것을 확인할 수 있습니다.



자~ Service Contract에 대한 설명은 여기까지 입니다.
이번에는 실습보다는 이론적인 설명이 위주였습니다. 그래서 조금 재미가 없을 수도 있을 것 같네요 ㅎ
하지만, 이론도 중요하다는 것,, 아시죠? ^^
아무 생각없이 닷넷 인터페이스 만들고 ServiceContract 특성을 주는 것 보다 이러한 작업으로 서비스가 어떻게 클라이언트에 노출되는지를 알고 있는 것이 서비스를 구성하고, 클라이언트를 개발하는데 있어서 많은 도움을 줄 것이라 확신합니다.

이 글 역시, 많은 분들에게 조금이라도 도움이 되었으면 하는 바람을 가지면서 이만 줄이겠습니다 ^^
다음 포스팅때 뵙죠~ ㅎ

5. Assembly - Strongly named assemblies

CLR 2010. 1. 26. 09:00 Posted by 알 수 없는 사용자
CLR에서는 Assembly를 크게 두 종류로 나눌 수 있습니다. Strongly named assemblies(강력한 이름의 어셈블리 - 뭔가 말이 좀 이상하지요?) 그렇지 않은 Assembly 입니다. 

Strongly named assemblies는 해당 assembly의 제공자를 확인할 수 있는 유일한 공개/개인키 쌍으로 서명되어 있고 이 키들은 assembly는 고유한 ID의 일부분으로 인식되어 안전하게 버전이 관리되며 이 키를 통해서 서명된 assembly는 어느곳에서라도 유일한 이름으로 인식되며 배포가 가능하게 됩니다. 

assembly는 크게 전용(Private)으로 배포하는 방식과 전역(Global)으로 배포하는 방법으로 배포 방법을 나눌 수 있습니다. 

전용 배포라는 것은 매우 일반적인 방법의 배포방식으로 배포할 프로그램의 기본 디렉토리와 그 디렉토리의 하위 디렉토리에 관련 assembly들이 설치되어 배포된 형태이며 전역 배포라는 것은 Global Assembly Cache - GAC(전역 어셈블리 캐시) 같은 잘 알려진 특정 디렉토리에 배포되는 방식을 말합니다.

Strongly named assemblies는 전용, 전역 배포가 가능하지만 그렇지 않은 assembly는 전용 배포는 가능하나 전역 배포는 안됩니다. 위에서 알았다시피 Strongly named assemblies가 아닌 경우 유일하게 해당 assembly를 인식할 수 있는 방법이 없으니 당연히 전역적인 배포가 불가능합니다.


자 그럼 Strongly named assemblies를 어떻게 만들 수 있는지 살펴보도록 하지요. 그 전에 잠깐 왜 Strongly named assemblies가 필요한지 잠깐 생각해 봅시다.

다양한 프로그램들이 자신들이 사용하는 assembly를 사용하려고 하는 상황입니다. 일반적으로 그렇듯이 여러 프로그램에서 자주 사용하는 assembly는 잘 알려진 디렉터리에 위치해 있어야 다양한 프로그램들이 사용하기 용이할 것입니다. 

CLR 프로그램 이전의 배포 방식을 되새겨 볼까요.

Visual Studio 6, 7 버전의 Visual C++ 프로그램을 살펴보면 Visual C++ 컴파일러로 생성된 프로그램들은 공통적으로 msvcp71.dll이라던가 msvcp60.dll 등의 공용 모듈을 사용하게 됩니다. 그래서 일반적으로 프로그램 설치시 위의 모듈들을 설치되는 프로그램과 같은 경로에 넣기도 하지만 windows 폴더의 system32 디렉터리에 넣어놓곤 하지요. 일반적으로 MS관련 프로그램을 설치하게 되면 위의 ms..로 시작하는 dll들은 system32 디렉터리에 설치가 되기 때문에 응당 위의 모듈이 모든 PC의 system32 폴더에 있겠거니 착각하고 배포본에 넣어놓지 않았다가 낭패를 보는 경우도 적지 않게 있었지요. 

MS관련의 공통모듈 뿐만이 아니라 다양한 프로그램에서 자주 사용하는 모듈들은 Windows가 설치된 PC라면 설치된 프로그램이 어느 디렉터리에 설치가 되던지 참조가 가능한 system32 폴더에 설치해 놓는 경우가 많습니다. 이러면서 문제가 발생하게 되었는데 다른 회사에서 같은 파일 이름을 가진 모듈을 system32 폴더에 설치를 하게 되었다던가, 같은 이름을 가지지만 버전이 틀린 파일을 설치하게 되어 특정 프로그램은 정확히 자신이 참조해야 하는 모듈을 찾을 수 없어 프로그램이 정상적으로 실행되지 않는 이른바 DLL Hell과 관련된 문제가 생기가 된 것입니다. 무엇보다 별 생각없이 system32같은 중요한 디렉터리에 자신들이 배포하는 프로그램과 관련한 모듈들을 무작정 설치하는 것도 DLL Hell을 만들게 된 중요한 원인 중 하나였지요.

최근에도 그런 문제가 있었습니다. 인터넷 익스플로러 8과 아래아 한글과의 충돌 문제였지요,

인터넷 익스플로러 8이 설치된 PC에 아래아 한글이 설치되면 인터넷 익스플로러 8이 시작하자마자 다운되는 문제가 발생했는데 그 원인은 이미 인터넷 익스플로러 8 이 사용하는 system32폴더에 설치된 최신 버전의 jscript.dll 모듈을 아래아 한글이 사용자 PC에 설치되면서 구 버전의 jscript.dll모듈로 교체 설치를 함으로써(같은 파일명이니 덮어씌워지는 형태로 설치가 되어버린 겁니다.) 인터넷 익스플로러 8은 자신이 사용하는 jscript.dll 파일을 찾지 못해 뻗어버리게 된 것이지요.

단순히 파일 이름만으로 프로그램 자신이 참조해야 하는 모듈 또는 assembly를 찾는 건 좋은 방법이 아니라는 것이 증명된 것입니다. 그래서 CLR의 경우 정확히 자신이 참조해야 하는 assembly를 식별하기 위해서 다음과 같은 4가지 요소를 이용하여 assembly를 식별하게 됩니다.

1. 파일 이름 (확장자를 제외한)
2. 버전 번호
3. 컬쳐 (로케일)
4. 공개키 (또는 공개키를 이용하여 생성한 작은 해시값)

어떤 프로그램이 자신이 원하는 assembly를 찾을 때 저 4가지 요소가 정확히 맞아야지 해당 assembly를 자신이 찾는 assembly라고 확신하고 사용하게 된다는 말이지요. Strongly named assemblies에 해당하는 이야기입니다.

저 4가지 요소중 1, 2, 3번 요소는 굉장히 드물기는 하겠지만 다른 회사와 동일 할수도 있습니다. 하지만 4번 공개키는 공개/개인키 쌍을 만들어서 사용하는 것이니만큼 해당 assembly의 제작자가 틀리다면 같을 수가 없을 것입니다.

Strongly named assemblies가 아닌 경우는 공개키를 제외한 요소들을 manifest metadata로 가질 수 있지만 assembly를 찾을 때는 단순히 파일 이름만을 이용하여 찾게 됩니다.

자 그럼 이젠 Strongly named assemblies를 만드는 방법을 살펴보도록 합시다.

우선은 키를 생성해야 합니다. 키를 생성하기 위해 .NET Framework에서는 SN.exe 라는 툴을 제공합니다. Visual Studio Command Prompt 2010을 실행하여 다음과 같이 실행해 보면-

SN -k VSTSTeam.keys

VSTSTeam.keys 라는 파일명의 공개/개인키의 쌍을 생성하게 됩니다. 이 파일은 바이너리의 형태로 공개/개인키의 쌍을 갖고 있습니다. 우리는 공개키를 사용해야 합니다. 공개키를 확인하기 위해서는 만들어진 키 파일을 이용하여 다음과 같이 SN.exe 를 한번더 실행해야 합니다.

SN -p VSTSTeam.keys VSTSTeam.publickey

결과로 VSTSTeam.publickey 라는 파일이 생성됩니다. 이 파일은 공개키를 포함하고 있는 바이너리 파일입니다. 이 파일의 공개키를 한번 확인해 봅시다.

SN -tp VSTSTeam.publickey

그럼 다음과 같이 굉장히 긴- 공개키 값을 확인할 수 있습니다.


이렇게 공개키는 확인할 수 있지만 개인키를 확인할 수 있는 방법은 제공하지 않고 있습니다.

이렇게 생성한 키를 이용하여 assembly를 컴파일 할 때 다음과 같은 Argument를 이용하여 assembly에 공개키를 포함시키게 됩니다.

csc /keyfile:VSTSTeam.keys hello.cs

당연히 Visual Studio IDE에서도 이런 작업이 가능합니다.



Sign the assembly 라는 체크박스에 체크를 한 후 새로 key를 생성해도 되고 이미 생성된 key 파일이 있다면 해당 key파일을 이용하여 사용하면 됩니다.



참고 자료
CLR Via C# 2nd. Ed.

'CLR' 카테고리의 다른 글

7. System.Object  (0) 2010.02.16
6. Assembly - GAC(Global Assembly Cache)  (2) 2010.02.02
4. Assembly  (2) 2010.01.15
3. MSCorLib & Metadata  (4) 2010.01.06
2. CLR! CLR! CLR!  (3) 2009.12.30