HeeJae's Blog

그외 새로 들어가는 IDE 기능들

2009-01-25T17:41:48Z

전에 쓴 post에 있는 새로운 IDE 기능은 dynamic과 COM interop에 관련되어 새로 추가된 기능들이고, 당연히 이 밖에도 여러가지 새로 VS10에 추가 되는 IDE 기능들이 있습니다. 이번 post에서는 요 기능들에 대해 얘기 할까 합니다.

일단 새로 추가된 기능을 2가지로 분류 한다면, 첫번째는 새로이 들어가는 기능이고, 두번째는 기존의 기능을 향상 시킨것입니다.

일단 새로이 들어간 기능에 대해서 먼저 쓰자면,

Quick Search

solution 네에 정의된 type, member, filename등을 object browser의 find symbol 보다 아주 빠른 속도로 찾아 주는 기능입니다. 일반적으로 몇 초 안에 원하는걸 찾을수 있습니다.

Call Hierarchy

이 기능은 method 간의 caller와 callee를 찾아 주는 기능입니다. method간의 관계를 찾아 보는데 아주 유용하죠. 게다가 기존의 “Find All Reference”로는 할수 없는 Override를 찾는다 던가, 아니면 interface의 implement를 찾을수 있습니다.

Highlight References

이 기능은 같은 파일안에서 동일한 symbol을 화면에 보여 주는 기능입니다. 기존 “Find all reference”이 전체 솔루션에서 같은 symbol을 찾아준다면 이건 동일한 기능을 한 파일에서만 한다고 생각 하시면 됩니다.

Generate from Usage

이 기능은 정의되어 있지 않은 type/constructor/property/enum member 등을 사용하면, 그 type/member를 자동으로 생성해 주는 기능입니다. generate method와 비슷하다고 보시면 됩니다. 이 기능은 소위 말하는 consume first 방식의 프로그래밍을 하시는 분들을 위한 기능입니다.

Co/Contravariance

이 기능은 간단히 말해서 이제 C# 4.0에서 아래와 같이 할수 있다는겁니다.

interface I<in T, out U> { }

class Base { }
class Derived : Base { }

    class Program
    {
        void Test(I<Base, Derived> ib)
        {
            I<Derived, Base> id = ib;
        }
    }

아시다시피, 기존에는 같은 generic type 사이에서만 conversion이 가능했지, 보시는것 처럼 inheritance에 따라서 assign 하는것이 불가능 했엇죠. 이제 interface와 delegate의 경우, generic argument에 한해, 이것을 지원합니다. 또한 언어만 지원하는게 아니고, BCL혹은 mscorlib에 정의되어 있는 interface와 delegate 중, co/contravariance 를 씀으로써 혜택 받을수 있는 타입들은 이번 CLR 4.0에서 co/contravariance를 쓰도록 바뀌었습니다. 예를 들어 IEnumerable 이나 Func 같은것들 말이죠.
보다 자세한 내용은 Covariance and Contravariance in C# 4.0 혹은 Eric Lippert 을 참조 하시기 바랍니다.

뭐 이정도 인거 같고, 기존의 있었던 기능들 중에 발전된것들을 나열하자면

Background errors (live squiggles)

이 기능은 VS 2008 SP1에서 처음 소개된 기능인데, 이번 VS10에서 더욱 다듬어졌습니다.

Refactoring performance

기존에 사용하던 refactoring engine을 vs 2008에서 새로이 개발한 LAF로 교체 하였습니다. 이로 인해 “Find All reference”, “Rename” 과 같은 여러 refactoring 기능들의 성능이 많이 향상 되었습니다. 특히 local variable 같은 경우는 거의 실시간으로 작동하게 되었습니다.
전체 solution을 찾아야만 하는 것도 기존의 engine에 비해 거의 2배 이상 성능 향상이 있었습니다.

refactoring on xml doc comment

밑에 보시는 바와 같이 이제 refactoring operation들이 xml doc comment안에 있는 reference도 찾아낼수 있습니다.

Completion set

기존의 completion set과 달리 존재 하지 않는 타입 혹은 심볼을 사용하더라도 강제로 commit 시키지 않습니다. 대신 builder를 이용하여 존재 하지 않은 symbol을 commit 할수 있게 해줍니다. (아쉽게도 제가 아직 이 기능이 작동하는 VS를 인스톨 하지 않았네요…)

뭐 기능이 향상 된건 이정도 인거 같네요. 이것보다 몇개 더 했던거 같은데, 지금 기억나는건 이게 다네요.

몇 달후에 beta1 아마도 나올테니 관심있으신 분들은 다운 받아서 함 써봐주세요.

그럼 수고.

VS10에 대한 링크 모음

2009-01-25T08:46:31Z

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

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

수고.

Com Interop과 dynamic에 대한 IDE의 지원

2009-01-25T07:45:00Z

어제 포스트에서 제가 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와 비슷한 뭐 그런것 말이죠.

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

수고.

다음 버젼에 새로 추가 되는 기능들 …

2009-01-24T11:18:04Z

안녕하세요, 간만에 포스팅 합니다. 이제 비쥬얼 스튜디오 2008이 릴리지 된지도 일년이 넘어 가네요. 이번 포스팅은 다음버젼의 VS에 들어가게 될 새 기능에 대한 간략한 소개 입니다. 물론 제가 C# IDE 팀이므로 C# IDE에 관계된거만 이겠지만요 하하하.

일단 가장 눈에 띄는게 VS 자체가 WPF로 바뀐겁니다. 물론 슬쩍 보기엔 기존 VS와 다른게 하나도 없어 보이지만, 자세히 보면 editor에서 부터 shell, menu, toolbar 까지 다 WPF로 바뀌었습니다. WPF로 바뀌므로 해서 사용자 분들에게 가는 이익은? 전에 비해 훨씬 다양한 방법으로 data를 visualize 해줄수 있다는거 겠죠. 또한 WPF 성능이 향상 함에 따라 좀 더 많은 부분들이 하드웨어의 도움 받아 더 화면에 그려지게 됨으로써 성능 향상도 기대해 볼수 있겠죠. 뭐 아직 까진 아니지만 하하.

지금 딱 생각나는 다른 점 하나는 WPF 답게 clear type 과 zoom이 기본 지원 된다는거?

그럼 이제 C# IDE 에 대해서 얘기를 하자면, 일단 이번 C# 4.0의 주 포인트는 COM interop 및 dynamic 입니다. C# 1.0이 C# 언어 자체의 파운데이션을 확립하는게 주 였다면 2.0는 generics이 요 였고 3.0은 Linq 였죠. 이번 4.0은 확실한 COM interop 및 dynamic 의 지원입니다.

일단 COM interop부터 얘기를 시작하면, 아시다시피 C#이 .NET 언어이므로 자연스럽게 COM interop을 지원하기는 합니다만, 그 사용 방법이 무척 노가다 였습니다.

예를 들어, 그냥 TLB에서 COM interop interface를 생성할 경우 기대와는 달리 많은 interface들이 strong type이 아닌 object를 입력 혹은 리턴값으로 돌려 주게 됩니다. 따라서 C# 같은 강력한 static type 언어에서 이를 쓰려면 리턴된 object를 원하는 type으로 다시 casting 한 후에 사용하게 되므로 method 하나 부르는데 코드가 한 가득이게 되죠. 또 C# 언어와 COM interface 사이의 괴리로 인해 쓰잘데기 없는 코드를 한가득 써야 했습니다. 예를 들어 COM interface는 overload를 지원하지 않는 대신에 optional parameter와 default value를 지원하지요. 하지만 C#은 이런걸 지원하지 않기때문에 결국 메소드 하나 부르는데 무시 하는 파라메터를 엄청 넣어 부르게 됩니다.

이 모든 것들이 다 C# 이 COM interop에 별로 friendly 하지 않다는 증거들이죠. 이번 C# 4.0의 목표는 바로 이런 모든걸 VB 수준으로 쉽게 COM interop들을 사용할수 있게 하는게 목표 입니다. COM interop의 경우에만 특별히 기존 C#의 언어규칙에서 예외를 사용할수 있게 해 주는거죠.

위에 쓴 예는 아주 간단한것 몇개만 나열한것이고, 실제 이걸 가능하게 하기 위해 새로 들어간 기능들은 아래와 같습니다.

ref의 생략 – COM interop interface를 사용할 경우, parameter 앞의 ref를 생략할수 있습니다.
PIA의 생략 – COM interop interface를 사용할 경우, Primary interop assemblies를 프로그램과 같이 deploy 하지 않으셔도 됩니다. 대신 실제 프로그램에서 사용된 type은 프로그램에 embed 되게 됩니다.
Named and Optional Parameter – method를 정의 하거나 부를때, VB 혹은 C++ 처럼 기본 default 값을 주고 생략할수 있게 하거나, parameter의 위치와 상관 없이 parameter의 이름을 이용해 함수를 부를수 있습니다.
dynamic invocation – 뒤에 좀 더 자세히 설명 하겠지만, 더이상 함수 하나를 부르기 위해 cast에 cast를 할 필요 없이, 그냥 다른 dynamic 언어나 VB 처럼 함수 이름을 써 주면, runtime에 맞는 함수를 찾아서 알아서 불러줍니다.

이 기능들이 한대 어울려지면, COM interop 사용이 기존 C# 코드 사용할때 혹은 VB나 script 언어로 COM 을 사용할때 만큼이나 간편하게 됩니다.

다음 이슈인 dynamic은 사실 Linq와 비슷합니다. Linq가 C# 언어안에서 SQL을 사용하게 하기 위한 거다 생각 하시는 분들도 계실지 모르지만 사실 Linq는 back end의 provider에 상관 없이 C#에서 한가지 syntax로 여러 가지 다양한 data를 manipulate 하게 해주는 framework 같은겁니다. 같은 linq query를 이용해서 object를 query 할수도 있고, sql, xml 혹은 linq provider를 지원 하는 많은 다양한 back end를 사용할수 있게 되는거죠. (예 참조)

그럼 dynamic이 Linq와 비슷하다니 무슨 뜻인가? 예 생각 하신데로 dynamic은 단지 COM interop만을 위한게 아닌 COM interop의 경우와 같이 runtime에 타입 정보를 얻어 dynamic 하게 콜을 할수 있게 해주는 framework 같은겁니다. 좀 더 정확하게 말하면 그 platform은 DLR이고 C#은 그 DLR이 제공해주는 정보를 소비 하게 되는거고 실제 provider들은 DLR을 중심에 두고 작동하게 되는거죠. Linq도 마찬가지 입니다. Linq의 경우 CLR이 그 중심에 있는거죠. framework는 System.Core.dll에 들어 있고.

결론적으로 C# 4.0에서 dynamic이 지원 된다는 말은 COM interop 뿐만 아니라, Silverlight, IronRuby, IronPhyton 같은 언어에서 정의한 타입과 method들을 C#에서 같은 syntax로 사용할수 있다는 말입니다. Linq가 있어서 sql, xml, plinq 와 같은 다양한 데이타 콜랙션들을 같은 syntax로 사용할수 있었듯이 말입니다.

말로만 장대 하게 떠들었는데, 여기 보시면 절대 후회 하지 않으실 link를 몇개 걸어 놓겠습니다. 정확히 감이 안 잡히시는 분들은 한번 보시기 바랍니다.

Anders Hejlsberg가 이번 PDC에서 발표한 동영상 입니다.
- 이분이 바로 C# 및 터보 파스칼, 델파이를 설계하고 만드신 분이죠 하하 강력 추천 입니다.
저희 팀의 PM인 Alex Turner가 dynamic에 대해 PDC에서 데모한 동영상입니다. 앤덜스것에 비해 직관적으로 dynamic이 어떻게 이익이 될수 있는지 알수 있는 동영상입니다.
마지막으로 저희 C# Compiler Team 분들이 dynamic에 대해 자세히 설명하는 동영상입니다.

그럼 재미있으셨으면 좋겠습니다.

수고.

마이크로 소프트 와 애플의 폰트 차이점

2008-12-12T08:27:00Z

그냥 웹 보다 잼난 글을 봐서 함 올려 봅니다..

http://www.joelonsoftware.com/items/2007/06/12.html

내용은. 마이크로 소프트의 폰트와 애플의 폰트는 무엇이 왜 다를까? 뭐 이런 내용 :)

수고

The P-Invoke Interop Assistant

2008-10-02T21:27:47Z

밑에 쓴 글의 연장선상인데, 오늘 RSS 보다가 옆 VB 팀의 jared가 만든 P-Invoke interop assistant라는 툴을 알게 됐는데 www.pinvoke.net 보다 더 쓰기 편한거 같아서 올립니다. channel9 에서 jared가 직접 툴 사용법도 알려주네요. 툴은 여기서 다운 받을수 있습니다.

www.pinvoke.net이 기존 win32 api만 convert 하는걸 알려줬다면, 이 프로그램은 그것 뿐만 아니라 그냥 아무 C++ 코드나 넣으면 C#/VB 코드로 바꿔 주네요.

그럼 도움 되셨으면 좋겠습니다.

수고

- 희제

C# 에서 windows API 쓸수 있는 방법 도와 주는 사이트

2008-09-22T11:11:33Z

웹에 가끔 질문을 올리시는 분들이 계셔서 모르시는 분들에게 도움이 될까 해서 올립니다. 아시다 시피 .NET은 COM 도 지원하지만 그냥 DLL을 직접 콜 하는 방식도 지원합니다. 이걸 PInvoke라고 하지요. 근데 이 PInvoke 이 사용하기가 조금 까다롭습니다. COM처럼 TLB가 있어서 상호간의 마샬이나 콜 방법을 도와 주는것이 있는것도 아니고, 따라서 자동으로 .NET wrapper을 만들어 주는 툴이 있는것도 아니고, 사용하는 사람이 직접 맞는 맵핑을 찾아야 하죠. 완전 시간 허비하며 이리저리 맞을때 까지 해봐야 하는게 일반적 입니다. 물론 spec을 보면 장황한 설명이 있습니다. win32의 경우는 특히 natvie 무슨 타입 형식이 .NET의 무슨 타입과 1:1 대응이 되며, 메모리 structure는 어찌 지정해야 되고 어쩌고 저쩌고. 그걸 다 외우면 기계적으로 맵핑이 다 될꺼 같은데... 아닙니다 . ㅡ.ㅡ.

하여간 그래서, 사람들이 모여서 그 정보를 모아 놓는 곳이 있습니다.

http://www.pinvoke.net 입니다.

여기 가셔서 찾으시는 win32 함수 이름을 맨위 search 박스에 넣고 찾으시면 거의 90% 찾으실수 있을 껍니다. 그 함수를 dllimport 하는 방법 부터, memory structure는 어떻게 해 줘야 하고 marshal 은 어떤 형식으로 해줘야 하는지 또 parameter로 사용되는 타입은 어떻게 지정해야 하는지 등등...

도움이 되셨으면 좋겠습니다.

수고

- 희제

XPerf 새로운 performance profiling 툴

2008-04-04T10:28:00Z

제가 visual studio 2008 performance work 할때 사용한 툴인데 Vista 하 에서만 제대로 작동하긴 하지만, 기존 VS profiling tool과는 비교 할수 없을 정도로 자세한 정보를 제공합니다. 사실 VS profiling 툴은 시간에 따라 각 부위별 performance count가 아닌, 그냥 맨 전체적으로 어떤지만 나오는데, 이건 시간 별 각 단위별로 아주 자세한 정보를 보실수 있습니다.

하여간 제가 이번에 정말 많은 도움을 받은 툴이라 관심있으신 분들은 한번 들여다 보시길.

보다 자세한 정보를 원하시는 분은.. 여기로..

http://blogs.msdn.com/ntdebugging/archive/2008/04/03/windows-performance-toolkit-xperf.aspx

수고!

Extension method 그 최고의 유용성

2008-03-17T04:43:35Z

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

2008-03-09T12:20:00Z

이번엔 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 에 바뀌는 것들

2008-03-08T23:01:00Z

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 성능 향상

2008-03-08T21:12:00Z

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 문제가 있으시다면 여기 피드백 남겨 주시면 감사!!

- 수고

Visual Studio 2005 SP1 에 새로 추가 되는 기능 Web Application Project

2006-08-23T10:36:00Z

Visual Studio 2005 가 릴리지 된지 어언.... 어언... 하여간 좀 됐다. VS 2005 가 릴리즈 된후에 가장 많이 받은 feedback 중 하나가 VS 2005에서 새로 바뀐 웹 프로젝트 방식이 기존 2003 방식과 너무 달라 2003에서 2005로 Migrate 하기가 힘들다는 거였다

소위 Web Site Project 라 불리는 이 새로운 방식은 일반적인 VS project system을 사용하지 않고 php나 asp 처럼 on-demand로 각 페이지를 컴파일 하고 서비스 하는 방법인데, 그 나름의 사용상의 편의점이나 이점이 있다.

문제는 WSP가 WAP 보다 낫다 나쁘다가 아니라, 이 새로운 WSP를 채용하면서 기존의 WAP - Web Application Project의 지원을 아예 안 함으로써 기존 WAP 형태로 많은 코드를 이미 보유 하고 있는 기업/사람들로 하여금 VS 2005를 사용하기 위해선 기존 WAP을 WSP로 무조건 바꾸게 하는것이 문제 였다.

하여간 많은 분들이 이 점을 지적하자 VS 2005가 발표된 이후 Venus team 에서 Add-in 형식으로 VS 2005에서 2003과 같은 WAP 형태의 웹 프로젝트를 사용 가능 하게 하는 AddIn을 발표 하였다.

이번 VS 2005 SP1에서 이 Add-in 형식으로 발표된 기능을 SP1에 집어 넣기로 했다. 다시 말해 SP1 부터 WAP 을 지원하기로 한거다

여기 까지는 우리 팀이 아닌 Venus 팀의 일이라 나도 자세히 모른다 더 자세한 정보는 Venus team의 blog를 읽어 보기 바란다.

하여간, 이렇게 SP1에 부터 web application project 형태의 웹 프로젝트를 지원하기로 함으로써 우리 C# IDE 팀도 WAP 형태의 프로젝트에 맞게 몇가지 수정을 해야 하는데. 현재 아직 어떻게 할지 결정이 안난 상태다.

일단 문제가 무엇이냐면. 이 새로운 WAP 에서는 aspx 파일에 <script></script> 불록 안에 들어 있는 코드에 대해 몇가지 지원 되지 않는 기능이 있다.

첫째는 aspx 파일 안에는 Find All reference가 작동 하지 않게 된다, 두번째는 rename refactoring 기능이 작동하지 않게 된다. 세번째는 Go to Definition이 소스 파일로 가는게 아니라 메타 데이타로 가게 된다.

이유는 WAP 시스템이 내부적으로 작동하는 방식 때문인데 알다 시피 WAP은 VS 2003 버젼에서 쓰던 시스템이고 그때 까지는 모든 reference가 metadata reference 였다. 다시 말해 솔루션 안에 2개의 C# 프로젝트 간에 reference를 추가 하더라도 이건 project to project의 reference가 아닌, project to metadata reference 였다.

이번 2005에 들어가면서 새로 도입된 기능이 project to project 기능인데, 이 기능이 들어 가면서 사용자가 다른 project에서 정의 된 타입에 대해 go to definition을 하게 되면 자동으로 그 소스 파일을 열어 IDE에 보여줄수 있게 된거다.

하지만 이 WAP은 여전히 VS 2003 형태의 시스템을 사용하게 됨으로써, code behind 파일이 metadata reference로 aspx 파일에 전달 되게 되고, 이렇게 됨으로써 위에 말한 여러 기능들을 사용할수 없게 되는거다.

VS 2003과 비교해서 더 나뻐지는건 없지만 VS 2005에 새로 들어간 여러 가지 기능들을 쓸수 없게 된다.

어떻게 결론 날진 모르겠지만, 하여간 몇가지 안되는 기능들이 있더라도, WAP 형태로 웹을 쓰시고 싶으신 분들은 SP1 을 이용하시면 2003과 똑같은 작업 환경을 이용하실수 있을꺼 같다.

수고...

비주얼 스튜디어 2005 SP1

2006-05-03T07:51:00Z

오늘 한참 노가다 작업을 하고 있는데, 버그가 뭉태기로 나한테 할당 됐다 ㅡ.ㅡ 아 내가 또 뭐 잘못 건드렸나 싶어 놀란 가슴을 쓸어내리면 봤더니 SP1 에 픽스 하기로 결정된 버그들이 뭉태기로 나한테 할당 되었다 ㅡ.ㅡ

뭐 어차피 MQ 동안 픽스된 버그를 vs 2005 코드 베이스로 포팅만 하면 되는거라 별로 큰 일은 아니지만, 새로운 버젼인 Orcas 작업을 하고 싶었는데.. 이것 처리 할동안 좀 기다려야 되게 생겼다.

...

아마도 새 VS 버젼에 FormatEngine 부분을 담당하게 될꺼 같다. 이번에 새로 들어가는 C# 3.0 Linq의 포맷을 지원하는거다.

뭐, Orcas의 타임 라인이 너무 짧아서, 아마도 아주 단순한 포맷만 지원 하는게 목표인거 같은데, 어찌 결정 될지는 기다려 봐야겠다.

...

나중에 SP1에서 픽스될 버그들 소개하는 글이나 써야겠다

수고!!

로컬리제이션 버그

2006-05-03T07:38:00Z

그제 어제는 일본어 로컬리제이션 버그 때문에 골머리를 앓았다. 별로 큰 버그도 아닌데, 로케일에 따라 변하는게 많다 보니까 버그를 픽싱 하는것도 아니고, 버그 픽스를 하기 위한 셋업 하는데 거의 대부분의 시간을 허비 했다 ㅡ.ㅡ

여기 와서 느낀 건데, 워낙 프로그램의 크기가 방대 하다 보니까, 작은 프로젝트 할때는 별것도 아닌 일들에 많은 시간을 잡아 먹힌다.

이를테면, 워낙 많은 팀들이 동시에 작업을 하다 보니까, 하나의 branch에서 모든 작업을 하는게 아니라, 각 PU마다, 각 팀마다, 각 feature crew 마다 가장 위의 main branch로 부터 파생된 branch에서 작업을 하게 된다

가장 이상적으로 각자의 branch에서 작업을 할 경우는 프로그램밍에만 신경을 쓰면 되지만, 일단 이 이상적인 환경 밖으로 벗어 나는 경우, 온갖 복잡한 문제에 직면하게 된다..

이번 버그 처럼 우리의 branch가 아닌 main에서 부터 내려온 로컬리제이션 버그의 경우, 일단 내 branch에서 나와서 main branch 에 enlist를 한후에 작업을 해야 한다. 그럼 단지 main branch에 enlist 하면 되는가, 아니다, 아직 VS가 side by side를 지원 하지 않는 관계로, 픽스를 시도 할때 마다, 새로 컴파일된 component를 현재 작업 중인 branch로 카피를 해 와서 확인을 하던지, 아니면 main branch에서 나온 VS를 새로 깔던지 해야 한다.

그럼 카피만 하면 되는가? 아니다, 각 branch마다 따로 작업을 하기 때문에 운이 좋아 바뀐 인터페이스가 없다면, 작동 하는경우도 있지만 아닌경우, 어디서 작업을 해서 어디로 fix를 포팅 할지, 어떤 VS를 죽이고 어떤 VS를 써야 할지, 온갖 프로그램밍 하고는 상관 없는 문제에 부딪히게 된다.

그럼 어떻게든 픽스만 만들면 되는가? 이거 처럼 다른 브랜치에서 작업을 하거나 그 브랜치에서 픽스를 확인 하는 경우, 다시 현재 우리 branch에서도 fix가 유효한지 확인 해봐야 한다.. 말은 쉬운거 같지만, 정말 노가다다 ㅡ.ㅡ

뭐든 그렇지만, 역시 덩어리가 커지면 커질수록, 본꺼 외에 들어가는 노력이 많아 지는거 같다.

하여간, 오늘 하도 노가다를 많이 해서 (이리 저리 포팅하고, 픽스 하고 확인 하고 .. ), 피곤해서 함 넔두리 써봤다

수고!!