Control template 과 관련한 내용입니다.


WPF_Control_Template.pdf


'Programming > .NET' 카테고리의 다른 글

WPF IScrollInfo  (0) 2019.02.17
[ 번역 ] .NET 에서 클래스를 선택할까? 구조체를 선택할까?  (0) 2016.02.12
[ 7 ] Style  (0) 2012.10.22
[ 6 ] WPF Content Model  (0) 2012.10.19
[ 5 ] DataTemplate  (0) 2012.10.17
[ 4 ] DataBinding  (0) 2012.10.14
[ 3 ] Dependency property.  (0) 2012.10.11
[ 2 ] XAML  (0) 2012.10.10
[ 1 ] WPF Architecture.  (0) 2012.10.08
[ 6 ] Proerty, indexer, attribute  (0) 2012.10.05

WPF style 에 대한 내용입니다.


WPF_Style.pdf


'Programming > .NET' 카테고리의 다른 글

WPF IScrollInfo  (0) 2019.02.17
[ 번역 ] .NET 에서 클래스를 선택할까? 구조체를 선택할까?  (0) 2016.02.12
[ 8 ] Control Template  (0) 2012.10.24
[ 6 ] WPF Content Model  (0) 2012.10.19
[ 5 ] DataTemplate  (0) 2012.10.17
[ 4 ] DataBinding  (0) 2012.10.14
[ 3 ] Dependency property.  (0) 2012.10.11
[ 2 ] XAML  (0) 2012.10.10
[ 1 ] WPF Architecture.  (0) 2012.10.08
[ 6 ] Proerty, indexer, attribute  (0) 2012.10.05

WPF customization 을 위해서는 반드시 알아야할 content model.



WPF_Content_Model.pdf


'Programming > .NET' 카테고리의 다른 글

WPF IScrollInfo  (0) 2019.02.17
[ 번역 ] .NET 에서 클래스를 선택할까? 구조체를 선택할까?  (0) 2016.02.12
[ 8 ] Control Template  (0) 2012.10.24
[ 7 ] Style  (0) 2012.10.22
[ 5 ] DataTemplate  (0) 2012.10.17
[ 4 ] DataBinding  (0) 2012.10.14
[ 3 ] Dependency property.  (0) 2012.10.11
[ 2 ] XAML  (0) 2012.10.10
[ 1 ] WPF Architecture.  (0) 2012.10.08
[ 6 ] Proerty, indexer, attribute  (0) 2012.10.05

DataTemplate 과 관련한 내용입니다.


WPF_DataTemplate.pdf


'Programming > .NET' 카테고리의 다른 글

WPF IScrollInfo  (0) 2019.02.17
[ 번역 ] .NET 에서 클래스를 선택할까? 구조체를 선택할까?  (0) 2016.02.12
[ 8 ] Control Template  (0) 2012.10.24
[ 7 ] Style  (0) 2012.10.22
[ 6 ] WPF Content Model  (0) 2012.10.19
[ 4 ] DataBinding  (0) 2012.10.14
[ 3 ] Dependency property.  (0) 2012.10.11
[ 2 ] XAML  (0) 2012.10.10
[ 1 ] WPF Architecture.  (0) 2012.10.08
[ 6 ] Proerty, indexer, attribute  (0) 2012.10.05

DataBinding 에 대한 내용을 정리.


WPF_DataBinding.pdf


DataBindingLab.zip


'Programming > .NET' 카테고리의 다른 글

[ 번역 ] .NET 에서 클래스를 선택할까? 구조체를 선택할까?  (0) 2016.02.12
[ 8 ] Control Template  (0) 2012.10.24
[ 7 ] Style  (0) 2012.10.22
[ 6 ] WPF Content Model  (0) 2012.10.19
[ 5 ] DataTemplate  (0) 2012.10.17
[ 3 ] Dependency property.  (0) 2012.10.11
[ 2 ] XAML  (0) 2012.10.10
[ 1 ] WPF Architecture.  (0) 2012.10.08
[ 6 ] Proerty, indexer, attribute  (0) 2012.10.05
[ 5 ] Delegate and event.  (0) 2012.10.02

Dependency property 에 대한 내용입니다.


WPF_DependencyProperty.pdf


'Programming > .NET' 카테고리의 다른 글

[ 8 ] Control Template  (0) 2012.10.24
[ 7 ] Style  (0) 2012.10.22
[ 6 ] WPF Content Model  (0) 2012.10.19
[ 5 ] DataTemplate  (0) 2012.10.17
[ 4 ] DataBinding  (0) 2012.10.14
[ 2 ] XAML  (0) 2012.10.10
[ 1 ] WPF Architecture.  (0) 2012.10.08
[ 6 ] Proerty, indexer, attribute  (0) 2012.10.05
[ 5 ] Delegate and event.  (0) 2012.10.02
[ 4 ] Classes and structs  (0) 2012.09.27

XAML overview 와 compilation.


WPF_XAML.pdf


'Programming > .NET' 카테고리의 다른 글

[ 7 ] Style  (0) 2012.10.22
[ 6 ] WPF Content Model  (0) 2012.10.19
[ 5 ] DataTemplate  (0) 2012.10.17
[ 4 ] DataBinding  (0) 2012.10.14
[ 3 ] Dependency property.  (0) 2012.10.11
[ 1 ] WPF Architecture.  (0) 2012.10.08
[ 6 ] Proerty, indexer, attribute  (0) 2012.10.05
[ 5 ] Delegate and event.  (0) 2012.10.02
[ 4 ] Classes and structs  (0) 2012.09.27
Extension Methods  (0) 2012.09.26

'Programming > .NET' 카테고리의 다른 글

[ 6 ] WPF Content Model  (0) 2012.10.19
[ 5 ] DataTemplate  (0) 2012.10.17
[ 4 ] DataBinding  (0) 2012.10.14
[ 3 ] Dependency property.  (0) 2012.10.11
[ 2 ] XAML  (0) 2012.10.10
[ 6 ] Proerty, indexer, attribute  (0) 2012.10.05
[ 5 ] Delegate and event.  (0) 2012.10.02
[ 4 ] Classes and structs  (0) 2012.09.27
Extension Methods  (0) 2012.09.26
[ 3 ] .NET Garbage Collection.  (0) 2012.09.25

Property, indexer, attribute 에 대해서 MSDN 을 요약하면서 보충한 내용입니다.


CS_PropertyIndexerAttribute.pdf


PropertyIndexerAttribute.zip


'Programming > .NET' 카테고리의 다른 글

[ 5 ] DataTemplate  (0) 2012.10.17
[ 4 ] DataBinding  (0) 2012.10.14
[ 3 ] Dependency property.  (0) 2012.10.11
[ 2 ] XAML  (0) 2012.10.10
[ 1 ] WPF Architecture.  (0) 2012.10.08
[ 5 ] Delegate and event.  (0) 2012.10.02
[ 4 ] Classes and structs  (0) 2012.09.27
Extension Methods  (0) 2012.09.26
[ 3 ] .NET Garbage Collection.  (0) 2012.09.25
[ 2 ] C# Types  (0) 2012.09.25

Delegate 와 event 에 대해 정리한 글입니다.


CS_delegate_event.pdf


DelegateAndEvent.zip


'Programming > .NET' 카테고리의 다른 글

[ 4 ] DataBinding  (0) 2012.10.14
[ 3 ] Dependency property.  (0) 2012.10.11
[ 2 ] XAML  (0) 2012.10.10
[ 1 ] WPF Architecture.  (0) 2012.10.08
[ 6 ] Proerty, indexer, attribute  (0) 2012.10.05
[ 4 ] Classes and structs  (0) 2012.09.27
Extension Methods  (0) 2012.09.26
[ 3 ] .NET Garbage Collection.  (0) 2012.09.25
[ 2 ] C# Types  (0) 2012.09.25
[ 1 ] .NET Framework 4.0 소개.  (0) 2012.09.20

MSDN 의 내용을 요약하면서 보강한 PT 입니다.


http://msdn.microsoft.com/en-us/library/ms173109(v=vs.100).aspx


CS_Class_Structure.pdf


'Programming > .NET' 카테고리의 다른 글

[ 4 ] DataBinding  (0) 2012.10.14
[ 3 ] Dependency property.  (0) 2012.10.11
[ 2 ] XAML  (0) 2012.10.10
[ 1 ] WPF Architecture.  (0) 2012.10.08
[ 6 ] Proerty, indexer, attribute  (0) 2012.10.05
[ 5 ] Delegate and event.  (0) 2012.10.02
Extension Methods  (0) 2012.09.26
[ 3 ] .NET Garbage Collection.  (0) 2012.09.25
[ 2 ] C# Types  (0) 2012.09.25
[ 1 ] .NET Framework 4.0 소개.  (0) 2012.09.20

Googling 을 하다가 난감한 용법을 만나게 되었다.


    void Foo( this MyClass arg );


대체 method 의 parameter 에 this qualifier 를 붙이는 것이 무슨 의미일까 고민하다가, 결국에는 다시 googling 을 했다.

어떤 고마우신 분이 이 주제에 대해서 blogging 을 했고, 이를 Extension Methods 라고 부른다는 것을 알게 되었다.


아래쪽의 예제를 보면 이것이 얼마나 강력한 기능인가를 알 수 있으며, .NET 언어들이 가지는 확장성에 놀라게 된다.


New "Orcas" Language Feature : Extension Methods.


자세한 내용은 위의 링크를 참조하기 바란다. 여기에서는 일부분만 번역하고 요약하도록 하겠다.




Extension Method 란?


Extension method 는 개발자가 현재 존재하는 CLR type 의 public contract 에 새로운 method 를 추가할 수 있도록 해 주는데, 이 때 그것을 sub-classing 하거나 원래 type 을 recompile 할 필요가 없다. Extension method 는 오늘날의 동적 언어들에서 유명하게 지원하는 "duck typing" 의 유연성을 strongly-typed language 의 성능 및 compile-time 유효화와 합쳐질 수 있도록 한다.

Extension Method 는 여러 가지 유용한 시나리오를 가능하게 하며, "Orcas" 릴리즈의 일부로 .NET 과 함께 소개된 LINQ query framework 를 정말 강력하게 만드는데 도움을 준다.


예제


String 변수가 유효한 이메일 주소인지를 확인하고자 한다고 하자. 당신은 아마도 ( static method 를 가진 ) 서로 다른 클래스를 구현하게 될 것이다.


    string email = Request.QueryString["email"];
    if ( EmailValidator.IsValid(email) ){   }


새로운 "extension method"를 사용하면, 유용한 "IsValidEmailAddress()" method 를 String 클래스 자체에 추가할 수 있다. 그리고 코드를 다음과 같이 작성할 수 있다.


    string email = Request.QueryString["email"];
    if ( email.IsValidEmailAddress() ){   }


새로운 IsValidEmailAddress() method 를 현존하는 String type 에 어떻게 추가할까? 우리는 static method 를 포함하는 static class 를 다음과 같이 정의한다.


    public static class ScottGuExtensions
    {
        public static bool IsValidEmailAddress(this string s)
        {
            Regex regex = new Regex(@"^[\w-\.]+@([\w-]+\.)+[\w-]{2,4}$");
            return regex.IsMatch(s);
        }
    }


'Programming > .NET' 카테고리의 다른 글

[ 4 ] DataBinding  (0) 2012.10.14
[ 3 ] Dependency property.  (0) 2012.10.11
[ 2 ] XAML  (0) 2012.10.10
[ 1 ] WPF Architecture.  (0) 2012.10.08
[ 6 ] Proerty, indexer, attribute  (0) 2012.10.05
[ 5 ] Delegate and event.  (0) 2012.10.02
[ 4 ] Classes and structs  (0) 2012.09.27
[ 3 ] .NET Garbage Collection.  (0) 2012.09.25
[ 2 ] C# Types  (0) 2012.09.25
[ 1 ] .NET Framework 4.0 소개.  (0) 2012.09.20

.NET 의 garbage collection 을 정리한 내용입니다. http://msdn.microsoft.com/en-us/library/hh156531.aspx 에 기반하고 있습니다.


NET_Garbage_Collection.pdf


'Programming > .NET' 카테고리의 다른 글

[ 4 ] DataBinding  (0) 2012.10.14
[ 3 ] Dependency property.  (0) 2012.10.11
[ 2 ] XAML  (0) 2012.10.10
[ 1 ] WPF Architecture.  (0) 2012.10.08
[ 6 ] Proerty, indexer, attribute  (0) 2012.10.05
[ 5 ] Delegate and event.  (0) 2012.10.02
[ 4 ] Classes and structs  (0) 2012.09.27
Extension Methods  (0) 2012.09.26
[ 2 ] C# Types  (0) 2012.09.25
[ 1 ] .NET Framework 4.0 소개.  (0) 2012.09.20

CTS( Common Type System ) 와 관련한 내용을 위주로 정리했습니다. MSDN 의 Types section 을 요약하면서 내용을 보충한 것입니다.

CS_Types.pdf

'Programming > .NET' 카테고리의 다른 글

[ 4 ] DataBinding  (0) 2012.10.14
[ 3 ] Dependency property.  (0) 2012.10.11
[ 2 ] XAML  (0) 2012.10.10
[ 1 ] WPF Architecture.  (0) 2012.10.08
[ 6 ] Proerty, indexer, attribute  (0) 2012.10.05
[ 5 ] Delegate and event.  (0) 2012.10.02
[ 4 ] Classes and structs  (0) 2012.09.27
Extension Methods  (0) 2012.09.26
[ 3 ] .NET Garbage Collection.  (0) 2012.09.25
[ 1 ] .NET Framework 4.0 소개.  (0) 2012.09.20

원문 : Introducing the .NET Framework 4.0

주의 : 번역이 개판이므로 반드시 원문을 참조하십시오.

주의 : 가독성을 높이기 위해 잘 알려진 용어나 발음이 유사한 용어는 한글로 표기합니다.

주의 : 허락받고 번역한 것이 아니므로 언제든 내려갈 수 있습니다.


Introducing the .NET Framework 4.0.


Visual Basic 2010 개발자로서, 당신은 응용프로그램을 향상시킬 수 있는 개념과 기술에 대해 이해할 필요가 있다; Microsoft .NET Framework 가 그것이다. .NET Framework( 혹은 단순하게 .NET 이라 부르기도 함 )는 당신이 생성하려고 하는 차세대 응용프로그램을 만들기 위한 기반을 제공한다. 비록 .NET Framework 의 모든 관점에 대해서 다루는 것은 불가능하지만, 이 장에서 당신은 .NET Framework 구조에 대한 기본, 그것이 단순한 platform 이 아닌 이유, 그리고 Base Class Library 및 도구들에 대한 개념에 들을 배우게 된다. 이 장은 이 책의 나머지 부분에서 전반적으로 사용하게 되는 중요한 개념과 기술에 대해서도 소개한다.


What Is the .NET Framework.


Microsoft .NET Framework 은 복잡한 기술인데, 이는 차세대 응용프로그램들을 빌드하고, 실행하고, 관리하기 위한 기반을 제공한다. 레이어를 가지고 표현해 보면, .NET Framework 는 Microsoft Windows 운영 체제와 당신의 응용프로그램 사이에 위치한 레이어이다. .NET 은 platform 이지만, 기술( technology )로서 정의되어 있기도 하다. 왜냐하면 그것은 운영체제와 관련이 있는  라이브러리, 실행 도구, 관계 및 통합과 같은 부분들을 포함하고 있기 때문이다. Microsoft Visual Studio 2010 은 새로운 버전의 .NET Framework 4.0 에 의존한다. Visual Basic 2010, C# 4.0, F# 2010 과 같은 것들은 .NET Framework 에 의존하는 .NET 언어이며, 이들은 .NET Framework 4.0 을 위한 응용프로그램을 빌드할 수 있다. 이 새로운 버전의 기술은 몇 가지 중요한 기능을 소개하는데, 그것들에 대해서는 나중에 설명할 것이다. 이 장에서 당신은 .NET Framework 에서 가장 중요한 기능들에 대해 훓어 볼 것이고, 이를 통해 당신은 Visual Basic 2010 을 사용해서 빌드된 응용프로그램이 빌드되고 실행되는 방법에 대해서 알게 될 것이다.


Where Is the .NET Framework.


Microsoft Visual Studio 2010 을 설치할 때, 설치 프로세스는 .NET Framework 4.0 을 설치한다. .NET 은 %windir%\Microsoft\Framework\4.0 이라는 이름의 폴더에 설치된다. 만약 이 폴더를 Windows Explorer 로 열어 본다면, 당신은 하위 폴더들과 라이브러리들, 그리고 실행 도구들을 찾아볼 수 있다. 대부분의 DLL 라이브러리들은 Base Class Library 를 구성한다. 반면에 대부분의 실행 도구들은 서로 다른 종류의 작업들을 Visual Studio 2010 에 의해 실행된다. 하지만 그것들을 커맨드라인에서 실행할 수도 있다. 이 장의 뒷 부분에서 우리는 Base Class Library 에 대해서 설명하고, 그 도구들에 대한 개관을 제공할 것이다; 지금은 Vbc.exe 라는 이름을 가진 파일의 위치만 알고 있으면 된다. 그 파일은 Visual Basic Compiler 이며 커맨드라인 도구이다. 대부분의 경우에 당신은 직접 Visual Basic Compiler 를 실행할 필요가 없다. 왜냐하면 당신은 Visual Basic 응용프로그램들을 Visual Studio 2010 내부에서 작성하여 빌드할 것이며, IDE 가 당신을 위해서 컴파일러를 실행할 것이기 때문이다. 그러나 당신이 Windows 의 노트패드를 사용해 매우 복잡한 응용프로그램을 만들고 나서 Vbc 를 실행할 수 있다는 것을 언급해둘 필요는 있다. 마지막으로 .NET Framework 4.0 은 Microsoft 로부터 무료로 얻을 수 있다는 것도 언급해 둘 필요가 있다. 이는 Visual Basic 컴파일러도 .NET 과 함께 무료로 제공된다는 것이며, 이는 2002 년에 처음 릴리즈되었던 버전으로부터 이어진 .NET 개발을 특별하게 만들어 주는 철학이다.


The .NET Framework Architecture.


.NET Framework 의 구조를 더 잘 이해하기 위해서는, 그것을 레이어로 형태의 구조로 생각하라. 그림 1.1 은 .NET Framework 4.0 의 구조를 고수준에서 표현한 것을 보여 준다.


그림 1.1 .NET Framework 4.0 구조.


첫 번째 level 은 운영체제이다; .NET 레이어는 시스템과 응용프로그램 사이에 위치한다. 두 번째 level 은 Common Language Runtime( CLR )인데, 이는 대부분의 작업을 처리하는 .NET Framework 의 일부이다. 우리는 이 장의 뒷 부분에서 CLR 에 대해서 논의할 것이다. 다음 level 은 Base Class Library( BCL )인데, 이는 응용프로그램을 생성할 때 당신의 코드와 Visual Basic 에 의해서 사용될 수 있는 모든 .NET 오브젝트들을 제공한다. BCL 은 WPF, Windows Forms, ASP.NET, WCF 등과 같은 응용프로그램을 빌드하면서 사용하는 몇 가지 .NET 기술들에 대한 기반을 제공하기도 한다. 마지막 level 은 이전 레이어들에 의존하는 응용프로그램을 의미한다.


이전 버전과의 차이점.

당신이 Visual Basic 2008 에서 Visual Basic 2010 으로 업그레이드했다면, 가장 큰 차이점은 .NET 4.0 이 standalone infrastructure 라는 것을 깨닫게 된다는 것이다. .NET Framework 3.5 는 이전에 설치된 .NET 2.0 과 .NET 3.0 을 필요로 하는 incremental framework 이었다는 것을 기억할 것이다. 예를 들어 LINQ 는 .NET 3.5 의 일부이지만, WPF 는 .NET 3.0 의 일부이며, Windows Forms 는 .NET 2.0 의 일부이다( 그림 1.2 를 보라 ). .NET 4.0 을 사용하면 이러한 incremental structure 가 사라진다. 그리고 모든 framework, BCL, 그리고 도구들이 새로운 버전의 일부가 된다.


그림 1.2. .NET Framework 3.5 SP1 의 incremental architecture.



BCL 에 의해 노출되는 다양한 framework 들이 이 책에서 나중에 논의되지만, 이 장에서는 라이브러리에 대한 개관을 보게 될 것이고, 그것들이 작동하는 방식과, 당신이 그것을 사용하는 방법에 대해서 이해할 수 있을 것이다. 그러나 BCL 을 테스트해 보기 전에, Common Language Runtime 을 살펴 보자.


The Common Language Runtime.


이름이 의미하고 있듯이, Common Language Runtime 은 모든 .NET 언어들에 대한 공통적인 기반( infrastructure )를 제공한다. 이 기반은 응용프로그램의 실행을 제어할 책임이 있고, 메모리 관리나 시스템 리소스에 대한 접근, 보안 서비스 등과 같은 작업들을 관리할 책임이 있다. 이러한 종류의 공통 기반은 서로 다른 Win32 프로그래밍 언어들과의 차이를 메꾸는 가교 역할을 한다. 왜냐하면 모든 .NET 언어들은 같은 기능을 가지기 때문이다. 더우기 Common Language Runtime 은 응용프로그램이 관리되는( managed ) 환경에서 실행될 수 있도록 해 준다. "관리되는"이라는 용어는 .NET 개발에서 기본적인데, 다음 절에서 설명한다.


Writing Managed Code.


Visual Studio 2010 개발에 대해서 이야기할 때, 더욱 일반적으로는 .NET 개발에 대해 이야기할 때, 당신은 managed code 를 작성하는 것에 대해서 자주 들었을 것이다. 첫 번째 버전의 .NET 이전에( 혹은 아직 .NET 개발 환경이 아닐 때 ), 개발자가 시스템 리소스와 운영 체제와 상호작용하기 위한 책임을 가지는 유일한 사람이었다. 예를 들어 운영 체제의 일부에 접근하거나 오브젝트들을 위한 메모리 할당을 관리하는 것을 고려하는 것은 개발자가 고려해야만 하는 작업이었다. 다르게 표현하면, 응용프로글매은 시스템과 직접적으로 상호작용하지만, 당신이 쉽게 이해할 수 있듯이 이러한 접근은 보안 이슈뿐만 아니라 위험할 수도 있는 피해들 때문에 큰 제약을 가지고 있다. 대신에 .NET Framework 은 관뢰되는 환경을 제공한다. 이는 응용프로그램이 운영체제가 아니라 .NET Framework 과 통신한다는 것을 의미하며, .NET 런타임은 응용프로그램의 실행 뿐만아니라, 메모리 관리, 리소스 관리, 시스템 리소스들에 대한 접근까지 관리할 책임이 있다. 예를 들어 Common Language Runtime 은 만약 응용프로그램이 .NET 보안 영역에 따라 완전히 신뢰되는( full-trusted ) 것으로 간주되지 않으면, 그것이 특정 시스템 리소스에 접근하는 것을 방지할 수 있다.


시스템에 연결.

당신은 여전히 운영체제와 직접적으로 상호작용할 수 있다. 예를 들어 Windows API 를 실행하는 것이다( 이는 Platform Invoke 나 P/Invoke 라고 알려져 있기도 하다 ).  이 기술은 엄격히 요구될 때만 사용될 수 있는 비관리 코드를 작성하는 것으로 알려져 있다.이 주제는 49 장의 "Platform Invokes and Interoperability with the COM Architecture" 에서 논의된다.


관리 코드의 작성과 Common Language Runtime 의 존재는 응용프로그램이 컴파일러에 의해 생성되는 방식에도 영향을 미친다.


.NET Assemblies.


Visual Basic 6 나 Visual C++ 과 같은 전통적인 Win32 개발 환경에서, 당신의 소스 코드는 컴파일러에 의해서 분석되는데, 그것은 이진 실행 파일들을 생성한다. 그 파일들은 운영체제에 의해 직접적으로 해석되고 실행될 수 있다. 실제로 Visual Basic 6 와 C++ 에 의해서 빌드된 Win32 응용프로그램은 런타임을 사용하지만, 다른 프로그래밍 언어를 사용해서 개발된 응용프로그램을 가지고 있다면, 적절한 런타임을 설치해야만 한다. .NET 개발에서는 모든 것이 매우 다르다. 당신이 응용프로그램을 개발하는 데 사용하고 있는 .NET 언어가 무엇이든 간에, 컴파일러는 어셈블리( assembly )를 생성한다. 이는 .NET 실행 코드를 포함하고 있으며, 두 종류의 필수 요소로 구성된다 : MSIL 코드와 메타데이터( metadata ). MSIL 은 Microsoft Intermediate Language 이다. 이는 개체지향적이며, ( CPU 의존적인 명령어 집합을 구현하는 실행파일을 빌드하기 보다는 ) CPU 독리적인 명령어 집합을 제공하는 고수준 어셈블리 프로그래밍 언어이다. MSIL 은 서로 다른 .NET 언어로 작성된 같은 프로그래밍 작업들이 같은 IL 코드를 생성한다는 의미의 공통 언어이다. 메타데이터는 코드 내에 구현된 타입들과 관련된 정보 집합이다. 그러한 정보는 서명( signature ), 함수, 프로시저, 타입의 멤버, 외부에서 참조되는 타입의 멤버들을 포함할 수 있다. 기본적으로 메타데이터의 목적은 .NET Framework 에 대한 코드를 기술하는데 있다. 어셈블리가 .exe 확장자를 가질 수 있음에도 불구하고, 앞에서 언급한 구조 때문에 그것은 운영체제에 의해 직접적으로 실행될 수 없다. 사실 당신이 .NET 응용프로그램을 실행할 때 운영체제는 그것을 .NET 어셈블리로 인식하고( 왜냐하면 .NET 과 Windows 사이에는 엄격한 협력이 존재하기 때문이다 ), Just-In-Time 컴파일러를 실행한다.


The execution Process and the Just-In-Time ( JIT ) Compiler.


.NET 컴파일러들은 IL 코드와 메타데이터를 포함하는 어셈블리들을 생성한다. 실행을 위해 어셈블리를 시작( launch )하면, .NET Framework 은 모든 정보를 패키징( package )하며 그것들을 운영체제가 이해하고 실행할 수 있는 실행파일로 번역한다. 이 작업은 Just-In-Time( JIT ) 컴파일러가 책임진다. JIT 는 코드를 실행 전에 실시간에( on-the-fly ) 컴팡리하며, 컴팡리된 코드를 실행할 수 있는 상태로 유지시킨다. 그것은 method level 에서 동작한다. 이는 그 코드가 실행되기 전에 응용프로그램의 진입점( 보통 Sub Main )을 먼저 찾은 다음에, 진입점에 의해서 참조되거나 실행되는 다른 프로시저나 함수들( .NET 용어로는 메서드들 )을 컴파일한다는 것을 의미한다. 만약 외부 어셈블리에 정의된 코드를 가지고 있다면, 그 메서드가 실행되기 전에 JIT 컴파일러가 어셈블리를 메모리에 로드한 다음에 코드를 컴파일한다. 물론 외부 어셈블리를 메모리에 로딩하는 것은 시간이 걸리는 작업이며 성능에 영향을 미치지만, 좀처럼 거의 사용하지 않는 메서드들을 외부 어셈블리에 배치하는 것은 좋은 아이디어일 수 있으며, 비슷한 방식으로 거의 사용하지 않는 코드들을 독립된 메서드들에 배치하는 것도 좋은 아이디어일 수 있다.


The Base Class Library.


.NET Framework 의 Base Class Library( BCL )는 수 천개의 재사용 가능한 타입( type )들을 제공하는데, 당신은 그것들을 당신의 코드에서 사용할 수 있으며, 그것들은 Windows Presentation Foundation, ASP.NET, LINQ 등과 같은 모든 .NET 기술들을 다루고 있다. Base Class Library 에서 정의된 타입들은 비관리 코드와 Windows APIs 를 호출하지 않고, 외부 컴포넌트에 대한 의존없이 수백만개의 일을 할 수 있도록 해 준다. 타입은 오브젝트가 표현해야 하는 것이 무엇인지를 진술하는 것이다. 예를 들어 String 과 Integer 는 타입이다. 그리고 당신은 String 타입의 변수( 즉 텍스트 메시지 )를 가지거나, Integer 타입의 변수( 즉 숫자 )를 가질 수 있다. 타입은 Class 와는 다르다. 사실 타입은 두 종류이다 : 참조형( reference type )과 값형( value type ). 이 주제는 4장의 "Data Types and Expressions"에서 다룬다 - 클래스는 단지 참조형일 뿐이다. BCL 에서 타입들은 네임스페이스( namespace ) 내에 들어가 있는데, 네임스페이스는 타입들의 컨테이너처럼 동작하고, 그것의 이름은 그것들이 가리키고 있는 기술과 엄밀한 관련이 있다. 예를 들어 System.Windows.Forms 네임스페이스는 Windows Forms 응용프로그램을 사용해 작업하기 위한 타입들을 구현하며, System.Web 은 Web 응용프로그램을 사용해 작업하기 위한 타입을 구현하는 식이다. 3장 "The Anatomy of a Visual Basic Project" 와 9장 "Organizing Types Within Namespaces" 에서 더욱 세부적인 네임스페이스에 대한 설명을 찾아볼 수 있다. 기본적으로 System 으로 시작하고 있는 네임스페이스의 이름은 BCL 의 일부이다. Microsoft 라고 시작하는 이름을 가진 일부 네임스페이스들이 있는데, 그것들도 BCL 의 일부이다. 이러한 네임스페이스들은 ( 코드 생성과 같은 ) 특별한 시나리오에서 그것들을 당신의 코드에서 사용할 수 있기는 하지만, 보통의 경우에는 Visual Studio 개발 환경과 Visual Basic 컴파일러에 의해서 사용된다. 


BCL 은 몇 개의 어셈블리로 구성된다. 가장 중요한 것은 MsCorlib.dll( Microsoft Core library )인데, 그것은 .NET Framework 의 일부이며, 당신의 프로젝트에서 항상 요구될 것이다. 다른 어셈블리들은 특정 기술에 따라 자주 사용될 수도 있다; 예를 들어 System.ServiceModel.dll 어셈블리는 BCL 을 Windows Communication Foundation main infrastructure 와 통합한다. 또한 어떤 네임스페이스는 다른 기술을 위한 infrastructure 를 제공하지 않으며, 그것들은 특별한 시나리오에서만 사용된다; 결국 그것들은 MsCorlib( Microsoft Core Library )의 외부 어셈블리에서 정의된다. 이러한 모든 어셈블리들과 네임스페이스들은 적절한 장에서 소개될 것이다.


.NET Language.


Microsoft 는 .NET Framework 4.0 을 위한 몇 개의 프로그래밍 언어를 제공한다. Visual Studio 2010 을 사용해, 당신은 다음과 같은 통합된 프로그래밍 언어들을 사용해 응용프로그램을 개발할 수 있다 :

  • Visual Basic 2010.
  • Visual C# 4.
  • Visual F# 2010.
  • Visual C++ 2010.

Visual J# 은 더이상 .NET Framework 패밀리의 일부가 아니다. 당신의 Phython 과 Ruby 와 같은 동적 언어들에 대한 Microsoft 식의 구현을 사용해 네이티브 언어들을 통합할 수도 있는데, 그것들은 각각 IronPython 과 IronRuby 로 알려져 있다.


IronPython 과 IronRuby 는 어디에 있는가?

IronPython 과 IronRuby 는 현재 Microsoft 에서 개발중이며, CodePlex 커뮤니티의 오픈소스 프로젝트로서 이용가능하다. 당신은 IronPython 을 http://ironpython.codeplex.com 에서 받을 수 있다. 당신은 IronRuby 를 http://ironruby.codeplex.com 에서 찾을 수 있다.


Fortran, Forth, Pascal 과 같은 유명한 프로그래밍 언어의 .NET 을 위한 서드파티( third-party ) 구현들도 있느데, 이것들에 대해 논의하는 것은 이는 이 장이나 이 책의 목적이 아니다. 하지만 이 언어들이 .NET Framework base class library 의 이점 및 VB 나 C# 과 같은 infrastructure 를 취한다는 것을 아는 것은 중요하다. 이는 Common Language Runtime 이 모든 .NET 프로그래밍 언어들을 위한 공통 기반을 제공하고 있기 때문에 가능하다.


.NET Framework Tools.


.NET Framework 은 몇 개의 커맨드라인 도구들을 제공하는데, 이것들은 응용프로그램을 생성하는데 필요하다. 그 도구들 중에 는 Vbc.exe( Visual Basic Compiler ), Csc.exe( Visual C# compiler ), MSBuild.exe( the build engine for Visual Studio )와 같은 컴파일러들이 있다. 이러한 모든 도구들은 C:\Windows\Microsoft.NET\Framework\v4.0 폴더에 저장되어 있다. 대부분의 경우에, 당신은 직접 .NET Framework 도구들을 실행할 필요는 없다. 왜냐하면 당신은 Microsoft Visual Studio 2010 Integrated Development Environment 를 사용해서 작업을 할 거이고, 이는 필요할 때 적절한 도구를 실행해 줄 책임이 있기 때문이다. 우리가 아직 어떤 주제들에 대해서 이야기하지 않았기 때문에, 여기에서 모든 도구들을 나열하지는 않겠다. Visual Studio 에 의해 실행되는 .NET 도구들에 대한 정보에 대해서는 특정 도구들을 포함하는 특별한 주제를 논의할 때 이야기하는 것으로 한다.


Windows Software Development Kit.


Visual Studio 2008 부터, 설치 프로세스는 당신의 컴퓨터에 .NET Framework 와 개발 환경과 함께 Windows SDK 도 설치할 것이다. 이 software development kit 은 부가적인 도구들과 라이브러리들을 제공하는데, 이것들은 .NET Framework 을 위한 응용프로그램을 개발하는데 유용하다. 이전 버전의 .NET Framework 과 Microsoft Windows 운영체제에서는 당신이 두 개의 패키지를 설치해야만 했고, 예전에는 .NET Framework SDK 와 Microsoft Platform SDK 라고 불렸었다. Windows Vista 가 소개되면서, .NET Framework 은 운영체제의 코어중 일부가 되었다; Microsoft 는 Windows SDK 를 릴리즈했는데, 그것은 관리 및 비관리 응용프로그램 모두를 빌드하는데 사용되는 도구들을 제공한다. Windows SDK 는 C:\Program Files\Microsoft SDKs\Windows\v7.0A 폴더에 설치되는데, 이는 배포( deployment ), 코드 분석, Windows Communication Foundation 프로젝트를 위한 프락시( proxy ) 클래스 생성과 같은 어셈블리들을 빌드하는 작업들을 위해 Microsoft Visual Studio 에 의해서 사용되는 부가적인 도구들을 포함하고 있다. 또한 이 경우에도 당신은 이들 도구를 직접 실행할 필요가 없다. 왜냐하면 Visual Studio 가 당신을 위해서 이를 처리해 줄 것이기 때문이다. 적절한 장에서 Windows SDK 의 도구들에 대한 정보를 찾아볼 수 있다.


What's New in .NET Framework 4.0.


만약 당신이 .NET Framework 3.5 를 사용한 개발 경험을 가지고 있다면, 그것이 incremental architecture 를 가지고 있다는 것을 알고 있을 것이다. 이는 ( LINQ 와 같은 이 버전의 전통적인 기술들을 포함한 ) .NET 3.5 가 Windows Forms 와 같은 핵심 .NET 기능 및 기술들을 위해서 .NET 2.0 에 의존한다는 것을 의미한다. 반면에 Windows Presentation Foundation, Windows Workflow Foundation, CardSpace 등과 같은 framework 을 위해서는 .NET Framework 3.0 을 요구한다. 이는 .NET Framework 3.5 가 이전 버전이 prerequisite 로서 설치되어 있을 것을 요구한다는 것을 의미한다. .NET Framework 4.0 은 완전히 독립적인 기술이며, 이는 다른 버전이 설치될 것을 요구하지 않는다. .NET Framework 3.0, 3.5 에 대한 지식을 가지고 있다고 가정하고, 당신의 편의를 위해 .NET 4.5 에서 새롭게 추가된 기능을 정리했다 :

  • Windows Presentation Foundation.
  • Windows Communication Foundation.
  • ASP.NET( 이제 Ajax 와 MVC 를 포함 ).
  • ADO.NET Entity Framework.
  • Visual Studio Tools for Office.
  • Windows Workflow Foundation.

이 새로운 버전의 기술들은 단지 부가적인 기능을 추가한 것뿐만 아니라, 구조가 변경되고 개선되었다. .NET Framework 4.0 은 이전 버전에서 직접 설치해야만 했거나 .NET 3.5 Service Pack 1 의 일부였던 framework 들도 포함하고 있다 :

  • ADO.NET Data Services.
  • Parallel Extensions for the Task Parallel Library, or TPL for shot( related to the parallel computing ).
  • Code Contracts.

Windows Forms 기술은 여전히 .NET Framework 2.0 에 있다. 거기에는 얼마 안 되는 부가적인 사용자 컨트롤( user control )들만 있으며, 그것들은 30 장의 "Creating Windows Forms 4.0 Application" 에서 논의된다.


Summary.


.NET Framework 을 이해하는 것은 Visual Basic 2010 을 사용하여 응용프로그램을 개발하는데 있어서 매우 중요하다. 왜냐하면 당신은 .NET Framework 을 위한 응용프로그램을 빌드할 것이기 때문이다. 이 장은 Common Language Runtime 과 Base Class Library, 그리고 응용프로그램이 컴파일되고 실행되는 방식과 같은 .NET Framework 4.0 의 고수준 개관 및 핵심 개념들을 제공했다. 또한 가장 중요한 커맨드라인 도구들과 .NET 언어들에 대한 개관도 제공했다.


'Programming > .NET' 카테고리의 다른 글

[ 4 ] DataBinding  (0) 2012.10.14
[ 3 ] Dependency property.  (0) 2012.10.11
[ 2 ] XAML  (0) 2012.10.10
[ 1 ] WPF Architecture.  (0) 2012.10.08
[ 6 ] Proerty, indexer, attribute  (0) 2012.10.05
[ 5 ] Delegate and event.  (0) 2012.10.02
[ 4 ] Classes and structs  (0) 2012.09.27
Extension Methods  (0) 2012.09.26
[ 3 ] .NET Garbage Collection.  (0) 2012.09.25
[ 2 ] C# Types  (0) 2012.09.25

 

일단 "Graphic card 를 만드는 제조사에 종속되지 않도록, 순수 OpenCL 을 설치해 보겠어!!!" 라는 다짐을 하고 계신 분이 있다면 말리고 싶다. 아니 불가능하다고 말하고 싶다. 왜냐하면 Khronos group 은 단지 specification 만을 제공하기 때문이다. Khronos 의 OpenCL page 에 가면 header file 은 있는데, source file 이 없다는 데 대해 엄청난 의아함을 느끼게 된다. 나도 source file 찾아보려고 노력해 봤는데, 절대 없었다.

 

단순한 이유다. 이전 글에서도 언급했듯이, Khronos group 에서 제공하는 표준을 구현하는 것은 driver 제조 업체별로 이루어지는 일이기 때문에 source file 이 있으면 그게 더 이상한거다.

 

결국 AMD/ATI card 를 사용하는 사람은 Stream SDK 를 NVidia card 를 사용하는 사람은 CUDA toolkit 을 깔지 않으면 안 되는 상황이 된다. 그리고 구현하는 입장에서도 NVidia 용이냐 AMD/ATI 용이냐에 따라서 서로 다른 실행 파일을 제공해야 한다. 여기에서는 NVidia 를 기준으로 설명하도록 하겠다.

 

일단 http://developer.nvidia.com/ 로 가서 Cuda toolkit page 로 이동한 다음, 자신의 OS 에 맞는 Cuda toolkit 용 graphic card driver 와 CUDA toolkit 을 download 한다. 그리고 그것을 설치한다. 그리고 CUDA toolkit 이 설치된 경로를 확인한다.

 

예를 들어 CUDA 같은 경우에는 다음과 같은 경로에서 OpenCL 의 header 와 library 를 찾을 수 있다.

 

C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v3.2\include

C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v3.2\lib

 

물론 이 경우는 내 machine 에서의 설치 경로이기 때문에 다른 사람들은 자신만의 경로를 지정해야만 할 것이다.

 

위의 경로를 visual studio 의 VC++ Directories 항목에 추가해 준 다음에 source code 에 다음과 같이 입력하면, OpenCL 을 사용할 준비를 마친 것이다.

 

#include < CL/cl.h >

#pragma comment( lib, "OpenCL" )

 

물론 lib 를 project 속성에서 넣어도 상관은 없다. 이것은 NVidia 나 AMD/ATI 나 동일한 식으로 하면 되는 것으로 알고 있다.

 

해 보진 않았지만 program 의 호환성 보장을 위해서는 NVidiaOpenCL.dll, ATIOpenCL.dll 같은 wrapper 를 따로 만들어서 실행시에 동적으로 loading 할 수 있도록 하는 것이 좋을 것 같다.




최근에 multi-platform platform 에 대응하는 OpenCL 관리자를 만들려고 하다가 보니 모든 종류의 platform 에 대한 lib 를 수집해야 한다는 문제가 발생했다. 예를 들면 다음과 같은 조합이 필요하다.


  • 제조사 : AMD, Intel, NVida.
  • 기기 : Desktop, Notebook.
  • 운영체제 : Windows XP, Windows 7.


물론 더 많은 제조사가 존재하겠지만 게임이 돌아 갈 만한 환경은 저 정도가 되겠다. 이 경우 3 X 2 X 2 = 12 개의 조합이 나온다. 아무리 생각해도 이건 좀 아니다 싶은 상황이 되었다.


모든 platform 에서 돌아 갈 수 있는 프로그램을 만들기 위해서는 좀 더 많은 고민이 필요할 것 같다.




OpenCL.lib 는 static library 가 아니고 import library 였다. Multi-platform 에 대응하기 위해서는 해당 platform 을 위해 배포된 OpenCL.dll 을 직접 LoadLibrary() 로 부른 다음에 GetModuleHandle() 을 통해서 API 를 획득하는 방식을 취해야 할 것 같다.


+ Recent posts