Hudson Tutorials - 윈도우에 Hudson 설치하기

2010-01-12T00:46:39+09:00

Hudson은 간단히 얘기하면 빌드, 배포, 테스트 자동화 시스템이다. 어느 하나의 프로젝트의 소스코드를 업데이트 받아 지정된 시간이 프로젝트를 빌드하여 에러 유무를 출력하고, 각 빌드 별 배포파일 관리 및 테스트 통과 여부를 확인할 수 있는 프로그램이다. 또한, Hudson은 오픈소스로, 기존에 많이 사용하던 CruiseControl.NET 보다 손쉬운 환경을 제공하기 때문에 최근 많은 사랑을 받고 있다.

지금부터 Hudson을 윈도우 운영체제에 설치해보도록 하겠다.

1. 최신버전의 Hudson을 다운로드 한다.

최신버전의 Hudson 다운로드 링크 (마우스 오른쪽으로 클릭하여 다른이름으로 저장하세요)http://hudson-ci.org/latest/hudson.war

본 Tutorial에서는 F:\Hudson 폴더에 저장하도록 하겠다.

2. Java SE Runtime Environment(JRE) 를 설치한다.

Hudson은 자바로 구현되어 있으므로, PC에 Java를 설치해야 한다.

Java 다운로드 링크 (쉬프트키를 누르고 클릭하세요)http://java.sun.com/javase/downloads/index.jsp

위 링크로 이동하여 Java SE Runtime Environment를 다운로드 하고 설치하도록 하자.

3. Hudson을 실행한다.

자바로 Hudson을 실행하기 위해서는 명령 프롬프트에서 해당 폴더로 이동해야 한다. 아래의 화면에서 처럼 시작->실행에서 'cmd'를 입력하고 엔터를 친다.

명령 프롬프트가 나타나면 아래의 화면과 같이 Hudson을 다운로드한 폴더로 이동하고, Hudson을 실행하도록 하자.

-DHUDSON_HOME=data 라고 명시하게 되면 Hudson의 Home Directory를 현재 폴더의 하부에 data라는 폴더로 지정하게 된다. 이 옵션을 생략하면 현재 계정폴더 하부에 Home Directory가 생성되게 되므로 주의하자.

위 명령어를 실행하게 되면 Hudson이 동작중인 문구가 표시되며 실행되게 된다. 그러면 인터넷 익스플로러를 이용하여 Hudson에 접근해 보도록 하자.

접근 주소는, http://localhost:8080 으로 접근하면 된다.

위와 같은 화면이 출력된다면 Hudson이 정상적으로 설치된 것이다. 정말로 쉽다.. ㅋㅋ

4. Hudson을 Windows Service로 동작시키기

위에서 Hudson을 실행 한 것 처럼, 맨날 컴퓨터 부팅시 마다 명령 프롬프트에서 명령어를 치고 수행 할 수는 없다. 그래서 Hudson에서는 Windows Service로 수행할 수 있는 기능을 제공한다. Hudson 메인 페이지에서 좌측의 'Hudson 관리' 메뉴로 들어가 보면 'Install as Windows Service' 메뉴가 있는 것을 볼 수 있다.

메뉴를 클릭하면 아래의 화면과 같이 설치할 디렉토리를 지정하는 화면이 나타난다. 아까 Hudson 실행 시 지정했던 Home Directory가 표시되는 것을 볼 수 있다. 구지 변경할 필요가 없으므로 'Install' 버튼을 클릭하도록 하자.

설치가 끝나게 되면 기존에 명령 프롬프트에서 실행중인 Hudson은 자동으로 종료되고, Windows Service로 등록된 Hudson이 자동으로 시작되면서 Hudson 메인 페이지가 다시 보여지게 된다.

만일, 설치중에 Access Denied 등의 권한관련 문제가 발생한다면, 현재 운영체제가 UAC(Use Access Control)을 사용하는 운영체제일 가능성이 높다. 그럴경우 기존의 명령 프롬프트에서 실행중인 Hudson은 Ctrl+C를 눌러 그냥 종료시키고, 명령 프롬프트를 이용하여 Hudson이 설치된 폴더 하부에 data 폴더로 이동해 보도록 하자.

data 폴더 하부에 Windows Service 형식의 프로그램인 hudson.exe 파일이 존재하는 것을 확인할 수 있다. 해당 파일을 명령 프롬프트상에서 등록해보도록 하자.

아래의 화면과 같이 hudson.exe install 이라고 실행하면 서비스로 등록할 수 있을 것이다.

마치며,

여기까지, 윈도우 운영체제에서 Hudson을 설치해보고 Windows Service 형식으로 설정하는 방법까지 알아보았다. 정말 간편하게 설치가 되는 것 같다. 다음에는 .NET 프로젝트를 위한 플러그인에 대해서 알아보도록 할 것 이다.

VisualSVN Server를 이용해 손쉽게 SVN 서버 구축하기

2010-01-12T00:12:06+09:00

VisualSVN Server를 이용하면 아파치(Apache) 서버에서 서비스되는 SVN 서버를 손쉽게 구축할 수 있다.

1. VisualSVN 사이트에서 최신 버전의 VisualSVN Server 프로그램을 다운로드 한다.

VisualSVN Server 다운로드 링크http://www.visualsvn.com/server/download/

쉬프트를 누르고 클릭하면 새창에서 열립니다.

위 화면에서 처럼 화면 중앙에 보이는 'download now' 링크를 클릭하면 다운로드가 된다.

참고로, VisualSVN Server 프로그램에 Subversion이 포함되어 있으므로 Subversion은 따로 설치할 필요가 없다.

2. VisualSVN Server를 설치한다.

계속 'Next' 버튼을 누르다 보면 아래와 같이 Component를 선택하는 화면이 나타난다.

현재 우리는 VisualSVN Server와 관리 콘솔을 현 PC에 같이 설치 해 보도록 하겠다. 만일 실질적인 VisualSVN Server가 다른 컴퓨터에 설치되어 있고, 현 PC에서는 관리 콘솔만 설치하려 한다면 아래 옵션을 선택하면 된다.

다시 'Next' 를 클릭하자.

VisualSVN Server를 설치할 위치를 지정할 수 있다.

그리고 Repositories 위치를 지정할 수 있다. Repositories는 우리말로 '저장소' 라고 보통 얘기하며, svn으로 관리될 모든 프로젝트의 부모 디렉토리라고 생각하면 된다.

Server Port는 원하는 포트를 지정하도록 한다. 오른쪽에 'Use secure connection' 항목이 체크되어 있으면 https 를 통해서 svn에 접근하게 되고, 체크를 하지 않으면 http를 통해서 접근할 수 있다.

Authentication 항목은 2개중 원하는 방식을 선택할 수 있다. 'Use Subversion authentication'은 VisualSVN Server에서 사용할 사용자 및 그룹을 따로 만들어서 관리한다는 뜻이고, 'Use Windows authentication'은 윈도우 운영체제의 사용자 및 그룹 정보를 그대로 이용한다는 뜻이다. 원하는 옵션을 선택하면 된다.

이후에는 특별한 내용이 없으므로 계속 'Next'를 눌러 설치를 마치도록 한다.

3. 설치된 VisualSVN Server를 실행한다.

바탕화면 및 프로그램 그룹에 생성된 VisualSVN Server Manager를 실행해 보자.

위 그림과 같이 GUI 상에서 간편히 설정할 수 있는 SVN 서버가 구축되었다.

그러면 이제 샘플로 하나의 프로젝트를 만들어 보자.

4. 새로운 저장소를 생성한다.

화면의 'Repositories' 항목에서 마우스 오른쪽을 클릭하여 'Create New Repository' 항목을 선택한다.

메뉴를 클릭하면 아래와 같은 창이 나타난다. Repository Name항목에 생성하려고 하는 저장소명을 입력한다. 여기에선 TestProject라고 입력했다.

그리고 하단에 보면 'Create default structure (trunk, branches, tags)' 체크박스가 있다. 이 체크박스를 체크하게 되면 최초 저장소 생성시 하부에 trunk, branches, tags 폴더를 자동으로 생성해 준다. 이 하부 폴더들은 일반적으로 많이들 사용하는 저장소 구성이라고 보면 된다. 간단히 설명을 하자면, trunk 폴더는 항상 최신 소스코드가 유지되는곳, branches 폴더는 소스코드에서 특수한 기능이 추가된 특별한 버전이 만들어 질경우 하부에 각각 폴더를 만들어 관리하는 곳, tags 폴더는 소스코드 관리중 원하는 단계의 소스코드를 따로 분리하여 저장해 놓을때 사용한다. 좀 더 자세한 내용은 여기를 클릭하여 살펴보도록 하자.

OK 버튼을 눌러 저장소를 생성하게 되면 아래의 화면과 같이 저장소가 생성되며 기본적인 폴더 구조를 가지고 있는 것을 확인할 수 있다.

5. 저장소에 권한을 부여한다.

VisualSVN Server의 기본설정은 Everyone이 Read/Write 할 수 있도록 되어 있다. 소스코드의 보안을 위해 사용자를 설정해보도록 하자.

Users 항목에서 마우스 오른쪽 버튼을 눌러 'Create User' 메뉴를 선택하도록 하자.

새로운 계정 하나를 생성하도록 하겠다.

이제, 생성한 사용자를 TestProject 저장소에 접근이 가능하도록 설정해 보자. TestProject에서 마우스 오른쪽 버튼을 눌러 'Properties' 메뉴를 클릭하도록 하자.

아래의 화면과 같이 Security 탭에 현재 Everyone이 Read/Write 할 수 있도록 설정되어 있는 것을 확인할 수 있다.

인증된 사용자만 접근이 가능하도록 Everyone은 아래 항목에서 'No Access'로 설정하여 접근하지 못하도록 하고, Add 버튼을 클릭하여 아까 생성한 사용자를 추가하여 Read/Write 권한을 주도록 하자.

이제 모든 설정이 완료되었다. 정상적으로 동작하는지 웹브라우저로 접근해보도록 하겠다.

인터넷 익스플로러를 실행하여 주소에 'http://localhost:81/svn/TestProject' 를 입력해보자.

위 화면과 같이 로그인 정보를 입력하는 화면이 나타난다. 아까 생성한 계정정보를 입력해 보도록 하자.

아까 생성한 프로젝트의 구조가 표시되면 정상적으로 설정된 것이다.

마치며,

기존에 아파치, Subversion 등등 필요한 여러한 여러 프로그램를 설치 및 구성하는데 애를 먹어본 사람이라면, VisualSVN Server의 간편함에 반하게 될 것 같다. 정말 간편하고 모든것을 관리 할 수 있는 GUI 화면을 제공해주기까지 하니 정말 감사할 따름이다.

안드로이드폰 프로그램개발을 위한

2010-01-08T09:14:50+09:00

안드로이드(Android) SDK를 다운받자

링크 : http://developer.android.com/sdk/index.html

개발을 위한 자료를 찾기 위한 사이트네...괜찮은거 같애...

사이트 링크: http://www.androidpub.com/

참고링크 : http://graynote.tistory.com/entry/%EC%95%88%EB%93%9C%EB%A1%9C%EC%9D%B4%EB%93%9CAndroid-SDK-%EA%B0%9C%EB%B0%9C-%EA%B8%B0%EB%B3%B8-%EA%B0%95%EC%A2%8C

Comparing TWO continuous build tools: Cruise Control and Hudson

2010-01-07T20:52:38+09:00

Continuum, Cruise Control and Hudson are some of the famous continuous integration tools which people are using nowadays. Cruise Control is the pioneer one and people are using from a long period of time. Continuum is from the Maven team and very high integration with Maven 1 and 2. Hudson is the new one but it is more popular now.

In our department my PM asked me and to my friend, to do the Cruise Control + SVN +Maven based continuous build mechanism. During this process I had gone through some more R&D on the tools which are available for the continuous build process. In that process I found some of the comments about Hudson. Those were very interesting.. So I thought of comparing this with our Cruise control.

Here in this post I am trying to compare Hudson and Cruise Control. The basic TEN points or features listed below are taken from Hudson’s official site and I am just trying to compare these all with the capabilities of cruise Control. I had tried to add my own experience with these. Correct me if there is any features that were wrongly entered or any new features that you know about these.

Versions and platform:

Hudson : 1.213

Cruise Control : 2.7.1

Plat form : Windows

	Hudson		Cruise Control
1	Open Source	1	Open Source
2	Easy installation: Just java -jar Hudson.war, or deploy it in a servlet container. No additional install, no database.	2.	It also gives us very easy installation. Just unzip the downloaded zip file. That’s it. It is actually using an internal Jetty server. No Database, no install here also.
3	Easy configuration: Hudson can be configured entirely from its friendly web GUI with extensive on-the-fly error checks and inline help. There’s no need to tweak XML manually anymore, although if you’d like to do so, you can do that, too.	3.	Big difference comes here. The GUI providing by Cruise control for configuration is not at all good. It just displays the config.xml file. Its no way near to Hudson for Configuration GUI part. If you want to configure Cruise Control then you must study about the structure of the Config.xml first.
4	Change set support: Hudson can generate a list of changes made into the build from CVS/Subversion. This is also done in a fairly efficient fashion, to reduce the load of the repository.	4.	Cruise control also show the list of files which are changes at this check-in process.
5	Permanent links: Hudson gives you clean readable URLs for most of its pages, including some permanent links link “latest build”/”latest successful build”, so that they can be easily linked from elsewhere.	5.	Uhm… Cruise control is not giving this. It gives a link with some log code number attached with it. Its looking horrible and cant be easily likable.
6	RSS/E-mail/IM Integration: Monitor build results by RSS or e-mail to get real-time notifications on failures.	6.	It also gives RSS and email functionality. Don’t know about IM support. If we need to change the Email structure then either we have to change XSL or CSS file which we are using in the email config.
7	After-the-fact tagging: Builds can be tagged long after builds are completed	7.	N.A.
8	Detect new failing tests while build	8	Failing tests will show in the dashboard. But no separation between new and old.
9	Notify when first test in build fails	9	No such type of notification.
10	JUnit/TestNG test reporting: JUnit test reports can be tabulated, summarized, and displayed with history information, such as when it started breaking, etc. History trend is plotted into a graph.	10	It is showing all the unit test results but not as good as Hudson does. There is no detailed information like when it started breaking, History etc. and no graph for unit results too.
11	Distributed builds: Hudson can distribute build/test loads to multiple computers. This lets you get the most out of those idle workstations sitting beneath developers’ desks.	11.	The build distribution is done through the maven install goal. Its
12	File fingerprinting: Hudson can keep track of which build produced which jars, and which build is using which version of jars, and so on. This works even for jars that are produced outside Hudson, and is ideal for projects to track dependency.	12.	No idea.
13	Plugin Support: Hudson can be extended via 3rd party plug-ins. You can write plug-ins to make Hudson support tools/processes that your team uses.	13.	Plug-ins are there in Cruise control also.
14	Dash board: Hudson has an attractive dashboard with Colorful as well as meaningful icons. We can separate this building projects into subgroups also. It will also shows building projects. Well designed Ajax pages.	14.	It gives an attractive Dash board. It displays all the necessary information which we need to know. We can directly build from there also. Viewing/ downloading the log file is also allowed from this Interface.
15	Local Copy of projects: Handled by Hudson itself. No need to do by the user.	15.	Maintaining a local copy with the exact SVN data makes us more uncomfortable. The user has to copy the Project into the local folder with SVN data.
16	Auto copy of SVN updates: No need to provide any other code to copy the project from SVN to the local compiling folder.	16.	Its not copying the data from the SVN directly. We need to write (In our case we wrote an ANT build file to download the latest copy of Project from SVN) something separate.
17	Running In background: If the server where we deployed the war is running then its okay for Hudson.	17.	If we want to run it without console then we need to make it a separate ‘WINDOWS Service’ using any third party tool.
18	We can deploy the war file in any of the server we wanted.	18.	Jetty server is using internally.
19	User authorization schemes. more configurable.	19.	User authentication is there but no schemes at all.
20	Very Active mailing list.	20.	From a long period people are using this. So it gives so many search results. But its mailing list is not that much active when compared with Hudson.

Alternative building tools available.

I got this list from ThoughtWorks. HERE we will get a good comparison of these all.

Conclusion:

In my opinion Hudson much more better than Cruise Control. The time we will take to start to use Cruise control will be high when we compared with Hudson. The GUI which makes all the Configurations very very easy. The Ajax support makes the configuration more “Error Free”. Though Cruise control is using by a lot of people, when we looked into the features, mailing list, the fastness and support from Developers I think Hudson will be a good option.

del.icio.us Tags: Cruise Control,Hudson,Continous Integration

Technorati Tags: Cruise Control,Hudson,Continous Integration

Popularity: 100% [?]

Creating Web services using Apache CXF (Part 1) : The Basics. As we discussed in the previous post, CXF is...
Apache CXF- An ultimate web service open source framework : Lets start learning… Apache CXF is an open source services framework which...

Related posts brought to you by Yet Another Related Posts Plugin.

IIS에서 WCF호스팅하기

2010-01-06T20:34:56+09:00

1. WCF 서비스 라이브러리 프로젝트를 생성한다.

2. 텍스트 형식의 프로젝트명.svc 파일을 만들어 정의한다.

3. Web.config 파일에 서비스를 정의한다.

4. 인터넷 정보 서비스를 실행하고, 웹사이트에 가상 디렉토리를 추가한다.

5. Windows Console Application 프로젝트를 생성한다.

6. System.ServiceModel 라이브러리를 참조한다.

7. 서비스 참조 추가에서 WCF 서비스를 선택하여 추가한다.

8. 클라이언트에 생성된 프록시를 사용한다.

다국어 프로그래밍의 기초지식

2010-01-06T00:00:22+09:00

출처 : 마이크로소프트웨어

i18N

i18N은 국제화(internationalization)를 줄여서 쓴 말이다. i와 n 사이에 18개의 알파벳이 있다는 뜻에서 붙여진 이름이다. 즉, 이미 만들어진 프로그램을 다른 언어를 사용하는 사용자가 사용할 수 있도록 변경하는 과정을 말한다. 즉, 시스템에서 기본적으로 사용하는 언어의 문자들을 자유롭게 사용할 수 있어야 한다.

문자 집합

각 나라의 언어들은 그 말을 표현하기 위한 문자들을 가지고 있습니다. 이를 컴퓨터 상에서 나타내기 위해 필요한 것이 문자 집합(character set)이다. 예를 들자면 한글을 표현하기 위해서는 KSC-5601 완성형을 사용할 수도 있으며, 조합형을 사용할 수도 있다. 이와 같이 하나의 언어에도 여러 가지의 문자 집합이 존재할 수 있다.

코드 페이지

코드 페이지(code page)는 쉽게 말하면 문자나 특수 문자를 숫자로 표현한 대조표 같은 것이다. 1바이트 코드 페이지는 8비트를 사용하여 기본적으로 256개의 문자를 가지고 있다. 첫 128개는 표준 ASCII 문자들로 구성되어 있으며 이 속에 기본적인 영어의 알파벳 문자들이 들어 있다. 나머지 128개의 공간에는 각 언어별로 특별히 사용되는 문자들이 들어 있다. 물론 우리나라나 중국, 일본, 대반 등의 2바이트 코드 페이지를 사용하는 국가는 이런 1바이트 코드 페이지로는 표현할 수 없는 문자들이 너무 많다.

유니코드

컴퓨터는 기본적으로 숫자만 처리한다. 글자나 다른 문자에도 숫자를 지정하여 저장한다. 유니코드가 개발되기 전에는 이러한 숫자를 지정하기 위해 수백 가지의 다른 기호화 시스템을 사용했다. 단일 기호화 방법으로는 모든 문자를 포함할 수 없었기 때문이다. 예를 들어 유럽 연합에서만 보더라도 모든 각 나라별 언어를 처리하려면 여러 개의 다른 기호화 방법이 필요하다. 영어와 같은 단일 언어의 경우도 공통적으로 사용되는 모든 글자, 문장 부호 및 테크니컬 기호에 맞는 단일 기호화 방법을 가지고 있지 못했다.

이러한 기호화 시스템은 또한 다른 기호화 시스템과 충돌한다. 즉, 두 가지 기호화 방법이 두 개의 다른 문자에 대해 같은 번호를 사용하거나 같은 문자에 대해 다른 번호를 사용할 수 있다. 주어진 모든 컴퓨터(특히 서버)는 서로 다른 여러 가지 기호화 방법을 지원해야 한다. 그러나, 데이터를 서로 다른 기호화 방법이나 플랫폼 간에 전달할 때마다 그 데이터는 항상 손상의 위험을 겪게 된다.

유니코드는 사용 중인 플랫폼, 프로그램, 언어에 관계없이 문자마다 고유한 숫자를 제공한다. 유니코드 표준은 Apple, HP, IBM, JustSystem, Microsoft, Oracle, SAP, Sun, Sybase, Unisys 및 기타 여러 회사와 같은 업계 선두주자에 의해 채택되었다. 유니코드는 XML, Java, ECMAScript(JavaScript), LDAP, CORBA 3.0, WML 등과 같이 현재 널리 사용되는 표준에서 필요하며 이는 ISO/IEC 10646을 구현하는 공식적인 방법이다. 이는 많은 운영 체제, 요즘 사용되는 모든 브라우저 및 기타 많은 제품에서 지원된다. 유니코드 표준의 부상과 이를 지원하는 도구의 가용성은 최근 및 전 세계에 불고 있는 기술 경향에서 가장 중요한 부분을 차지하고 있다.

유니코드를 클라이언트-서버 또는 다중-연결 응용 프로그램과 웹 사이트에 통합하면 레거시 문자 셋트 사용에 있어서 상당한 비용 절감 효과가 나타난다. 유니코드를 통해 리엔지니어링 없이 다중 플랫폼, 언어 및 국가 같에 단일 소프트웨어 플랫폼 또는 단일 웹 사이트를 목표로 삼을 수 있다. 이를 사용하면 데이터를 손상없이 여러 시스템을 통해 전송할 수 있다.

유니코드 컨소시엄은 비영리 조직으로서 현대 소프트웨어 제품과 표준에서 텍스트의 표현을 지정하는 유니코드 표준의 사용을 개발하고 확장하며 장려하기 위해 세워졌다. 컨소시엄 멤버십은 컴퓨터와 정보 처리 산업에 종사하고 있는 광범위한 회사 및 조직의 범위를 나타낸다. 컨소시엄의 재정은 전적으로 회비에 의해 충당된다. 유니코드 컨소시업에서의 멤버십은 전 세계 어느 곳에서나 유니코드 표준을 지원하고 그 확장과 구현을 지원하고자 하는 조직과 개인에게 개방되어 있다.

Gemini Key Features

2009-12-30T23:32:03+09:00

ASP.NET web application
SQL Server database back-end
Time-tracking and fully interactive web-based Project Gantt
Source control integration
Configurable email alert templates
Custom fields support
Gemini event sub system– event/listener model
Gemini Web Services
Automatic project road map and change logs
Customisable issue workflow
RSS feed support
Customisable issue type and priority
Controlled anonymous user access
Issue linking across projects
Unicode support
Windows and web forms authentication
Optional add-on products: Desktop Client, Visual Studio Add-in, Time Tracker

Gemini 시작하기

2009-12-30T23:04:40+09:00

어제 회식하던 중, 이슈 트래킹(Issue Tracking) 툴의 필요성이 다시 대두되었다. 기존에 Trac을 도입하려고 시도했으나, 이번에 새로오신 과장님의 소개로 Gemini라는 툴에 대해 알게 되었다. 처음 들어본 이슈 트래킹 툴이였으나 설치가 간편하고 웹 페이지도 Trac에 비해 화려하게 나오는게 아주 마음에 든다.. ㅋㅋ

CounterSoft Homepagehttp://www.countersoft.com

Gemini Software 제작사 홈페이지

Gemini는 프로젝트를 관리할때 팀이나 기관에서 효율적인 대화 및 협업을 위한 프로젝트 관리 및 이슈 트래킹, 버그 트래킹 기능을 지원한다. 그리고 5유저까지는 무료라이센스를 받아서 사용이 가능하다는 장점이 있다.

또한, 여러상황에서 편리한 사용이 가능하도록 여러가지 애드온을 제공한다.

C# 설계에 참고사항

2009-12-29T11:39:50+09:00

상속보다는 interface를 정의하고 구현하자.
interface의 구현과 virtual 메서드의 overriding을 구분하자.
delegate를 이용하여 콜백을 표현하자.
이벤트를 이용하여 외부로 노출할 인터페이스를 정의하자.
클래스 내부 객체에 대한 reference 반환을 피하자.
명력적 프로그래밍보다 선언적 프로그래밍이 더 좋데요.
serializable 타입이 더 좋다네.
IComparable과 IComparer를 이용하여 순차관계만들자.

WPF 소개

2009-12-29T11:39:30+09:00

WPF를 바로 보는 나의 가장 인상적 특징은 UI를 GDI/GDI+가 아닌 DirectX로 그린다는 점이다.

책에 소개된 WPF의 인상적인 특징은(나는 아직 못느껴 봄 ㅋㅋ)

웹과 유사한 레이아웃 모델
풍부한 드로잉 모델
풍부한 텍스트 모델
최상의 프로그래밍 개념으로서의 애니메이션
오디오 미디어와 비디오 미디어 지원
스타일과 템플릿
명령
선언 형식의 사용자 인터페이스
페이지 기반의 응용 프로그램

이상이다.ㅋㅋ

앞으로 공부하다가 참고 할만한 내용은 정리해놔야겠군 ㅋㅋ

Open Source Charting & Reporting Tools in C#

2009-12-29T09:21:23+09:00

C# 환경에서 개발 시 무료로 사용할 수 있는 차트 & 레포팅 툴들을 정리해 놓은 사이트이다.

페이지로 이동

Pro WPF in C# 2008 구입

2009-12-23T15:30:12+09:00

WPF공부를 좀 해볼까하는 찰나에..이 책을 보게 되넹..ㅋㅋ

나온지도 얼마되지 않은 따끈한 책이구먼..ㅋㅋ

오면 열심히 함봐야겠다.

예스24에서 오전에 출발했다니 이제 곧 오겠징 ㅋㅋ

확장 메서드의 활용

2009-12-23T11:44:54+09:00

기존형식(클래스or 구조체)에 Static 메서드를 추가하여 기능을 확장할수 있다.
확장 메서드는 Static 클래스에서 정의하며, this 키워드와 함께 메서드의 첫번째 파라미터에 사용하는 형식으로 지정

Static class Util

{

public static int Negate(this int i)

{

return -1;

}

Full-Screen Application

2009-12-02T12:59:55+09:00

http://digitalformula.net/development/c-full-screen-application-complete-application-example/

출처 : http://digitalformula.net/development/c-full-screen-application-complete-application-example/

Yesterday I posted a quick update to an article I wrote back in 2007 entitled How to make a full-screen Windows app using VB.NET. Aside from 1 or 2 people saying “Oh man why don’t you be a man and write it using C#?” I reckon it’s a good idea to do that anyway. Thanks Scott for the suggestion. And thanks Phil for pointing me in the right direction with the DLL import stuff.

So, without any mucking about here’s the exact same complete application example only this time in C#. You can download the application’s source on the Digital Formula Downloads page or, alternatively, from the application source’s direct link. For those that want to see the main form’s complete source before they download, it can be found at the end of this article.

Please feel to ask any questions necessary. Thanks!

Form1’s complete source:

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Windows.Forms;
using System.Runtime.InteropServices;
 
namespace Play
{
    public partial class Form1 : Form
    {
 
        public Form1()
        {
            InitializeComponent();
        }
 
        [DllImport ("user32.dll")]
        private static extern bool SetWindowPos(IntPtr hWnd, IntPtr hWndIntertAfter, int X, int Y, int cx, int cy, int uFlags);
        [DllImport("user32.dll")]
        private static extern int GetSystemMetrics(int Which);
 
        private const int SM_CXSCREEN = 0;
        private const int SM_CYSCREEN = 1;
        private IntPtr HWND_TOP = IntPtr.Zero;
        private const int SWP_SHOWWINDOW = 64;
 
        public int ScreenX
        {
            get
            {
                return GetSystemMetrics(SM_CXSCREEN);
            }
        }
 
        public int ScreenY
        {
            get
            {
                return GetSystemMetrics(SM_CYSCREEN);
            }
        }
 
        private void FullScreen()
        {
            this.WindowState = FormWindowState.Maximized;
            this.FormBorderStyle = FormBorderStyle.None;
            this.TopMost = true;
            SetWindowPos(this.Handle, HWND_TOP, 0, 0, ScreenX, ScreenY, SWP_SHOWWINDOW);
        }
 
        private void Restore()
        {
            this.WindowState = FormWindowState.Normal;
            this.FormBorderStyle = FormBorderStyle.SizableToolWindow;
            this.TopMost = false;
        }
 
        private void button1_Click(object sender, EventArgs e)
        {
            FullScreen();
        }
 
        private void cmdRestore_Click(object sender, EventArgs e)
        {
            Restore();
        }
 
        private void cmdExit_Click(object sender, EventArgs e)
        {
            Application.Exit();
        }
    }
}

Overloading Methods in WCF

2009-10-12T11:04:50+09:00

Post : http://jeffbarnes.net/blog/post/2006/09/20/Overloading-Methods-in-WCF.aspx

Yesterday, I attended a local MSDN event in the Birmingham area. It covered the .NET 2.0 System.Net namespace, an introduction to WCF, and a look at Atlas. During the course of the WCF overview, someone asked the presenter whether it was possible to overload a method in WCF. The presenter wasn't completely sure and there were mixed answers from people in the audience. So, I thought I would provide the correct answer.

The short answer is yes. Technically, it is possible to overload a method in WCF. However, when you want to expose overloaded methods as operations in a WCF contract, there is more to it than simply writing two or more methods with the same name.

Consider the following example:

[ServiceContract]
public interface ICalendarService
{
   [OperationContract]
   ScheduledEvent[] GetScheduledEvents(DateTime date);

   [OperationContract]
   ScheduledEvent[] GetScheduledEvents(DateTime start, DateTime end);
}

Now, try to actually implement this interface and host it as a WCF service. Kaboom! An InvalidOperationException will be raised when you invoke ServiceHost.Open. Jeff, I thought you said that methods could be overloaded in WCF. What gives?

As far as the C# compiler is concerned, this is a completely legal piece of code. The interface contains two methods. The methods have the same name, but their signatures are unique since their parameters differ. The interface and methods are decorated with attributes. However, WCF doesn't have any special hooks into the compiler. Consequently, the compiler doesn't have any special knowledge about the attributes. It is simply going to emit their information in the assembly metadata.

When WCF attempts to start the service, it essentially interrogates the metadata to generate a WSDL contract. WSDL is all about technology neutral, message based communication. It doesn't support object-oriented concepts such as inheritance and overloading. (Actually, I think the earliest versions of WSDL allowed overloading to a certain extent, but it has since been removed in the newer versions.) So, WCF basically detects there are two methods with the same name and raises an exception to indicate this isn't allowed even though the code compiled without any errors.

Regardless, WCF still provides the ability to overload methods. This can be achieved by using the name property of the OperationContract attribute. By default, the name of the method will be used for the value of the name property. However, you can explicitly set the value of the name property to provide a unique value. Under the covers, WCF will use the value you supply as the name of the corresponding operation in the generated WSDL.

Here is our previous example revised to use alias method names:

[ServiceContract]
public interface ICalendarService
{
   [OperationContract(Name = "GetScheduledEventsByDate")]
   ScheduledEvent[] GetScheduledEvents(DateTime date);

   [OperationContract(Name = "GetScheduledEventsByDateRange")]
   ScheduledEvent[] GetScheduledEvents(DateTime start, DateTime end);
}

You may be wondering how the method will appear to the consumer of the service. Will it appear as two different names (based on the the alias) or as overloaded methods with the same name? This will depend upon the proxy class used by your client. If you use the proxy class that is automatically generated by svcutility.exe, the alias method names will be used. However, you can manually edit the generated proxy class to achieve the appearance of overloaded methods on the client as well. This can be accomplished by applying the same attributes to the methods defined in the interface that is used by the proxy class.

As you can see, overloading of methods is possible in WCF. However, there is another question that remains to be answered. Just because you have the ability to overload methods exposed in the contract, should you do it? There are a lot of varied opinions about this type of question. It is hard to say whether any of them are definitively right or wrong. Personally, I am in the camp that you should avoid it unless there is a compelling reason.

Don't get me wrong. There is absolutely nothing wrong with method overloading in the realm of object oriented programming. However, object oriented development doesn't translate directly to service oriented development. I don't think it is generally a good idea to expose overloaded methods as part of a service contract. It is a specific object-oriented concept that doesn't really fit into the semantics of service orientation.

At any rate, to answer the question of the person at the MSDN event...yes, it is possible to overload methods exposed as operation contracts in WCF.

Hosting multiple WCF services under a single windows service

2009-10-07T16:06:20+09:00

using System;

using System.Collections.Generic;

using System.ServiceModel;

using System.ServiceProcess;

namespace Server

{

public partial class Service1 : ServiceBase

{

public Service1()

{

InitializeComponent();

}

private readonly ServiceManager serviceManager = new ServiceManager();

protected override void OnStart(string[] args)

{

base.OnStart(args);

serviceManager.OpenAll();

}

protected override void OnStop()

{

serviceManager.CloseAll();

base.OnStop();

}

public class ServiceManager

{

readonly List<ServiceHost> serviceHosts = new List<ServiceHost>();

public void OpenAll()

{

OpenHost<Service1>();

OpenHost<Service2>();

OpenHost<Service3>();

}

public void CloseAll()

{

foreach (ServiceHost serviceHost in serviceHosts)

{

serviceHost.Close();

}

private void OpenHost<T>()

{

Type type = typeof(T);

ServiceHost serviceHost = new ServiceHost(type);

serviceHost.Open();

serviceHosts.Add(serviceHost);

}

Managed Extensibility Framework : Overview

2009-07-28T16:56:47+09:00

http://channel9.msdn.com/pdc2008/TL33/

Managed Extensibility Framework

2009-07-28T16:49:47+09:00

출처 : http://blogs.msdn.com/kcwalina/archive/2008/04/25/MEF.aspx

Several months ago we formed what we call Application Framework Core team. The charter of the team is to play the same role in the application frameworks space (WinForms, ASP.NET, WPF, Silverlight) as the Base Class Libraries (BCL) team plays at the bottom of the platform stack.

The BCL team did a good job fulfilling the role of the team responsible for decreasing duplication and providing common abstractions for the low levels of the platform. Unfortunately, we did not have a similar team really focused on these sets of issues higher up on the stack. This resulted in some unfortunate duplication (like several data binding models for each of the application models, different dependency property system for WPF and WF) and lack of common abstractions (what undo APIs should my generic application plugin call?) for application model code. The Application Framework Core team is now in place to start addressing the problems.

One of the first concrete projects that we are working on and are ready to slowly talk about is what we call the Managed Extensibility Framework (MEF). We observed that there are more and more places in the .NET Framework itself and increasingly managed applications (like Visual Studio) where we want to provide, or already provide, hooks for 3^rd party extensions. Think about TraceListener plugins for the TraceSource APIs, pluggable rules for Visual Studio Code Analysis (and the standalone FxCop), etc. In the absence of a built-in extensibility framework (like MEF), our developers who want to enable such extensions often are forced to create custom mechanisms, thus duplication. We hope that MEF will both stop such duplication and encourage/enable more extensibility in the Framework and applications built on top of it.

We will blog more details about MEF in the upcoming months, but here are some early details (subject to changes, of course): MEF is a set of features referred in the academic community and in the industry as a Naming and Activation Service (returns an object given a “name”), Dependency Injection (DI) framework, and a Structural Type System (duck typing). These technologies (and other like System.AddIn) together are intended to enable the world of what we call Open and Dynamic Applications, i.e. make it easier and cheaper to build extensible applications and extensions.

The work we are doing builds on several existing Microsoft technologies (like the Unity framework) and with feedback from the DI community. The relationship with the Unity team is the regular relationship between the P&P group and the .NET Framework group where we trickle successful technologies and ideas from the P&P team into the .NET Framework after they have passed the test of time. We have done this with some features in the diagnostics, exceptions, and UI space in the past. The direct engagement with the DI community is also starting. We gave a talk on the technology at last week’s MVP Summit, and talked with Jeremy Miller (the owner of Structure Map) and Ayende Rahien (Rhino Mocks) . We got lots of great feedback from Jeremy and Ayende and I think their experience in the DI space and their feedback will be invaluable as the project evolves. Thanks guys! We are of course also looking forward to engaging others in the DI community.

And finally here is some code showing basic scenarios our framework supports:

Creating an Extension Point in an Application:

public class HelloWorld {

[Import] // import declares what a component needs

public OutputDevice Output;

public void SayIt() {

Output.WriteLine("Hello World");

}

// Extension Contract

public abstract class OutputDevice {

void WriteLine(string output)

}

1. Creating an Extension

[Export(typeof(OutputDevice))] // export declared what a component gives

public class CustomOutput : OutputDevice {

public void WriteLine(string output) {

Console.WriteLine(output);

}

2. Magic that makes composes (DIs) the application with the extensions.

var domain = new ComponentDomain();

var hello = new HelloWorld();

// of course this can be implicit

domain.AddComponent(hello);

domain.AddComponent(new CustomOutput());

domain.Bind(); // bind matches the needs to gives

hello.SayIt();

Expecting lots of questions, I will preemptively answer (J): we don’t yet know whether or when we will ship this. We do have working code and we are looking into releasing a preview/CTP of the technology. For now we would be very interested in high level feedback. What do you think hinders extensibility in frameworks and application? Where would you like the Framework to be more extensible? What DI framework features you need, like, want, and use on daily basis? i.e. is constructor injection required?

And lastly, we are hiring! :-)

Published 25 April 08 09:45 by kcwalina

Simple Introduction to Extensible Applications with the Managed Extensions Framework

2009-07-28T16:38:08+09:00

출처 : http://blogs.msdn.com/brada/archive/2008/09/29/simple-introduction-to-composite-applications-with-the-managed-extensions-framework.aspx

Recently my team has been working on the Managed Extensions Framework (MEF)... I have gotten a chance to explain the concept to folks and I think I have discovered a way to talk about MEF that folks can easily get. So I thought I'd spend a little time walking through a *very* simple MEF example as a way to introduce folks to the power of extensible applications in general, and MEF in particular.

BTW, you can download the current MEF CTP and the final working sample.

Background

Let's start with the most simple example: Hello World!

   1: using System;

2:

   3: class Program

   4: {

   5:     public void Run()

   6:     {

   7:         Console.WriteLine("Hello World!");

   8:         Console.ReadKey();

   9:     }

  10:     static void Main(string[] args)

  11:     {

  12:         Program p = new Program();

  13:         p.Run();

  14:     }

  15: }

Now, you might now always want to print the same string, so let's refactor slightly to pull the string out..

   1: public string Message { get; set; }

2:

   3: public void Run()

   4: {

   5:     Console.WriteLine(Message);

   6:     Console.ReadKey();

   7: }

This looks nice, now we need to add the message... well, the actual text is a separate concern, as such it should be in a different class. Such as:

   1: public class SimpleHello

   2: {

   3:     public string Message

   4:     {

   5:         get

   6:         {

   7:             return "hello world!!";

   8:         }

   9:     }

  10: }

Now we simply need wire these up:

   1: public void Run()

   2: {

   3:     SimpleHello hello = new SimpleHello();

   4:     Message = hello.Message;

5:

   6:     Console.WriteLine(Message);

   7:     Console.ReadKey();

   8: }

This works, but something looks odd about line 3 and 4... We have introduced tight coupling back.. What we really want to do is externalize lines 3 and 4, so they can be controlled without effecting the rest of the logic of the program.

Enter MEF

Add a Reference to the System.ComponentModel.Composition.dll assembly found in the bin directory of the MEF zip.

Add

   1: using System.ComponentModel.Composition;

Now in the Program class, we need to import a value for Message -- that is, we want to specify that someone outside of this program needs to supply a message. Then we need to remove our tight coupling. Note in line 4-5 and we saying we want to import the value for Message. Here I am showing doing it by type (string).. because basic types such as strings might be pretty common, consider using a named import such as [Import("Message")]

   1: class Program

   2: {

3:

   4:     [Import]

   5:     public string Message { get; set; }

6:

   7:     public void Run()

   8:     {

   9:        // SimpleHello hello = new SimpleHello();

  10:         //Message = hello.Message;

11:

  12:         Console.WriteLine(Message);

  13:         Console.ReadKey();

  14:     }

Now in the SimpleHello class we need to export the Message property. This tells the system it can be used to satisfy requirements. Notice line 3 and 4 and am marking it with an Export attribute.. Again, this exports it by type (string in this case). As with above, you might want to do it with an explicit name for a more real world example [Export("Message")]

   1: public class SimpleHello

   2: {

   3:     [Export]

   4:     public string Message

   5:     {

   6:         get

   7:         {

   8:             return "hello world!!";

   9:         }

  10:     }

  11: }

Now we need to tell MEF to wire these up for us.

   1: public void Run()

   2: {

   3:     //SimpleHello hello = new SimpleHello();

   4:     //Message = hello.Message;

   5:     var catalog = new AttributedAssemblyPartCatalog(Assembly.GetExecutingAssembly());

   6:     var container = new CompositionContainer(catalog.CreateResolver());

   7:     container.AddPart(this);

   8:     container.Compose();

9:

10:

  11:     Console.WriteLine(Message);

  12:     Console.ReadKey();

  13: }

In line 5, we create a catalog -- that tells MEF where to look for imports and exports. In this case, we are saying the currently running assembly. There are tons of different parts catalogs, we will look at some later and you can of course build your own.

in line 6, we create a Composition container-- this is effectively the soup that all the different parts will be wired up together.

In line 7, we add this instance of Program to the container so that its dependencies get wired up.

In line 8, we do the compose magic. this is where the Message property of Program gets set.

Notice, in this case the wire up is done by matching types (String to String)... clearly that isn't always the right way, we will look at other ways to wire up later.

Run it and you get the expected output of "hello world!".

Now let's add another message, just to be a little more fun...

   1: public class MoreMessages

   2: {

   3:     [Export]

   4:     public string FunMessage

   5:     {

   6:         get

   7:         {

   8:             return "This is getting fun!";

   9:         }

  10:     }

  11: }

Now run.. It blows up! Why? Well, let's look at the exception:

System.ComponentModel.Composition.CompositionException Error : Multiple exports were found that match the constraint '(composableItem.ContractName = \"System.String\")'. The import for this contract requires a single export only."

From the error it looks like we provided too many ways to satisfy the Import... MEF didn't know which one to pick. Of course you can programmatically get in there and help, you can also just remove the export from one of the messages... but more fun, you can actually tell MEF you are able to deal with zero or more results. Change the Message property of Program as follows:

   1: [Import]

   2: public IEnumerable<string> Messages { get; set; }

Notice we changed the return type to be a collection of strings rather than just one string.

Now change the usage code slightly and we get:

   1: class Program

   2: {

3:

   4:     [Import]

   5:     public IEnumerable<string> Messages { get; set; }

6:

   7:     public void Run()

   8:     {

   9:         //SimpleHello hello = new SimpleHello();

  10:         //Message = hello.Message;

  11:         var catalog = new AttributedAssemblyPartCatalog(Assembly.GetExecutingAssembly());

  12:         var container = new CompositionContainer(catalog.CreateResolver());

  13:         container.AddPart(this);

  14:         container.Compose();

15:

  16:         foreach (var s in Messages)

  17:         {

  18:             Console.WriteLine(s);

  19:         }

20:

21:

  22:         Console.ReadKey();

  23:     }

Wow -- we get both messages! Pretty cool...

More Value of MEF

Ok, I think we can all agree that we added a little complexity if all we were going to do is factor what was in the same assembly. MEF really shines when you have separate independent groups working on different components. By definition these are often in different assemblies with cross no dependencies. To show how MEF supports this, let's add a new Class Library project to our solution. Call it ExternalMessages and add a reference to the System.ComponentModel.Composition.dll assembly.

Add the following class.

   1: using System;

   2: using System.ComponentModel.Composition;

3:

   4: public class Class1

   5: {

   6:     [Export]

   7:     public string Message

   8:     {

   9:         get

  10:         {

  11:             return "I am starting to get it...";

  12:         }

  13:     }

  14: }

Now we need to wire up this class into the catalog... Notice in line 6, we change the catalog to look in a directory for the parts...

   1: public void Run()

   2:  {

   3:      //SimpleHello hello = new SimpleHello();

   4:      //Message = hello.Message;

   5:      var catalog = new DirectoryPartCatalog(@"..\..\..\ExternalMessages\bin\Debug");

   6:          // new AttributedAssemblyPartCatalog(Assembly.GetExecutingAssembly());

   7:      var container = new CompositionContainer(catalog.CreateResolver());

   8:      container.AddPart(this);

   9:      container.Compose();

10:

  11:      foreach (var s in Messages)

  12:      {

  13:          Console.WriteLine(s);

  14:      }

15:

16:

  17:      Console.ReadKey();

  18:  }

Note: DirectoryPartCatalog also supports relative paths that will look for a path under the current AppDomain.CurrentDomain.BaseDirectory. For example:
new DirectoryPartCatalog(@”.\extensions\”);

Run it and we get our new message!

Cool, but we lost our old messages, and I kind of liked them too... Well, luckily, we have an aggregate part catalog that can take parts from several sources.

   1: public void Run()

   2:  {

   3:      //SimpleHello hello = new SimpleHello();

   4:      //Message = hello.Message;

   5:      var catalog = new AggregatingComposablePartCatalog();

   6:         catalog.Catalogs.Add (new DirectoryPartCatalog(@"..\..\..\ExternalMessages\bin\Debug"));

   7:         catalog.Catalogs.Add (new AttributedAssemblyPartCatalog(Assembly.GetExecutingAssembly()));

   8:      var container = new CompositionContainer(catalog.CreateResolver());

   9:      container.AddPart(this);

  10:      container.Compose();

Pretty cool, we now get all the messages!

Finally, just to bring up the point here... I created a bunch of different assemblies that exported Messages... All I need to do is point the catalog at them and go.

   1: public void Run()

   2: {

   3:     //SimpleHello hello = new SimpleHello();

   4:     //Message = hello.Message;

   5:     var catalog = new AggregatingComposablePartCatalog();

   6:        catalog.Catalogs.Add (new DirectoryPartCatalog(@"..\..\..\ExternalMessages\bin\Debug"));

   7:        catalog.Catalogs.Add(new DirectoryPartCatalog(@"..\..\..\ExtraMessages"));

   8:        catalog.Catalogs.Add (new AttributedAssemblyPartCatalog(Assembly.GetExecutingAssembly()));

   9:     var container = new CompositionContainer(catalog.CreateResolver());

  10:     container.AddPart(this);

  11:     container.Compose();

12:

See where I added them in line 7.. Now just copy the assemblies into this directory and they become available for this program to use! Notice how I don't need to change any of the logic of the core program as I add more and more extensions.

Taking MEF to the Next Level

Above I showed the simplest scenario... let's get a bit more powerful. If you pick apart the main program looking for tight coupling, that Console.WriteLine() will really stand out.. What if you want to log to a file, call a web service or print to HTML or WPF? Tightly coupling to the Console does not make that easy. How can we use the seperation of concerns principle and MEF to get rid of this tight coupling?

First, we need to define an interface that describes the contract for outputting strings. To ensure correct dependency management go ahead and create a new Library project called SharedLibrary, add this interface and reference this project from each of the other team projects.

   1: namespace SharedLibrary

   2: {

   3:     public interface IOutputString

   4:     {

   5:         void OutputStringToConsole(string value);

   6:     }

   7: }

Now, back in the main program we can factor out the Console.WriteLine ()...

   1: class Program

   2: {

   3:     [Import]

   4:     public IEnumerable<string> Messages { get; set; }

5:

   6:     [Import]

   7:     public IOutputString Out { get; set; }

8:

   9:     public void Run()

  10:     {

  11:         //SimpleHello hello = new SimpleHello();

  12:         //Message = hello.Message;

  13:         var catalog = new AggregatingComposablePartCatalog();

  14:            catalog.Catalogs.Add (new DirectoryPartCatalog(@"..\..\..\ExternalMessages\bin\Debug"));

  15:            catalog.Catalogs.Add(new DirectoryPartCatalog(@"..\..\..\ExtraMessages"));

  16:            catalog.Catalogs.Add (new AttributedAssemblyPartCatalog(Assembly.GetExecutingAssembly()));

  17:         var container = new CompositionContainer(catalog.CreateResolver());

  18:         container.AddPart(this);

  19:         container.Compose();

20:

  21:         foreach (var s in Messages)

  22:         {

  23:             Out.OutputString(s);

  24:         }

25:

26:

  27:         Console.ReadKey();

  28:     }

In line 6-7 we define Out and in line 23 we change from Console.WriteLine() to Out.OutputString().

Now in External Messages project add the following class

   1: [Export(typeof(IOutputString))]

   2: public class Class1 : IOutputString

   3: {

   4:     public void OutputString(string value)

   5:     {

   6:         Console.WriteLine("Output=" + value);

   7:     }

8:

9:

Notice here we are explicitly saying the expert type to be that shared interface. Now when we run it we get:

To make things more interesting, lets add another implementation of IOutputString that is a bit more creative.

   1: [Export(typeof(IOutputString))]

   2: public class ReverseOutputter : IOutputString

   3: {

4:

   5:     public void OutputString(string value)

   6:     {

   7:         foreach (var s in value.Split().Reverse())

   8:         {

   9:             Console.ForegroundColor = (ConsoleColor)(s.Length % 10);

  10:             Console.Write(s + " ");

  11:         }

  12:         Console.WriteLine();

  13:     }

  14: }

Just running this now would give us an error right, because we told MEF we wanted exactly one IOutputString... if we change our code to work with multiple we get more fun! In line 7 we changed to request a set of IOutputStrings and in line 19 we changed to loop through all the output devices.

   1: class Program

   2: {

   3:     [Import]

   4:     public IEnumerable<string> Messages { get; set; }

5:

   6:     [Import]

   7:     public IEnumerable<IOutputString> OutputSet { get; set; }

8:

   9:     public void Run()

  10:     {

  11:         var catalog = new AggregatingComposablePartCatalog();

  12:            catalog.Catalogs.Add (new DirectoryPartCatalog(@"..\..\..\ExternalMessages\bin\Debug"));

  13:            catalog.Catalogs.Add(new DirectoryPartCatalog(@"..\..\..\ExtraMessages"));

  14:            catalog.Catalogs.Add (new AttributedAssemblyPartCatalog(Assembly.GetExecutingAssembly()));

  15:         var container = new CompositionContainer(catalog.CreateResolver());

  16:         container.AddPart(this);

  17:         container.Compose();

18:

  19:         foreach (var Out in OutputSet)

  20:         {

  21:             foreach (var s in Messages)

  22:             {

  23:                 Out.OutputString(s);

  24:             }

  25:         }

26:

27:

  28:         Console.ReadKey();

  29:     }

Now when we run it we get all our messages in all our outputs..

Now the only real logic in our main is the nested foreach loops. We may very well like to change that in the future as well... so let's see if we can abstract that out using exactly the same techniques we have talked about already.

   1: class Program

   2: {

   3:     [Import]

   4:     public IEnumerable<string> Messages { get; set; }

5:

   6:     [Import]

   7:     public IEnumerable<IOutputString> OutputSet { get; set; }

8:

   9:     [Import("OutputMessages")]

  10:     public Action<IEnumerable<IOutputString>, IEnumerable<string>> OutputMessages { get; set; }

11:

  12:     public void Run()

  13:     {

  14:         var catalog = new AggregatingComposablePartCatalog();

  15:            catalog.Catalogs.Add (new DirectoryPartCatalog(@"..\..\..\ExternalMessages\bin\Debug"));

  16:            catalog.Catalogs.Add(new DirectoryPartCatalog(@"..\..\..\ExtraMessages"));

  17:            catalog.Catalogs.Add (new AttributedAssemblyPartCatalog(Assembly.GetExecutingAssembly()));

  18:         var container = new CompositionContainer(catalog.CreateResolver());

  19:         container.AddPart(this);

  20:         container.Compose();

21:

22:

  23:         OutputMessages(OutputSet, Messages);

24:

  25:     }

First, in line 9-10 we define an Action that can do the output... and in line 23 we remove our nested foreach loops and replace it with a call to this method. Now all we have in our Main is effectively wiring up components. Very loosely coupled!

Now let's add an option for how the messages are outputted. It would be very easy to define a config file option for selecting these and returning the correct one. Notice that MEF knows that this method follows the contract of the Action delegate above, so it does all the wireup for us.

   1: [Export("OutputMessages")]

   2: public void OutputByMessage(IEnumerable<IOutputString> outputSet, IEnumerable<string> messages)

   3: {

   4:     foreach (var s in messages)

   5:     {

   6:         foreach (var Out in outputSet)

   7:         {

   8:             Out.OutputString(s);

   9:         }

  10:     }

  11:     Console.ReadKey();

  12: }

I would love to hear what you think? Can you think of usage for MEF in your applications? I'd also love for you to grab the final sample and see how many different ways you can extend it.. Here is the final working sample. Enjoy!

Published 29 September 08 08:21 by BradA

MEF Preview 6 공개

2009-07-26T17:54:45+09:00

출처 : http://vsts2010.net/101

MEF(Managed Extensibility Framework) 이 2009년 7월 13일에 릴리즈되어 14일에 공개가 되었습니다. 특히 MEF 는 .NET Framework 4.0 에 포함이 되어있으며, CodePlex 에서 굉장히 빠른 속도로 발전하고 있는 프레임워크 중에 하나 입니다.

CodePlex MEF 사이트에 등록된 릴리즈 노트 입니다.

그 중에서 몇 가지만 살펴보도록 하겠습니다.

실버라이트 3 지원

특히 이번에 눈여겨 볼 만한 것이 Silverlight 3 를 지원하는 것입니다. 이미 Preview 5 이전의 MEF 에서는 실버라이트를 지원하기 위해 코드에서 전처리 명령 구문을 사용하여 프레임워크 실버라이트가 지원되긴 했습니다. 그것을 기반으로 이번 Preview 6 버전에서는 실버라이트 3 용 솔루션이 제공됩니다. 이 솔루션을 통해 실버라이트용 MEF 프레임워크를 빌드 하시면 됩니다.

ExportAttribute 의 seal 키워드 제거

이번 MEF Preview 6 에서 ExportAttribute 의 seal 키워드가 제거됩니다. 이 전 Preview 5 에서는 ExportAttribute 을 절대 상속할 수 없는 구조였기 때문에 독자적인 Export 를 제공할 수 없었기, Metadata 를 ExportAttribute 와 같은 기능울 개별적으로 지정해야 하는 등의 Export 기능의 확장에 불합리한 구조로 되어있었습니다. 하지만 이번 Preview 6 버전에서는 ExportAttribute 클래스의 seal 키워드가 제거 됨으로써 ExportAttribute 의 확장이 용이하게 되었습니다.

ImportMany 로 통일된 컬렉션 처리

이제 모든 컬렉션은 ImportMany 로 통일되었습니다. Preview 5 에서는 ExportCollection<T> 또는 IEnumerable<T> 와 같이 사용하기도 까다롭고 이것으로 반환된 객체를 처리하기에도 편리한 구조는 아니였습니다. Preview 5 에서도 ImportMany 의 기능이 존재하였지만, 이번 Preview 6 는 이것으로 모든 컬렉션 처리를 하도록 통일되었다는게 혼란스러웠던 부분을 간소화할 수 있을 것 같습니다.

기타 그 밖에도 구조적으로 보다 안정되었고, 메서드나 클래스의 네이밍이 변경되었고, 예외 시에 Composition 동작의 분석을 추적하기 쉽도록 덤프(Dump) 를 뜰 수 있는 로깅 기능 등 다양한 기능이 추가되었습니다. 정식 버전의 MEF 는 어떤 모습으로 나올지 정말 기대가 됩니다. 더 자세한 내용은 아래의 링크를 통해 더 쉽게 설명이 되어있으니 참고 하십시오.

참고문헌
MEF Preview 6 Available
http://blogs.msdn.com/nblumhardt/archive/2009/07/09/mef-preview-6-available.aspx

Querying the CompositionContrainer

2009-07-26T17:53:25+09:00

Querying the CompositionContainer

출처 : http://vsts2010.net/68

CompositionContainer 의 Exported 구성 요소를 취득하기 위해서는 컨테이너에 하나의 구성 요소만이 존재해야 합니다. 쿼리(Query) 를 통해 이러한 객체들이 여러 개 존재할 경우 MEF 는 예외를 발생하게 됩니다.

바로 아래와 같은 경우이죠.

l 하나의 인스턴스를 요청할 때, 인스턴스를 찾지 못했을 경우

l 하나의 인스턴스를 요청할 때, 인스턴스가 여러 개일 경우

GetExportedObject

일반적으로 ExportAttribute 에 인자가 전달되지 않은 경우는 클래스의 타입이 키 값이 되어, 아래와 같이 구성 요소를 취득할 수 있습니다.

class Program

{

static void Main(string[] args)

{

var container = new CompositionContainer(new AssemblyCatalog(Assembly.GetExecutingAssembly()));

var export = container.GetExportedObject<Export1>();

export.Say();

Console.ReadKey();

}

[Export]

class Export1

{

public void Say()

{

Console.WriteLine("Export1 Say..");

}

만약, ExportAttribute 에 Contract Name 이 선언이 될 경우는 클래스의 타입 정보와 Contract Name 이 일치해야 구성요소를 취득할 수 있습니다.

class Program

{

static void Main(string[] args)

{

var container = new CompositionContainer(new AssemblyCatalog(Assembly.GetExecutingAssembly()));

var export = container.GetExportedObject<Export2>("export2");

export.Say();

Console.ReadKey();

}

[Export("export2")]

public class Export2

{

public void Say()

{

Console.WriteLine("Export2 Say..");

}

GetExport

만약 여러 개의 구성 요소의 인스턴스가 필요하다면 GetExport 메서드를 통해 Export 의 구성 정보를 가져오면 됩니다.

var exports = container.GetExport<Export1>();

exports.GetExportedObject().Say();

필요하다면 ExportAttribute 의 Contract Name 으로 질의(Query) 할 수 있습니다.

var exports = container.GetExport<Export2>("export2");

exports.GetExportedObject().Say();

아쉽게도 MEF Preview 4 까지 지원하던 C# 3.0 의 Expression 을 통해 질의하는 방법은 MEF Preview 5 이후 없어진 것이 아쉽네요.

GetExportedObjectOrDefault

일반적으로 MEF 에서는 질의(Query) 결과가 없을 경우 예외를 발생하게 되는데, GetExportedObjectOrDefault 메서드를 통해 결과가 없을 경우 Null 값으로 대체할 수 있습니다.

var obj = container.GetExportedObjectOrDefault<Export1>("A");

if( obj != null )

obj.Say();

Recomposition

2009-07-26T17:52:30+09:00

Recomposition

출처 : http://vsts2010.net/42

이전 포스트의 MEF 의 특징 중에 MEF 의 플러그인 모델(Plugin Model) 은 교체가 용이하다고 하였습니다. Composable Part 는 구성 요소로써 고유의 기능을 구현합니다. 그리고 MEF 는 각각의 Composable Part 를 조립하여 다양한 컴포넌트 또는 애플리케이션을 완성합니다.

어떠한 경우에는 특정한 구성 구성요소를 사용하다가 그것이 필요 없어질 경우 구성 요소를 언로드(Unload) 하거나 다른 구성요소로 교체할 필요가 있습니다.

MEF 의 이러한 유연함의 예를 들어보죠.

예를 들어, 어플리케이션의 로그(Log) 기능을 생각해볼 수 있습니다. 만약 어플리케이션이 동작하는 환경이 인터넷에 연결되지 않는 환경이라면 사용자의 컴퓨터 로컬에 로그를 기록하다가, 인터넷에 연결될 경우 외부 데이터베이스로 로그를 기록하는 시나리오를 가정할 수 있습니다. 그리고 이러한 기능 또는 요구 사항이 언제 변경될지도 모르는 일입니다.

일단 위의 시나리오를 구현하기 여러 가지 고려해야 할 사항이 있고, 기능 또는 요구 사항이 변경될 경우도 고려해야 합니다. 결국, MEF 는 이러한 변화에 굉장히 유연하게 대처할 수 있습니다.

MEF 에서 ImportAttribute 의 AllowRecomposition 프로퍼티를 통해 구성 요소를 런타임(Runtime) 시 동적(Dynamic) 으로 교체할 수 있도록 합니다.

아래는 위의 예로 든 시나리오를 구현하기 위해 작성한 간단한 소스 코드 입니다.

ILogger 인터페이스

public interface ILogger

{

void Write();

}

ILogger 인터페이스는 Write 메서드를 통해 로그를 기록할 수 있는 예입니다.

TextLogger 클래스

[Export(typeof(ILogger))]

public class TextLogger : ILogger

{

public void Write()

{

Console.WriteLine("Logged TextLogger");

}

DatabaseLogger 클래스

[Export(typeof(ILogger))]

public class DatabaseLogger : ILogger

{

public void Write()

{

Console.WriteLine("Logged DatabaseLogger");

}

LoggerContext 클래스

[Export]

public class LoggerContext

{

[Import(AllowRecomposition=true)]

public ILogger Context { get; set; }

[ImportingConstructor]

public LoggerContext(ILogger sender)

{

}

여기에서 ImportAttribute 의 AllowRecomposition 프로퍼티의 값을 true 로 지정해 주었습니다. AllowRecomposition 프로퍼티가 true 일 경우 Imported 된 구성 요소를 동적(Dynamic)하게 교체할 수 있도록 합니다.

Main 어플리케이션

class Program

{

static void Main(string[] args)

{

Program p = new Program();

p.Run();

}

void Run()

{

var catalog = new AggregateCatalog(new TypeCatalog(typeof(LoggerContext)));

var container = new CompositionContainer(catalog);

var batch = new CompositionBatch();

var defaultPart = batch.AddPart(new TextLogger());

container.Compose(batch);

var obj = container.GetExportedObject<LoggerContext>();

obj.Context.Write();

batch = new CompositionBatch();

batch.RemovePart(defaultPart);

batch.AddPart(new DatabaseLogger());

container.Compose(batch);

obj.Context.Write();

}

이 코드는 처음에 TextLogger 를 사용하다가, 필요 없어진 TextLogger 를 제거하고 DatabaseLogger 로 교체하는 코드입니다.

아래는 위의 소스 코드를 실행한 결과입니다.

[그림1] 소스 코드 실행 결과

Wow! Recomposition

사실 이러한 것이 기존에는 기능의 정의 또는 요구 사항에 따라 직접 구현할 수 있었지만, MEF 의 특징인 플러그인 모델(Plugin Model) 은 이러한 고민에 대해 좋은 방법을 제공해 줍니다. 개발자는 자신이 구현해야 할 기능에 더 충실하고, 비즈니스 로직에 대한 고민만을 하면 됩니다. 그리고 정책에 따라 그것을 집행하는 결정권을 가진 자는 구현된 구성 요소를 조립하고 교체하여 기존의 정적인(Static) 어플리케이션에게 동적인(Dynamic) 유연함을 제공합니다.

기존에 정적인 어플리케이션은 변화에 따라 유지 보수를 위해 지속적인 많은 리소스가 필요하였지만, 플러그인 모델(Plugin Model) 의 동적인 어플리케이션은 그러한 변화에 능동적으로 대처할 수 있는 큰 기쁨을 줄 수 있을 것입니다.

Strongly Typed Metadata

2009-07-26T17:51:37+09:00

Strongly Typed Metadata

출처 : http://vsts2010.net/34

지난 포스트의 [MEF] 7. Exports and Metadata를 통해 Export 의 Contract 에 Metadata 를 제공하는 방법을 알아보았습니다.

MetadataAttribute 을 선언하여 Export 의 Metadata 를 제공하는 방법입니다.

[Export(typeof(IMessageSender))]

[ExportMetadata("SenderType", "Email")]

[ExportMetadata("Logging", true)]

public class EmailMessageSender : IMessageSender

{

public void Say()

{

Console.WriteLine("Import EmailMessageSender");

}

Export 에 Metadata 를 제공해 주어서 무척 고맙지만, 위의 방법처럼 MetadataAttribute 를 선언하는 방법을 사용하기에 그다지 내키지 않는 구석이 있습니다.

아무래도 아래와 같은 이유 때문이겠죠?

l 메타데이터의 타입 불안정

l 빌드 시 오류를 해결이 어려움

l 사용상 모든 키값을 외우기 어렵고, 오타 발생 위험

위의 이유 때문에 Metadata 를 사용하기 위해 강력한 타입을 원하게 될 것입니다. 그리고 강력한 타입의 Metadata 를 사용하길 권장 드립니다.

Declaring Strongly Typed Metadata

Attribute 을 상속받아 Export 의 Metadata 를 Strongly Typed 으로 확장시키는 방법입니다.

아래의 Stringly Typed Metadata 를 위해 Attribute 클래스를 만드는 소스 코드 입니다.

[MetadataAttribute]

[AttributeUsage(AttributeTargets.Class, AllowMultiple=false)]

public class MessageSenderTypeAttribute : Attribute

{

public MessageSenderTransport Transport { get; set; }

public bool IsSecure { get; set; }

public MessageSenderTypeAttribute() { }

public MessageSenderTypeAttribute(MessageSenderTransport transport)

: this(transport, false)

{

}

public MessageSenderTypeAttribute(MessageSenderTransport transport, bool isSecure)

{

this.Transport = transport;

this.IsSecure = IsSecure;

}

public enum MessageSenderTransport

{

Email,

Phone,

Sms

}

Strongly Typed Metadata 를 위한 Attribute 클래스를 완성하였으면, 이것을 그대로 ExportAttribute 과 함께 추가적으로 선언하면 됩니다.

그리고 ExportAttribute 을 선언한 코드에 위의 Attribute 특성을 부여합니다. 아래는 그 소스 코드의 일부입니다.

[Export(typeof(IMessageSender))]

[MessageSenderType(MessageSenderTransport.Email)]

public class EmailMessageSender : IMessageSender

{

public void Say()

{

Console.WriteLine("Import EmailMessageSender");

}

[Export(typeof(IMessageSender))]

[MessageSenderType(MessageSenderTransport.Phone, true)]

public class PhoneMessageSneder : IMessageSender

{

public void Say()

{

Console.WriteLine("Import PhoneMessageSneder");

}

[Export(typeof(IMessageSender))]

[MessageSenderType(Transport=MessageSenderTransport.Sms, IsSecure=true)]

public class SmsMessageSender : IMessageSender

{

public void Say()

{

Console.WriteLine("Import SmsMessageSender");

}

그렇다면 아래와 같이 Metadata 를 Strongly Typed 으로 질의(Query) 할 수 있게 됩니다.

아래의 소스 코드는 지난 포스트의 소스 전체 소스 코드를 참고하십시오.

foreach (var export in program.Sender)

{

if ((MessageSenderTransport)export.Metadata["Transport"] == MessageSenderTransport.Sms)

{

export.GetExportedObject().Say();

if ((bool)export.Metadata["IsSecure"] == true)

{

Console.WriteLine("Security message");

}

위의 소스 코드 실행 결과는 원하던 결과대로 다음과 같습니다.

[그림1] Strongly Typed 질의 결과

하지만 아직도 문제는 남아 있는 것 같아 보이네요. Strongly Typed 으로 Export Metadata 를 선언하였지만 여전히 질의(Query) 과정은 똑같은 문제점을 가지고 있습니다.

l 메타데이터의 질의(Query) 과정의 타입 불안정

l 빌드 시 오류를 해결이 어려움

l 사용상 모든 키값을 외우기 어렵고, 오타 발생 위험

More Strongly Typed Metadata Query

Metadata 를 질의(Query) 하기 위해 MEF 는 보다 강력하게 Import 하는 방법을 제공해 줍니다. 확장된 MetadataAttribute 에 인터페이스(Interface) 를 구현하도록 하여 Import 시에 인터페이스(Interface) 를 통한 Metadata 를 질의(Query) 하는 방법입니다.

우선 Attribute 에 사용되는 프로퍼티를 인터페이스로 선언합니다.

public interface IMessageSenderTypeAttribute

{

bool IsSecure { get; }

MessageSenderTransport Transport { get; }

}

단, 여기에서 반드시 Getter 만 선언하셔야 합니다. Setter 를 선언하시면 MEF 는 Setter 프로퍼티로 인해 유효하지 않는 Attribute 으로 인식하여 예외를 발생하게 됩니다.

아래의 소스 코드는 Metadata Attribute 클래스에 위의 인터페이스를 구현한 코드 입니다.

[MetadataAttribute]

[AttributeUsage(AttributeTargets.Class, AllowMultiple=false)]

public class MessageSenderTypeAttribute : Attribute, IMessageSenderTypeAttribute

{

public MessageSenderTransport Transport { get; set; }

public bool IsSecure { get; set; }

public MessageSenderTypeAttribute() { }

public MessageSenderTypeAttribute(MessageSenderTransport transport)

: this(transport, false)

{

}

public MessageSenderTypeAttribute(MessageSenderTransport transport, bool isSecure)

{

this.Transport = transport;

this.IsSecure = IsSecure;

}

이제 Export 의 MetadataView 로 질의할 수 있도록 MetadataView 의 인터페이스를 알려주도록 해야 합니다.

[Import(typeof(IMessageSender))]

ExportCollection<IMessageSender, IMessageSenderTypeAttribute> Sender { get; set; }

아래의 소스 코드는 MetadataView 를 통해 Strongly Typed 으로 Export Metadata 를 질의(Query) 하는 소스 코드 입니다.

[Import(typeof(IMessageSender))]

ExportCollection<IMessageSender, IMessageSenderTypeAttribute> Sender { get; set; }

static void Main(string[] args)

{

Program program = new Program();

program.Run();

foreach (var export in program.Sender)

{

if (export.MetadataView.Transport == MessageSenderTransport.Email)

{

export.GetExportedObject().Say();

}

Exports and Metadata

2009-07-26T17:50:44+09:00

Exports and Metadata

출처 : http://vsts2010.net/33

Export 에 Metadata 를 등록하고 제어하는 방법입니다. 지난 포스트에서 알 수 있듯이 Export 는 구성 요소간에 Contact 를 제공하여 이들을 구성(Composition) 할 수 있는 플러그인 모델(Plugin Model) 을 제공해 줍니다.

하지만 Contract 가 제공되어 구성 요소를 확장하고 구성하는 것은 매우 용이하다는 것을 알게 되었으나 Contract 로 인해 파생된 다양한 구성 요소를 어떻게 제어하느냐의 고민을 하게 됩니다. 즉, 다양한 구성 요소 가운데 내가 필요로 하는 구성 요소를 골라낼 수 있도록 Metadata 를 제공하여 구성 요소를 질의(Query)할 수 있도록 하는 것입니다.

예를 들어 아래와 같은 Export 구성 요소 중 어떻게 EmailMessageSender 로 Say() 를 호출할 것인가가 문제인 것이죠.

[Export(typeof(IMessageSender))]

public class EmailMessageSender : IMessageSender

{

public void Say()

{

Console.WriteLine("Import EmailMessageSender");

}

[Export(typeof(IMessageSender))]

public class PhoneMessageSneder : IMessageSender

{

public void Say()

{

Console.WriteLine("Import PhoneMessageSneder");

}

[Export(typeof(IMessageSender))]

public class SmsMessageSender : IMessageSender

{

public void Say()

{

Console.WriteLine("Import SmsMessageSender");

}

이런 경우, 원초적인 방법으로 리플랙션(Reflection) 을 이용하여 Type 검사를 통해 EmailMessageSender 를 골라내서 사용하면 되지만, 직접적으로 Type 을 검사하기 위해서는 Tightly Coupling 이 발생하여 결국 유연한 플러그인 모델을 구현하기 위해 아무런 도움이 되지 않습니다.

이러한 방법을 해소하기 위해 또 다른 우회 방법은 리플랙션을 통해 Modules Name 으로 비교하는 방법이지만, 이것 또한 플러그인 모델에서 구성 요소가 교체 되었을 경우를 생각하면 전혀 대응할 수 없는 방법입니다.

MEF 에서는 이런 문제를 해소하기 위해 Contract 에 Metadata 를 제공하며 정적/동적인 방법을 제공해 줍니다.

Attaching Metadata to an Export

Export 에 Metadata 를 제공해 주기 위해서 MEF 에서는 ExportMetadataAttribute 특성을 제공해 줍니다.

[AttributeUsage(AttributeTargets.Class | AttributeTargets.Property | AttributeTargets.Method | AttributeTargets.Field,

AllowMultiple = true, Inherited = false)]

public ExportMetadataAttribute(string name, object value)

왜 ExportMetadata 클래스는 sealed 로 선언이 되었나요?

일반적으로 sealed 로 클래스를 봉인할 경우 리플랙션의 성능이 향상됩니다.

http://msdn.microsoft.com/ko-kr/library/ms229023.aspx

ExportMetadata 는 키와 값(Key/Value) 을 지정하여 Contract 에 Metadata 를 제공해 줄 수 있습니다. 그리고 하나의 Export 에 여러 개의 Metadata 를 제공할 수 있도록 AllowMultiple 을 지원합니다.

Metadata 는 여러 가지의 정보를 포함할 수 있습니다. Export 가 제공하는 기능의 특성을 기술할 수 있으며, 예를 들어, 권한, 로깅, 구성 요소 분류 방법 등이 될 수 있을 것입니다.

아래의 소스 코드는 Metadata 를 지정하는 예를 보여줍니다.

[Export(typeof(IMessageSender))]

[ExportMetadata("SenderType", "Email")]

[ExportMetadata("Logging", true)]

public class EmailMessageSender : IMessageSender

{

public void Say()

{

Console.WriteLine("Import EmailMessageSender");

}

[Export(typeof(IMessageSender))]

[ExportMetadata("SenderType", "Phone")]

public class PhoneMessageSneder : IMessageSender

{

public void Say()

{

Console.WriteLine("Import PhoneMessageSneder");

}

[Export(typeof(IMessageSender))]

[ExportMetadata("SenderType", "Sms")]

public class SmsMessageSender : IMessageSender

{

public void Say()

{

Console.WriteLine("Import SmsMessageSender");

}

Constraining Imports statically

MEF Preview 5 에서는 ImportRequiredMetadataAttribute 클래스가 제거되었습니다.

MEF Preview 4 에서는 선언적인 방법으로 ImportRequiredMetadataAttribute 를 통해 Metadata 를 질의할 수 있었으나, MEF Preview 5 에서는 ImportRequiredMetadataAttribute 클래스가 제거되었습니다.

아마도 추측으로는 ImportRequiredMetadataAttribute 를 선언 시에 여러 개의 구성 요소가 검색될 경우 Exception 이 발생하는데, Exception 을 최소화 하고자 제거가 된 것 같습니다.

혹시 Statically 한 방법으로 ImportRequiredMetadataAttribute 에 대응되는 클래스를 아시면 저에게 알려주세요.

Constraining Imports dynamically

이 방법은 Export 의 ExportMetadata 를 런타임 시에 질의(Query) 하는 방법입니다.

Import 시 ExportCollection<T> 을 사용하여 Export 를 수동적으로 질의(Query) 하는 방법입니다. 이 방법은 지난 포스트의 Lazy Load 를 이용한 방법으로 단지 Metadata 만 질의(Query) 뿐이고, 객체의 생성에 대한 판단은 필요 시에만 GetExportedobject() 메서드를 이용하여 생성할 수 있습니다.

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

using System.ComponentModel.Composition;

using System.ComponentModel.Composition.Hosting;

using System.Reflection;

namespace MetadataSample

{

class Program

{

[Import(typeof(IMessageSender))]

ExportCollection<IMessageSender> Sender { get; set; }

static void Main(string[] args)

{

Program program = new Program();

program.Run();

foreach (var export in program.Sender)

{

if ((string)export.Metadata["SenderType"] == "Email")

export.GetExportedObject().Say();

if (export.Metadata.ContainsKey("Logging") &&

(bool)export.Metadata["Logging"] == true)

Console.WriteLine("Logged success");

}

void Run()

{

var catalog = new AggregateCatalog(new AssemblyCatalog(Assembly.GetExecutingAssembly()));

var container = new CompositionContainer(catalog);

var batch = new CompositionBatch();

batch.AddPart(this);

container.Compose(batch);

}

public interface IMessageSender

{

void Say();

}

[Export(typeof(IMessageSender))]

[ExportMetadata("SenderType", "Email")]

[ExportMetadata("Logging", true)]

public class EmailMessageSender : IMessageSender

{

public void Say()

{

Console.WriteLine("Import EmailMessageSender");

}

[Export(typeof(IMessageSender))]

[ExportMetadata("SenderType", "Phone")]

public class PhoneMessageSneder : IMessageSender

{

public void Say()

{

Console.WriteLine("Import PhoneMessageSneder");

}

[Export(typeof(IMessageSender))]

[ExportMetadata("SenderType", "Sms")]

public class SmsMessageSender : IMessageSender

{

public void Say()

{

Console.WriteLine("Import SmsMessageSender");

}

실행 결과는 예상할 수 있듯이 아래와 같이 런타임 시에 결과를 보여줍니다.

Lazy Exports

2009-07-26T17:49:48+09:00

일반적인 Exports

출처 : http://vsts2010.net/30

Composable Part 를 구성하는 동안 특정 Part 에 대한 요청으로 객체 내부의 객체가 필요할 때가 있습니다. 만약 객체가 이런 연관 관계가 있을 경우 객체 내부에 ImportAttribute 을 선언하여 외부 Part 를 Import 할 수 있습니다. 이런 경우는 객체 내부에 Export 간의 Related 관계를 갖게 됨으로써 자동적으로 객체를 초기화할 수 있게 됩니다. ([MEF] 3. Export 선언 참조)

일반적인 Export 를 통해 객체 내부에 Import 를 선언하는 방법입니다.

class Program

{

static void Main(string[] args)

{

Program p = new Program();

p.Run();

}

void Run()

{

var catalog = new AggregateCatalog(new AssemblyCatalog(Assembly.GetExecutingAssembly()));

var container = new CompositionContainer(catalog);

var batch = new CompositionBatch();

batch.AddPart(this);

container.Compose(batch);

var obj = container.GetExportedObject<EmailMessageSender>();

obj.Sender.Say();

}

[Export]

public class MessageSender

{

public void Say()

{

Console.WriteLine("Say Method");

}

[Export]

public class EmailMessageSender

{

[Import]

public MessageSender Sender { get; set; }

}

Lazy Exports

하지만 비용이 비싼 객체를 생성할 경우 위의 [일반적인 Exports] 는 매우 비효율적일 수 있습니다. 객체 내부의 Import Object 를 사용하지 않을 가능성이 크거나, 객체의 생성 비용이 클 경우는 Lazy Export 를 고려해야 합니다. 그리고 내부 객체가 동기적(Synchronicity)이 아닌 비동기성(Asynchronism) 성격의 객체일 경우에도 반드시 필요한 기법입니다.

이런 경우 내부 객체의 생성을 선택적, 수동적으로 제어하여, 게으른 초기화(Lazy Initialization) 를 할 필요가 있습니다.

아래의 굵은 표시의 코드가 Lazy Export 로 제어하는 코드입니다.

class Program

{

static void Main(string[] args)

{

Program p = new Program();

p.Run();

}

void Run()

{

var catalog = new AggregateCatalog(new AssemblyCatalog(Assembly.GetExecutingAssembly()));

var container = new CompositionContainer(catalog);

var batch = new CompositionBatch();

batch.AddPart(this);

container.Compose(batch);

var obj = container.GetExportedObject<EmailMessageSender>();

obj.Sender.Say();

var lazyObj = container.GetExportedObject<EmailMessageSenderByLazyExport>();

lazyObj.Sender.GetExportedObject().Say();

}

[Export]

public class MessageSender

{

public void Say()

{

Console.WriteLine("Say Method");

}

[Export]

public class EmailMessageSender

{

[Import]

public MessageSender Sender { get; set; }

}

[Export]

public class EmailMessageSenderByLazyExport

{

[Import]

public Export<MessageSender> Sender { get; set; }

}

ImportAttribute 의 프로퍼티를 Export<T> 타입으로 변경하면 내부 객체를 GetExportedObject() 메서드를 이용하여 지연하여 객체를 생성할 수 있습니다.

Catalog 사용

2009-07-26T17:48:59+09:00

Catalog

출처 : http://vsts2010.net/27

Catalog 는 동적으로 Composable Part 를 찾아 Container 에 등록합니다. Composable Part 는 ExportAttribute 으로 Contract 를 선언할 수 있는데 개별적으로 일일이 Composable Part 를 등록하는 것은 너무나 큰 반복 작업이 될 수 있지만, MEF 의 Catalog 로 쉽게 자동적으로 등록을 할 수 있습니다.

Catalog 를 사용하지 않는 Composable Part 의 등록는 매우 고단한 작업입니다. 아래의 예제 소스 코드는 수동으로 Composable Part 를 등록하는 방법입니다.

예제에서는 단지 하나의 Export 를 등록하였지만 실제로 이러한 Composable Part 는 수십에서 수백개를 넘을 수 도 있습니다. 많은 Composable Part 를 동적이고 또는 자동적으로 등록해 주기 위해서 Catalog 를 사용하면 쉽게 해결할 수 있습니다.

이 외에도 Composable Part 를 Catalog 에 등록하는 여러 가지 방법이 있습니다. 아래는 MEF 에서 지원하는 Catalog 입니다.

Assembly Catalog

Assembly Catalog 는 닷넷 어셈블리를 Catalog 로 사용할 수 있습니다.

public AssemblyCatalog(string codeBase)

public AssemblyCatalog(Assembly assembly)

var catalog = new AssemblyCatalog(Assembly.GetExecutingAssembly());

AssemblyCatalog 의 시그너처(Signature) 에서 보듯이 CodeBase 로 Catalog 를 사용할 수 있지만, 실버라이트에서는 CodeBase 를 지원하지 않으므로 실버라이트에서는 CodeBase 로 AssemblyCatalog 를 사용할 수 없습니다.

Directory Catalog

Directory Catalog 를 사용하면 특정 폴더의 어셈블리를 모두 검색하여 Composable Part 를 사용할 수 있습니다.

public DirectoryCatalog(string path)

public DirectoryCatalog(string path, string searchPattern)

Directory Catalog 는 내부적으로 System.IO 의 Directory.GetFiles() 메서드를 사용하여 지정한 폴더의 모든 어셈블리를 검색하도록 하여 Composable Part 를 가져오도록 합니다.

var catalog = new DirectoryCatalog("Addins");

기본적으로 *.DLL 확장자의 어셈블리만 검색하도록 설정되어있고, 어셈블리 파일의 검색 패턴을 지정하여 검색할 수 있습니다.

var catalog = new DirectoryCatalog("Addins", "*.exe");

아마 MEF 의 예제중에 XFileExplorer 처럼 특정 폴더에 어셈블리를 복사해 넣으면 자동으로 Composable Part 가 로드되는 예제가 있는데, 이것은 DirectoryCatalog 가 자동으로 처리해 주는 것이 아니라 FileSystemWatcher 클래스를 이용하여 직접 구현해야 합니다.

FileSystemWatcher 로 파일의 변경이 감지되면 DirectoryCatalog 의 Refresh() 메서드를 이용하여 폴더를 재검색 또는 새로고침을 할 수 있습니다.

Aggregation Catalog

Aggregation Catalog 는 복합적인 Catalog 를 사용할 수 있도록 합니다. 만약 Assembly Catalog 와 Directory Catalog 등을 동시에 사용하여 Composable Part 를 가져오도록 하려면 Aggregation Catalog 를 사용하면 됩니다.

public AggregateCatalog(params ComposablePartCatalog[] catalogs)

Aggregation Catalog 의 생성자는 params 로 인자를 받을 수 있습니다.

var catalog = new AggregateCatalog( new AssemblyCatalog(Assembly.GetExecutingAssembly()),

new DirectoryCatalog("."));

Type Catalog

Type Catalog 는 Composable Part 를 Type 으로 개별적으로 사용하도록 합니다. 가장 단순하고 무식(?)한 방법일 수도 있지만 세세한 제어가 필요할 때 사용 가능한 Catalog 일 것 같습니다.

public TypeCatalog(params Type[] types)

public TypeCatalog(IEnumerable<Type> types)

var catalog = new TypeCatalog(typeof(EMailMessageSender), typeof(PhoneMessageSender));

Using catalog with a Container

이제 Catalog 를 Composable Container 에서 Composition 하도록 넘겨주는 일만 남았습니다.

public CompositionContainer()

public CompositionContainer(params ExportProvider[] providers)

public CompositionContainer(ComposablePartCatalog catalog, params ExportProvider[] providers)

var container = new CompositionContainer(catalog);

Imports 선언

2009-07-26T17:46:05+09:00

Import 선언

출처 : http://vsts2010.net/21

MEF 의 구성 요소에 System.ComponentModel.Composition.ImportAttribute 특성을 선언하여 Import 를 선언할 수 있습니다. Import 는 Export 와 사용 방법이 매우 유사합니다. Import 는 프로퍼티(Properties), 필드(Fields), 생성자(Constructors) 에 선언할 수 있으며, 계약된 Export 구성 요소들을 Import 할 수 있습니다.

Property Import

프로퍼티로 값을 가져오기 위해 ImportAttribute 특성을 선언하면 됩니다.

Import 특성은 세 가지의 시그너처(Signature) 를 제공합니다.

public ImportAttribute();

public ImportAttribute(string contractName);

public ImportAttribute(Type contractType);

일반적으로 타입을 명시하지 않을 경우 프로퍼티의 타입이 Export 의 계약(Contract) 을 결정하게 됩니다.

아래는 프로퍼티에 Import 를 사용하는 방법입니다.

[Import]

MessageProcess MessageProcess { get; set; }

Field Import

필드의 Import 는 프로퍼티에 Import 를 선언하는 방법과 동일합니다.

[Import]

MessageProcess _messageProcess;

Constructor Parameters (생성자 파라메터)

Constructor Parameters 는 ImportingConstructor 특성을 사용하여 정의합니다. 특히 Constructor Parameters 는 여러 구성 요소를 사용하기 위해 프로퍼티 또는 필드로 선언되는 Import 의 선언을 생략할 수 있어 편리하게 사용할 수 있습니다. 또한, 암시적인 Import 가 가능하기 때문에 수동적으로 이것을 제어할 필요가 없으며, 구성 요소의 교체가 매우 용이합니다.

아래의 코드는 ImportingConstructor 특성을 이용하여 암시적으로 Import 하는 예입니다.

[Export]

public class Controller

{

public View CurrentView { get; set; }

public Model CurrentModel { get; set; }

[ImportingConstructor]

public Controller(View view, Model model)

{

this.CurrentView = view;

this.CurrentModel = model;

}

명시적인 Import 를 하기 위해서는 생성자 파라메터에 ImportAttribute 특성을 명시해 주면 됩니다.

아래는 Constructor Parameters 예의 전체 소스 코드입니다.

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

using System.Reflection;

using System.ComponentModel.Composition;

using System.ComponentModel.Composition.Hosting;

namespace ImportSample

{

class Program

{

[STAThread]

static void Main(string[] args)

{

Program p = new Program();

p.Run();

}

private void Run()

{

var catalog = new AggregateCatalog();

catalog.Catalogs.Add(new AssemblyCatalog(Assembly.GetExecutingAssembly()));

var container = new CompositionContainer(catalog);

var batch = new CompositionBatch();

batch.AddPart(this);

container.Compose(batch);

var controller = container.GetExportedObject<Controller>();

Console.WriteLine(controller.CurrentView.ToString());

Console.WriteLine(controller.CurrentModel.ToString());

}

[Export]

public class Controller

{

public View CurrentView { get; set; }

public Model CurrentModel { get; set; }

[ImportingConstructor]

public Controller(View view, Model model)

{

this.CurrentView = view;

this.CurrentModel = model;

}

[Export]

public class View

{

public override string ToString()

{

return "Export View";

}

[Export]

public class Model

{

public override string ToString()

{

return "Export Model";

}

실행 결과는

[그림1] Constructor Parameters 예제 소스 코드 실행 결과

Importing Collection

MEF 는 Composable Container 의 모든 Contract 의 인스턴스를 컬렉션으로 가져올 수 있습니다. MEF 는 플러그인 모델(Plugin Model) 로써 구성 요소를 교체와 추가/제거가 용이하다고 하였습니다. 이러한 구성 요소가 동적으로 교체 또는 컨테이너에 의해 관리가 되면서 구성 요소는 업데이트 또는 Recomposable(재구성 가능한) 될 수 있습니다.

Contract 기반의 MEF 구성 요소는 동적인(Dynamic)한 환경을 제공하며, 이것을 관리하기 위해 컬렉션으로 제어할 수 있습니다.

아래는 Importing Collection 의 예제 소스 코드입니다.

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

using System.Reflection;

using System.ComponentModel.Composition;

using System.ComponentModel.Composition.Hosting;

namespace ImportSample

{

class Program

{

[Import]

IEnumerable<IMessageSender> MessageSenders;

[STAThread]

static void Main(string[] args)

{

Program p = new Program();

p.Run();

foreach (var sender in p.MessageSenders)

{

sender.Say();

}

private void Run()

{

var catalog = new AggregateCatalog();

catalog.Catalogs.Add(new AssemblyCatalog(Assembly.GetExecutingAssembly()));

var container = new CompositionContainer(catalog);

var batch = new CompositionBatch();

batch.AddPart(this);

container.Compose(batch);

}

public interface IMessageSender

{

void Say();

}

[Export(typeof(IMessageSender))]

public class PhoneMessageSender : IMessageSender

{

public void Say()

{

Console.WriteLine("Message Send - Phone");

}

[Export(typeof(IMessageSender))]

public class EMailMessageSender : IMessageSender

{

public void Say()

{

Console.WriteLine("Message Send - EMail");

}

IMessageSender 인터페이스를 구현한 구성 요소를 컬렉션으로 루핑하여 호출한 결과입니다.

[그림2] Importing Collection 예제 소스 코드 실행 결과

INotifyImportSatisfaction

INotifyImportSatisfaction 인터페이스는 Import 처리가 완료가 되었을 때 통보되는 인터페이스 입니다. System.ComponentModel.Composition.INotifyImportSatisfaction 인터페이스는 ImportCompleted() 메서드만 구현하면 됩니다. 클래스내 모든 Import 처리가 완료가 되었을 경우 ImportCompleted() 메서드가 호출됩니다.

아래 소스 코드는 INotifyImportSatisfaction 인터페이스를 구현한 예 입니다.

class Program : INotifyImportSatisfaction

{

public void ImportCompleted()

{

Console.WriteLine("Completed");

}

MEF 다시 보기

MEF 는 마치 어린 아이들이 좋아하던 조립 로봇을 보는 듯한 인상입니다. 로봇의 몸체만 있다면 팔, 다리를 끼워 로봇을 어렵지 않게 완성하는 것처럼 말입니다. 플라스틱 로봇에게 강철 옷을 입히고 싶다면, 로봇을 전부 때려부시고 새로 만들지 않고서도 MEF 를 이용하면 가능합니다. 그리고 칼과 방패를 채워주고 싶다면 그렇게 하시면 됩니다.

[그림3] MEF 와 조립 로봇 (그림 출처는 여기)

MEF 를 볼수록 하나의 작은 SOA(Service Oriented Architecture) 라고 봐도 무방할 것 같습니다. (비교하는 것이 무리이긴 하지만…) MEF 의 플러그인 모델(Plugin Model) 은 느슨한 결합(Loose Coupling) 으로 Service 와 EndPoint 의 Contract 기반의 유연한 확장성을 제공해 줍니다. 아마도 단시간내에 새로운 아키텍처의 모델로써 주목을 받을 수 있지 않을까 기대해봅니다.

Exports 선언

2009-07-26T17:41:43+09:00

Exports 선언

출처 : http://vsts2010.net/16

MEF 는 Export 를 통해 외부로 구성요소를 노출할 수 있습니다. Export 는 System.ComponentModel.Composition.ExportAttribute 특성을 통해 선언합니다. 이 특성은 클래스 뿐만 아니라 프로퍼티와 메서드에도 선언을 할 수 있습니다.

구성요소 Export 하기

ExportAttribute 특성을 사용하여 아래와 같이 구성요소를 외부로 노출하게 됩니다. ExportAttribute 은 몇 가지의 시그너처(Signature) 를 제공하는데 매개변수를 생략하게 될 경우 MEF 은 클래스의 타입으로 Contract 를 매핑하게 됩니다.

[Export]

class MessageSender

{

}

프로퍼티 Export

프로퍼티를 Export 하는 방법입니다. 프로퍼티를 Export 할 수 있게 되어 여러 가지 면에서 유리할 수 있습니다.

Core CLR 이 제공하는 타입(Type) 뿐만 아니라 외부의 다양한 타입(Type) 을 사용할 수 있습니다. 프로퍼티에 Export 를 선언할 수 있음으로써 Export 를 구조적으로 분리하여 단순화 할 수 있습니다. 그러므로 같은 구성요소 내에서 Export 간의 Related 관계를 가질 수 있습니다.

아래의 코드와 같이 Timeout 프로퍼티는 Contract 를 맺게 됩니다.

public class Configuration

{

[Export("Timeout")]

public int Timeout

{

get { return int.Parse(ConfigurationManager.AppSettings["Timeout"]); }

}

[Export]

public class UsesTimeout

{

[Import("Timeout")]

public int Timeout { get; set; }

}

메서드 Export

구성요소의 메서드를 Export 할 수 있습니다. 메서드의 Export 는 기본적으로 대리자(Delegate) 를 통해 호출하게 됩니다. 메서드를 Export 하게되면 보다 더 세세한 제어를 가능하게 하고, 심플하게 방법으로 Code Generating 이 가능합니다.

public class MessageSender

{

[Export(typeof(Action<string>))]

public void Say(string message)

{

Console.WriteLine(message);

}

[Export]

public class MessageProcess

{

[Import(typeof(Action<string>))]

public Action<string> MessageSender { get; set; }

public void Send()

{

MessageSender("Call send process in MessageProcess");

}

그리고 ExportAttribute 은 타입(Type) 대신 문자열을 사용하여 Contract 를 사용할 수 있습니다.

public class MessageSender

{

[Export("MessageSender")]

public void Say(string message)

{

Console.WriteLine(message);

}

[Export]

public class MessageProcess

{

[Import("MessageSender")]

public Action<string> MessageSender { get; set; }

public void Send()

{

MessageSender("Call send process in MessageProcess");

}

아래의 소스 코드는 이번 예제에서 사용된 전체 소스 코드입니다.

namespace ExportSample

{

class Program

{

[Import]

MessageProcess MessageProcess { get; set; }

[STAThread]

static void Main(string[] args)

{

Program p = new Program();

p.Run();

p.MessageProcess.Send();

}

private void Run()

{

var catalog = new AggregateCatalog();

catalog.Catalogs.Add(new AssemblyCatalog(Assembly.GetExecutingAssembly()));

var container = new CompositionContainer(catalog);

var batch = new CompositionBatch();

batch.AddPart(this);

container.Compose(batch);

}

public class MessageSender

{

[Export("MessageSender")]

public void Say(string message)

{

Console.WriteLine(message);

}

[Export]

public class MessageProcess

{

[Import("MessageSender")]

public Action<string> MessageSender { get; set; }

public void Send()

{

MessageSender("Call send process in MessageProcess");

}

Export 요약

이렇게 ExportAttribute 을 사용하여 Contract 를 제공하는 것은 굉장히 중요한 의미를 가지게 됩니다. 플러그인 모델(Plugin Model) 에서 Export 는 구성요소를 외부로 노출하는, 즉 Contract 의 방법을 제공해 주게 됩니다.

Contract 맺음으로써 개발자는 Contract Base 로 단지 Contract 만 제공받으면 됩니다. 이러한 Contract 는 제한된 상호작용을 극복하여 대부분의 커플링(Coupling)을 해소할 수 있으며, 플로그인 모델(Plugin Model) 에서 보다 쉽게 구성요소를 캡슐화 할 수 있습니다.

Parts 와 Contracts 선언

2009-07-26T17:36:02+09:00

시작하기 전에

출처 : http://vsts2010.net/14

MEF 는 이미 CodePlex 사이트의 Wiki 에 코드를 중심으로 설명이 잘되어 있습니다. 그렇기 때문에 저도 CodePlex 의 사이트를 참고하여 나름대로 각색하여 작성을 하고자 합니다. 레퍼런스가 이미 CodePlex 에 충분하지만, 저는 나만의 시각에서 바라보고 느낀 바를, 그리고 소스 코드를 만들어 가고자 합니다^^ (사실 Wiki 의 설명은 미약할 다름입니다^^;)

CodePlex 의 Wiki 를 먼저 보실 분은 최신 버전이 적용이 되지 않은 예제도 있으니 이런 부분은 조심해서 리뷰하시기 바랍니다.

어플리케이션에 MEF 호스팅하기

[그림1] Composition Container

Composable Part

MEF 에 어플리케이션을 호스팅하기 위해서는 몇 가지의 반복적인 절차를 거치면 됩니다. 먼저 MEF 를 호스팅할 수 있는 컨테이너(Container) 를 만들어야 합니다. 컨테이너는 MEF 에서 상위 그룹에 존재하며 MEF 의 파트(Part) 를 관리하며 핵심 역할을 담당합니다.

MEF 의 컨테이너는 배치(Batch) 를 구조적으로 구성하고 캡슐화 합니다. 배치(Batch) 의 각 구성 단위를 파트(Part) 라고 부릅니다. 각 파트(Part) 는 닷넷 어셈블리에서 타입(Type) 이 될 수 있으며, 타입(Type) 을 배치(Batch) 로 등록할 수 있습니다.

파트(Part) 는 메인 호스트(Main Host) 가 반드시 포함되어야 하며, 아래의 소스 코드에서 보는 것처럼 this 키워드가 바로 메인 호스트(Main Host) 가 됩니다.

Contract

이러한 Composable Part 는 다른 컴포넌트와 의존 관계를 갖지 않습니다. 모든 외부 기능(Export) 는 계약(Contract) 를 맺게되며 이것이 필요할 경우에는 Import 할 수 있습니다.

MEF 의 컨테이너는 Contract 정보의 타입 정보나 메타 데이터를 통해 Export 와 Import 를 매칭합니다.

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

using System.ComponentModel.Composition;

using System.ComponentModel.Composition.Hosting;

class Program

{

static void Main(string[] args)

{

Program p = new Program();

p.Run();

}

public void Run()

{

var container = new CompositionContainer();

var batch = new CompositionBatch();

batch.AddPart(this);

container.Compose(batch);

}

이러한 파트(Part) 를 제어하는 작업은 어플리케이션 차원에서 유일해야 하므로 스레드(Thread) 작업에 안전하도록 lock 으로 블로킹(Blocking) 되어있습니다.

이 작업은 메인 호스트(Main Host) 를 등록하는 과정에 불과하며 실행 시에 아무런 결과가 없습니다.

외부로 기능 노출하기 (Export)

이제 어떤 플러그인(Plugin) 을 외부로 노출해야 합니다. 외부로 노출하는 이유는 내/외부에서 노출된 확장 기능을 가져다 쓰기 위해서입니다. 확장 기능을 노출하기 위해서는 단지 Export Attribute 을 정의해 주면 됩니다.

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

using System.ComponentModel.Composition;

using System.ComponentModel.Composition.Hosting;

namespace MEFLab_Hosting_MEF

{

class Program

{

static void Main(string[] args)

{

Program p = new Program();

p.Run();

}

public void Run()

{

var container = new CompositionContainer();

var batch = new CompositionBatch();

batch.AddPart(this);

container.Compose(batch);

}

public interface IHelloWorld

{

void Say();

}

[Export(typeof(IHelloWorld))]

public class HellowWorld : IHelloWorld

{

public void Say()

{

Console.WriteLine("Hello MEF!");

}

인터페이스(Interface) 를 구현한 HelloWorld 클래스는 Export Attribute 를 정의합니다. Export 의 파라메터는 메타 데이터(Meta Data)로 사용되기 때문에 타입(Type) 을 정의해 주어야 합니다.

혹자는 왜 인터페이스를 정의해야 하느냐고 궁금해 하기도 합니다. 정답을 드리자면, 반드시 인터페이스를 정의하지 않아도 됩니다. 하지만 특히 MEF 에서 인터페이스는 다형적이고 표준적인 메타 데이터를 제공하기 위해 인터페이스를 선언하여 사용하는 것이 좋을 것 같네요^^

외부 기능 가져오기 (Import)

Export Attribute 으로 외부로 노출된 확장 기능은 Import Attribute 으로 가져올 수 있습니다. 단, 배치(Batch) 의 파트(Part) 로 등록이 되어 있어야 합니다. 내부적으로 Import 의 타입을 생략할 경우 Export 의 타입의 메타 데이터를 통해 Import 의 개체를 쿼리(Query) 하여 생성하게 됩니다.

class Program

{

static void Main(string[] args)

{

Program p = new Program();

p.Run();

}

[Import]

IHelloWorld HelloWorldCompoent { get; set; }

public void Run()

{

var container = new CompositionContainer();

var batch = new CompositionBatch();

batch.AddPart(new HellowWorld());

batch.AddPart(this);

container.Compose(batch);

HelloWorldCompoent.Say();

}

public interface IHelloWorld

{

void Say();

}

[Export(typeof(IHelloWorld))]

public class HellowWorld : IHelloWorld

{

public void Say()

{

Console.WriteLine("Hello MEF!");

}

이 예제에서 알 수 있듯이 코드에서 모듈(Module) 이나 타입(Type) 의 관계를 크게 신경 쓰지 않았습니다. Export 와 Import 를 통해서 의존(Dependency) 는 어느 정도 해소된 것처럼 보입니다. (인터페이스만 잘 활용하면 MEF 없이도 충분히 가능합니다)

이것이 끝이라면 정말 재미가 없겠죠. 차차 나오게 될 내용이지만, 이러한 Export 와 Import 를 활용하고 Lazy Load, 그리고 메타 데이터를 이용한 쿼리(Query) 를 활용하게 되면 복잡한 기능을 획기적으로 단순화 할 수 있습니다.

MEF (Managed Extensibility Framework) 란?

2009-07-26T17:18:58+09:00

MEF (Managed Extensibility Framework) 란?

출처 : http://vsts2010.net/13

Menaged Extension Framewkr(이하 MEF) 란? 가장 쉽게 얘기하자면, 어플리케이션과 컴포넌트의 재사용성을 높일 수 있는 프레임워크입니다. 기존의 어플리케이션은 하나의 목적을 하나의 어플리케이션으로 구현한 정적인(Statically) 어플리케이션이라면, MEF 는 보다 동적인(Dynamically) 어플리케이션을 구축할 수 있는 새로운 라이브러리를 제공합니다.

기존의 정적인 어플리케이션은 새로운 요구사항으로 기능을 확장할 필요가 있을 경우 새로운 빌드 버전을 필요로 합니다. 그리고 새로운 빌드 버전은 기존 어플리케이션과 확장된 기능간에 종속적인 관계를 탈피할 수 없었습니다. 이미 프로그램 언어를 사용하여 코드를 작성하는 분들이라면 반복적이거나 확장에 대해 많은 고민을 한번쯤 해보았을 것입니다.

[그림1] MEF 의 컨셉 이미지

MEF 는 플랫폼의 저레벨(Low Level) 에서 공통된 추상적인 기능을 제공하고 여러 곳에 흩어진 이중 작업을 감소시킬 수 있습니다.

몇 달 전 마이크로소프트에서는 Application Framework Core 팀이라 부르는 팀이 만들어졌다고 합니다. 이 팀은 ASP.NET, Windows Forms, WPF, Silverlight 의 여러 플랫폼에서 동작하기 위한 BCL(Base Class Library) 과 같은 역할을 한다고 합니다.

MEF 는 플러그인 모델(Plugin Model)

MEF 는 플러그인 모델(Plugin Model) 이라고도 부릅니다. 플러그인 모델을 잘 모르신다면, 전기 콘센트의 플러그를 연상하시면 됩니다. 전기 콘센트의 플러그는 그 수가 제한되어 있지만 어댑터를 추가로 구매하여 꽃으면 몇 개의 콘센트를 꽃을 수 있습니다. 그리고 TV 나 컴퓨터를 사용하고 싶다면 콘센트에 꽃기만 하면 TV 와 컴퓨터를 동작시킬 수 있습니다.

[그림2] MEF 는 플러그인 모델(Plugin Model) 이다. (출처는 여기)

만약 더 좋은 TV 나 컴퓨터가 생겼다면 플러그를 빼고 더 좋은 TV 나 컴퓨터의 플러그를 콘센트에 꽂기만 하면 됩니다.

이처럼 MEF 는 어플리케이션의 확장을 위한 보다 유연한 아키텍처를 제공하며, 약간의 개념만 이해한다면 사용하기도 쉽습니다.

어디서 많이 본 듯한 아키텍처?

맞습니다. 저도 MEF 를 처음 보는 순간 느꼈습니다. MEF 의 외관은 마치 DI(Dependency Injection) 과 IoC(Inversion of Control) 의 그것과 매우 유사해 보였습니다.

용어 설명

DI(Dependency Injection) / 의존성 주입

객체간의 의존성과 결합도를 낮추기 위한 기술

IoC(Inversion of Control) / 역제어

인스턴스의 관리를 컨테이너에서 인스턴스의 생성과 소멸의 생명주기를 관리

하지만 MEF 는 DI 나 IoC 와 전혀 다릅니다. 위에서 얘기한대로 MEF 는 플러그인 모델입니다. 어플리케이션의 확장을 위한 프레임워크이며, DI 와 IoC 는 잊어버리십시오! 아래의 단원에서 DI 와 IoC 를 잊을 수 있는 분명한 근거를 설명하도록 하겠습니다.

플러그인 모델(Plugin Model) 로 뭘 할 수 있나요?

MEF 의 플러그인 모델(Plugin Model) 은 보다 나은 확장성을 제공해 줍니다. 마치 Visual Studio 의 Addin 을 연상하시면 됩니다. Visual Studio Addin 은 Visual Studio 의 기능을 쉽고 강력하게 활용할 수 있도록 도와주며 전혀 새로운 기능을 추가할 수 있는 플러그인(Plugin) 입니다. 그럼 MEF 의 플러그인 모델(Plugin Model) 은 어떠한 장점이 있을까요?

MEF 의 플러그인 모델은 아래와 같은 장점을 제공합니다.

l 확장 기능에 대한 인스턴스를 생성하는 방법(SingleCall, Singleton)을 제공하며, 인스턴스의 회수할 수 있어야 합니다.

l 상호작용을 할 수 있습니다. 확장 기능간에 메시지의 전달이 쉽고 용이해야 합니다. Global Service 처럼 상호간의 인터페이스가 제공되어야 하고 이러한 메시지에 응답할 수 있어야 합니다.

l 확장 기능은 Lazy Load 할 수 있어야 합니다. 확장 기능은 원하는 시기에 로드해야 합니다. 마치 VSIP(Visual Studio Integration Package) 의 VSCT 와 같이 인터페이스나 이벤트는 노출이 되어 있지만 실제로 확장 기능이 로드된 것은 아닙니다.

l 확장이 용이해야 합니다. 예를 들어, 확장 기능이 특정 폴더(Addin 폴더라고 가정)로 복사된다면 이를 감지하여 인터페이스를 제공하거나 확장 기능이 활성화 되어야 합니다.

l 교체가 쉬워야 합니다. 새로운 기능이 추가된 확장 기능은 교체가 쉬워야 하며, 필요 없어진 확장 기능을 언로드(Unload) 할 수 있어야 합니다.

MEF 는 여러분의 정적인 어플리케이션에 동적인 생명력을 불어넣어 줄 수 있으며, 그 근간은 바로 플러그인 모델(Plugin Model) 입니다.

이러한 플러그인 모델은 근본적인 상호간의 의존(Dependency) 관계를 보다 자연스럽게 해결할 수 있으며, 유연하고 매끄럽게 다룰 수 있을 것으로 기대합니다.

MEF 설치하기

MEF 는 .NET Framework 4.0 에 포함될 예정입니다. 하지만 아쉽게도 .NET Framework 4.0 CTP 버전에는 포함되어 있지 않기 때문에 Visual Studio Team System 2010 의 VPC 이미지에서도 테스트할 수 있는 환경이 갖추어지지 않았습니다.

현재 2009-03-16 기준으로 MEF 는 Preview 4 버전이며 CodePlex 에서 소스코드와 바이너리를 다운로드 받을 수 있습니다.

MEF (Managed Extensibility Framework) 다운로드

http://mef.codeplex.com/

시작이 반이다! 친절한 HelloWorld 따라하기

자… 이제 MEF 도 설치했고 언제나 그렇듯 HelloWorld 를 콘솔에 출력하는 코드를 작성해 보도록 합시다. 소스 코드에 대한 설명은 다음 단원으로 넘기도록 하고, 오늘은 MEF 가 어떻게 동작하는지 눈대중만 익히시면 될 것 같습니다.

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

using System.Reflection;

using System.ComponentModel.Composition;

using System.ComponentModel.Composition.Hosting;

namespace ConsoleApplication1

{

class Program

{

static void Main(string[] args)

{

Component com = new Component();

var catalog = new AggregateCatalog();

catalog.Catalogs.Add(new AssemblyCatalog(Assembly.GetExecutingAssembly()));

var container = new CompositionContainer(catalog);

var batch = new CompositionBatch();

batch.AddPart(com);

container.Compose(batch);

com.HelloWorldComponent.Say();

}

public class Component

{

[Import]

public IHelloWorld HelloWorldComponent { get; set; }

}

public interface IHelloWorld

{

void Say();

}

[Export(typeof(IHelloWorld))]

public class HelloWorld : IHelloWorld

{

public void Say()

{

Console.WriteLine("Hello MEF");

}

출력 결과는

[그림3] 소스 코드 실행 결과

혹자는 HelloWorld 를 찍는데 왜 이렇게 많은 코드가 필요한가에 불만이 있을지도 모릅니다. 맞습니다. 단순히 결과가 HelloWorld 가 출력되기만 바란다면 이렇게 긴(?) 코드는 필요가 없을지도 모릅니다. 하지만 위의 소스 코드는 보다 큰 어플리케이션을 만들기 위한 초석이며 실제로 큰 어플리케이션에서는 훨씬 적은 코드로 복잡한 요구사항을 구현할 수 있을지도 모르는 일입니다^^

MEF 는 아직은 Preview

언제나 그렇듯이 새로운 프레임워크는 새로운 패러다임을 가져옵니다. 그리고 보다 나은 아키텍처와 개발 방법을 제시합니다. 물론 MEF 도 더 깊이 살펴볼수록 그 놀라운 기능에 감탄을 하게 될 것입니다.

하지만 아직 MEF 는 Preview 입니다. MEF 의 플러그인 모델은 충분히 활용 가치가 있지만 아직은 실무에서 즉시 도입하기엔 많은 고민이 따를 것 같습니다. 그리고 이런 애로 사항이 아마로 정식 버전에서는 해결되리라 생각합니다. 시간이 되면 이 부분도 한번 다루어 보도록 하겠습니다.

System.AddIn Scenarios

2009-07-22T14:47:27+09:00

출처 : http://msmvps.com/blogs/kathleen/archive/2008/01/14/system-addin-scenarios.aspx

System.AddIn Scenarios

I started writing an entry about the System.AddIn pipeline and realized that post was not helpful without having a clue why you might be interested in System.AddIn. So, let me start here.

System.AddIn is designed to isolate portions of your application. It was designed for the scenario of AddIns. Despite the naming confusion, this has nothing to do with Visual Studio. System.AddIn is all about extending your application.

Let’s say you have a commercial application and some clients want to do extra stuff. Giving them back channel access to your database should give you an anxiety attack. With System.AddIn, you just build interfaces with very specific access to your business layer in a way you control. You create an API, and System.AddIn manages it for you.

Understand – with System.Addin and your API, later programmers do not alter your code. They do not even recompile or have the source code. They access your application on channels you define. And you can sandbox them as much as you like.

Don’t yawn. System.AddIn manages application domain boundaries so poorly behaved add-ins don’t crash your application making you look bad. That sand boxing thing is pretty important if there are third parties involved. And System.AddIn assumes your application and the add-in will independently version. You can version in a way that won’t break applications clients or third parties wrote for your application.

Actually, yes, you could have done all this yourself. .NET 3.5 sits on top of 2.0 so I know of nothing changed in the CLR that suddenly opens a new day. You could have written HashSet as well. Heck, there’s a lot in the framework you could have done yourself. But why would you want to. System.AddIn has Microsoft’s backing and commitment so it’s the way to provide application extensibility to your application going forward.

I believe System.AddIn is important beyond retail applications. Here are a few key scenarios:

1. You need to let your clients or third parties add functionality

2. Internally, you need to logically branch your application for multiple client’s business logic

3. Different clients need different WPF user interfaces

4. You need to unload code so it can be changed without closing the application

5. Different segments of your application will evolve at different rates

6. Interacting with a semantic based organization wide service bus

The second and third are similar, but I wanted to call out the fact that the WinForms model does not play well with System.AddIn. There is a workaround on the team blog involving hosting WinForm pieces in WPF on both sides. I haven’t done that yet but it looks like an interesting approach.

The fourth one is what drew me to System.AddIn. The new version of my code generation harness will have the best possible support for VB 9 XML Literal Code Generation. This means templates will be in assemblies and you’ll want to load the harness, run, change templates, run again. Stopping the harness for a small change would be a major pain. I need to unload after each harness run.

That’s not the only time I’ve wanted to unload an assembly. The last time was when we rejected doing customization through satellite assemblies because we could not update them without shutting down the application – and users would be updating localization strings on the fly. Honestly, we’d probably have a tough time anyway because satellite assemblies aren’t setup to run through System.AddIn and you would not want the hit of crossing the isolation boundaries. But we didn’t explore further because updating at runtime of any assembly required app domain isolation which brings in a slew of issues that the CLR team solved with System.AddIn.

The fifth will probably be the most important role of System.AddIn to most programmers within the next few years. One of the side benefits of services is that they allow independent evolution of different segments of your applications, with the corresponding versioning challenges. But what if you are working with an app that does not need service boundaries for deployment, or needs independent evolution within a single service boundary? Why use WCF if what you really need is versioning support? The concept of what an application is has changed in service based world, System.AddIn allows that same shift in thinking without service boundaries – it’s a different kind of API boundary.

I’m going to postpone discussing the last until I can do a really good job of it, and let my friend David McComb look over it. Dave expanded my view of coding in the most amazing way because of his insights on the range of the ecosystem from assembly bytes to organizations. I’d darn near work for free if I get another chance to work for Semantic Arts. My fingers are just itching to keep going on this…but I really need to wait and do it right.

These are some good reasons to keep an eye on System.Addin. There may be more. Prior to the PipelineBuilder release, System.AddIn was such a pain to use that I couldn’t recommend it. The beauty is that System.AddIn went from an absolute pain to downright easy in one day. It’s a tool you should understand for your arsenal, especially if you claim to be anything resembling an architect.

Look for more in upcoming posts…

Separate Datasets from TableAdapters

2009-06-08T16:03:48+09:00

http://blogs.microsoft.co.il/blogs/bursteg/archive/2007/05/19/OrcasDatasets.aspx

Orcas Datasets - Separate Datasets from TableAdapters

In Visual Studio 2005, we were introduced to the new DataSet Designer, that also generated a TableAdapter for each DataTable in the DataSet.

Along with this great way of creating Data Access Layer for easily, there was a big problem. The Table adapters and the generated Data set are inseparatable which means that when you expose your business entities to the client side or another services, you also expose your data access layer with the connection info inside. This is both a security issue and a software engineering problem.

After receiving some feedback about these problems, Visual Studio "Orcas" can help us with that. The new DataSet Designer has a new property called DataSet Project, that lets you specify a project in which the generated DataSet and table will be created.

With this feature you can easily separate between the Data Access Layer components (the Table Adapters) and the generated business entities. This can help you expose your business entities without exposing your DAL and your connection info.

Enjoy!

Team Foundation Server and Windows SharePoint Services SP2

2009-05-17T16:59:02+09:00

If you install Windows SharePoint Services SP2, you may receive a TF31002 (Unable to connect) error. This is because SP2 disables NTLM authentication on the default site virtual server in favor of using Kerberos authentication.

To use a script to enable NTLM authentication on the virtual server, follow these steps:

On the application tier computer, open a Command Prompt in the root folder of the system drive and change directory to the \inetpub\adminscripts directory (for example, C:\inetpub\adminscripts).
Type the following command, and then press ENTER:

cscript adsutil.vbs get w3svc/1/NTAuthenticationProviders

Note The virtual server ID number of the Default Web site in IIS is 1.

To enable NTLM authentication on the virtual server, type the following command, and then press ENTER:

cscript adsutil.vbs set w3svc/1/NTAuthenticationProviders "NTLM"

Restart IIS.

For more information, see this KB article: http://support.microsoft.com/?id=832769

오라클에서 Date vs. Number(or Varchar2)

2009-05-13T10:33:58+09:00

출처 : http://ukja.tistory.com/131

날짜를 표현하는 데이터 타입으로 Date를 사용해야 하는가? 혹은 Number나 Varchar2를 사용해야하는가?라는 해묵은 논쟁이 있다.

"너무나 간단하지 않은가?"라고 반문하겠지만, 의의로 적용되는 상황을 보면 그리 쉬운 질문은 아닌거 같다. 여러가지 판단 기준이 있겠지만, 가장 중요한 기준은 이것이어야 한다.

"어느 쪽이 CBO가 더 이해하기 쉬운가?"

이 기준으로 생각하면 선택은 언제나 Date 타입이어야 한다. 거의 반론의 여지가 없다고 본다. 간단한 테스트를 통해 확인해보자.

drop table t1 purge;
create table t1 (
c_date    date,
c_char    varchar2(8),
c_numb    number
);

-- 1,000일간의 데이터를 생성한다.
-- 동일한 데이터를 Date, Varchar2, Number 타입으로 생성한다.
insert into t1
select
sysdate - level,
to_char(sysdate-level, 'yyyymmdd'),
to_number(to_char(sysdate-level,'yyyymmdd'))
from
dual
connect by level <= 1000
;

-- Date와 Number 기준으로 2007년 10월 1일 ~ 2008년 5월 1일까지의 범위를 구한다.
with v as (
select
max(c_date) as max_date, min(c_date) as min_date,
max(c_char) as max_char, min(c_char) as min_char,
max(c_numb) as max_numb, min(c_numb) as min_numb,
count(*) as total_rows
from
t1
)
select
total_rows *
(to_date('20080501','yyyymmdd')-to_date('20071001','yyyymmdd'))
/(max_date - min_date) as diff_d,
total_rows * (20080501-20071001) / (max_numb-min_numb) as diff_n
from
v
;

DIFF_D DIFF_N
---------- ----------
213.213213 319.919178 <-- 날짜는 213일이지만, 숫자값으로는 320만큼 차이가 난다.

이제 다음과 같이 각 데이터 타입별로 2007년 10월 1일 ~ 2008년 5월 1일까지의 날수를 누가 더 정확하게 표현하는지 확인해본다.

-- Date 타입
explain plan for
select *
from t1
where
c_date between to_date('20071001','yyyymmdd') and
to_date('20080501', 'yyyymmdd')
;

@plan

-- Varchar2 타입
explain plan for
select *
from t1
where
c_char between '20071001' and
'20080501'
;

@plan

-- Number 타입
explain plan for
select *
from t1
where
c_numb between 20071001 and
20080501
;

@plan

결과는 다음과 같다(Cardinality의 차이에 주의하자)

-- Date 타입인 경우
--------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------
| 0 | SELECT STATEMENT |    | 215 | 4945 | 3 (0)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| T1 | 215 | 4945 | 3 (0)| 00:00:01 |
--------------------------------------------------------------------------

-- Varchar2 타입인 경우
--------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------
| 0 | SELECT STATEMENT |    | 321 | 7383 | 3 (0)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| T1 | 321 | 7383 | 3 (0)| 00:00:01 |
--------------------------------------------------------------------------

-- Number 타입인 경우
--------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------
| 0 | SELECT STATEMENT |    | 321 | 7383 | 3 (0)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| T1 | 321 | 7383 | 3 (0)| 00:00:01 |
--------------------------------------------------------------------------

위의 결과를 보면 오직 Date 타입을 사용한 경우에만 실제 데이터 분포를 합리적으로 해석하는 것을 알 수 있다. 이유는 간단하다. CBO가 "날짜"를 "날짜"로 해석할 수 있기 때문이다.
(Oracle이 예측한 Cardinality가 우리가 Min/Max를 이용해 구한 값과 거의 일치하는 것에 유의하자)

반면 Number나 Vachar2 타입을 사용한 경우에는 "날짜"로 해석할수 없기 때문에 단순히 범위만을 고려한 값을 예측하게 된다. 이런 차이들이 실행 계획의 합리성을 결정하기 때문에 그 효과는 하늘과 땅 차이라 하겠다.

하지만, 여기서 다시 한번 이런 복잡한 질문을 던질 수 있다.

"지난 몇 년 동안 날짜를 표현하는데 Varchar2나 Number를 사용해왔지만, 아무런 문제도 없었다. 이것은 어떻게 해석할 것인가?"

답변은 운이 좋았거나, Bind 변수를 사용했기 때문이라는 것이다.

Oracle은 다음과 같이 Between Range 조건을 Bind 변수로 사용한 경우에는 0.25%라는 고정된 값을 Selectivity(선택도)로 사용한다.
(이것은 단일 Range 조건이 5%의 선택도를 사용하기 때문이다. Between Range 조건(And 조건의 일종)은 5%*5% = 0.25%가 된다)

explain plan for
select *
from t1
where
c_numb between :b1 and
:b2
;

@plan

---------------------------------------------------------------------------
| Id | Operation    | Name | Rows | Bytes | Cost (%CPU)| Time |
---------------------------------------------------------------------------
| 0 | SELECT STATEMENT |    | 3 |    69 | 3 (0)| 00:00:01 |
|* 1 | FILTER    |    | | |    |    |
|* 2 | TABLE ACCESS FULL| T1 | 3 |    69 | 3 (0)| 00:00:01 |
---------------------------------------------------------------------------

전체 Row수가 1,000개 이므로 1,000*0.0025 = 2.5 = 3이 되는 것을 알 수 있다.

아마 예외없이 Bind 변수를 사용함으로써 항상 고정된 Cardinality가 나왔을 것이고, 이로 인해 잘못된 데이터 타입으로 인한 부작용을 확인할 길이 없었을 것이다.

Range Predicate는 Histogram과 더불어 CBO에게 가장 골치아픈 문제 중 하나이다. 오라클을 오라클답게 사용하려면 선택의 기준을 항상 "CBO에게" 맞추는 습관이 필요할 것이다.

네트워크에서 rewirte 에 대한 기본 개념

2009-05-12T18:59:43+09:00

IPv4에서의 IP 주소 체제의 만점과 몇 가지 보안상의 이유로, 점점 더 많은 네트워크들이 외부 네트워크(또는 인터넷)에서 사용될 수 없는 개인용도의 IP 주소체제(private IP addresses)를 사용한다. 내부 네트워크의 호스트가 인터넷에 접근하려 할 때나, 인터넷에서 접근되도록 하러할 때, 네트워크 주소 번역(network address translation)의 필요성이 생긴다. 네트워크 주소 번역은 인터넷 전송 규약의 헤더들(headers)이 적절히 수정되어, 클라이언트들이 각기 다른 서버들에 연결되었지만 하나의 IP 주소와 연결되고 있는 것처럼 보이고, 서버들도 클라이언트에 직접 연결된 듯 보이도록 할 수 있다는 사실에 의지한다. 이러한 성질은 가상서버 즉, 다른 IP 주소에서의 병렬 서비스들이 NAT에 의한 하나의 IP 주소위에, 하나의 가상 서비스로 보이도록 할 수 있는 서버를 구축하는데 이용될 수 있다.

NAT에 의한 가상 서버의 구조는 load balancer와 실제 서버들은 스위치(switch)나 허브(hub)로 상호 연결되어있다. 실제 서버들은 대개 같은 서비스를 운용하고 같은 서비스 구성 항목을 가진다. 서비스 내용은 각 서버의 하드디스크(local disk)에 복제되거나, 네트워크 파일 시스템으로 공유되거나, (ASF나 CODA같은) 분산 파일 시스템으로 제공된다. load balancer는 request들을 NAT에 의해 다른 실제의 서버들로 전송(dispatch)한다.

NAT에 의한 가상 서버의 작업 흐름은 다음과 같다: 사용자가 서버 클러스터가 제공하는 서비스에 접근하면 가상 IP 주소(Load Balancer의 외부 IP 주소)로 향하는 패킷(request packet)이 Load Balancer에 도달한다. 그러면 Load Balancer는 그 패킷의 목적지 주소와 포트 번호를 검사한다. 만일 그것들이 가상 서버의 역할 분류표(virtual server rule table)에 따른 가상 서버 서비스와 일치한다면 작업할당방식(scheduling algorithm)에 따라 클러스터로부터 실제 서버를 선택하고, 이 접속을 모든 성립된 접속들(established connections)을 기록하는 해쉬 테이블(hash table)에 추가해 넣는다. 그 후 그 패킷의 목적지 주소와 포트 번호를 선택된 서버의 것으로 변경(rewrite)한다. 그러면, 그 패킷은 선택된 서버로 전송된다. 해쉬 테이블에서 발견된 접속에 속하는 패킷이 들어온다면 그 패킷은 변경(rewrite)되어 해당 서버로 전송된다. 응답 패킷(reply packet)이 돌아오면, Load Balancer는 그 패킷의 발생지 주소(source address)와 포트를 가상 서비스의 것으로 변경(rewrite)한다. 접속이 종료하거나 시간 초과되면 접속기록은 해쉬 테이블에서 지워진다.

Extension 클래스를 통해 기존 클래스를 확장하기

2009-05-11T21:18:58+09:00

C# 3.0 에서부터 새로 제공되는 기능으로 Extensions 라는 것이 있다.

이 것은 기존에 정의되어 있는 클래스를 확장할 수 있도록 해주는 방법이라고 할 수 있다. 백문이 불여일견이니 어떻게 하는지 한번 살펴보도록 하겠다.

일단 먼저 기본으로 제공되는 String에 현재의 문자열의 길이를 리턴해주는 GetStringLength() 라는 함수를 제공하도록 해보겠다.

프로젝트를 하나 생성하고 StringExtensions 라는 이름의 클래스를 하나 추가한 후 아래와 같이 코딩하도록 하자.

StringExtensions.cs

namespace ExtensionMethodTest
{
    public static class StringExtensions
    {
        public static int GetTextLength(this string s)
        {
            return s.Length;
        }
    }
}

이와 같이 코딩한 후 폼을 하나 추가하고 폼에서 String 변수를 하나 생성해서 아래와 같이 코딩하도록 하자.

Form1.cs

using System;
using System.Windows.Forms;

namespace ExtensionMethodTest
{
    public partial class Form1 : Form
    {
        public Form1()
        {
            InitializeComponent();
        }

        private void Form1_Load(object sender, EventArgs e)
        {
            string message = "Hello~~~~~";
            MessageBox.Show(message.GetTextLength().ToString());
        }
    }
}

위와 같이 string 함수에 위에서 정의한 함수가 확장되어 들어가 있는 것을 볼 수 있다.

Need to make a user control transparent

2009-04-29T10:59:01+09:00

To make your user control transparent, Add code described in three steps

Step 1

protected override CreateParams CreateParams
{
    get
    {
        CreateParams cp = base.CreateParams;
        cp.ExStyle |= 0x00000020;
        return cp;
    }
}

Step 2

protected override void OnPaintBackground(PaintEventArgs e)
{
    // dont code anything here. Leave blank
}

Step 3

protected void InvalidateEx()
{
    if (Parent == null)
        return;
    Rectangle rc = new Rectangle(this.Location, this.Size);
    Parent.Invalidate(rc, true);
}

After doing 3 steps, place your user control in the form. Its going to be transparents. The controls placed on user control will be visible.

Drag & Drop 기능 구현 기초

2009-04-28T09:04:15+09:00

드래그 해서 전달하려고 하는 클래스 선언

Class1.cs

namespace DragTest
{
    public class Class1
    {
        public int a = 0;
    }
}

드래그(Drag) 하려고 하는 항목에 MouseDown 이벤트를 생성하고 이벤트 내부에 드래그 시작을 알리는 함수 구현

Form2.cs

using System;
using System.Windows.Form;

namespace DragTest
{
    public partial class Form2 : Form
    {
        public Form2()
        {
            InitializeComponent();
        }
        
        private void Form2_MouseDown(object sender, MouseEventArgs e)
        {
            this.DoDragDrop(new Class1(), DragDropEffects.Copy);
        }
    }
}

드래그한 객체를 받아드릴 컨트롤 또는 폼에 AllowDrop 속성을 True로 설정
DragEnter 이벤트 구현
DragDrop 이벤트 구현

.NET Code Converter

2009-04-24T13:08:37+09:00

.NET 언어인 C#과 VB.NET의 코드를 상호 변환해주는 사이트가 있어 소개하고자 한다.

http://www.developerfusion.com/tools/convert/csharp-to-vb/

이 사이트로 이동한 다음 원하는 변환 방법을 선택 후 코드를 붙여넣고 하단의 버튼을 누르기만 하면 자동으로 다른 언어의 코드를 생성해 준다.

무료료 Subversion + Trac 공간을 제공해주는 사이트

2009-04-23T13:20:50+09:00

인터넷에서 해외에 무료료 Subversion 및 Trac를 생성해 제공해주는 사이트가 있어 소개하고자 한다.

http://www.assembla.com/

위 사이트에서 회원가입 과정을 거친 후 무료로 이용이 가능하다.

그동안 서버가 없어서 사용해보지 못한 사람들은 이 사이트를 통해서 한번 써보는것도 괜찮을것 같다.

대한민국 PDF 뷰어! ePapyrus PDF-Pro4

2009-04-23T13:13:24+09:00

여러가지 다양한 기능을 가지고 있는 국산 PDF 뷰어 프로그램입니다.

국산답게 독도사랑 및 문화재사람등과 같은 버전도 있습니다.

특히, 여러개의 PDF문서를 병합해주는 기능은 매우 쓸만합니다. ^^;

다운로드 : http://www.pdfpro.co.kr/download/pdf-pro_free.php

Visual Studio에서 GAC에 등록한 Assembly가 참조추가에 출력되도록 설정하기

2009-04-22T13:20:53+09:00

Summary

When you are developing a class library, you may want Visual Studio .NET to list your library in the Add Reference dialog box on the .NET tab without the user having to browse for it.

This issue is not resolved if you install your assembly to the global assembly cache, because the Add Reference dialog box is path-based and does not enumerate the components from the global assembly cache.

To display your assembly in the Add Reference dialog box, you can add a registry key, such as the following, which points to the location of the assembly

[HKEY_CURRENT_USER\SOFTWARE\Microsoft\.NETFramework\AssemblyFolders\MyAssemblies]@="C:\\MyAssemblies"

where MyAssemblies is the name of the folder in which the assemblies reside.

NOTE: You can create the this registry entry under the HKEY_LOCAL_MACHINE hive. This will change the setting for all of the users on the system. If you create this registry entry under HKEY_CURRENT_USER, this entry will affect the setting for only the current user.

Restart Visual Studio .NET after you have added the key.

More Information

It is highly recommended that you not install your assemblies to the global assembly cache, unless you want to share your assemblies with other applications running on that system. Also, note that it is not possible to directly reference an assembly from the global assembly cache in your project. If you want to use an assembly from the global assembly cache, you should drop your assemblies to a local folder, and then add a reference to the assembly from this folder. You may want to set the Copy Local property to False for that assembly if you do not want the assembly to be copied locally to your project folders. At runtime, the application will use the assemblies from the global assembly cache.

If you install the .NET Framework 3.0 Service Pack 1 (SP1), the following registry subkey is added:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\AssemblyFolders\v3.0

If you install the .NET Framework 3.5, the following registry subkey is added:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\AssemblyFolders\v3.5

Note These registry subkeys are added to support the new functions that are included in Object Browser. For more information about Object Browser, visit the following Microsoft Developer Network (MSDN) Web site:

http://msdn.microsoft.com/en-us/library/exy1facf(VS.71).aspx

References

For more information about assemblies and the global assembly cache, vist the following MSDN Web site:
http://msdn.microsoft.com/en-us/library/yf1d93sz(vs.71).aspx

For more information about the Add Reference dialog box, the following MSDN Web site:
http://msdn.microsoft.com/en-us/library/ftcwa60a(vs.71).aspx

GAC(Global Assembly Cache)에 대해 알아보자

2009-04-21T19:52:50+09:00

1. GAC란?

GAC(Glocal Assembly Cache)란 마이크로소프트사의 CLR(Common Language Runtime) 플랫폼에 도입된 .NET 어샘플리 캐시입니다. 즉, 특수하게 관리되는 중앙 저장소를 두는 접근방법을 통해서 예전에 발생했던 DLL 지옥과 같은 문제가 발생하는것을 피하기 위한 공유 라이브러리라고 생각하시면 됩니다.

GAC에 존재하는 어셈블리들은 강력한 이름으로 서명되어 있기 때문에 동일한 이름이지만 버전이 틀린 여러개의 파일을 동시에 보관할 수 있습니다.

2. GAC의 몇가지 문제점

Global Assembly Cache 매커니즘은 예전의 DLL 지옥과 같은 문제를 피할 수 있게 해주지만, 아직 몇가지 결점을 가지고 있습니다.

기본적으로 어플리케이션은 컴파일할때 사용됐었던 .NET Framework 버전이 컴퓨터에 설치가 되어 있어야지만 동작이 가능합니다. 최신 버전의 .NET Framework가 설치되어 있어도 어플리케이션은 동작되지 않습니다.
만일 어플리케이션에서 사용된 .NET 코어의 몇가지 호출이 framework의 몇가지의 버전만 지원할 경우 Conditional compilation을 사용해야 할 필요가 있습니다.
네이티브 코드에 의존한 .NET 어플리케이션은 GAC 매커니즘안에서도 호환성에 문제가 발생할 위험이 있습니다.
GAC에 추가할 모든 어셈블리는 강력한 이름을 가지고 있어야 합니다. 그러나 몇가지 상황에서는 강력한 이름을 생성하는게 매우 힘들수 있습니다. 예를 들자면, 만일 강력한 이름을 가지고 있지않은 어셈플리를 참조하는 어셈블리일 경우 GAC에 등록할 수 없습니다. 만일 서드파티 어셈블리 파일을 개발한 개발자가 강력한 이름으로 어셈블리를 서명하지 않았다면 GAC에 등록하는것이 불가능하게 된다는 뜻입니다.

Visual Studio 2010의 Code Analysis Enhancements

2009-04-21T09:19:23+09:00

Visual Studio 2010에서는 기존의 코드분석 기능이 3가지 부분에서 향상이 이루어 졌다고 합니다.

자세한 사항은 Visual Studio 2010 공식 블로그에서 확인해 보시기 바랍니다.

[Better Code]VSTS 2010 Code Analysis Enhancements - 1.개요

[Better Code]VSTS 2010 Code Analysis Enhancements - 2. Rule Sets Feature

마이크로소프트의 'I am a developer' 사이트

2009-04-20T20:05:33+09:00

마이크로소프트에서 개발자를 위한 사이트를 하나 제작했다.

http://www.iamadeveloper.co.kr

이 사이트에서 개발에 필요한 간단한 정보 및 MIX09에 관한 정보를 얻을 수 있다.

개발자라면 가끔씩 들려서 새로운 정보를 얻는것도 좋을것 같다.

.htaccess 파일을 이용해 특정 IP 접근 차단하기

2009-04-20T09:20:16+09:00

요즘 댓글, 트랙백 등의 서비스 때문에 서버의 트래픽이 날로 증가하고 있다.

이럴때 맘에 안드는 스팸 IP를 차단하는 방법이 있다.

웹서버의 루트폴더에 .htaccess 파일을 생성한다.

생성된 파일에 아래와 같이 설정하도록 한다.

SetEnvIfNoCase remote_addr 94.229.65.* go_out
Order allow,deny
Allow from all
Deny from env=go_out

이렇게 하게 되면 94.229.65.* 에 해당하는 아이피가 접근을 시도하게 될 경우 거부하도록 설정할 수 있다.

Make 'Sub Main()' function like C#

2009-04-15T12:59:14+09:00

비주얼 베이직 닷넷(이하 VB.NET)에는 프로젝트 속성에 이전 VB처럼 응용프로그램 정보를 설정할 수 있는 기능인 '응용 프로그램 프레임워크 사용' 기능을 가지고 있다.

VB.NET 프로젝트를 하나 생성한 후 프로젝트 속성을 살펴보도록 하자.

'응용 프로그램' 탭에서 '응용 프로그램 프레임워크 사용' 체크박스를 찾을 수 있다.

이 항목이 체크되어 있으면 이전 VB와 같은 스타일로 어플리케이션을 손쉽게 설정 할 수 있다는 장점이 있다.

그러나 응용 프로그램 최초 시작시에 어떤 작업을 해야할 경우, 예를 들자면 폼 스킨을 초기화해야하거나 할 때에 C#에서처럼 static void Main() 함수를 사용해서 프로그램 시작 시점을 잡아야 할 경우가 있다.

이럴 경우에는 다음과 같은 순서로 작업하면 된다.

1. 프로그램에 모듈 1개를 새로 생성한다. 여기에서는 'MyModule' 이라는 이름으로 생성했다.

2. 생성된 모듈에 C#과 같은 스타일의 Main() 함수를 제작한다.

Module MyApplication

    <STAThread()> _
    Public Sub Main()

        ' 프로그램 시작시 해야 할 일
        'USkin.USkinSDK.USkinInit("", "", "Theme.msstyles")

        'Application.EnableVisualStyles()
        Application.SetCompatibleTextRenderingDefault(False)

        Application.Run(new Form)

    End Sub

End Module

3. 프로젝트 설정에서 '응용 프로그램 프레임워크 사용' 항목을 체크해제 하고, 위의 시작 개체 항목에서 'Sub Main' 함수를 선택한다.

이렇게 하게되면 C#과 동일한 방식으로 프로그램 시작 관련 설정을 할 수 있다.

윈도우 폼(Form)에 스킨(Skin)을 입히자! USkin

2009-04-15T12:55:59+09:00

윈도우 어플리케이션을 제작하면서 자신의 폼에 스킨을 입히고 싶은 경우가 있었을 것이다.

그러나 상용 컴포넌트를 사용할 수는 없고, 그리자니 너무 힘들고...

이럴때 사용할 수 있는 무료 윈도우 스킨 프로그램이 있다.

NEEMEDIA - USkin V3.0

이 프로그램은 .NET 및 MFC에서도 사용할 수 있다.

일단 사이트에 방문해서 프로그램을 다운받도록 하자.

사이트 링크 : http://www.neemedia.com/newsite/index.php?entry=entry081110-153248

프로그램을 다운받은 후 압축을 풀어서 데모를 실행해 보도록 하자.

이와 같이 스킨이 입혀진 프로그램이 실행되는것을 확인할 수 있다.

가장 좋은 점은 msstyles 파일을 로드하여 사용할 수 있다는 점이다.

netstat, tasklist 명령으로 쉽게 할당된 프로그램 찾기

2009-04-03T10:11:51+09:00

보통 컴퓨터를 사용하는 도중 컴퓨터에서 사용중인 포트를 어느프로그램에서 쓰고 있는지 궁금할 때가 있다.

이럴때 보통 'netstat' 명령을 사용해서 각 포트별 프로세스 아이디를 찾아내 확인하고는 했다.

Windows XP SP2 이후부터는 이 netstat 명령엉 옵션에 '-b' 가 추가되어 어떤 프로그램에 할당받아 사용하고 있는지 좀 더 손쉽게 확인할 수 있게 되었다.

위와 같이 '-b' 옵션을 통해 각 포트별 할당된 프로그램명을 알 수 있게 되었다.

또한 윈도우 명령어 중에 tasklist 라는 명령어가 있다.

우리가 보통 사용하는 작업관리자와 비슷한 역할을 하는 프로그램이다.

이 프로그램에 '-svc' 옵션을 사용하여 어떤 프로그램이 어떤 서비스 명으로 동작중인지 확인하는 것이 가능하다.

위와 같이 각 프로그램이 어떤 서비스로 등록되어 동작중인지 확인 할 수 있다.

배치(Batch) 프로그래밍 참고자료

2009-04-03T09:48:39+09:00

자료 출처: http://blog.naver.com/darkstorm001/40017851898

▶ 참고자료

다음은 배치 프로그래밍의 대가인 티모 살미 교수가 정리한 것입니다.

아주 유용한 테크닉들이 들어있습니다.

1. "@echo off"를 일반적으로 사용하기
====================================
화면에 명령어들이 표시되지 않게 echo off 하고, 그 라인도 화면에 표시 되지 않게 하기 위해서 다음과 같이 하면 된다.
@echo off
이 것은 MsDos 3.30 이후 버전에서만 작동한다. 이것을 일반적으로 사용하게 하기 위해서 3.30이상의 MsDos를 사용한다면 autoexec.bat 안에 다음과 같이 적어 놓는다.
set _echo=@
그리고 배치파일에서 다음과 같이 사용한다면 어느 버전의 MsDos버전에서도 작동한다.
%_echo%echo off

2. 모든 파일을 지우기
=====================
가장 흔하게 질문되는 것(FAQ)중의 하나는 del *.* 을 사용껦 때,"Are you sure (Y/N)?" 라는 확인을 어떻게 하면 나타나지 않게 하는것이다. 다음과 같이 사용한다.
echo y| del *.*
화면에 나타나는 메세지도 보이지 않게 하려면 다음과 같이 한다.
echo y| del *.* > nul
이러한 확인 절차를 표시하지 않게 하는 것은 토론의 여지가 많지만,위와 같이 사용할 수 있다.

3. 다중 반복
============
배치파일에서 다중 루프(반복)를 사용하는 것이 가능하다. 다음의 두배치파일을 생각해 보자. 그리고 test.bat을 불러 실행시켜 보자.
echo off
rem TEST.BAT
for %%f in (a b c d e f) do %comspec% /c test2 %%f

echo off
rem TEST2.BAT
for %%g in (1 2 3) do echo %1%%g
아니면 한줄로 다음과 같이 써서 사용할 수도 있다.
for %%f in(a b c d e f) do %comspec% /c for %%g in (1 2 3) do echo %%f%%g
이 두번째 방법의 단점은 echo가 화면에 표시된다는 것이다.

4. 디렉토리가 존재하는지 확인하는 방법
======================================
디렉토리가 있는지 확인하는 것은 가끔 매우 쓸모있는 일이다. %1의 디렉토리가 없다면 다음 확인은 참이 될것이다.
if not exist %1\nul if not exiat %1nul echo Directory %1 does not exist

5. 프로그램을 현디렉토리나 경로에서 사용할 수 있는지 확인하기
====================================
배치 프로그램에서 프로그램을 불러서 사용할때, 그 파일에 대한 경로를 써주지 않았을 경우, 그 프로그램이 현재의 디렉토리나 경로에서 사용가능한지 확인할 때 도움이 될 것이다.
set _found=
if exist %1 set _found=yes
for %%d in (%path%) do if exist %%d\%1 set _found=yes
for %%d in (%path%) do if exist %%d%1 set _found=yes
if "%_found%"=="yes" goto _continue
echo %1 is not at path or the current directory
goto _out
:_continue
echo %1 found at path or in the current directory
:_out

6. 배치파일에서 서브루틴이나 재귀적방법을 사용하기
====================================
배치파일 안에서 서브루틴을 사용하는 것은 가능하다. 방법은 서브루틴이 실행된 뒤에 돌아가야할 곳을 가르키는 환경변수(예를들면_return)를 설정하는 것이다. 이런 예는 UNPACK.BAT 이나 BOOT.BAT의:_common 과 :_subru 부분에서 찾아 볼 수 있다.
마찬가지로 재귀적인 사용이 가능하다. ("재귀적인 방법"의 의미는 한 배치파일이 자기 자신을 불러 사용하는 것이다.) 이 예는 SAFEDEL.BAT에서 아래의 행을 따라 찾아 보면 된다.
for %%f in (%1) do call safedel %%f recurse
배치파일의 0번째 인수(%0)는 배치파일 자신을 나타내므로, safedel은 %0으로 대치 되어 사용할 수도 있다.

7. 매개 인수(parameter)를 대문자로 바꾸기.
====================================
다음은 배치파일에 사용한 인수 %1 를 대문자로 바꾸어 주는 예제이다. 이는 MsDos는 path를 대문자로 바꾼다는 점을 이용한 것이다. 결과는 upcase_에 저장될 것이고, 원래의 경로가 다시 저장될 것이다.
set tmp_=%path%
path=%1
set upcase_=%path%
path=%tmp_%

8. 새로운 디렉토리를 경로에 붙이기
====================================
자주 필요한 이 기술은 매우 간단하다. 예를 들어 %1를 경로에 덧붙이려면
path=%path%;%1
이라고 하면된다.
이 기술은 배치파일 안에서만 사용할 수 있다. 배치파일 안에서만 환경변수(%path%)를 사용할 수 있기 때문이다. 존재하지 않는 디렉토리를 덧붙이려한다거나 중복해서 경로를 덧붙이는 것을 방지하는 ADDPATH.BAT이라는 배치파일이 있다.

9. 두 파일을 비교하기
====================================
배치파일에서 두 파일이 같은지 아닌지 확인해 볼 수 있다. 이 기술은 MsDos의 외부 명령어인 fc.exe와 find.exe를 사용한다. (외부 명령어라는 뜻은 MsDos와 같이 있는 프로그램들이다. 대부분의 외부 명
령어용 프로그램들은 c:\dos 에 위치한다.)
fc %1 %2 > tmp$$$
type tmp$$$ | find /i "fc: no differences encountered" >diffe$$$
if exist notsame$ del notsame$$$
copy diffe$$$ notsame$ > nul
if not exist notsame$ echo Files %1 and %2 are different
if exist notsame$ echo Files %1 and %2 are identical
if exist tmp$$$ del tmp$$$
if exist notsame$ del notsame$
if exist diffe$$$ del diffe$$$
좀더 생각하면 이 기술은 다른 목적에도 사용할 수 있다. 이는 파일안에 주어진 문자열이 있는지 확인 하는데 바탕을 두고 있기 때문이다.

10. 빈줄을 쓰기
====================================
이는 간단하지만 종종 필요하고 유용한 기술이다. echo 바로 다음에점(.)을 찍으면 빈줄을 표시할 수 있다.
echo.

11. pause를 이용해 메세지를 표시하기
====================================
메세지를 손쉽게 나타나게 할 수 있다. 메세지를 echo한 다음 pause 를 사용하는데, pause의 메세지를 nul로 보내면 된다.
echo Break to quit, any other key to remove the tmp directory
pause > nul

12. for를 이용한 다양한 rename 기술
===================================
이 기술이 기본적이고 사소하지만, 이를 생각해 내기란 쉽지 않을 것이다. for 문은 파일의 이름을 바꾸는데 특별히 유용하다. 예를 들면, 내가 다음의 파일들을 가지고 있을 때, (터보 파스칼 TP 4.0,
5.0, 5.5, 6.0) 내가 버전 29를 30으로 바꾸기 원한다고 할때,
tspa2940.zip
tspa2950.zip
tspa2955.zip
tspa2960.zip
다음은 손쉽게 그런 일을 해준다.
for %f in (40 50 55 60) do re tspa29%f.zip tspa30%f.zip
물론 파일이름 바꾸는 일 말고도 이 기술로 다양한 일을 할 수 있다.
하나의 예는 다음과 같다.
for %d in (a b) do format %d:

13. 와일드카드를 확인하기
====================================
이 예제는 인수 %1이 와일드 카드를 사용하고 있는지 아닌지 확인한다.
@echo off
for %%f in (%1) do if "%%f"=="%1" goto _nowilds
echo Parameter %1 contains wildcards (or is missing)
:_nowilds

14. 배치 작업을 중간에 그만두지 못하게 하기
====================================
ctty 명령어를 사용해서 입력장치나 출력장치를 새로 설정하여 배치파일을 중단시키는 것을 방지할 수 있다. 여기의 예제는 패스워드로 e를 넣어야 하는 간단한 배치파일이다.
ctty가 nul로 돌려진 동안<,>의 리디렉션이 필요한 것을 눈여겨 보라. ask라는 배치파일을 돕
기 위한 프로그램은 같이 포함되어 있다. ( MsDos의 choice와 비슷하다. 단, 에러 레벨을 입력한 문자의 아스키 값으로 돌리는 것만 틀리다.)
@echo off
ctty nul
echo Now you cannot break the batch with ^C or ^Break > con
:_ask
echo Use e to break > con
ask /b /d < con
if errorlevel==101 if not errorlevel==102 goto _out
goto _ask
:_out
ctty con
echo Back to normal. Now you can break the batch with ^C or
^Break.
이 배치파일이 작동되고 있는 동안에는 alt-crtl-del로 다시 부팅할수도 없다. 이 같은 일을 하는 noboot.exe라는 램상주 프로그램도 있다.

15. autoexec.bat를 중지하고 건너뛰는 것을 방지하기
====================================
브레이크를 눌러 autoexec.bat를 건너 뛰어 지나치지 않게 하기 위해서 다음과 같이 config.sys에 쓰면 된다.
shell=c:\command.com /p nul
이렇게 하기 전에 만일의 경우를 대비해서 플로피 디스켓으로 부팅할준비를 해둔다. autoexec.bat 맨 뒷줄에 'ctty con'이라고 덧 붙여야 된다. 그렇게 하지 않으면 키보드가 말을 듣지 않을 것이고, 준비한 플로피 디스켓으로 부팅해야 할 것이다 :-).

16. 확장자를 인식하기
====================================
단지 확장자를 확인하려던가, 주어진 파일의 이름에서 확장자를 환경변수로 저장하려고 할때, 이 것은 매우 유용하다. 어떻게 하는지 여기에 있다. 이 배치파일은 PC-Magazine July 1992, Vol 11, No. 13,
page 528에 나온 정보를 이용한 것이다. for 루프에서 슬레시(/)로 시작하는 인수는 두 부분으로 나누어지는데, 처음 부분은 인수의 첫문자이고 다른 부분은 나머지 문자열이다.
이 해결방법에서 하나의 문제점은 .* 이라던가 .??? 이란 확장자를 인식하지 못하는 것이다. 그러나 "와일드카드를 확인하기"를 이용해서 확인하면 될 것이다. 이러한 기술을 이용한 것중에 UNPACK.BAT라
는 배치파일이 있다.
@echo off
set exten_=%1
:_next
set prev_=%exten_%
for %%f in (/%exten_%) do set exten_=%%f
if ".%exten_%"=="%prev_%" goto _extfound
if not "%exten_%"=="%prev_%" goto _next
goto _noext
:_extfound
echo The filename %1 has an extension %exten_%
goto _out
:_noext
echo The filename %1 has no extension
:_out
set exten_=
set prev_=

17. % 문자 인용부호
====================================

%1은 배치파일에 주어진 첫번째 인수를 가르킨다. 이처럼 'echo %1'이라고 하면 첫번째 인수를 표시해 준다. 대신에 %1라는 문자를 표시하고 싶은 경우 어떻게 해야하는가? % 문자는 인용부호처럼 행동한다. 그래서 %%1이라고 쓴 경우 실제로는 "%1"이라고 화면에 표시된다. 아래의 간단한 연습을 실행해보라.
@echo off
if "%1"=="" goto _out
echo %1
echo %%1
:_out
이 기능을 이용한 것은 "배치의 보조 배치파일을 없애기"를 보아라.
좋은 예로는 DELPATH.BAT가 있다.

18. 배치의 보조 배치파일을 없애기
====================================
많은 배치 프로그램이 call을 사용해서 보조 배치파일을 불러다 쓴다. 많은 경우 이런 일을 재귀적인 사용을 통해 자기 자신을 불러다씀으로써 보조 파일을 사용하는 것을 줄일 수 있다. 보조코드는 배치파일 자기자신에 넣어 놓는다. 이러한 기술은 와일드 카드를 받아들이는 TYPE 같은 SHOW.BAT 에서 가장 잘 나타나 있다. 일반적으로는 개개의 파일을 type하기 위해서 보조파일이 필요하다. 다른 예는
SAFEDEL.BAT에서 찾아볼수있다.
이와 같은 일을 하기 위한 다른 기술이 있다. 원래의 배치파일이 보조 배치파일을 만든 다음 그것을 불러 사용하는 것이다. 이런 것으로는 DELPATH.BAT의 예를 들 수 있다. 여기에는 사용되는 드라이브를
보여주는 간단한 예가 있다. (c 부터 t 까지 가능하다. 여기선 더 쓰면 줄이 넘어가니까!)
@echo off
echo @echo off> tmp$$$.bat
echo if exist %%1:\nul echo Drive %%1: is present>> tmp$$$.bat
for %%d in (c d e f g h i j k l m n o p q r s t) do call tmp$$$
%%d
del tmp$$$.bat
디스크의 볼륨 레이블을 찾아내는 창의적인 기교가 PC-Magazine August 1992, Vol. 11, No. 14, p. 527에 실렸다. 여기는 같은 기술을 사용하는 예가 있다. 환경변수 getdir_에 현재의 디렉토리를 저장한다. 이 기술은 PUSHDIRE.BAT에 사용되고 있다.
@echo off
echo @echo off> director.bat
echo set getdir_=%%2>> director.bat
echo echo %%getdir_%%>> director.bat
dir | find "Directory"> go.bat
call go
if exist director.bat del director.bat
if exist go.bat del go.bat

19. subst 명령어를 경로에 사용하기
====================================
어떤 디렉토리를 읽기 쉽게 하기 위해서 간단한 배치파일을 사용한다. 만약 subst 가 이미 설정되어서 생길 수 있는 에러를 방지한다. 그리고 마지막으로 현재 대치된 디렉토리의 현황을 보여준다.
@echo off
if exist m:\nul echo The substitution has already been made
if not exist m:\nul subst m: c:\math
if not exist s:\nul subst s: c:\support
subst

20. 일주일에 한번 실행하기. (요일을 확인하기)
====================================
요일을 환경변수에 넣는 것은 어려운 기술이다. 완전한 예는 WEEKLY.BAT에서 찾아볼수 있다. 이 기술의 핵심은 아래에 나와 있는데, 요일을 weekday_라는 환경변수에 저장하는 것이다. 일반 도스 프로그램 외에 아무런 보조 프로그램이 필요없다.
@echo off
echo.| date | find "Current" > tmp$$$.bat
echo set weekday_=%%3> current.bat
call tmp$$$
echo %weekday_%
if "%weekday_%"=="Fri" echo Thank God it's Friday
if exist tmp$$$.bat del tmp$$$.bat
if exist current.bat del current.bat
set weekday_=
사실, 위에서 %%3 대신에 %%4를 사용하면 오늘의 날짜를 확인할 수 있다.

21. 파일이름에 경로가 포함되었는지 확인하기
====================================
우선 먼저 "확장자를 인식하기"를 보면 같은 아이디어인 것을 알 수 있다. 파일이름이 단순히 go.exe 로 이루어 졌는지, 아니면 경로를 포함해서 r:\progs\go.exe와 같이 이루어 졌는지 확인하는 것은 r:\progs\*.exe와 같이 확장자를 사용했다면 매우 복잡한 일이다. 여기서 어떻게 되는지 설명하였다. 이를 완전히 이해했다면 확실히 배치 파일들에 대해서 이해하기 시작했다고 말할 수 있을 것이다.
@echo off
echo @echo off> tmp$$$.bat
echo set rest_=%%1>> tmp$$$.bat
echo :_next>> tmp$$$.bat
echo set prev_=%%rest_%%>> tmp$$$.bat
echo for %%%%g in (/%%rest_%%) do set rest_=%%%%g>> tmp$$$.bat
echo if ":%%rest_%%"=="%%prev_%%" goto _found>> tmp$$$.bat
echo if "\%%rest_%%"=="%%prev_%%" goto _found>> tmp$$$.bat
echo if not "%%rest_%%"=="%%prev_%%" goto _next>> tmp$$$.bat
echo goto _nopath>> tmp$$$.bat
echo :_found>> tmp$$ at
echo set haspath_=yes>> tmp$$$.bat
echo goto _out>> tmp$$$.bat
echo :_nopath>> tmp$$$.bat
echo set haspath_=no>> tmp$$$.bat
echo :_out>> tmp$$$.bat
echo set rest_=>> tmp$$$.bat
echo set prev_=>> tmp$$$.bat
for %%f in (%1) do call tmp$$$ %%f
if "%haspath_%"=="yes" echo Filename %1 includes a path
if "%haspath_%"=="no" echo Filename %1 does not include a path
rem if exist tmp$$$.bat del tmp$$$.bat
set haspath_=

22. 엔터키를 누르지 않고 시간을 보기
====================================
현재의 시간을 보는 간단한 기술은 다음과 같다.
echo.| time | find /v "new"
시간을 환경변수로 저장하는 방법은 LASTBOOT.BAT을 보아라.

23. 에러레벨 값을 확인하는 다른 방법
====================================
많은 프로그램과 몇개의 도스명령어들( diskcomp, format, xcopy)은끝날 때 에러 레벨을 발생시킨다. 에러레벨의 누적적인 성질 때문에 에러 레벨을 확인하는 것은 다소 복잡해진다. 그래서 만약 에러레벨이 정확히 2인지 확인하기 위해서는 다음과 같이 한다.
if errorlevel==2 if not errorlevel==3 echo Errorlevel 2
for 명령어를 사용하는 다른 방법으로 다음을 들수 있다.
for %%e in (0 1 2 3 4 5 6 7) do if errorlevel==%%e set
_errlev=%%e
if "%_errlev%"=="2" echo Errorlevel 2
좀 더 일반적으로 다음과 같이 할 수 있다.
for %%e in (0 1 2 3 4 5 6 7) do if errorlevel==%%e set
_errlev=%%e
if "%_errlev%"=="2" echo Errorlevel %_errlev%
복잡한 배치파일에서 편리한 방법은 goto를 사용하는 것이다.
for %%e in (0 1 2) do if errorlevel==%%e goto _label%%e
goto _out
:_label0
echo Errorlevel 0
:_label1
echo Errorlevel 1
:_label2
echo Errorlevel 2
:_out
이 기술을 실제로 사용하는 예는 BOOT.BAT에서 찾아볼수 있다.

24. 배치파일의 출력을 리디렉션(redirection)하기
====================================
배치파일 안에서의 출력은 손 쉽게 재 방향전환(redirecion)할 수 있다. 다음과 같은 example.bat 이라는 배치파일을 생각해보자.
@echo This is a redirection test> test
"example"를 실행시키면 아래의 문장을 담은 "test"라는 파일을 생성 할 것이다.
This is a redirection test
이 줄은 eoln(end of line: ascii 13 + 10)을 줄 끝에 포함하고 있다. 리디렉션 기호 '>' 앞에 아무런 공백도 주지 않는 것이 현명할때가 있다.
배치파일이 만드는 출력을 다시 재 방향전환(redirection)하는 것은 다소 복잡하다. 다음과 같은 내용을 지닌 example2.bat을 생각해 보자.
@echo This is another redirection test
실행하면,
example2 > test
출력은 화면에 나오고, 빈 test라는 파일이 생성될 것이다. 출력을 재 방향 전환 시키기 위해서는 다음과 같이 command.com 명령어 해석기를 통해서 배치파일을 실행해야 한다.( command.com은 현디렉토리나 경로에 있어야 한다.)
command /c example2 > test
이와 같이 하면 내용이 "test"라는 파일에 담길 것이다.

25. 환경저장 공간이 충분한지 확인하기
=====================================
만약 배치파일이 환경저장 변수를 사용하면, 환경저장 공간이 부족할경우가 있다. 만약 "Out of environment space"라는 메세지를 받는다
면 잘 알려진 방법을 통해서 다음과 같이 config.sys 의 shell을 설정해서 환경저장 공간을 늘릴 수 있다.
shell=c:\bin\command.com c:\bin /e:1024 /p
이 보다 덜 알려진 기술로는 환경저장 공간이 모자라기 전에 미리 확인해 볼수 있다. 아래의 예는 32바이트의 환경이 남아 있는지 확인한다.
@echo off
set test_=12345678901234567890123456789012
if "%test_%"=="12345678901234567890123456789012" goto _yes
echo Insufficient environment space
goto _out
:_yes
echo Sufficient environment space
set test_=
rem Whatever you wish to do
:_out

26. 드라이브를 사용 못하게 하는 간단한 방법
====================================
임시로 드라이브를 사용하지 못하게 하려면, subst명령어를 사용하면 된다. 예는 아래와 같다.
@echo off
md c:\none
subst d: c:\none
다시 사용하게 하려면,
@echo off
subst d: /d
rd c:\none

27. 프린터에 escape 명령어를 보내기
===================================
여기 정말 사소한 기술이 있다. 명령행에서 곧바로 프린터에게 escape sequence를 보낼 수 없다. 그러나 다음과 같은 배치파일을 이용하면 간단하다.
@echo ESC%1> prn
ESC는 진짜 escape문자로 에디터로 쓰여져야 된다. 이 방법의 한가지 결점은 라인피드를 보내는 것이다.

28. 무작위 문자열을 만든는 방법
===============================
UseNet news에서 무작위 문자열을 만드는 방법을 물어보는 사람이 있었다. 대답은 다음과 같다. 이를 확장해서 공부해보기 바란다.
@echo off
echo 10 randomize(val(mid$(time$,7,2))) > tmp.bas
echo 20 open "tmp2.bat" for output as #1 >> tmp.bas
echo 30 x$ = mid$(str$(int(rnd*10000)),2) >> tmp.bas
echo 40 print #1,"@set ramdom_=";x$ >> tmp.bas
echo 50 close #2 >> tmp.bas
echo 60 system >> tmp.bas
gwbasic tmp.bas
call tmp2
del tmp.bas
del tmp2.bat
set

29. 문자열의 길이를 알아내기
============================
문자열의 길이를 찾아내는 일은 PC Magazine January 26, 1993 issue 에 실렸다. 여기서 제안하는 방법은 PC 메거진의 방법과 근본적으로 같지만, 더 일반적이다.
@echo off
set test_=Testing the lenght of a string
echo %test_% > len$&$&$
dir len$&$&$ | find "LEN$&$&$" > go$$$.bat
echo @echo off> len$&$&$.bat
echo set length_=%% len$&$&$.bat
call go$$$
echo The lenght is %length_% bytes
del len$&$&$
del len$&$&$.bat
del go$$$.bat

30. MsDos의 버전을 환경변수로 저장하기
======================================
ADJCURS.BAT을 보면 알겠지만, 배치파일로만 버전을 알아낼 수있다.
여기에 다른 방법이 있다.
@echo off
ver > go$$$.bat
echo @echo off> ms-dos.bat
echo set version_=%%2>> ms-dos.bat
call go$$$
echo Your MsDos version is %version_%
del go$$$.bat
del ms-dos.bat

Software Architecture Tactics

2009-04-02T09:14:43+09:00

인터넷에서 발견한 Software Architecture Tactic을 요약한 자료입니다.

SA-tactics.pdf

객체지향을 내것으로

2009-04-01T23:11:38+09:00

마소에서 연재되었던 객체지향 관련 자료입니다.

마소 소켓통신 관련 자료 모음

2009-04-01T22:24:53+09:00

마이크로소프트웨어에서 연재된 소켓통신 관련 자료 모음입니다.

ATL을 이용해 Internet Explorer Tool Band 제작하기

2009-04-01T22:16:59+09:00

인터넷에서 찾은 실전 자료입니다.

저작권에 문제가 있으면 삭제하겠습니다.

실전! Explorer Tool Band 제작

실전! Explorer Tool Band 제작1.doc
실전! Explorer Tool Band 제작2.doc
실전! Explorer Tool Band 제작3.doc
실전! Explorer Tool Band 제작4.doc
실전! Explorer Tool Band 제작5.doc

ATL을 이용한 IE Browser Extension Component 만들기

ATL을 이용한 IE Browser Extension component 만들기1.doc
ATL을 이용한 IE Browser Extension component 만들기2.doc
ATL을 이용한 IE Browser Extension component 만들기3.doc
ATL을 이용한 IE Browser Extension component 만들기4.doc

Effective C#

2009-03-31T14:05:38+09:00

데이터 멤버 대신에 항상 프로퍼티를 사용하라
const 보다는 readonly가 좋다
cast 보다는 is나 as가 좋다
#if 대신 Conditional Attribute를 사용하라
항상 ToString()을 작성하라
value 타입과 reference 타입을 구분하라
immutable atomic value 타입이 더 좋다
value 타입을 사용할 때 0이라는 값이 의미를 가질 수 있도록 하라
ReferenceEquals(), static Equals(), instance Equals(), operator==의 상호 연관성을 이해하라
GetHashCode()의 함정에 유의하라
foreach 루프가 더 좋다
할당문보다는 변수 초기화를 사용하는 편이 더 좋다
static 클래스 멤버는 static 생성자를 사용하여 초기화하라
연쇄적인 생성자 호출을 이용하라
자원해제를 위해서 using과 try/finally를 이용하라
Grabate를 최소화하라
boxing과 unboxing을 최소화하라
표준 Dispose 패턴을 구현하라
상속보다는 interface를 정의하고 구현하는 것이 좋다
interface의 구현과 virtual 메서드의 overriding을 구분하라
delegate를 이용하여 콜백을 표현하라
이벤트를 이용하여 외부로 노출할 인터페이스를 정의하라
클래스 내부 객체에 대한 reference 반환을 피하라
명령적 프로그래밍보다 선언적 프로그래밍이 더 좋다
serializable 타입이 더 좋다
IComparable과 IComparer를 이용하여 순차관계를 구현하라
ICloneable의 구현을 피하라
형변환 연산자의 구현을 피하라
가변 클래스의 변경이 영향을 줄 경우에만 new 한정자를 사용하라
CLS를 준수하는 어셈블리가 더 좋다
작고 단순한 메서드가 더 좋다
작고 응집도가 높은 어셈블리가 더 좋다
타입의 가시성을 제한하라
웹 API는 큰 단위로 작성하라
이벤트 핸들러보다 override를 사용하는 편이 낫다
닷넷 런타임의 진단기능을 활용하라
표준 환경설정 메터니즘을 이용하라
데이터 바인딩을 사용하라
닷넷의 유효성 검증 기능을 사용하라
적정한 collection 개체를 이용하라
새로운 구조체보다는 DataSet이 좋다
reflection을 단순화하기 위해서 attribute를 사용하라
reflection을 과도하게 사용하지 말라
애플리케이션에 특화된 예외 클래스를 완벽하게 작성하라
견고한 예외 보증 기법이 더 좋다
Interop를 최소화하라
안전한 코드가 더 좋다
활용할 수 있는 다양한 툴과 리소스에 대해서 알아두라
C# 2.0의 주요 특징
ECMA 표준을 익혀라

[영어비법]영어_이제_그걸_디벼주마_(45page로_요약)김기호

2009-03-31T13:09:00+09:00

[영어비법]영어_이제_그걸_디벼주마_(45page로_요약)김기호.doc

[PDF] Wiley Pattern Oriented Software Architecture Volumn 5

2009-03-31T13:05:59+09:00

[PDF] Wiley Pattern Oriented Software Architecture Volumn 5

ZemnaCmd v1.2 배포합니다.

2009-03-31T09:20:35+09:00

ZemnaCmd v1.2를 배포합니다.

수정사항

ZemnaCmd Configure 아이콘 수정
ZemnaCmd 메뉴 출력시 상/하단에 Seperator 출력되도록 수정
설치 프로그램 InnoSetup으로 변경

다운로드

ZemnaCmd_v1.2.exe

가볍고 무료인 패스워드관리 프로그램! KeePass

2009-03-30T17:08:25+09:00

KeePass 프로그램은?

요즘시대에 우리는 많은 패스워드를 기억해야 할 필요가 있습니다. 윈도우 네트워크를 사용하기위한 로그인 정보, 이메일 계정, 홈페이지 FTP 정보, 온라인 게임 계정정보 등등 수도없이 많은 패스워드를 우린 사용하고 있습니다. 또한, 우리는 각각의 로그인정보에 다른 패스워드를 사용해야 합니다. 그렇지 않으면 만일 비밀번호를 타인이 얻었을 경우 상상하기도 싫은 피해를 입을 수 있습니다.

KeePass 프로그램은 오픈소스 패스워드 관리 프로그램입니다. 이 프로그램을 통해 비밀번호를 안전하게 관리할 수 있습니다. KeePass 프로그램을 통해 마스터 키나 키 파일로 잠겨있는 하나의 패스워드 데이터베이스를 생성 할 수 있습니다. 그래서 하나의 마스터 패스워드나 키 파일만 잘 관리하면 모든 비밀번호를 안정적으로 관리할 수 있습니다. 이 데이터베이스는 현재 잘 알려진 AES, Twofish 암호화 알고리즘을 사용하여 암호화 되어 있습니다.

프로그램 다운로드 : http://keepass.info/download.html

.NET 용 Docking Library! DockPanel Suite

2009-03-26T16:23:02+09:00

무료로 사용가능한 윈도우 도킹(Docking) 라이브러리를 찾는 도중 소스포지(http://sourceforge.net/projects/dockpanelsuite)에서 발견한 오픈소스 라이브러리이다. 이 라이브러리를 이용하면 Visual Studio 2008과 같은 형식의 도킹 시스템을 구현할 수 있다.

가장 아쉬운 점은 디자인 타임에서 컨트롤을 도킹할 수 없다는 점이다. 도킹하려고 하는 컨트롤을 UserControl이 아닌 Form을 기반으로 상속받아 만들어야 하기 때문이다.

개발자는 'Weifen Luo' 라고 하는 사람이다. 이런 소스를 개발하여 오픈하다니.. 그저 고마울 따름이다..

C# Naming Guide

2009-03-26T16:09:29+09:00

Naming Conventions for .NET / C# Projects

Martin Zahn, Akadia AG, 20.03.2003

The original of this document was developed by the Microsoft special interest group. We made some addons.

This document explains the naming conventions that should be used with .NET projects.

A consistent naming pattern is one of the most important elements of predictability and discoverability in a managed class library. Widespread use and understanding of these naming guidelines should eliminate unclear code and make it easier for developers to understand shared code.

Capitalization Styles Defined

We define three types of capitalization styles:

Pascal case

The first letter in the identifier and the first letter of each subsequent concatenated word are capitalized.

Example:

BackColor, DataSet

Camel case

The first letter of an identifier is lowercase and the first letter of each subsequent concatenated word is capitalized.

Example:

numberOfDays, isValid

All letters in the identifier are capitalized.

Example:

ID, PI

Hungarian Type Notation Defined

Hungarian notation is any of a variety of standards for organizing a computer program by selecting a schema for naming your variables so that their type is readily available to someone familiar with the notation. It is in fact a commenting technique.

Example:

strFirstName, iNumberOfDays

There are different opinions about using this kind of type notation in programming nowadays. Some say that it’s useful, and it should be used everywhere to enhance clarity of your code. Others say it just obfuscates your code, because it has no real advantage in modern programming environments.

Our point of view is a moderated one: use it wisely, meaning, we only use Hungarian notation for private or local variables, that are only accessible and interesting to the programmer of the class.

Don’t use it with public variables, properties or parameters in methods, because they are exposed to the outside world. Someone who uses your classes and accesses properties of your class, is not interested in type, but just wants to use them.

In the .NET framework, there are a lot of types, so we extended and adapted the Hungarian notation with our own type notation.

Naming Guidelines

1). Private Variables (Fields in C#) Naming Guidelines

Prefix private variables with a "_" and Hungarian-style notation.

Use camel case as a general rule, or uppercase for very small words

Example:

_strFirstName, _dsetEmployees

// Field
private OleDbConnection _connection;

// Property
public OleDbConnection Connection
{
get { return _connection; }
set { _connection = value; }
}

2). Local Variables Naming Guidelines

Prefix private or local variables with Hungarian-style notation.

Use camel case as a general rule, or uppercase for very small words

Example:

strFirstName, dsetEmployees

3). Namespace Naming Guidelines

The general rule for naming namespaces is to use the company name followed by the technology name and optionally the feature and design as follows:

CompanyName.TechnologyName[.Feature][.Design]

Prefixing namespace names with a company name or other well-established brand avoids the possibility of two published namespaces having the same name. Use a stable, recognized technology name at the second level of a hierarchical name.

Example:

Akadia.Traffic, System.Web.UI, System.Windows.Forms

Use Pascal case as a general rule, or uppercase for very small words.

Example:

System.Windows.Forms, System.Web.UI

4). Class Naming Guidelines

Use a noun or noun phrase to name a class.
Do not use a type prefix, such as C for class, on a class name.
Do not use the underscore character (_).

Use Pascal case. Example:

FileStream, Button

5). Interface Naming Guidelines

Prefix interface names with the letter "I", to indicate that the type is an interface.
Do not use the underscore character (_).

Use Pascal case. Example:

IServiceProvider, IFormatable

6). Parameter Naming Guidelines

Use descriptive parameter names. Parameter names should be descriptive enough that the name of the parameter and its type can be used to determine its meaning in most scenarios. To distinguish parameters from other variables the prefix "p" should be used.

Do not prefix parameter names with Hungarian type notation.

Do not use a prefix for parameter names of an event handler and exceptions.

Use camel case. Example:

pTypeName, pNumberOfItems

7). Method Naming Guidelines

Use verbs or verb phrases to name methods.

Use Pascal case. Example:

RemoveAll(), GetCharAt()

8). Property / Enumerations Naming Guidelines

Use a noun or noun phrase to name properties.
Do not use Hungarian notation.

Use Pascal case. Example:

BackColor, NumberOfItems

9). Event Naming Guidelines

Use an EventHandler suffix on event handler names.

Specify two parameters named sender and e. The sender parameter represents the object that raised the event. The sender parameter is always of type object, even if it is possible to use a more specific type. The state associated with the event is encapsulated in an instance of an event class named "e". Use an appropriate and specific event class for the e parameter type.

Name an event argument class with the EventArgs suffix.

Use Pascal case. Example:

public delegate void MouseEventHandler(object sender, MouseEventArgs e);

9). Exception Naming Guidelines

Event handlers in Visual Studio .NET tend to use an "e" parameter for the event parameter to the call. To ensure we avoid a conflict, we will use "ex" as a standard variable name for an Exception object.

Example

catch (Exception ex)
{
// Handle Exception
}

10). Constant Naming Guidelines

The names of variables declared class constants should be all uppercase with words separated by underscores. It is recommended to use a grouping naming schema.

Example (for group AP_WIN):

AP_WIN_MIN_WIDTH, AP_WIN_MAX_WIDTH, AP_WIN_MIN_HIGHT, AP_WIN_MAX_HIGHT

11). C# Primitive Type Notation

sbyte   sy
short   s
int     i
long    l
byte    y
ushort us
uint    ui
ulong   ul
float   f
double d
decimal dec
bool    b
char    c

12). Visual Control Type Notation

Assembly                                asm
Boolean                                 bln
Button                                  btn
Char                                    ch
CheckBox                                cbx
ComboBox                                cmb
Container                               ctr
DataColumn                              dcol
DataGrid                                dgrid
DataGridDateTimePickerColumn            dgdtpc
DataGridTableStyle                      dgts
DataGridTextBoxColumn                   dgtbc
DataReader                              dreader
DataRow                                 drow
DataSet                                 dset
DataTable                               dtable
DateTime                                date
Dialog                                  dialog
DialogResult                            dr
Double                                  dbl
Exception                               ex
GroupBox                                gbx
HashTable                               htbl
ImageList                               iml
Integer                                 int
Label                                   lbl
ListBox                                 lbx
ListView                                lv
MarshallByRefObject                     rmt
Mainmenu                                mm
MenuItem                                mi
MDI-Frame                               frame
MDI-Sheet                               sheet
NumericUpDown                           nud
Panel                                   pnl
PictureBox                              pbx
RadioButton                             rbtn
SDI-Form                                form
SqlCommand                              sqlcom
SqlCommandBuilder                       sqlcomb
SqlConnection                           sqlcon
SqlDataAdapter                          sqlda
StatusBar                               stb
String                                  str
StringBuilder                           strb
TabControl                              tabctrl
TabPage                                 tabpage
TextBox                                 tbx
ToolBar                                 tbr
ToolBarButton                           tbb
Timer                                   tmr
UserControl                             usr
WindowsPrincipal                        wpl

Generic List<> 복제하는 방법

2009-03-23T14:19:58+09:00

클래스에서 Copy() 나 Clone() 함수를 제공하지 않아 For 문을 이용해서 대입해야 하는 줄 알았다...

// Generic List 생성
List<int> a = new List<int>();

// 값 추가하기
a.Add(1);
a.Add(2);
a.Add(3);

// List 복제하기
List<int> b = new List<int>(a);

위의 코드와 같이 생성할 List 템플릿의 생성자에 복제할 List 클래스의 인스턴스를 넘겨주면 복제가 된다.

소스 커밋(Commit)시 메세지를 입력하지 않으면 커밋되지 않도록 설정하기

2009-03-16T13:34:18+09:00

pre-commit.cmd

 "C:\Program Files\Subversion\bin\svnlook.exe" log -t %2 %1 | FindStr [a-zA-Z0-9]
IF %ERRORLEVEL% EQU 0 GOTO OK
echo "커밋 메세지를 입력해야 합니다" >&2
exit 1
:OK
exit 0

바이너리(Binary) 파일 Read/Write 하기

2009-03-03T09:27:18+09:00

.NET Framrwork에서는 바이너리(Binary) 파일을 읽고 쓰기위한 BinaryReader, BinaryWriter 클래스를 제공한다.

이 클래스를 이용하면 쉽게 파일을 읽고 쓸 수 있다.

BinaryReader 를 이용한 파일 읽기

BinaryReader

// 파일 열기
FileStream fs = File.OpenRead("a.bin");

// 스트림을 이용하여 BinaryReader 클래스 생성하기
BinaryReader br = new BinaryReader(fs);

// 파일 Read용 임시 변수
Int16 temp = 0;

// 2바이트 읽기
temp = br.ReadInt16();

// 60문자 만큼 스트링 읽기
String str = new String(br.ReadChars(60));

br.Close();
fs.Close();

BinaryWriter 를 이용한 파일 쓰기

BinaryWriter

// 파일 생성
FileStream fs = File.Create("a.bin");

// 스트림을 이용하여 BinaryWriter 클래스 생성하기
BinaryWriter bw = new BinaryWriter(fs);

// 임시 변수
Int16 temp = 0;

// 2바이트 쓰기
bw.Write(temp);

bw.Close();
fs.Close();

이와 같이 쉽에 Read/Writer가 가능하다.

윈도우(Windows), 리눅스(Linux), 맥(Mac)에서 이슈트래커 정상적으로 사용하기

2009-03-02T14:14:17+09:00

현재 제로보드 XE에 적용되어 있는 이슈트래커는 리눅스 기반에 설치되어야만 정상적으로 동작이 가능하다.

왜 윈도우나 맥에서는 동작되지 않는지 분석해 본 결과 각 운영체제별로 줄바꿈 문자에 대한 처리가 틀려 나타난 현상이였다.

각 운영체제별 줄바꿈 문자는 아래와 같은 구성으로 이루어져 있다.

윈도우 : 캐리지 리턴(Cr) & 라인 피드(Lf)

리눅스 : 라인 피드(Lf)

맥 : 캐리지 리턴(Cr)

그러므로, 각 줄바꿈 문자를 통일되게 하나의 형식으로 변환해주면 정상적인 사용이 가능하다.

/modules/issuetracker/classes/svn.class.phpgetList 함수

 function getList($path, $revs = null) {
    if(substr($path,0,1)=='/') $path = substr($path,1);
    if(strpos($path,'..')!==false) return;

    $command = sprintf(
        '%s --non-interactive %s --config-dir %s list %s%s%s',
        $this->svn_cmd,
        $this->_getAuthInfo(),
        $this->tmp_dir,
        $this->url,
        $path,
        $revs?'@'.(int)$revs:null
    );

    $buff = $this->execCmd($command, $error);

    // 운영체제 별 줄바꿈 문자 처리가 틀리므로 \n으로 통일시키기
    $buff = str_replace(array("\r\n", "\r"), "\n", $buff);

    $list = explode("\n",$buff);

    if(!count($list)) return null;

    $file_list = $directory_list = $output = array();

    foreach($list as $name) {
        if(!$name) continue;
        $obj = null;
        $obj->name = $name;
        $obj->path = $path.$name;

        $logs = $this->getLog($obj->path, $revs, null, false, 1);
        $obj->revision = $logs[0]->revision;
        $obj->author = $logs[0]->author;
        $obj->date = $this->getDateStr("Y-m-d H:i",$logs[0]->date);
        $obj->gap = $this->getTimeGap($logs[0]->date);
        $obj->msg = $this->linkXE($logs[0]->msg);

        if(substr($obj->path,-1)=='/') $obj->type = 'directory';
        else $obj->type = 'file';

        if($obj->type == 'file') $file_list[] = $obj;
        else $directory_list[] = $obj;
    }
    return array_merge($directory_list, $file_list);
}

위의 코드의 18행에서처럼 줄바꿈 문자인 '\n' 을 이용하여 분리하기 전에 윈도우와 맥의 줄바꿈 문자인 '\r\n' ,'\r' 을 먼저 '\n' 으로 치환하고 분리하게 되면 정상적인 동작이 가능하다.

XmlTextReader 클래스를 이용한 XML파일 읽기

2009-02-27T11:34:23+09:00

이번에는 XML파일을 XmlTextReader 클래스를 이용하여 읽는 방법에 대해 살펴보도록 하자.

읽고자하는 XML 파일

<?xml version="1.0"?>
<!--This file stores application version list-->
<Programs>
  <Program>
    <ID>ZemnaAutoUpdater</ID>
    <Name>Zemna Auto Updater</Name>
    <Contents>하하하하하</Contents>
    <RegistrationDate>2009-02-27 오전 11:28:02</RegistrationDate>
    <Versions>
      <Version>
        <VersionNo>1.0.0</VersionNo>
        <RegistrationDate>2009-02-27 오전 11:28:02</RegistrationDate>
        <EditDate>2009-02-27 오전 11:28:02</EditDate>
        <FolderPath>cadfasd</FolderPath>
        <Files>
          <File>123.tx</File>
        </Files>
      </Version>
    </Versions>
  </Program>
</Programs>

위 파일을 읽는 코드는 아래와 같다.

XmlTextReader로 파일 읽기 샘플

List<ProgramInfo> IDataProcessor.LoadList(string filePath)
{
    // 데이터를 저장 할 변수 선언
    List<ProgramInfo> listPrg = null;

    int piIdx = 0;  // Last ProgramInfo Index
    int viIdx = 0;  // Last VersionInfo Index

    XmlTextReader reader = new XmlTextReader(filePath);

    // 공백을 처리하지 않음
    reader.WhitespaceHandling = WhitespaceHandling.None;

    while (reader.Read())
    {
        reader.MoveToContent();

        if (reader.NodeType == XmlNodeType.Element)
        {
            switch (reader.Name)
            {
                case "Program":
                    if (listPrg == null)
                        listPrg = new List<ProgramInfo>();
                    ProgramInfo pi = new ProgramInfo();
                    listPrg.Add(pi);
                    piIdx = listPrg.Count - 1;
                    break;
                case "ID":
                    listPrg[piIdx].ID = reader.ReadString();
                    break;
                case "Name":
                    listPrg[piIdx].Name = reader.ReadString();
                    break;
                case "Contents":
                    listPrg[piIdx].Contents = reader.ReadString();
                    break;
                case "RegistrationDate":
                    if (reader.Depth == 2)
                        listPrg[piIdx].RegistrationDate = Convert.ToDateTime(reader.ReadString());
                    else
                        listPrg[piIdx].Versions[viIdx].RegistrationDate = Convert.ToDateTime(reader.ReadString());
                    break;
                case "Version":
                    if (listPrg[piIdx].Versions == null)
                        listPrg[piIdx].Versions = new List<VersionInfo>();
                    VersionInfo vi = new VersionInfo();
                    listPrg[piIdx].Versions.Add(vi);
                    viIdx = listPrg[piIdx].Versions.Count - 1;
                    break;
                case "VersionNo":
                    listPrg[piIdx].Versions[viIdx].VersionNo = reader.ReadString();
                    break;
                case "EditDate":
                    listPrg[piIdx].Versions[viIdx].EditDate = Convert.ToDateTime(reader.ReadString());
                    break;
                case "FolderPath":
                    listPrg[piIdx].Versions[viIdx].FolderPath = reader.ReadString();
                    break;
                case "File":
                    if (listPrg[piIdx].Versions[viIdx].FileList == null)
                        listPrg[piIdx].Versions[viIdx].FileList = new List<string>();
                    listPrg[piIdx].Versions[viIdx].FileList.Add(reader.ReadString());
                    break;
            }
        }
    }

    reader.Close();

    return listPrg;
}

XmlTextWriter 클래스를 이용한 XML파일 생성법

2009-02-27T10:39:48+09:00

.NET Framework에서는 XML을 쉽게 기록할 수 있도록 XmlTextWriter 클래스를 제공하고 있다.

이 XmlTextWriter 클래스는 속도가 빠르고, 캐시되지 않으며, 앞으로만 이동 가능한 방법을 제공한다.

아래는 XmlTextWriter 클래스를 사용한 예제이다.

XmlTextWriter 사용 예제

void IDataProcessor.SaveList(List<ProgramInfo> programList, string filePath)
{
    XmlTextWriter writer = new XmlTextWriter(filePath, null);

    // 자식요소에 따라 들여쓰기하기
    writer.Formatting = Formatting.Indented;

    writer.WriteStartDocument();

    writer.WriteComment("This file stores application version list");

    // <Programs>
    writer.WriteStartElement("Programs");

    for (int i = 0; i < programList.Count; i++)
    {
        // <Program>
        writer.WriteStartElement("Program");

        // <ID />
        writer.WriteElementString("ID", programList[i].ID);

        // <Name />
        writer.WriteElementString("Name", programList[i].Name);

        // <Contents />
        writer.WriteElementString("Contents", programList[i].Contents);

        // <RegistrationDate />
        writer.WriteElementString("RegistrationDate", programList[i].RegistrationDate.ToString());

        // <Versions>
        writer.WriteStartElement("Versions");

        for (int j = 0; j < programList[i].Versions.Count; j++)
        {
            // <Version>
            writer.WriteStartElement("Version");

            // <VersionNo />
            writer.WriteElementString("VersionNo", programList[i].Versions[j].VersionNo);

            // <RegistrationDate />
            writer.WriteElementString("RegistrationDate", programList[i].Versions[j].RegistrationDate.ToString());

            // <EditDate />
            writer.WriteElementString("EditDate", programList[i].Versions[j].EditDate.ToString());

            // <FolderPath />
            writer.WriteElementString("FolderPath", programList[i].Versions[j].FolderPath);

            // <Files>
            writer.WriteStartElement("Files");

            for (int k=0; k<programList[i].Versions[j].FileList.Count; k++)
            {
                // <File />
                writer.WriteElementString("File", programList[i].Versions[j].FileList[k]);
            }

            // </Files>
            writer.WriteEndElement();

            // </Version>
            writer.WriteEndElement();
        }

        // </Versions>
        writer.WriteEndElement();

        // </Program>
        writer.WriteEndElement();
    }

    // </Programs>
    writer.WriteEndElement();

    writer.Flush();
    writer.Close();
}

위의 형식대로 파일을 기록하게 되면 아래와 같은 구조의 XML 파일이 생성되게 된다.

생성된 XML 파일

<?xml version="1.0"?>
<!--This file stores application version list-->
<Programs>
  <Program>
    <ID>ZemnaAutoUpdater</ID>
    <Name>Zemna Auto Updater</Name>
    <Contents>하하하하하</Contents>
    <RegistrationDate>2009-02-27 오전 11:28:02</RegistrationDate>
    <Versions>
      <Version>
        <VersionNo>1.0.0</VersionNo>
        <RegistrationDate>2009-02-27 오전 11:28:02</RegistrationDate>
        <EditDate>2009-02-27 오전 11:28:02</EditDate>
        <FolderPath>cadfasd</FolderPath>
        <Files>
          <File>123.tx</File>
        </Files>
      </Version>
    </Versions>
  </Program>
</Programs>

버전관리를 위한 ObsoleteAttribute

2009-02-24T14:28:54+09:00

프로그램이나 라이브러리를 버전업할 때 기존에 제작했던 함수를 새로운 기능을 추가한 함수로 대체하거나 할 경우가 생길 수 있습니다.

이런 경우, 기존에 제공하던 함수를 삭제하게 되면 하위 프로그램들과의 호환성에 문제가 생기고, 그냥 두면 코드가 복잡해지고 어디에서 사용했는지 분간해내기 어려운 경우가 생깁니다.

이때, Obsolete 특성을 사용하게 되면 그러한 문제를 해결 할 수 있습니다.

Obsolete 특성은 그 위치의 항목을 앞으로 계속 사용하지 않는 편이 좋은 것으로 표시해줍니다. 이 특성이 어떻게 구성되어 있는지에 따라 Obsolete로 표시된 항목을 사용할 때마다 경고나 오류가 표시됩니다. 예를 들면 다음과 같습니다.

[System.Obsolete("use class B")]
class A
{
    public void Method() { }
}
class B
{
    [System.Obsolete("use NewMethod", true)]
    public void OldMethod()  { }
    public void NewMethod()  { }
}

위와 같이 적용하고 A 클래스를 사용하게 되면 "use class B" 메세지의 경고가 생성되게 됩니다.

그리고 B 클래스의 OldMethod 함수를 호출하게 되면 이 경우에는 두번째 인수가 true로 설정되어 있으므로 컴파일러 오류가 발생하게 됩니다.

Obsolete 특성은 인수 없이도 사용할 수 있지만 해당 항목이 계속 사용되지 않는 이우와 대신 사용할 항목에 대한 정보를 포함하는 것이 좋습니다.

Hudson Tutorials - 윈도우에 Hudson 설치하기

1. 최신버전의 Hudson을 다운로드 한다.

2. Java SE Runtime Environment(JRE) 를 설치한다.

3. Hudson을 실행한다.

4. Hudson을 Windows Service로 동작시키기

마치며,

VisualSVN Server를 이용해 손쉽게 SVN 서버 구축하기

1. VisualSVN 사이트에서 최신 버전의 VisualSVN Server 프로그램을 다운로드 한다.

2. VisualSVN Server를 설치한다.

3. 설치된 VisualSVN Server를 실행한다.

4. 새로운 저장소를 생성한다.

5. 저장소에 권한을 부여한다.

마치며,

안드로이드폰 프로그램개발을 위한

안드로이드(Android) SDK를 다운받자

개발을 위한 자료를 찾기 위한 사이트네...괜찮은거 같애...

Comparing TWO continuous build tools: Cruise Control and Hudson

Alternative building tools available.

IIS에서 WCF호스팅하기

1. WCF 서비스 라이브러리 프로젝트를 생성한다.

2. 텍스트 형식의 프로젝트명.svc 파일을 만들어 정의한다.

3. Web.config 파일에 서비스를 정의한다.

4. 인터넷 정보 서비스를 실행하고, 웹사이트에 가상 디렉토리를 추가한다.

5. Windows Console Application 프로젝트를 생성한다.

6. System.ServiceModel 라이브러리를 참조한다.

7. 서비스 참조 추가에서 WCF 서비스를 선택하여 추가한다.

8. 클라이언트에 생성된 프록시를 사용한다.

다국어 프로그래밍의 기초지식

i18N

문자 집합

코드 페이지

유니코드

Gemini Key Features

Gemini 시작하기

C# 설계에 참고사항

WPF 소개

Open Source Charting & Reporting Tools in C#

Pro WPF in C# 2008 구입

확장 메서드의 활용

Full-Screen Application

Overloading Methods in WCF

Hosting multiple WCF services under a single windows service

Managed Extensibility Framework : Overview

Managed Extensibility Framework

Simple Introduction to Extensible Applications with the Managed Extensions Framework

Background

Enter MEF

More Value of MEF

Taking MEF to the Next Level

MEF Preview 6 공개

Querying the CompositionContrainer

Recomposition

Strongly Typed Metadata

Exports and Metadata

Lazy Exports

Catalog 사용

Imports 선언

Exports 선언

Parts 와 Contracts 선언

MEF (Managed Extensibility Framework) 란?

System.AddIn Scenarios

System.AddIn Scenarios

Separate Datasets from TableAdapters

http://blogs.microsoft.co.il/blogs/bursteg/archive/2007/05/19/OrcasDatasets.aspxOrcas Datasets - Separate Datasets from TableAdapters

Team Foundation Server and Windows SharePoint Services SP2

오라클에서 Date vs. Number(or Varchar2)

네트워크에서 rewirte 에 대한 기본 개념

Extension 클래스를 통해 기존 클래스를 확장하기

Need to make a user control transparent

Drag & Drop 기능 구현 기초

.NET Code Converter

무료료 Subversion + Trac 공간을 제공해주는 사이트

대한민국 PDF 뷰어! ePapyrus PDF-Pro4

Visual Studio에서 GAC에 등록한 Assembly가 참조추가에 출력되도록 설정하기

Summary

More Information

References

GAC(Global Assembly Cache)에 대해 알아보자

Visual Studio 2010의 Code Analysis Enhancements

마이크로소프트의 'I am a developer' 사이트

http://blogs.microsoft.co.il/blogs/bursteg/archive/2007/05/19/OrcasDatasets.aspx

Orcas Datasets - Separate Datasets from TableAdapters