HeeJae's Blog : 2008

VS10에 대한 링크 모음

HeeJae Chang — Sun, 25 Jan 2009 08:46:31 GMT

저희 팀에 Kirill Osenkov이 쓴 blog post인데 정말 유용한 VS10과 C# 4.0에 대한 link가 있습니다. 시간 나시면 꼭 한번 둘러 보세요.

* 그중 가장 첫번째 PDC video 링크들은 정말 엑기스 입니다. C#과 프로그램밍에 관심있으시다면 정말 다 꼭 봐야 할 것들이죠.

수고.

Com Interop과 dynamic에 대한 IDE의 지원

HeeJae Chang — Sun, 25 Jan 2009 07:45:00 GMT

어제 포스트에서 제가 C# 4.0에 새로 지원 되는 주 기능으로 Com interop과 dynamic을 얘기 하면서 그에 대한 IDE의 새 기능을 쓰기로 해 놓고 C# 4.0에서 새로 지원 되는 Compiler 기능만 쓰고 이에 대한 IDE 기능은 전혀 쓰질 않았죠 ㅡ.ㅡ.

이유는 사실 dynamic의 경우 IDE 에서 해 줄수 있는게 별로 없기 때문이기도 합니다.

이 Com Interop이나 dynamic이 C# 언어 쪽에서 본다면 여러 dynamic 언어들을 무척 간단하게 사용할수 있게 해 주는 반면 IDE 쪽에서는 별로 크게 도움을 줄만한게 없습니다. IDE에서 제공 하는 intellisense 라는게 static 한 타입 정보들이 있어야 보여 줄수 있는건데 dynamic 의 경우 다 runtime에 타입들이 정해지는거라 design time에 IDE가 해줄수 있는거라곤 사실 별로 없죠.

그래서 이로 인해 새로 들어간 IDE 기능이라고 해 봤자,

ref 나 optional parameter처럼 생략 할수 있는 정보들의 경우, parameter help 및 그 와 비슷한 곳에서 “[]”로 옵션 항목임을 표시해 줍니다.
No PIA의 경우는 프로젝트 Property 페이지에 아래와 같은 새 옵션이 들어가게 됐구요. 한가지 알아 두셔야 할 것은, No PIA 옵션을 사용할 경우, COM interface에 들어 있는 모든 object 타입이 자동으로 dynamic 타입으로 변환 됩니다.
Named and Optional Parameter의 경우는 method를 정의하거나 부를때 아래처럼 사용할수 사용하실수 있게 됐습니다.
Refactoring 기능들의 경우, 새로운 named and optional parameter 들을 지원 할수 있게 변경 됐습니다. 특히 signature change의 경우는 아래와 같이 새로운 dialog를 갖게 됐구요.
Dynamic invocation의 경우는 아쉽게도 intellisense가 지원되지 않습니다. 다만, 현재 사용하는 expression이 dynamic 구문이라는걸 알려주기 위해 아래처럼 표시를 해줍니다.
QuickInfo의 경우도 역시, 현재 마우스 밑에 있는 구문이 dynamic expression이라는것만 알려줍니다.
Edit and Continue 역시, 현재로써는 method block안에 dynamic invocation 이 있을 경우, EnC를 사용할수 없도록 되어 있습니다.
Refactoring 역시 dynamic member들의 경우 지원 되지 않습니다. Go to definition 역시 지원되지 않구요. 이유는 당연히 design time에 타입이 무엇인지 모르므로, member들 역시 마찬가지구요. 따라서 아무것도 지원되지 않습니다.

아마 이정도가 C# 4.0의 새로운 기능인 COM interop과 dynamic을 위해 새로 들어간 IDE기능들인거 같습니다. 비록 이번 버젼에는 이정도 밖에 지원하지 않지만, 내부적으로는 어떻게 해야 dynamic 타입을 static 정보가 존재 하는 기존 C# construct들 만큼은 정보들을 제공할수 있을까 논의 중입니다. F#의 interactive window와 비슷한 뭐 그런것 말이죠.

그럼 도움 되었음 좋겠네요.

수고.

Extension method 그 최고의 유용성

HeeJae Chang — Mon, 17 Mar 2008 04:43:35 GMT

C# 3.0의 새로운 기능이라 하면 Linq만을 생각 하시는 분들이 많은거 같아, 오늘은 C# 3.0의 새 기능중 내 생각에 가장 유용하다. 아니 적어도 Design 면에서는 가장 유용하다할 Extension method에 대해 써 볼까 한다.

뭐 Extension method가 무엇이냐, 이런건 인터넷에서 쉽게 찾아 볼수 있으니 자세한 설명은 생략하고 그냥 간단한 예제 하나로 대체 하도록 하겠다.

using System;

namespace Examples

{

public static class Extensions

{

// Extension method 정의

public static double GetSqrt(this double d)

{

return Math.Sqrt(d);

}

public class Test

{

public Test()

{

// Extension method 사용

double d = (1.1).GetSqrt();

}

위 구문이 정말 가장 간단한 Extension method의 사용방법이라 하겠다. public static class 정의 후에 public static method를 정의 하고, 그 첫번째 parameter로 this type identifier 하면 되겠다.

사실 이 Extension method는 그 기능 자체만 보자면 별로 특별할것도 없고 이것이 있으므로 해서 전에는 못했던 아주 특별한 뭔가를 할수 있는것도 아니다. 어떻게 보면 이건 단지 기존에 Extensions.GetSqrt(1.1)이라 해야 했던걸 그냥 (1.1).GetSqrt()할수 있게 해주는것 밖에 없다.

하지만 기능 이외에 Design적 관점을 더 하면 말이 달라진다. Extension method의 그 유용성은 Design 면에서 최고의 빛을 발한다. 프로그래머들이 framework를 제작할때 항상 두가지의 상충된 design의 문제로 고민하게 된다. 첫번째는 framework의 심플함과 유연성이고 두번째는 framework 사용의 편리성이다.

첫번째 design 포인트는 프로그래머로 하여금 가장 최소한의 API만을 제공하고 data class와 operation class의 구분을 요구한다. 하지만 두번째 design 포인트는 보다 많은 helper method와 자주 쓰이는 logic은 그냥 framework에서 method call 하나로 알아서 다 처리 해 주길 요구한다.

문제는 이 두개의 design 포인트가 동전의 양면처럼 서로 공존 할수 없다는 점이다. 이전 까지는 항상 framework를 제작할때 이 두개를 어떻게 잘 balance 할것인가가 중요한 문제 였다.

그러나!! Extension method는 이 문제를 정말 깔끔하게 처리해 준다. C# 3.0 이상을 요구 하는 framework는 더 이상 이 balance에 대해 고민할 필요가 없다. framework 자체는 첫번째 디자인 포인트에 맞춰 많은 data class와 data manipulate에 필요한 가장 최소한의 method만을 제공하면 된다.

Design 포인트 2번째는 모두 다 Extension method를 이용해서 만족 시켜 주면 되는것이다.

using System;

using System.Net.Mail;

namespace Examples

{

public class Account

{

public string AccountNumber

{

public get;

private set;

}

public string OwnerName

{

public get;

private set;

}

public string OwnerEmail

{

public get;

private set;

}

public double Balance

{

public get;

private set;

}

public Account(string accountNumber, string ownerName, string ownerEmail)

{

this.AccountNumber = accountNumber;

this.OwnerName = ownerName;

this.OwnerEmail = ownerEmail;

this.Balance = 0;

}

public double Deposit(double amount)

{

Balance += amount;

return Balance;

}

public double Withdraw(double amount)

{

Balance -= amount;

return Balance;

}

public static class TransactionExtensions

{

public static double TransferTo(this Account src, Account dest, double amount)

{

src.Withdraw(amount);

dest.Deposit(amount);

return amount;

}

public static void SendMessage(this Account to, string title, string message)

{

MailMessage message = new MailMessage("me@home", to.OwnerEmail, title, message);

SmtpClient client = new SmtpClient();

client.Send(message);

}

class Test

{

static void Test()

{

Account c = new Account("00001", "you", "you@home");

c.SendMessage("Send Email", "Test Message");

Account dest = new Account("00002", "someone", "someone@home");

c.TransferTo(dest, 1000);

}

위에 예제는 작동하는건 아니고, 그냥 point만 보여 주기 위한 코드다. 위에서 처럼 Account의 내부 정보를 필요로 하는 최소한의 함수만을 class에 남겨두고 그 외의 helper class 들은 Extension method로 옮기면 된다. 이렇게 하면 실제 data class에는 최소한의 API만 남게 되며 helper method 들은 따로 한곳에 모아 둘수 있고, framework의 consumer들은 밑에 Test에서 처럼 쉽게 class들을 이용할수 있게된다.

이 외에도 여러 가지 트릭이 있을수 있는데, 이를테면 같은 데이타 클라스를 다르게 해석하게 할수 있고 (같은 signature의 extension method 지만 implementation이 다른, factory pattern의 변종?), Visitor pattern의 Visit 메서드를 실제 class가 아닌 extension methods로 만들수도 있고, 등등

하여간 C# 3.0에 새로 들어간 여러 가지 기능들이 단지 Linq만을 위한것이 아니다. 이제 C# 4.0에 들어갔는데 아마 이런 유용한 기능들이 4.0에는 더 많이 들어가지 않을까 싶다.

그럼 다음번엔 lamba expression에 대해 함 써볼까 한다. 그때까지 수고!!

Visual Studio 2008의 새로운 intellisense

HeeJae Chang — Sun, 09 Mar 2008 12:20:00 GMT

이번엔 VS 2008의 새로운 기능을 얘기 해 볼까 합니다. 뭐 각 버젼업 마다 새로운 기능을 추가 하는데 이번 VS 2008에서 C# IDE는 사실 C# 3.0의 새로운 기능을 지원 하는데만 거의 모든 시간을 다 사용했습니다. 여기서 C# 3.0의 새로운 기능이라 함은 lambda expression, type inference (var), query expression, object/collection initializer, extension methods, 등등을 말합니다.

위에 나열한 이 새로운 C# 3.0 기능들을 지원하기 위해 사실 저희 팀은 binding을 근본적으로 새로 만들어야 했습니다. VS 2005을 비롯한 그 이전 버젼의 경우, C# IDE의 intellisense는 사실 모든 expression을 이해 한게 아니고, 거의 top level construct들만 이해 했습니다. 쉽게 말하면 어떤 type들이 존재 하는지, 각 타입 에는 어떤 멤버들이 존재 하는지 멤버의 리턴 타입은 뭔지 이런것들은 이해 했지만 expression 레벨로 내려가면 전혀 이해 하지 못했습니다. 예를 들면 (2 + 2) Dot 을 누르면 (2+2)라는 expression을 이해 하지 못하기 때문에 intellisense를 제공 하지 못했습니다.

C# 2.0 까지는 이런게 큰 문제가 되지 않았습니다. 이유는 C# 2.0 까지만 해도 C#이 아주 정적이고 명시적인 언어라 expression 레벨을 지원 하지않아도 프로그램밍 하는데 아주 큰 불편을 주진 않았기 때문이죠. 그런데 이게 C# 3.0으로 완전히 변해 버렸습니다. type inferencing 하나만 가지고도 expression 레벨을 지원 하지 않고는 사용하기가 너무 힘들어 진것이죠. 게다가 query 와 anonymous type 까지 곁들여 준다면.. 기존의 C# intellisense로는 아무것도 할수 없게 된겁입니다. 그래서 VS 2008 에서는 intellisense에 대한 대대적인 보수 작업을 하게 되었습니다.

VS 2005 및 그 이전 버젼의 경우, C# IDE는 IDE 자체가 intellisense를 위한 binding 로직을 가지고 있었습니다. compiler의 binding 로직과는 다른 IDE만을 위한 기능이였죠. 이유야 당연히 compiler와 IDE는 서로 너무 다른 전제 조건을 가지고 있기 때문이죠. IDE의 경우는 99%는 잘못된 코드를 가지고 있고 속도가 정확성 보다 우선순위인데 반해, Compiler의 경우는 99%가 옳은 코드를 가지고 있고 정확성이 속도보다 우선 순위이기 때문이죠. 근데 이게 VS 2008에서 하나로 합쳐졌습니다. 이제 C# IDE의 intellisense의 정보의 정확성은 compiler의 그것과 같아 진것이죠. 물론 그러기 위해서 속도 개선 및 error tolerance 등등 아주 많은 기초 작업이 있었죠.

하여간, VS 2008의 C# IDE 써 보시면 intellisense에서 제공하는 정보가 전보다 확실히 더 정확해 진것을 보실수 있을겁니다.

(1 + 1)을 이해 함은 물론이거니와 new int [] { 1, 2, 3, 4 } 도 이해 하는 ... ㅋㅋ

그럼 수고!!!

Visual Studio 2008 SP1 에 바뀌는 것들

HeeJae Chang — Sat, 08 Mar 2008 23:01:00 GMT

Visual Studio 2008 이 정식 release 된게 몇일 안된거 같긴하지만 ㅡ.0 어차피 내부적으로는 RTM한지 벌써 몇달은 된거 같고 이미 SP1이 마무리 작업 중이다. 하여간 그리 하여 SP에 새로 들어갈 가능성이 있는 (뭐 당연히 실제 release 될때는 완전히 바뀔 가능성도 있다) 기능들에 대해 써 볼까 한다.

첫번째는 User Comment Scanning for Closed file.

이건 가장 많은 사용자들이 원했던 기능중에 하나다. VS 2008과 그 이전 버젼들은 현재 VS에 open 되어 있는 파일들에 대해서만 User Comment를 보여 준다. 이번 SP1에 이 기능이 들어가게 된다. 이제 파일이 열려 있던 닫혀 있던 솔류션에 속해 있는 모든 파일의 User Comment를 보여 준다.

두번째는 Live Squiggle.

아시다 시피, C#은 아직 Live background compile을 지원하지 않는다. 빌드 혹은 semantic 에러를 얻는 유일한 방법은 실제 solution을 Build 하는 방법 밖에 없다. 솔루션이 작을 경우는 별로 큰일이 아니지만 솔루션이 커져 갈수록 단지 현재 파일에 있는 에러를 알기 위해 전체를 컴파일 하는것은 overkill이다.

아직 완벽하진 않지만, 적어도 현재 VS에 Open 되어 있는 파일들과, method 내부에 대해 빌드에러를 live로 보여 주는 기능이 SP1에 들어 가게 된다.

세번째는 bug fix들

뭐 SP니 당연히 그동안 발견한 (뭐 정식 release는 얼마 안됐지만, MSDN을 통한 release는 이미 꽤 돼었다) 버그들에 대한 fix들이 들어가 있다.

뭐…. 생각해 보니 이정도 -.9 쓰고 보니 별로 많은거 같진 않다 -.0

- 수고

Visual Studio 2008의 C# IDE 성능 향상

HeeJae Chang — Sat, 08 Mar 2008 21:12:00 GMT

Visual Studio 2008의 C# IDE 성능 향상

이번 visual studio 2008 C# IDE 에 들어간 몇가지 성능 향상에 대해 쓸까 한다.

물론 모든 성능 향상의 목적은 궁극적으로 C# editor가 좀 더 부드럽고 빠르게 사용자에게 반응할수 있도록 하는거다.

이 궁극적인 목적을 위해 2008에는 2005와 다르게 몇가지 tweak을 했다

첫번째가 navigation bar다. 2005 와 그 이전 버젼의 navigation bar는 언제나 source와 synchronous 하게 작동했다. 사용자가 커서를 움직이지 마자 navigation bar가 거기에 따라 바로 update 되었다. 문제는 파일이 대용량일 경우 이 싱크 작업이 에디터를 잠시 먹통으로 만들수 있다는거다.

물론 이 먹통 문제의 핵심은 첫째, 싱크 작업이 UI Thread에서 된다는 점 둘째, 커서를 움직일때 마다 일어 난다는 점이다. 물론 이 보다 더 많은 내부적인 문제가 있지만 하여간 저 2개가 가장 큰 이유라 하겠다.

2008에서는 그래서 이 navigation bar가 asynchronous 하게 바뀌었다. 2008에서 editor를 사용하다가 느끼신 분들도 있겠지만, navigation bar가 더 이상 커서가 움직일때 마다 업데이트 되지 않는다. 다시 말해서 잠시 내용이 out-of-sync 하고 있다가 잠시 기다리면 sync 된다.

작은 파일에서는 별로 차이를 느낄수 없지만, 파일이 커져 갈수록 이 change하나만 으로도 editor가 휠씬 반응이 빠르다.

두번째 향상은 Designer Attribute scanning 이다. 이게 뭐냐면 Solution explorer에 나와 있는 file들을 보다 보면, 어떤 파일은 form 모양을 한 icon을 가지고 있다. 전에는 이걸 역시나 synchronous한 방법으로 detect 했다. 뭐 자세하게 어떻게 detect 했나는 별로 중요하지 않고 이걸 synchronous한 방법으로 하는 바람에 UI thread가 block 되었다는게 중요하다.

2008에서는 이것도 asynchronous하게 바뀌었다. 작은 솔루션일 경우는 별다른점이 없지만 아주 많은 파일이 가진 솔류션일 경우, icon이 전보다 늦게 변하는것을 볼수 있을꺼다.

세번째 향상은 User Comment scanning이다. 이건 예상하듯이 task list에 TODO 같은 user comment를 보여주는 기능이다. 이건 2005에서 이미 Asynchronous 하게 작동 했다 다만 scanning 할때 불필요 한 작업을 너무 많이 했다. 2008에서는 좀도 최적화된 방법으로 scanning을 하도록 바뀌어 있다.

이밖에도 작은 작은 성능 향상이 여러군데 들어 갔다. 전체 적으로 보면 2005 보다 약 2 배 이상 C# Editor의 성능이 향상 되었다.

뭐 아직 우리가 원하는 수준의 반응성을 가지진 못하지만, 계속 향상 시키고 있으니 VS10에서는 더욱 향상된 성능을 기대 해도 될것이라 본다.

혹 VS2008를 사용할때 C# IDE performance 문제가 있으시다면 여기 피드백 남겨 주시면 감사!!

- 수고

드디어 Orcas 첫번째 코드 마일스톤 들어가다 ...

HeeJae Chang — Sat, 29 Apr 2006 06:21:00 GMT

VS 2005 의 RTM 이후, MQ와 M0를 거쳐 5월 1일 부터 소위 말하는 코드 마일드스톤 M1에 들어간다.

이번 Orcas의 가장 요는 C# 3.0를 compiler와 IDE에서 지원 하는거다. 비록 IDE와 Compiler가 많은 부분 비슷한 작업을 해야 하지만, 둘이 작동하는 기본 환경이 다르기 때문에 Orcas 전에는 두 팀이 각각 다른 코드 베이스를 가지고 있었다

예를 들면, 컴파일러의 경우, 기본 전제는 대부분의 경우 코드가 올바른 형태를 가지고 있다는거다, 그리고 만약 에러가 있을경우, 에러 때리고 끝나면 된다.

그해 반해 IDE의 경우는, 기본 전제가 대부분의 경우 코드가 올바르지 않은 형태를 띄고 있다는거다, IDE의 경우 사용자가 타입을 계속 하는 상황에서 정보를 제공해야 하기때문에, 당연한 거라 생각하지만, 하여간 이런 가장 기본적인 차이로 인해, 서로 공유 하는 코드가 있긴 했지만, 대부분의 경우 서로 각자의 환경에 맞게 따라 구현을 했었다.

컴파일러는 정확한 정보를 제공하는데 중점이라면 IDE의 경우는 사용자 코드에 에러가 있을시 상황에 맞춰 최대한 올라른 정보를 제공하는것이 요 였다.

하지만 이번 Orcas에 들어가면서, 이 두개의 코드 베이스를 하나로 합치는 작업을 진행 중이다. 이유는 C# 3.0에서 제대로된 정보를 IDE에서 제공하기 위해선 IDE 단에서도 최대한 정확한 - Compiler 만큼의 - 정보를 사용자에게 제공해야 하기 때문이다.

하여간 그로 인해 요즘 C# 팀은 시끌 벅적이다. 코드 베이스도 통합 해야 하고 C# 3.0도 지원해야 하고 ...

그냥 이제 바쁜 나날이 시작 될꺼 같아.. 넔두리 써봤다..

수고.!!!