LINQPad를 이용하여 LINQ 편집하기

통합 언어 쿼리라고 불리는 LINQ ('링크'로 발음 합니다. )는 관계형 데이터 모델(RDB)를 객체지향 모델로 매핑하는
(MS의 표현에 따르면) 획기적인 방법을 제공 하는데요..  
이 LINQ 편집을 위한 좋은 툴이 있어 소개합니다.

LINQPad 사이트
물론, VisualStudio 2008에서도 이 언어를 편집할 수 있습니다만 여기서 소개하는 LINQPad 라는 프로그램은
C# 3.0 in a Nutshell의 저자 Joseph Albahari씨가 개발하였으며 설치가 필요없는 약 3MB 용량에 AutoUpdate를
지원합니다. 이 어플리케이션의 소스는 Standard Copyright Laws의 보호아래있지만 프로그램의 사용에는 별다른
라이센스 제약 없이 자유롭게 이용할 수 있습니다.
자동완성 기능을 지원하는 버전은 약간의 금액을 받는다고 합니다.

이 어플리케이션을 사용하기위해서는 .NetFramework 3.5가 필수요건입니다. 이는 어플리케이션보다는
Linq가 .NetFramwork 3.5 이후부터 사용가능하기 때문에 생긴 제약입니다.
현재 LINQPad를 적용할 수 있는 DBMS로는 SQL Express, SQL 2000, SQL 2005이며 약간의 제약이 있지만
SQL 2008에도 사용할 수 있다고 하네요.

LINQPad는 링크 편집에 도움이 될 뿐만 아니라 C# 3.0 in a Nutshell에 수록된 200여개의 예제 내장해 이를 통해
링크 문법을 익히는데도 큰 도움이 될듯합니다.
뿐만 아니라 아래 스크린샷에 있는 Linq to object, Linq to lambda, Linq to sql 같은 유용한 기능도 제공하고 있습니다.

LINQ 쿼리 결과 화면

LINQ 쿼리 결과 화면


LINQ를 lambda로 변환한 결과 화면

LINQ를 lambda로 변환한 결과 화면


LINQ를 SQL로 변환한 결과 화면

LINQ를 SQL로 변환한 결과 화면


2009/02/11 13:17 2009/02/11 13:17
Trackback Address:이 글에는 트랙백을 보낼 수 없습니다
  1. 정말 괜찮은 프로그램이군요. 한번 써봐야 겠습니다.

Java 개발자 입장에서 바라본 .Net의 Delegate


지난 수년간 JAVA로 개발을 해 오다 작년부터 필요에의해 MS의 .Net Framework와 C#으로 프로젝트를 진행하고 있다.

.Net Framework와 C#이란 언어를 다루면서 처음으로 접한 문화 충격이라면 Property와 Delegate일 거다.
MS진영 개발자라면 당연한것으로 받아들이고 있을 두 개념을 처음 접했을때의 신선함이란!

자바 개발자들을 위해 간략하게 첨언하면
.Net에서 이야기하는 Property란 java 세상에서는 쉽게말해 getter와 setter에 해당하는데 요걸 코드로 표현하는 방법이 재미있다.
(물론 이 property란게 코드의 표현이 재미있다의 수준에서 그치는 건 절대 아니다.)
그리고 .Net에서 이야기하는 Delegate는 메소드 레퍼런스의 OOP적인 Wrapper이다.
이 Delegate란게 Java언어에서도 구현은 할 수 있지만 .Net에서와 같은 우아한 코드로 표현되진 않는다.
( Java는 OOP 개념으로 접근하여 교과서스럽게 코드로 표현하기 때문일거다..
여튼 Java에서는 없는 개념이라고 맘편히 생각해도 되겠다. )

뭐? '메소드 레퍼런스의 OOP적인..'이 어쨌다고? 문자로 표현하니 뭘 이야기하는 건지 금방 못알아듣겠지만 개념이 그렇다.
(C의 표현을 빌자면 '함수의 포인터' 정도로 불릴 수 있겠다.) 나 역시 코드를보고서야 위 말의 의미를 알 수 있었으니까..

풀어 말하자면 클래스 인스턴스의 레퍼런스를 다른 클래스 인스턴스의 메소드에 전달하는것과 마찬가지로
메소드의 레퍼런스를 객체 다루듯이 다른 클래스 인스턴스의 메소드에 전달하는것이 가능하다.
놀랍지 않은가? 메소드를 객체처럼 주고 받을 수 있다니!!

이게 사용하다보면 은근히 편하다. Java 세상에선 Callback을 받기위해 자신의 레퍼런스를 넘겨야 가능할 일을
.Net에서는 Callback 메소드를 싼 클래스를 넘겨 버리면 그만이니...

확실히 최근에 나온 언어일수록 개발의 편의성이 높긴하다. Java에도 조금 유연성을 발휘하여 이런 개념을 도입하면 어떨까?
[상업적으로 가장 성공한 OOP언어가 Java가 아니던가. Java에 Generic 개념이 도입되었을때도 자바스럽지
않다며 유난을 떠는 사람들도 많았으니 .net의 delegate 개념을 언어 차원에서 지원한다면 이건 더이상 java가 아니다며
너스레를 떠는 사람이 넘쳐날지도.. ]

2008/11/18 22:42 2008/11/18 22:42
Trackback Address:이 글에는 트랙백을 보낼 수 없습니다
  1. 결국 그 delegate가 Python 언어의 람다 함수나 Javascript의 익명 함수와 같은 역할을 하죠. 원래 Lisp 같은 함수형 프로그래밍 언어 쪽에서 나온 개념인데 이게 은근 편리(?)하다보니 요즘은 원래 함수형 언어가 아닌 언어에서도 많이 지원하는 추세인 것 같습니다.

  2. Blog Icon
    서비

    예 daybreaker님께서 주신 말씀대로입니다.
    본질을 이해하고나면 표현하는 방법이 무슨 대수겠습니까만은..
    이게 시작을 대중적인 OOP언어로 한 저같은 사람은 생소한 코드
    표기방법과 쓰임에 당황+놀라움을 동시에 경험하기도 한답니다.. ^^

  3. Blog Icon

    자바보다 먼저나온 Delphi 에도 있는기능인데요....

  4. Blog Icon
    김코더

    기능은 앞으로도 나올언어들거 개발되어 배포되는것도 수두룩합니다
    적용시점이 관건이지..

HitTest를 통한 마우스 아래의 컨트롤 구하기

WPF 어플리케이션이든 아니든 마우스가 위치한 곳의 컨트롤을 알아야 할 때가 종종 있다.
다른 방식으로도 마우스 아래에 있는 컨트롤을 알아낼 수 있지만 WPF라면 아래와 같이 VisualTreeHelper클래스의
HitTest를 이용해서 컨트롤을 얻어오는 방법도 있다.

T GetItemAtLocation(Point location)
{
    T foundItem = default(T);
    HitTestResult hitTestResults = VisualTreeHelper.HitTest(treeView,location);
    
    if(hitTestResults.VisualHit is FrameworkElement)
    {
        object dataObject = (hitTestResults.VisualHit as 
            FrameworkElement).DataContext;

        if(dataObject is T)         {             foundItem = (T)dataObject;         }     }

    return foundItem; }



위 메소드의 사용법은 이렇게 될 수 있다.
void treeView_Drop(object sender,DragEventArgs e)
{
    if(e.Data.GetDataPresent(typeof(Task)))
    {
        Task sourceTask = (Task)e.Data.GetData(typeof(Task));
        Task targetTask = GetItemAtLocation(MouseUtilities.GetMousePosition());

        // Code to move the item in the model is placed here...     } }


2008/03/21 12:09 2008/03/21 12:09
Trackback Address:이 글에는 트랙백을 보낼 수 없습니다

닷넷 프로젝트에서 로깅을... Log4Net - Logging Framework for Microsoft .Net

프로그램을 개발하거나 운영하는데 있어 로깅만큼 중요한 기능도 없을것이다. 시스템이나 어플리케이션에서 발생한 문제 해결의 출발점이
'에러의 재현' 과 '로그 분석'이기 때문이다.

Java 진영에서는, 이미 오픈소스에서 발전해 온, Log4J라는 막강한 로깅 프레임웍이 사실상의 표준(de facto standard)으로 존재하고 있다.
( Commons Logging 도 있지만 Log4J의 Wrapper 정도라고 생각하면 된다. )
그럼, MS진영에는 어떤 로깅 프레임웍이 있을까?
지금 회사에서 진행중인 프로젝트가 .Net 기반의 윈도우즈 어플리케이션이라 MS계열에서 널리쓰이고 있을것 같은(?) 로깅툴을 찾아볼 필요가 있었다.

그런데 아니나 다를까.. 이미 이쪽 진영에까지 Log4J의 영향력이 미치고 있을줄이야..
이미 Log4J를 닷넷용으로 포팅한 Log4Net이 있는 것이다.

Log4J를 사용해 봤다면 Log4Net역시 어렵지 않게 사용 할 수 있다.
이번 포스팅에서는 Log4Net을 활용하여 .Net 어플리케이션을 로깅하는 방법을 살펴보자.

Log4Net 공식 사이트 : http://logging.apache.org/log4net/index.html
라이센스 : Apache License, Ver 2.0 ( 상용어플리케이션에 이용할 수 있다!! )
지원하는 프레임워크 : 2008년 1월 현재
                               MS .Net Framework 1.0 , MS .Net Framework 1.1 , MS .Net Framework 2.0 ,
                               MS .Net Compact Framework 1.0 , Mono 1.2.3, MS Shared Source CLI 1.0, CLI 1.0 Compatible
                               6개의 프레임워크를 지원.
Appenders 일람
Appender .NET Framework 1.0 .NET Framework 1.1 .NET Framework 2.0 .NET CF 1.0 Mono 1.2 Shared Source CLI 1.0 CLI 1.0 Compatible
AdoNetAppender x x x x x x
AnsiColorTerminalAppender x x x x x x x
AspNetTraceAppender x x x x x
BufferingForwardingAppender x x x x x x x
ColoredConsoleAppender x x x
ConsoleAppender x x x x x x x
DebugAppender x x x x x x x
EventLogAppender x x x x x
FileAppender x x x x x x x
ForwardingAppender x x x x x x x
LocalSyslogAppender x x x x x
MemoryAppender x x x x x x x
NetSendAppender x x x
OutputDebugStringAppender x x x x
RemoteSyslogAppender x x x x x x x
RemotingAppender x x x x x x
RollingFileAppender x x x x x x x
SmtpAppender x x x x x
SmtpPickupDirAppender x x x x x x x
TelnetAppender x x x x x x x
TraceAppender x x x x x x x
UdpAppender x x x x x x x

Log4Net은 최종으로 로그가 기록될 장소( 파일, DB, 메일 등..)를 Appender를 이용하여 구분하고 있다.
사용할 Appender를 Log4Net 설정파일에 기술하면 Log4Net이 해당 Appender를 사용하여 로그를 기록하게 된다.  

사용방법은 이렇다.

1. 어플리케이션 소스 코드를 작성한다.

소스코드 보기..

2. 다운로드 받은 Log4Net을 압축해제하여 나온 디렉토리중 개발을 진행하고 있는 닷넷 프레임워크 버전에 해당하는
   log4net.dll을 Reference 한다.
3. Log4Net 설정하기
    - 설정파일을 작성하여 어플리케이션이 빌드되는 디렉토리에 배치한다.

log4net.xml 보기..

4. 어플리케이션을 빌드후 구동하여 로그가 잘 남는것을 확인한다. ^^


Log4NetSample.zip

본 포스팅에 사용된 예제소스를 포함한 비주얼스튜디오용 솔루션파일

첨부한 프로젝트는 WPF 어플리케이션으로 작성 되었습니다. 비주얼 스튜디오 2008이라면 바로 빌드가 가능하겠지만 VS2005인 경우 실행을 위해서는 http://www.yunsobi.com/blog/280 포스트를 참조하여 WPF개발 환경을 구축 한 후 실행 하셔야 합니다.


좀 더 들여다 볼까요?.

퍼포먼스 ( Perfomance )
로깅에서 퍼포먼스를 이야기할 때 다음 세가지 이슈사항을 고려할 수 있습니다.

1. Logging을 하지 않을 경우( turned off ) 로깅코드에 의한 퍼포먼스
로깅레벨을 OFF 로 설정한 경우라면 메소드 호출 비용이 듭니다. 하지만 메소드 생성에는 파라메터 생성에따르는 숨겨진 비용도 포함되어 있음을 잊지 마세요. 예를들어 다음과 같은 코드
log.Debug("Entry number: " + i + " is " + entry[i].ToString()); 
에서 i 와 entry[i] 를 string으로 치환하는 비용과 각 string을 더하는 비용이 소모됩니다. 파라메터를 생성하는 비용은 파라메터의 갯수와 생성되는 횟수에 큰 영향을 받습니다.

파라메터 생성 비용을 없애고 싶다면 아래와 같은 코드를 작성 하세요.
if(log.IsDebugEnabled)
{
    log.Debug("Entry number: " + i + " is " + entry[i].ToString());
}

디버깅 모드가 꺼져 있다면 위 코드는 파라메터 생성에드는 비용은 0이 될것입니다. 반면에 디버그기능이 켜져 있다면 두배의 비교 시간이 필요합니다. '디버그기능이 켜져있는지(log.IsDebugEnabled)'와 '로거가 디버그 모드인지(log.Debug())' . 하지만 이를 비교하는데 필요한시간은 매우 미미해서 실제 로그를 기록하는데 드는 비용의 1%정도에 해당합니다.
어떤 개발자들은 전처리나 컴파일타임의 테크닉등을 이용하여 로깅에대한 모든 상태를 조절하기도합니다.이는 퍼포먼스 측면에서 보면 완벽하다고 할 수 있겠지만, 로그레벨을 변경하기가 매우 까다로워 집니다. 이렇게 하는것에 대해 많은 사람들이 작은 성능향상을 위해 너무 많은것을 잃고 있다고 조언 합니다.

2. 로깅기능이 켜져 있을 경우 로그레벨에 의한 '로그작성'과 '로그작성 않기'의 판단에 따른 퍼포먼스
이는 기본적으로 로거 Hierarchy의 동작 성능에 따릅니다. 로깅이 켜져(turn on)있다면 log4net은 로그레벨과 로거의레벨을 비교하는 작업이 필요합니다. 하지만 로거 자체에는 레벨이 할당되어 있지 않습니다. 로그레벨은 로거 Hierarch로부터 상속받게 됩니다. 로그레벨을 상속받기 이전에 로거는 상위클래스를 확인 할 필요가 있겠지요.

여기에는 가능하면 짧은시간으로 동작케하기위한 노력이 담겨있습니다. 예를들어, 자식 로거들은 그들의 부모하고만 연결이 됩니다. 이전에 살펴본 BasicConfigurator의 예에서, Com.Foo.Bar 라는 이름의 로거는 루트로거와 직접 연결됩니다. 이것으로 존재하지 않을 Com 이나 Com.Foo 로거를 찾는 수고를 피할 수 있습니다. 이것으로 산재한 (sparse) hierarchies 속에서 상당한 속도향상을 얻을 수 있습니다.

로그레벨 의한 로깅 여부 판단은, IsXXXEnable 프로퍼티를 조사하는것에비해 약 3배정도 느리다고 볼 수 있습니다.

3. 로그메세지를 실제 기록하기
이는 로그메세지를 포메팅하는것과 목표에 실제로 내보내는 비용이 발생합니다. 여기에는 포메터와 Appender가 가능한 빨리 동작하도록 노력을 기울이는 수밖에 없겠지요.


어찌돼었든, log4net의 많은 기능들은 '속도'의 관점에서 디자인되었습니다. 몇몇 log4net 컴포넌트들은 성능향상을 위해 몇번이고 재작성 되었으며, 여전히 옵티마이즈되고 있으며 자주 갱신되고 있습니다. 이것만은 알아주세요.
SimpleLayout의 퍼포먼스 테스트에서 log4net은 System.Console.WriteLine 만큼의 성능을 보여주고 있다는 것을. 


PatterLayout 수정하기
log4net의 출력형식을 조정하기위해서는 PatternLayout과  Conversion Character를 이용할 수 있습니다.
예를들어 log4net.xml에 아래와 같은 패턴을 정의하여 남긴 로그를 보면
   <appender name="RollingFile" type="log4net.Appender.RollingFileAppender">
       <file value="C:\Window1.log" />
       <appendToFile value="true" />
       <datePattern value="-yyyy-MM-dd" />
       <rollingStyle value="Date" />
       <layout type="log4net.Layout.PatternLayout"> <!-- 레이아웃으로 패턴레이아웃을 지정했습니다.  -->
           <conversionPattern value="%d [%t] %-5p %c - %m%n" /> <!-- conversion 캐릭터를 기술했습니다. -->
       </layout>
   </appender>

아래와 같은 형식으로 남습니다.
2008-01-08 13:30:18,938 [10] DEBUG Log4NetSample.Window1 - Log4NetSample.Window1인스턴스 생성 됨
2008-01-08 13:30:24,792 [10] DEBUG Log4NetSample.Window1 - OnButtonMouseDown 이벤트 발생!!
2008-01-08 13:30:24,856 [10] ERROR Log4NetSample.Window1 - 에러 발생!!!
System.FormatException: 입력 문자열의 형식이 잘못되었습니다.
   위치: System.Number.StringToNumber(String str, NumberStyles options, NumberBuffer& number,
 NumberFormatInfo info, Boolean parseDecimal)
   위치: System.Number.ParseInt32(String s, NumberStyles style, NumberFormatInfo info)
   위치: System.Int32.Parse(String s)
   위치: Log4NetSample.Window1.button_Click(Object sender, RoutedEventArgs e) 파일 D:\Project2007
\emodioroot\Samples\Log4NetSample\Log4NetSample\Window1.xaml.cs:줄 68


출력 결과물 형식을 변경하기위해선 Conversion Character를 변경할 필요가 있는데요.
이용가능한 Conversion Character 일람은 아래와 같습니다.

Conversion Character Effect
a Used to output the frienly name of the AppDomain where the logging event was generated.
c

Used to output the logger of the logging event. The logger conversion specifier can be optionally followed by precision specifier, that is a decimal constant in brackets.

If a precision specifier is given, then only the corresponding number of right most components of the logger name will be printed. By default the logger name is printed in full.

For example, for the logger name "a.b.c" the pattern %c{2} will output "b.c".

C

Used to output the fully qualified class name of the caller issuing the logging request. This conversion specifier can be optionally followed by precision specifier, that is a decimal constant in brackets.

If a precision specifier is given, then only the corresponding number of right most components of the class name will be printed. By default the class name is output in fully qualified form.

For example, for the class name "log4net.Layout.PatternLayout", the pattern %C{1} will output "PatternLayout".

WARNING Generating the caller class information is slow. Thus, it's use should be avoided unless execution speed is not an issue.

d

Used to output the date of the logging event. The date conversion specifier may be followed by a date format specifier enclosed between braces. For example, %d{HH:mm:ss,fff} or %d{dd MMM yyyy HH:mm:ss,fff}. If no date format specifier is given then ISO8601 format is assumed (ISO8601DateFormatter).

The date format specifier admits the same syntax as the time pattern string of the ToString.

For better results it is recommended to use the log4net date formatters. These can be specified using one of the strings "ABSOLUTE", "DATE" and "ISO8601" for specifying AbsoluteTimeDateFormatter, and respectively ISO8601DateFormatter. For example, %d{ISO8601} or %d{ABSOLUTE}.

These dedicated date formatters perform significantly better than ToString.

F

Used to output the file name where the logging request was issued.

WARNING Generating caller location information is extremely slow. It's use should be avoided unless execution speed is not an issue.

l

Used to output location information of the caller which generated the logging event.

The location information depends on the CLI implementation but usually consists of the fully qualified name of the calling method followed by the callers source the file name and line number between parentheses.

The location information can be very useful. However, it's generation is extremely slow. It's use should be avoided unless execution speed is not an issue.

L

Used to output the line number from where the logging request was issued.

WARNING Generating caller location information is extremely slow. It's use should be avoided unless execution speed is not an issue.

m

Used to output the application supplied message associated with the logging event.

M

Used to output the method name where the logging request was issued.

WARNING Generating caller location information is extremely slow. It's use should be avoided unless execution speed is not an issue.

n

Outputs the platform dependent line separator character or characters.

This conversion character offers practically the same performance as using non-portable line separator strings such as "\n", or "\r\n". Thus, it is the preferred way of specifying a line separator.

p

Used to output the level of the logging event.

P

Used to output the an event specific property. The key to lookup must be specified within braces and directly following the pattern specifier, e.g. %X{user} would include the value from the property that is keyed by the string 'user'. Each property value that is to be included in the log must be specified separately. Properties are added to events by loggers or appenders. By default no properties are defined.

r

Used to output the number of milliseconds elapsed since the start of the application until the creation of the logging event.

t

Used to output the name of the thread that generated the logging event. Uses the thread number if no name is available.

u

Used to output the user name for the currently active user (Principal.Identity.Name).

WARNING Generating caller information is extremely slow. It's use should be avoided unless execution speed is not an issue.

W

Used to output the WindowsIdentity for the currently active user.

WARNING Generating caller WindowsIdentity information is extremely slow. It's use should be avoided unless execution speed is not an issue.

x

Used to output the NDC (nested diagnostic context) associated with the thread that generated the logging event.

X

Used to output the MDC (mapped diagnostic context) associated with the thread that generated the logging event. The key to lookup must be specified within braces and directly following the pattern specifier, e.g. %X{user} would include the value from the MDC that is keyed by the string 'user'. Each MDC value that is to be included in the log must be specified separately.

%

The sequence %% outputs a single percent sign.

2008/01/08 13:42 2008/01/08 13:42
Trackback Address:이 글에는 트랙백을 보낼 수 없습니다
  1. 2010/08/01 18:33
    item 36, 닷넷 런타임의 진단기능을 활용하라 Tracked from 최익필의 이름없는 블로그
  1. 좋은 정보 감사합니다.

  2. Blog Icon
    서비

    도움이 되셨다니 고맙습니다.

  3. Blog Icon
    kkurrung

    좋은 정보 얻어 갑니다. ^^

WPF 어플리케이션 트레이 아이콘으로 실행하기

2007/10/16 22:34

서비 .NET & WPF ,

아래는 WPF로 작성된 윈도우즈 어플리케이션을 트레이 아이콘으로 실행 할 수 있는 코드.

public partial class Window1 : System.Windows.Window
{

    public Window1()
    {
        InitializeComponent();

        System.Windows.Forms.NotifyIcon ni = new System.Windows.Forms.NotifyIcon();
        ni.Icon = new System.Drawing.Icon("Main.ico");
        ni.Visible = true;
        ni.DoubleClick += 
            delegate(object sender, EventArgs args)
            {
                this.Show();
                this.WindowState = WindowState.Normal;
            };
    }

    protected override void OnStateChanged(EventArgs e)
    {
        if (WindowState == WindowState.Minimized)
            this.Hide();

        base.OnStateChanged(e);
    }
}


트레이 아이콘에서 제거 하고 싶으면 NotifyIcon 클래스의 Visible 프로퍼티를 조작한다.
ni.Visible = false;





2007/10/16 22:34 2007/10/16 22:34
Trackback Address:이 글에는 트랙백을 보낼 수 없습니다

WPF (Winsows Presentation Foundation) LifeTime :: WPF 어플리케이션 생명주기

WPF (Winsows Presentation Foundation) LifeCycle

출처 : MSDN Library


MSDN에 있는 WPF의 라이프 사이클에 대한 그림이다.
가운데 Application Object 상자 안이 코어 부분인데, 하나의 Application은
Run 매서드로 시작해서 Shutdown 매서드의 호출로 끝나게 된다.
Shoutdown 매서드의 호출은 ShutdownMode의 값에 따라서 Application이 자동으로 호출해주는 경우와  
사용자가 반드시 호출해주는 경우로 구분된다. 그리고 Activated, Deactivated,
DispatcherUnhandledException, SessionEnding, Exit는 Application에 발생하는 이벤트이다.
SessionEnding의 경우는 사용자가 OS를 Shutdown하거나 Logoff 시에 호출되는데 이 이벤트 안에서
OS의 종료를 취소시킬 수 있다. 또한 DispatcherUnhandledException 이벤트는 Application에서
처리되지 않는 예외가 발생했을 경우에 발생하는 범용 예외 처리가 가능한 곳으로 지정하지
않았을 경우 예외가 발생하면 Application은 자동으로 종료된다. 
2007/10/01 12:01 2007/10/01 12:01
Trackback Address:이 글에는 트랙백을 보낼 수 없습니다

C# 레지스트리에 값을 쓰고, 읽고, 삭제하기

2007/09/28 19:31

서비 .NET & WPF ,

using System;
using System.Collections.Generic;
using System.Text;
using Microsoft.Win32;  // 레지스트리관련 클래스를 쓰기위해서 추가

namespace regiEx1
{
    class Program
    {
        static void Main(string[] args)
        {
            string regSubkey = "Software\\myTestKey";
            // 서브키를 얻어온다. 없으면 null
            RegistryKey rk = Registry.LocalMachine.OpenSubKey(regSubkey, true);
            // 없으면 서브키를 만든다.
            if (rk == null)                                                         
            {
                // 해당이름으로 서브키 생성
                rk = Registry.LocalMachine.CreateSubKey(regSubkey);                 
            }
            string[] strData = new string[] {"aaa","bbb","ccc"};
            // 서브키 아래 값 쓰기
            rk.SetValue("test", strData);
            // 서브키 아래 값 읽기
            string[] regStr = rk.GetValue("test") as string[];                     
           
            Console.WriteLine(regStr[1]);
            Console.ReadLine();

            // 서브키 삭제
            Registry.LocalMachine.DeleteSubKey(regSubkey);                         
        }
    }
}
2007/09/28 19:31 2007/09/28 19:31
Trackback Address:이 글에는 트랙백을 보낼 수 없습니다