Visual Studio 2010 Beta 2 출시

Visual Studio 2010 2009.10.20 10:06 Posted by POWERUMC

미국 시간으로 2009년 10월 19일, Visual Studio 2010 Beta 2 버전이 공개가 되었습니다. MSDN 을 통해 Beta 2 버전을 다운로드 받으실 수 있습니다.

다운로드
http://msdn.microsoft.com/en-us/vstudio/dd582936.aspx

 

그간 Visual Studio 2010 CTP/Beta 버전에서 보여주었던 약간의 성능적인 문제는 이번 Beta 2 버전에서 상당히 많이 개선이 되었다고 합니다.

특히 이번 Beta 2 버전부터는 제품 라인이 전체적으로 변경되었습니다. 기존의 Professional 제품을 제외한 모든 제품의 라인이 변경이 됩니다. 다운로드 받으실 때 혼란이 없으시길 ^_^

더불어 Expression 제품 군도 두 개의 제품으로 나뉘어지게 될 것입니다.

기존 제품

Beta 2 부터 적용되는 제품

Visual Studio Team Suite

Visual Studio Ultimate

Visual Studio Test Edition
Visual Studio Database Edition
Visual Studio Architecture Edition Visual Studio Development Edition

Visual Studio Premium

Visual Studio Professional

Visual Studio Professional

아래는 변경된 MSDN 로고 입니다. ^_^

   

저작자 표시 비영리 동일 조건 변경 허락
신고

지난 번 포스팅에서 말씀 드렸던 것처럼 Visual Studio Team System 2010에서 이루어진 Code Analysis 기능 개선에 대해서 더 깊게 다뤄 보겠습니다. 그 첫 번째로 새롭게 추가된 Rule Sets 개념에 대해서 알아보도록 하겠습니다.


Visual Studio 2005, 2008에서의 코드 분석 설정

Visual Studio의 코드 분석 시스템에는 약 200개 정도의 규칙이 있습니다. 하지만, 사실 이 규칙들을 모두 준수를 해야 하는 것은 아닙니다. 모든 규칙이 나름의 이유와 정당성을 갖고 있다고 해도, 프로젝트의 성격에 따라, 모듈의 성격에 따라서 꼭 지켜야 할 규칙, 그렇지 않은 규칙, 심지어는 어쩔 수 없이 위반해야 하는 규칙도 있을 수 있습니다.

그래서 코드 리뷰를 할 때, 대부분의 경우 모든 규칙을 다 검사하지는 않습니다. 각각 케이스 바이 케이스로 규칙을 적절하게 조절하게 됩니다.

Visual Studio Team System 2005와 2008 버전에서는, 이런 설정을 Visual Studio Project Configuration에서 각 프로젝트 별로 할 수가 있습니다.

이 규칙 설정은 프로젝트 파일(.vbproj 혹은 .csproj)에 CodeAnalysisRules라는 Property 이름으로 아래와 같이 저장되게 됩니다. 내용을 보면 아시겠지만, “-“ 기호와 규칙 ID를 붙여 놓은 모양으로 되어있습니다. 즉, 거기에 열거된 규칙 ID를 Analysis Rules에서 빼는 형태로 저장이 되는 것입니다. 아래 샘플은 그래서 이 프로젝트는 코드 리뷰를 할 때에 Design Rule의 CA1000번 규칙을 검사하지 않는다라는 의미가 됩니다.

<CodeAnalysisRules>-Microsoft.Design#CA1000</CodeAnalysisRules>

이런 형태로 Visual Studio 프로젝트마다 다른 규칙을 적용할 수 있다는 것은 대단히 유연한 디자인이긴 하지만, 많은 수의 Visual Studio Project가 존재한다면, 관리가 참으로 어렵습니다. 그래서 예전에 Visual Studio Team System 2005 를 사용했던 프로젝트에서 전체 Visual Studio 프로젝트의 분석 규칙들을 통일하기 위해서, 개별 개발자들에게 위임하지 않고 제가 직접 모든 프로젝트를 텍스트 에디터로 열어서 저 부분만 Copy & Paste로 넣어서 Check-In하는 엄청난 단순 반복 작업을 한 적도 있습니다.

 

Visual Studio Team System 2010의 Rule Sets Feature

그래서 새롭게 출시될 Visual Studio Team System 2010에서는 Rule Sets라는 개념이 도입되었습니다. 이 Rule Sets 기능은 이름에서도 알 수 있듯이 Rule들을 미리 정해진 Set으로 관리할 수 있는 기능입니다. 이제 Visual Studio 프로젝트 별로 Rule을 하나 하나 빼는 수고를 할 필요가 없이 Visual Studio 프로젝트에 Rule Set을 지정하는 것으로 Code analysis를 커스터마이징할 수 있게 된 것입니다. 아래 그림에서 볼 수 있듯이, 하나 이상의 Rule Set을 선택하는 것도 가능합니다. (가장 아래의 Choose Multiple Rule sets를 선택하면 됩니다.)


Visual Studio Solution 전체에 Rule Set을 적용하는 것도 가능합니다. Solution Property에서 아래와 같이 설정할 수 있습니다.

 

위 그림에서 보시는 것처럼 마이크로소프트는 기본적으로 7개의 기본 Rule Set을 제공합니다. 이 기본 Rule Set의 목록은 다음과 같습니다.

  • Microsoft All Rules – 전체 Rule이 모두 포함된 Rule Set입니다.
  • Microsoft Basic Correctness Rules – 로직 에러와 자주 저지르는 실수를 예방하는 규칙들로 이루어진 Rule Set입니다.
  • Microsoft Basic Design Guideline Rules – Framework API 작성 상의 Best Practice에 집중된 Rule Set입니다.
  • Microsoft Extended Correctness Rules – Basic Correctness Rules를 확장하여, COM Interop이나 Mobile Application에도 사용 가능하도록 만들어진 Rule Set입니다.
  • Microsoft Extended Design Guideline Rules – Basic Design Guideline Rules를 확장해서, 사용성이나 유지 보수성도 체크할 수 있도록 만들어진 Rule Set입니다.
  • Microsoft Globalization Rules – Application의 Globalization에 있어서 문제가 있는지 검증하는데 집중된 Rule Set입니다.
  • Microsoft Minimum Recommended Rules - MS가 제안하는 최소한의 Rule Set입니다. 50개 정도의 규칙으로 이루어져 있습니다. 다른 대부분의 Rule Set들이 이 Rule Set을 포함하고 있습니다.
  • Microsoft Security Rules – 이름 그대로 보안에 집중된 Rule Set으로, 모든 Security 관련 규칙들이 모두 포함되어 있습니다.

 

물론 이 외에도 사용자가 직접 Rule Set을 편집할 수 있습니다. Rule Set은 .ruleset이라는 확장자를 가지는 XML 파일 포맷으로 되어 있습니다. 기본적으로 Visual Studio 2010에서 아래와 같은 UI를 통해서 편집할 수 있도록 되어 있습니다.


 

아래는 Rule Set 파일을 직접 Notepad로 열어본 것입니다.

<?xml version="1.0" encoding="utf-8"?>
<RuleSet Name="Microsoft Basic Correctness Rules" Description="These rules focus on logic errors and common mistakes made in the usage of framework APIs. Include this rule set to expand on the list of warnings reported by the minimum recommended rules." ToolsVersion="10.0">
  <Localization ResourceAssembly="Microsoft.VisualStudio.CodeAnalysis.RuleSets.Strings.dll" ResourceBaseName="Microsoft.VisualStudio.CodeAnalysis.RuleSets.Strings.Localized">
    <Name Resource="BasicCorrectnessRules_Name" />
    <Description Resource="BasicCorrectnessRules_Description" />
  </Localization>
  <Include Path="minimumrecommendedrules.ruleset" Action="Default" />
  <Rules AnalyzerId="Microsoft.Analyzers.ManagedCodeAnalysis" RuleNamespace="Microsoft.Rules.Managed">
    <Rule Id="CA1008" Action="Warn" />
    <Rule Id="CA1013" Action="Warn" />
    <Rule Id="CA1303" Action="Warn" />
    <Rule Id="CA1308" Action="Warn" />
    <Rule Id="CA1806" Action="Warn" />
    <Rule Id="CA1816" Action="Warn" />
    <Rule Id="CA1819" Action="Warn" />
    <Rule Id="CA1820" Action="Warn" />
    <Rule Id="CA1903" Action="Warn" />
    <Rule Id="CA2004" Action="Warn" />
    <Rule Id="CA2006" Action="Warn" />
  </Rules>
</RuleSet>

 

Team Foundation Server Check-In Policy

이 Rule Set 기능은 Team Foundation Server의 Check-In Policy에도 쓰이게 됩니다.

 

맺으며..

이번 Rule Set Feature를 통해서 확실히 이전 버전보다는 Code Analysis를 사용하는 것이 쉬워지고 편리해진 것 같습니다. 하지만, Code Analysis에서 중요한 것은 편의성보다는, Rule의 문제라고 생각됩니다. 그런 면에서 아직 FxCop이 처음 나왔을 때의 200개 정도의 Rule에서 많은 추가가 없다는 것은 굉장히 아쉽습니다. 특히 직접적인 경쟁 제품이라고 볼 수 있는 Compuware의 DevPartner Code Review가 처음 버전부터 600개 이상의 Rule을 가지고 있다는 점에 비교해 본다면 더욱 그렇습니다.

이어지는 포스팅에서는 새롭게 Code Analysis에 추가된 Phoenix 엔진과 그에 따라 다시 복귀한 Data Flow 관련 규칙들에 대해서 한 번 알아보겠습니다.

신고

Visual Studio Team System 2005 에서 코드 분석(Static Code Analysis) 기능이 처음 소개된 바가 있습니다. 이 코드 분석은 Microsoft에서 제안하는 닷넷 프레임워크에서의 디자인 가이드라인과 성능이나 보안, 신뢰성 등의 요소에 대한 Best Practice 등으로 이루어진 200개 이상의 Rule을 기반으로 Code를 검사하고 결함을 발견해 줍니다.

 

원래 이 Code Analysis는 FxCop이란 이름의 독립된 툴로써 세상에 먼저 선을 보인 바 있습니다.

이 FxCop이 Visual Studio 2005 Team System에서 통합되면서 현재의 코드 분석 기능이 나오게 된 것입니다. 실제로 비주얼 스튜디오에서 코드 분석 기능을 담당하는 실행 파일의 이름은 아직도 FxCopCmd.exe입니다.

앞으로 나오게 될 Visual Studio Team System 2010에서는 현재까지 알려진 바로는 다음 세 가지 부분에서 코드 분석의 기능 향상이 이루어 졌습니다. (출처: http://blogs.msdn.com/fxcop/archive/2008/10/30/new-code-analysis-features-in-visual-studio-2010-september-08-ctp.aspx)

  1. Rule Sets – 드디어, 규칙을 프로젝트 별로 하나 하나 빼던 수고스러움을 덜 수 있게 된 것 같습니다. DevPartner Code Review와 같은 상용 툴에서는 진작에 제공되던 기능이었지만, 이제 드디어 Visual Studio 2010에서는 Rule들을 Set으로 만들고 그 Rule Set 기반으로 코드 리뷰를 할 수 있게 되었습니다.
  2. Check-In Policy – 당연한 말이겠지만, 바로 위에서 소개한 Rule Sets 기능이 Team Foundation Server의 Check-In 정책에도 적용할 수 있게 됩니다.
  3. 8개의 새로운 Data-Flow 규칙MSDN Code Gallery의 VS2005와 VS2008 코드 분석 비교 문서를 보시면 아시겠지만, VS2008에서 7개의 규칙이 빠진 바 있습니다. Data-Flow Analysis Engine의 각종 버그와 낮은 성능으로 말미암은 결과라고 하는데, 이번 Visual Studio Team System 2010에서는 Phoenix라는 새로운 분석 엔진의 탑재와 함께 다시 7개의 규칙들이 복귀했고, 새롭게 추가된 하나를 합쳐서 총 8개의 새로운 규칙이 추가되었습니다. 그리고 이번에 추가된 Phoenix 분석 엔진은 당연히 기존 엔진이 가지고 있었던 버그나 성능 문제를 해결한 새롭고 강력한 엔진입니다.

그러면 다음 포스팅을 통해서 이 세 가지 개선점들에 대해서 더 자세히 다뤄보도록 하겠습니다.

신고

안녕하세요. 이번에 Visual Studio Team System 2010 공식 블로그에 새롭게 참여하게 된 LazyDeveloper.Net의 kkongchi라고 합니다. Better Code 시리즈를 통해서 Code Analysis, Unit Test 등에 대한 포스팅을 해보도록 하겠습니다. 부족한 부분 많이 지적해 주시길 바랍니다.

 

TDD?

eXtreme Programming의 창시자 중 하나인 Kent Beck의 eXtreme Programming explained라는 책을 보면 Test를 작성하는 방법에 대해서 이렇게 기술하고 있습니다.

  • If the interface for a method is at all unclear, you write a test before you write the method. (메서드의 인터페이스가 클리어하지 않다면, 메서드를 작성하기 전에 테스트를 먼저 작성해라)

  • If the interface is clear, but you imagine that the implementation will be the least bit complicated, you write a test before you write the method. (메서드의 인터페이스가 클리어하더라도 당신이 생각하기에 구현이 조금 복잡할 것 같다면, 메서드를 작성하기 전에 먼저 테스트를 작성해라)

  • 이런 eXtreme Programming의 Test-Before-Writing 전략을 개발 프로세스에 전면적으로 도입하는 것을 Test Driven Development, 즉 TDD라고 합니다. TDD에 관한 위키피디아 페이지에서 소개하는 TDD의 개발 사이클은 다음과 같습니다. “Red, Green, Refactor”라고 표현하기도 합니다.

    다들 아시다시피, Visual Studio에서는 2005 버전에서부터 Team System의 일부로써 Testing Framework을 제공하고 지원해왔습니다. 그리고 드디어 이번 Visual Studio Team System 2010에서는 완벽하게 TDD의 개념이 Visual Studio Team System안으로 녹아 들어가게 된 것 같습니다. 바로 새롭게 추가된 기능 “Generate” 기능을 통해서, Test를 먼저 작성한 후에 그 Test로부터 코드를 자동으로 Generate해주는 기능이 추가된 것입니다.

     

    TDD Development in VSTS 2010 by “Generate”

    지난 11월에 나온 Visual Studio 2010 and .NET Framework 4.0 Training Kit의 Lab을 통해서 이 기능에 대해서 좀 더 자세히 알아보도록 하겠습니다.

     

    당연히 먼저 테스트를 작성하는 것부터 시작합니다. 하지만, 아직 만들어지지 않은 클래스이기 때문에 아래 그림처럼 빨간색 물결 라인으로 경고가 뜹니다. 여기서 마우스 오른쪽 버튼을 눌러보면, 새로운 “Generate” 기능을 볼 수가 있습니다.

    Generate class를 선택하면 같은 프로젝트에 Class가 추가됩니다. 하지만 Generate other..를 선택하면 아래와 같은 팝업 윈도우가 나옵니다. 클래스를 만들 수 있는 Wizard 개념이라고 보시면 되겠습니다.

    이 Wizard를 통해서 클래스의 Access 한정자, Type, 그리고 파일을 만들 프로젝트까지 설정을 할 수가 있습니다. 이 과정을 통해서 우리는 완벽하게 Test로부터 시작해서 뼈대 코드를 만들어 낼 수가 있습니다. 아래 그림처럼 말이죠..

    이제 이 자동으로 만들어진 뼈대 코드에 구현을 추가하게 되면 여러분들은 다음과 같이 Test를 통과했다는 기분 좋은 화면을 보실 수 있으실 것입니다.


    위에서 보신 Demo Code의 시연은 http://channel9.msdn.com/shows/10-4/10-4-Episode-5-Code-Focused-in-Visual-Studio-2010/#Page=4 에서 Video로도 감상하실 수 있고, http://www.microsoft.com/downloads/details.aspx?FamilyID=752CB725-969B-4732-A383-ED5740F02E93&displaylang=en 에서 Lab Document와 소스 코드도 얻으실 수 있습니다.
     

    지금까지 보신 것처럼 앞으로 출시될 VSTS 2010에서는 IDE 자체에서 완벽한 TDD 지원 기능이 통합되었습니다. TDD가 만능의 도구는 아닙니다. 하지만, 적어도 개발자가 자신의 코드에 대한 이해도가 통상적인 개발 방법보다는 훨씬 크고 깊을 것이라 기대합니다. 어설픈 문서보다는 잘 만들어진 테스트 코드들이 오히려 실제 구현 코드를 이해하는 데 더 도움이 되는 경우도 많습니다. Visual Studio Team System 2010은 효율적인 Test Driven Development를 가능하게 해주는 최고의 도구가 될 것 같습니다.

    부족한 글 읽어주셔서 감사하고, 많은 의견 부탁 드립니다.

    신고

    .NET 의 과거와 현재, 그리고 미래

    .NET Framework 2009.02.01 21:00 Posted by POWERUMC

    학창 시절 사회/역사 시간을 통해 우리나라의 역사에 대해서 공부를 하였고, 많은 한 시대를 통치하던 왕 이름과, ~시대와 수많은 ~전쟁 이름 까지 외운 적이 있을 것입니다. 그때는 시험 때문이라도 목숨(?) 걸고 외웠던 적이 있지만, 그 때 배웠던 것을 통해 우리 사회와 문화를 이해하고, 계승할 수 있던 계기가 아니었나 생각합니다. 아마 지금의 .NET 세계도 마찬가지 일 것입니다. .NET 의 과거를 모르면 현재의 .NET 도 이해할 수 없는 것들이 많을 것입니다. 그래서 오늘날 .NET 4.0 의 출연에 앞서 .NET 의 역사를 한번 짚어 보고자 합니다.

    오늘날 우리 .NET 개발자들은 수많은 개발 툴(Visual Studio IDE) 버전과 .NET Framework 버전의 홍수 속에서 처음부터 .NET 1.0 을 다루어본 독자는 그리 많지는 않을 거라고 생각합니다. 아마도 .NET 3.0, 3.5 시대에 뛰어든 독자라면 이전 .NET 버전의 특징을 잘 알 수 없기 때문에, 쓰고 있는 신 버전의 특징도 체감하기가 쉽지 않을 것입니다.

    자! 그럼 .NET 의 세계를 한번 뒤돌아 보도록 합시다.

    Visual Studio .NET 2002 / .NET Framework 1.0

      제품의 버전 / 특징
    2002년
    • Visual Studio .NET 2002 / .NET Framework 1.0
      첫 통합 개발 환경
      발매 당초의 제품명은 ‘ Visual Studio .NET
    • C# 1.0 / Visual Basic .NET (7.0)
      C# 은 마이크로소프트의 새로운 객체 지향 언어
      Visual Basic 도 객체지향 언어


    Visual Studio 와 .NET Framework 의 최초 버전이다. PDC 2000 을 통해 처음으로 Beta 버전이 세상에 공개가 되었습니다. 이 버전을 통해 Managed Code(관리 코드)가 등장 하였고, C# 이라는 객체지향 언어가 출연하였습니다. 그리고 Visual Basic 7.0 이라는 이름으로 Visual Basic 도 객체지향 언어로 탈바꿈 하였습니다. 그리고 현재까지도 특정 버전이 명시되지 않은 Visual Studio.NET 이라는 IDE(통합 개발 도구)도 공개가 되었습니다.

    Visual Studio IDE 를 통해 하나의 개발 툴에서 Web Application, Windows Application, Mobile, XML, XML Web Services 를 쉽게 개발할 수 있게 되었습니다. 그리고 Java 진영의 개발자들을 위한 J# 이라는 Java 와 쉽게 호환이 되는 언어도 제공하였습니다. Visual Studio 를 통해 개발을 단순화하는 핵심 기술에 대한 엑세스를 제공하는 .NET Framework 의 기능을 활용할 수 있습니다.

    .NET Framework 는 응용 프로그램을 빌드하고  실행하는 Windows 의 구성요소로서, ADO.NET, ASP.NET, Windows Forms 등을 포함하는 .NET Framework 클래스 라이브러리와 CLR(Common Language Runtime-공용 언어 런타임) 을 일컫습니다. 이 CLR 을 통해 공통된 API 집합을 만들어 다양한 언어간의 상속, 오류 처리, 디버깅이 가능하며 개발자들은 사용하려는 언어를 자유롭게 선택할 수 있게 되었습니다.


    Visual Studio .NET 2003 / .NET Framework 1.1

      제품의 버전 / 특징
    2003년
    • Visual Studio .NET 2003 / .NET Framework 1.1 (5월)
    • C# 1.1 / Visual Basic .NET (7.1)
      모두 버전 업
    • Windows Server 2003
      .NET Framework 1.1 표준 탑재


    하지만, 첫 출발은 대중들에게 큰 이목을 집중하기에 충분하였지만, 그 행보는 순탄치만은 않았습니다. 왜냐하면, C# 이라는 언어가 Java 의 아류작에 불과하다는 편견과 수많은 버그로 인해 사용자들에게 원성을 사야 했습니다. 그리고 얼마 지나지 않아 새로운 버그 픽스 버전인 Visual Studio.NET 2003 과 .NET Framework 1.1 을 발표하였습니다.

    C# 과 Visual Basic 의 버전을 각각 C# 1.1, Visual Basic 7.1, .NET Framework 1.1 로 버전업 하였습니다. 그리고, Windows Server 2003 제품에 표준으로 탑재하여 .NET Framework 의 확산에 큰 공을 이루게 되었습니다.

    실제로 엔터프라이즈 시장에서 이 버전을 기준으로 많은 기업용 시스템에 도입이 되었습니다. 현재까지도 이 버전을 기준으로 운영이 되는 기업용 시스템이 상당수 존재하고 있으며, 아직까지도 많은 사랑(?)을 받고 있는 버전입니다.

    Visual Studio .NET 2005 / .NET Framework 2.0

    제품의 버전 / 특징
    2005년
    • Visual Studio 2005 / .NET Framework 2.0 (12월)
      ClickOnce 배포
      제네릭 클래스 도입
      ASP.NET 2.0, ADO.NET 2.0, Windows Form 2.0
      리팩토링 기능 / 코드 스니펫
      무료 Express Edition (C#, VB, C++)
    • C# 2.0 / Visual Basic 2005 (8.0)
      제네릭 대응
    • Visual Studio 2005 Team System
    • SQL Server 2005

     .NET Framework 2.0 과 Visual Studio 2005 와 함께 .NET Framework 의 주요 컴포넌트들도 ASP.NET 2.0, ADO.NET 2.0, Windows Forms 2.0, C# 2.0 과 같이 ‘~2.0’ 이라는 버전 번호를 붙였고, 많은 기능이 확장 되었습니다. .NET Framework 2.0 의 주요 컴포넌트들은 더 이상 .NET Framework 1.1 에 의존하지 않게 되었으며, .NET Framework 2.0 은 현재까지도 .NET Framework 의 모태가 되고 있습니다.

    Visual Studio 2005 도 .NET Framework 2.0 의 새로운 기능을 제공하기 위해 외관과 내관이 보다 화려해졌습니다. ClickOnce 배포를 Visual Studio 2005 에서 쉽게 수행할 수 있게 되었으며, 리팩토링(Refectoring)과 코드 스니펫(Code Snippet) 등의 기능이 추가되었으며, 솔루션 파일을 구조적으로 분류하기 위한 솔루션 폴더 등 수많은 기능이 추가되고 개선이 되었습니다.

    C# 2.0 은 기존 C# 1.0 의 Boxing(박싱), Unboxing(언박싱)의 반복적인 캐스팅(Casting) 의 비효율을 개선하고, 보다 객체지향적인 코드 품질을 생산할 수 있는 제네릭(Generic) 이 등장하였습니다.  이와 함께 .NET Framework 클래스 라이브러리에 다수의 제네릭(Generic) 클래스가 추가되었습니다.

    그리고, 이 제품의 버전부터 Visual Studio Team Suite + Team Foundation Server 의 제품을 조합하여 Visual Studio Team System(VSTS) 라는 새로운 개발 패러다임을 .NET 에서도 지원하게 되었습니다. VSTS 를 통해 ALM(Application Lifecycle Management-애플케이션 수명 주기 관리) 을 수행할 수 있게 되었으며, IT 조직의 비지니스 전반의 생산성을 향상 시키고, 사람과 개발 조직의 변화를 가져다 주는 시초가 되었습니다.

    .NET Framework 3.0

    제품의 버전 / 특징
    2006년
    • .NET Framework 3.0 (11월)
      코어 부분은 .NET Framework 2.0 그대로
      WPF(Windows Presentation Foundation)
      WCF(Windows Communication Foundation)
      WF(Windows Workflow Foundation)
      CardSpace
    • Windows Vista
      .NET Framework 3.0 기본 탑재

    .NET Framework 3.0 은 기존 2.0 보다 한층 버전업 되었지만, 그 내용은  .NET Framework 2.0 에 비해 한층 새로워졌습니다. .NET Framework 의 버전업 보다는 전혀 새로운 기술이 대거 등장하게 되었습니다.

    단연, .NET Framework 3.0 의 가장 큰 특징이라면 WPF 를 꼽을 수 있을 것입니다. XAML(Extensible Application Markup Language) 과 함께 WPF 의 출연으로 UX(User Experience) 의 시대 흐름에 진입하게 되었습니다.

    또한, WCF 의 출연으로 여러 가지의 분산 통신 기술이 통합되었습니다. 이전의 Remoting, XML Web Services, MSMQ 등이 하나의 WCF 컴포넌트에서 제공하게 됨으로써 Messaging Model 기반으로 통합할 수 있게 되었습니다.

    Visual Studio 2005 Service Pack 1 / Expression Studio / AJAX.NET

    제품의 버전 / 특징
    2007년
    • Visual Studio 2005 Service Pack 1 (6월)
    • ASP.NET AJAX 1.0 (추가 모듈)
      AJAX Web Application 개발이 용이
    • Expression Blend
      Expression Studio 첫 제품
      WPF 어플케이션의 GUI 구축

    ASP.NET 에서 AJAX 를 지원하기 위한 코드명 “Atlas” 의 정식 이름인 ASP.NET AJAX 1.0 이 릴리즈가 되었습니다. 클라이언트 사이드의 Sys 네임스페이스의 스크립트를 제공하고, 다양한 서버 사이드 모듈과 AJAX Control Toolkit 의 오픈 컨트롤 제공으로 이벤트 기반의 프로그래밍이 가능합니다.

    WPF 도 Expression Blend 의 출시로 UI 작업을 위한 공개 도구인 XamlPad 보다 강력한 기능을 제공하게 되었습니다.

    Visual Studio 2008 / .NET Framework 3.5

    제품의 버전 / 특징
    2007년
    • Visual Studio 2008 / .NET Framework 3.5 (11월 경)
      개발 코드명 ‘Orcas’
      WPF 의 GUI 설계 가능
      Javascript 디버그 기능 및 IntelliSense
      ASP.NET AJAX 표준 탑재
      .NET Framework 2.0, 3.0, 3.5 선택 가능
    • C# 3.0 / Visual Basic 2008 (9.0)
      LINQ 기능
    • SQL Server 2008
    • Windows Server 2008
    • Visual Studio Team System 2008


    이 제품의 가장 큰 특징이라면, C# 3.0 일 것이다. C# 2.0 의 제네릭(Generic) 과 C# 3.0 의 람다식(Labmda Expression), 확장 메서드(Extension Methods) 등의 결정체로 LINQ 가 탄생하였습니다. LINQ 를 통해 강력한 프로그래밍적 쿼리가 가능해졌으며, XML, Database, Object 등의 다양한 데이터 소스(Data Source) 를 통해 동일한 코딩 패턴을 사용하여 질의가 가능해졌습니다.

    WPF 도 Visual Studio 2008 에서 디자이너를 제공하게 되었습니다. 이전의 XamlPad 나 Expression Blend 와 같은 외부 도구의 도움이 없이도 WPF 의 UI 개발이 용이해졌습니다.

    Visual Studio 2008 Service Pack 1 / .NET Framework 3.5 Service Pack 1

    제품의 버전 / 특징
    2008년
    • Visual Studio 2008 SP1 / .NET Framework SP1
      ASP.NET Dynamic Data
      ADO.NET Entity Framework / Data Services (Astoria)
      WCF Atom Pub Services
      클라이언트 프로파일(Client Profile)
    • VSTS
      Windows Server 2008 지원
      SQL Server 2008 지원
      성능 향상 및 개선
    • Visual Studio SDK 1.1 (SP1)
      Visual Studio Shell 재배포 패키지 경량화
      DSL 출력 미리보기 등…
    • Visual C++ 2008
      오피스 리본 스타일 Interface
      고급 GUI 컨트롤 등…


    이번 업데이트는 정말 손가락으로 헤아리기 힘들 정도로 많은 부분에서 기능 개선과 새로운 기능을 제공하고 있습니다. 그렇기 때문에 지면상 요약하기도 굉장히 벅차지 않을까 생각하며, 필자가 월간 마이크로소프트 10월호에 기고한 내용을 참고하기 바랍니다.

    마소10월호 - Visual Studio 2008 서비스 팩 1 알아보기
    http://blog.powerumc.kr/article/2008/10/30/Maso-October-Visual-Studio-SP1.aspx

     

    이처럼 .NET 은 그리 긴 역사는 아니지만, 많은 변화를 거듭하여 발전해왔습니다. 우리가 바라는 이상적인 개발 환경에 아직은 부족한 점도 있습니다만, VSTS 2010 은 그러한 갈증을 해소시켜 줄 수 있는 단비와도 같을 거라고 생각합니다. VSTS 2010 의 출연으로 .NET 4.0 세대 또한 우리가 바라는 최종 결정판이 아니며, 현재 진행형 입니다. 지금과 비교하면 .NET 1.0 은 초라해 보이지만, 그러한 과거를 통해 현재가 존재하고 .NET 4.0 도 거부할 수 없는 현재라는 것입니다.

    참고 문헌
    http://blog.powerumc.kr/article/2007/09/10/DotNet-Framework-AND-Visual-Studio-History.aspx

    저작자 표시 비영리 동일 조건 변경 허락
    신고

    Visual Studio Team System 2010 (CTP10) - 작업 항목 링크

    지난 3년여 동안 VSTS에 대한 많은 프리젠테이션과 세미나, 교육을 하면서 가장 많이 들었던 질문 중 하나가 "작업 항목들을 hierarchy 형태로 표현할 수 있나요?"였습니다.. 그러면, 저의 대답은 항상 같았습니다. "아니요. 하지만, Rosario (VSTS 2010 코드 명)에서는 된다고 합니다." 그러면, 질문한 사람의 얼굴에는 '그것도 안 돼?'하는 실망의 빛이 역력했습니다. 사실, 저도 왜 hierarchy 표현이 안되는지 궁금하긴 했습니다.
     그래서, Visual Studio Team System 2010의 CTP가 나왔을 때 가장 먼저 확인해 본 것이 작업 항목들을 hierarchy 구조로 표현해 보는 것이었습니다. 결론적으로 말하면, '된다'입니다.

    그러면, 어떤 식으로 작업 항목의 hierarchy 구조를 표현하고, 또 어떤 식으로 조회하는지 살펴보겠습니다.

     (참고로 이 글은 Visual Studio Team System 2010 CTP10을 기준으로 작성되었습니다.)


    [작업 항목 링크 추가]

    Team Foundation Server 2010 CTP10 (이하 TFS CTP10)에는 작업 항목을 연결하는 링크 유형이 추가되었습니다. 기존의 TFS 2005/2008에는 링크 유형은 한 개 (Related - Related)였습니다.

    • 작업 항목 링크 유형
      • Parent - Child: 작업 항목을 트리 (tree) 형태로 구성할 때 사용. (MS Excel에서 표현 가능).
      • Predecessor - Successor: 작업 항목의 선행/후행 관계를 표현할 때 사용. (MS Excel, MS Project에서 표현 가능)
      • Related - Related: 위의 두 경우 아닌 단순한 relationship을 표현할 때 사용. 

    작업 항목 링크은 TFS 2005/2008에서처럼 링크 탭에서 추가합니다. 그러나, 링크 유형 별로 컨트롤이 분리되어 있다면 추가할 링크 유형에 맞는 컨트롤에서 링크를 추가해야 합니다 (그림 1 참조).
     

    [그림 1]

    링크 탭에서 Add 버튼을 클릭하면 링크 추가 창이 나타납니다. TFS CTP10에 추가된 작업 항목 링크 유형은 [그림 2]에서 보는 바와 같이 Link Type 항목에 나타납니다. 링크 유형을 선택하면 그 유형의 이해를 돕기위한 그림이 아래쪽에 표현됩니다.

     


    [그림 2]

     링크로 추가할 작업 항목을 선택하고 comment를 입력하는 방법은 TFS 2005/2008과  동일합니다.

     [그림 3]은 작업 항목에 Parent - Child 링크를 추가한 예입니다.


    [그림 3]

    작업 항목의 링크를 추가하는 방법은 링크 창을 사용하는 것 외에도 마이스로 drag&drop한다거나 Outdent, Indent 버튼을 클릭하는 것도 있습니다.

    이 기능은 작업 항목 쿼리 유형 중 Tree of Work Items 만 가능합니다 (작업 항목 쿼리 유형은 아래에 설명되어 있습니다).

    쿼리 결과에서 작업 항목 (A) 하나를 클릭한 후, 다른 작업 항목 (B) 쪽으로 drag&drop하면 A와 B 작업 항목 사이에 Parent - Child 링크가 추가됩니다 (그림 4 참조)

    [그림 4]

    또한, 쿼리 결과에서 작업 항목을 선택한 후, Outdent 버튼을 클릭하면 작업 항목의 레벨이 올라가고 아래에 있는 작업 항목들은 그 작업 항목의 Child로 추가됩니다. 만약, 그 작업 항목이 다른 작업 항목의 Child였다면 Parent였던 작업 항목과 동등한 레벨이 됩니다. Indent 버튼을 클릭하면 Outdent와 반대로 레벨이 내려갑니다.
    Outdent, Indent는 MS Project의 Outdent, Indent와 유사합니다.

     
    [그림 5]

    [작업 항목 링크 컨트롤]

    작업 항목 링크 유형이 추가되면서, 각 유형 별로 컨트롤을 분리할 수 있게 되었습니다. [그림 1]에서는 Parent - Child 링크 유형이 다른 링크 유형과 분리되어 별도의 컨트롤로 정의되었습다. 이처럼 Predecessor - Successor 링크 유형도 별도의 컨트롤로 분리될 수 있습니다.

    아래 Task.xml의 Layout은 [그림 1]의 Implementation 탭을 정의한 것입니다. 

                         <Tab Label="Implementation">
                            <Control Type="LinksControl" Name="Hierarchy" Label="Parents and &amp;Child Tasks:" LabelPosition="Top">
                                <LinksControlOptions>
                                    <WorkItemLinkFilters FilterType="include">
                                        <Filter LinkType="System.LinkTypes.Hierarchy" />
                                    </WorkItemLinkFilters>
                                    <ExternalLinkFilters FilterType="excludeAll"/>
                                    <LinkColumns>
                                        <LinkColumn RefName="System.ID" />
                                        <LinkColumn RefName="System.WorkItemType" />
                                        <LinkColumn RefName="System.Title" />
                                        <LinkColumn RefName="System.AssignedTo" />
                                        <LinkColumn RefName="System.State" />
                                        <LinkColumn LinkAttribute="System.Links.Comment" />
                                    </LinkColumns>
                                </LinksControlOptions>
                            </Control>
                        </Tab>
    [Task.xml]

    작업 항목 링크 유형 별 Reference Name은 다음과 같습니다.

    • Parent - Child: System.LinkTypes.Hierarchy
    • Predecessor - Successor: System.LinkTypes.Dependency
    • Related - Related: System.LinkTypes.Related

    작업 항목 링크 컨트롤을 분리하지 않고 TFS 2005/2008처럼 하나의 컨트롤로 정의를 하려면 예전처럼 정의하면 됩니다.

               <Tab Label="Links">
                <Control Type="LinksControl" LabelPosition="Top" />
              </Tab>

     [그림 6]은 Parent -Child 유형의 링크 컨트롤의 예입니다.


    [그림 6]

    [작업 항목 쿼리]

    작업 항목의 Parent - Child 또는 Predecessor - Successor 관계는 작업 항목 쿼리를 통해 아래와 같이 조회할 수 있습니다 (그림 7, 그림 8 참조). 작업 항목이 hierarchy 구조로 조회되는 것을 확인할 수 있습니다.

    [그림 7]

     

    [그림 8] 

    작업 항목을 hierarchy 구조로 조회할 수 있도록 작업 항목 쿼리 유형이 두 개 추가되었습니다.

    • Flat List of Work Items: 기존의 쿼리 유형
    • Work Items and Direct Links: 작업 항목과 연결된 작업 항목도 같이 조회. 단, 직접 연결된 작업 항목만 조회 (그림 8 참조)
    • Tree of Work Items: 작업 항목과 연결된 작업 항목도 같이 조회. 작업 항목의 hierarchy 구조를 tree 구조로 표현한다 (그림 7 참조)

    작업 항목 쿼리 유형은 쿼리를 작성할 때 선택합니다. 선택한 작업 항목 쿼리 유형에 따라 쿼리를 작성하는 UI가 달라집니다.

    • Flat List of Work Items

    이 유형은 기존의 TFS 2005/2008에서 쿼리를 작성하는 것과 동일합니다.

    [그림 9]

    • Work Items and Direct Links

    이 유형은 작업 항목과 연결된 작업 항목을 조회할 수 있는 서브 쿼리를 작성할 수 있습니다. 서브 쿼리에서는 링크 유형을 선택하여 해당 링크 유형만 조회가 가능합니다.

    [그림 10]

    • Tree of Work Items

    이 유형은 쿼리를 작성하는 것은 TFS 2005/2008과 같지만 쿼리를 실행했을 때 결과는 Tree 구조로 표현되는 것이 다릅니다(쿼리 결과는 그림 7 참조).

    [그림 11]

     
    이상으로 TFS CTP10의 작업 항목 링크 유형과 작업 항목 쿼리 유형에 대해 살펴 보았습니다.

    작업 항목을 hierarchy 구조로 표현할 수 있게 되므로써 얻을 수 있는 장점은 여러가지가 있습니다.

    일단, 작업 항목의 선후 관계나 상하 관계를 직관적으로 알 수 있는 장점이 있습니다. TFS 2005/2008에서는 이런 관계를 명시하기 위해서는 단지 comment에 두 작업 항목의 관계를 입력하는 정도였습니다. 하지만, 그 방법은 comment를 일일이 읽어야 한다는 불편함이 있습니다.

    그리고, MS Project와 연계에 있어서 자연스러워졌다는 점입니다. MS Project에서 작업을 tree 구조로 표현한 것과 작업의 선후 관계를 표현한 것이 그대로 TFS에서도 표현이 가능해졌습니다. 따라서, 두 도구의 작업 sync.가 더욱 쉬워졌습니다.

    예전에는 작업 항목을 hierarchy 형태로 보려면 보고서를 작성해야 했습니다. 이제 보고서를 작성해야 하는 번거로움이 줄어들었습니다.

    앞으로도 블로그를 통해 TFS CTP10에서 새로워진 기능을 중심으로 어떻게 사용하는지, 그리고 그 기능을 통해 어떤 점이 좋아졌는지를 살펴 보겠습니다.

     webmars.

     http://cafe.naver.com/teamsystem


    신고

    Visual Studio Team System(VSTS) 2010 은 현재 CTP 버전이며, 2008년 10월 31에 공개가 되었습니다. 아직 VSTS 2010 CTP 는 Install Version 이 아니며, Virtual PC 의 VHD Image 파일로 제공이 됩니다. 이 Image 는 Windows Server 2008 과 Visual Studio 2010 버전과 함께 Team Foundation Server 2010 버전도 제공이 되며, 모두 사용 가능하도록 설치되어 있습니다.

    Visua Studio Team System 2010 CTP 버전은 아래의 주소에서 다운로드 받을 수 있습니다.
    http://www.microsoft.com/downloads/details.aspx?FamilyID=922b4655-93d0-4476-bda4-94cf5f8d4814&DisplayLang=en

    하지만, 이 VSTS 2010 CTP 버전을 다시 구동시켜 보기 위해 두 가지 문제가 있습니다. 하나는, Windows Server 2008 의 사용 만료와 VSTS 2010 CTP 가 사용 만료가 되었습니다.

    1. Windows Server 2008 사용 만료

       

      이 문제는 Windows Server 2008 Product key 를 입력하여 해결할 수 있습니다. 그리고, Virtual PC Setting 을 통해 Network 가 인터넷에 연결이 되어 있어야 합니다. Product key 를 입력하여 인터넷(또는 다른 방법)을 통해 Windows Activation 할 수 있습니다.

      하지만, 유감스럽게도 Windows Server 2008 Product key 를 가지고 있지 않다면, 달리 VSTS 2010 CTP 를 구동시켜 볼 수 없을 것 같습니다.

    2. Visual Studio Team System 2010 CTP 사용 만료

       

      첫 번째 Windows Server 2008 만료를 해결한 후에 VSTS 2010 CTP 를 실행하면 또 다시, VSTS 2010 CTP 의 사용 기간이 만료가 되었다는 메시지가 보입니다. 그리고 더 이상 VSTS 2010 CTP 를 동작시킬 수 없습니다.

      이 문제는 Virtual Server Settings File 의 설정을 조작하여 Windows 의 날짜를 되돌리는 방법으로 해결할 수 있습니다.

      우선 노트패드 등을 이용하여 VSTS 2010 CTP 의 Image 가 저장된 폴더에, VisualStudio2010CTP.vmc 파일을 열어 XML 의 <mouse> 노드 다음에 아래의 설정을 해줍니다.

      <integration>
          <microsoft>
              <mouse>
                  <allow type="boolean">true</allow>
              </mouse>
              <components>
                  <host_time_sync>
                      <enabled type="boolean">false</enabled>
                  </host_time_sync>
              </components>

      그리고 한 가지 더, Windows 의 시간 동기화를 반드시 해제 하십시오. 그렇지 않으면 Windows 시간이 동기화 되어 반복적으로 VSTS 2010 CTP 사용이 만료되게 됩니다. 아니면, VPC 의 Network 를 해제하셔도 됩니다.


      참고 문헌
      http://blogs.msdn.com/jeffbe/archive/2008/12/09/dealing-with-the-team-system-2010-ctp-expiration.aspx 

    신고