Yi

Developers who are accustomed to the IDisposable pattern or to C#’s ‘using’ syntax sometimes ask why COM Interop doesn’t support IDisposable on every Runtime Callable Wrapper (RCW).  That way, managed code could indicate that it is finished using the unmanaged COM resource.  This would allow the resources to be cleaned up much earlier than they would be if we waited for a GC.  Also, it might better approximate the way an unmanaged client would have used this COM object through explicit Release calls.

There’s a service called System.Runtime.InteropServices.Marshal.ReleaseComObject() that looks suspiciously like it could be used as a Dispose() call.  However, this is misleading.  ReleaseComObject is quite different from Dispose() and it’s also quite different from IUnknown::Release() as I’ll explain.

The COM Interop layer in the CLR can make do with a single reference count against the unmanaged pUnk, regardless of how many managed clients refer to that object.  In other words, the Interop layer does not hold a reference count for each managed client of that pUnk.  Instead, we rely on the reachability magic of the GC to determine when nobody needs that pUnk anymore.  When nobody needs the pUnk, then we drop our single reference count on that pUnk.

Furthermore, negotiation for interfaces in managed code via COM Interop does not necessarily affect the unmanaged refcount of the COM object.  For instance, the managed wrapper might have already cached a pUnk for this interface.

Regardless of the actual refcount that the wrapper holds on the underlying COM object, ReleaseComObject will release all these refcounts at one time.

However, the return value from ReleaseComObject reveals that there’s an additional refcounting scheme involved.  This is unrelated to the COM refcount.  The same pUnk might be marshaled into the managed process a number of times.  We keep track of this count.  You can then call ReleaseComObject that same number of times before we will call IUnknown::Release on the pUnks held by the wrapper and start giving throwing InvalidComObjectExceptions.  If you are passing the pUnk backwards and forwards across the layer, this means that the “marshaling count” will be a large and arbitrary number.  But, for some usage patterns, the number of times the pUnk is marshaled across may correspond to the number of distinct managed clients that have got their hands on the wrapper.  If this happens to be the case, then that many managed clients can independently call ReleaseComObject before the wrapper is zombied and the underlying pUnks are Release’d.

I guess that this behavior is slightly more useful than a simple Release in some circumstances.  And you can turn it into the equivalent of IUnknown::Release by calling it in a loop until it returns 0.  At that point, our internal “marshaling count” has been decremented to 0 and we have Release’d the pUnks.  (We really need to add a ReleaseComObjectFully() service to avoid that silly loop).

Application code can either be on the GC plan, where we track whether there are references outstanding – but in a non-deterministic manner that is guided by memory pressure – or application code can do the tracking itself.  But if the application does the tracking, it is responsible for knowing whether there are other managed clients still using the COM object.

One way you might do this is by subtyping the wrapper and adding a Dispose protocol on the managed side that is reference counted.  But all managed clients in the process must observe the discipline you define.  A more practical approach is to ensure that you are the only client of the pUnk by creating the COM object yourself and then never sharing that reference with anyone else.

If you are using a COM object in a scoped, single-threaded manner then you can safely call ReleaseComObject on that object when you are done with it.  This will eagerly release any unmanaged resources associated with that object.  Subsequent calls would get an InvalidComObjectException.  So don’t make subsequent calls.

But if you are using a COM object from multiple places or multiple threads in your application (or from other applications in the same process), you should not call ReleaseComObject.  That’s because you will inflict InvalidComObjectExceptions on those other parts of the application.

So my advice is:

1)      If you are a server application, calling ReleaseComObject may be an important and necessary requirement for getting good throughput.  This is especially true if the COM objects live in a Single Threaded Apartment (STA).  For example, ASP compatibility mode uses the DCOM STA threadpool.  In these scenarios, you would create a COM object, use it, then eagerly call ReleaseComObject on each request.

2)      If you are a client application using a modest number of COM objects that are passed around freely in your managed code, you should not use ReleaseComObject.  You would likely inflict Disconnected errors on parts of the application by doing so.  The performance benefit of eagerly cleaning up the resources isn’t worth the problems you are causing.

3)      If you have a case where you are creating COM objects at a high rate, passing them around freely, choking the Finalizer thread, and consuming a lot of unmanaged resources… you are out of luck.

프로퍼티(property)는 자바나 C++에는 없는 기능으로, 클래스외부에서 보면 멤버변수처럼 보이고,클래스내부에서 보면 메소드처럼 보이는 것이다.

■프로퍼티사용법

엑세스레벨 형 프로퍼티이름
{
  set
  {
    //  set엑세서
    //  여기에 값이 변경될때 처리를 쓴다.
    //  value 라고 하는 이름의 변수에 대입된 값이 들어간다.
  }
  get
  {
    //  get엑세서
    //  여기에 값을 얻을때 처리를 쓴다.
    //  메소드의 경우와 같이 값은 return 키워드를 사용해서 돌려준다.
  }
}

예를 들어 실제로 클래스를 이용하는 쪽의 코드는 복잡해진다.

■프로퍼티를 사용하지 않은 클래스

using System;
//실체를 숨겨서 만든 복소수 클래스

class Complex
{

  //실체는 외부에서 숨김(private로 해놓는다.)
  private double re; // 실수부를 기억해 놓는다.
  private double im; // 허수부를 기억해 놓는다.
  public double Re(){return this.re;}    // 실수부를 꺼낸다.

  public void Re(double x){this.re = x;} // 실수부를 바꿔쓴다.
  public double Im(){return this.im;}    // 허수부를 꺼낸다.
  public void Im(double y){this.im = y;} // 허수부를 바꿔쓴다.

  public double Abs(){return Math.Sqrt(re*re + im*im);}  // 절대값을 꺼낸다.
}

// 클래스를 사용하는 쪽
class ConcealSample
{
  public static void Main()
  {
    // x = 5 + 1i
    Complex x = new Complex();
    x.Re(5);  // x.re = 5
    x.Im(1);  // x.im = 1

    // y = -2 + 3i
    Complex y = new Complex();
    y.Re(-2); // y.re = -2
    y.Im( 3); // y.im =  3

    Complex z = new Complex();
    z.Re(x.Re() + y.Re()); // z.re = x.re + y.re
    z.Im(x.Im() + y.Im()); // z.im = x.im + y.im

    Console.Write("|{0} + {1}i| = {2}\n", z.Re(), z.Im(), z.Abs());
    // |3 + 4i| = 5 로 표시됨

  }
}

위의 복소수 클래스를 프로퍼디를 이용해서 바꿔쓰면 아래와 같다.

■프로퍼티를 사용하는 클래스

using System;
// 클래스정의
class Complex
{
  // 실체를 외부로 부터 숨김(private로 해놓는다.)
  private double re; // 실수부를 기억해 놓는다.
  private double im; // 허수부를 기억해 놓는다.

  // 실수부 취득,변환용 프로퍼티
  public double Re
  {
    set{this.re = value;}
    get{return this.re;}
  }
  /* 위의 코드의 의미는 아래와 같다.
  public void SetRe(double value){this.re = value;}
  public double GetRe(){return this.re;}
  메소드와 같은 감각으로 사용한다.
  */

  // 실수부를 취득,변환용의 프로퍼티
  public double Im
  {
    set{this.im = value;}
    get{return this.im;}
  }

  // 절대값의 취득용 프로퍼티
  public double Abs
  {
    // 읽기 전용 프로퍼티
    // set 블록을 쓰지 않는다.
    get{return Math.Sqrt(re*re + im*im);}
  }
}

// 클래스를 이용하는 쪽
class PropertySample
{
  public static void Main()
  {
    Complex c = new Complex();
    c.Re = 4; // Re프로퍼티의 set 엑세스를 불러낸다.
    c.Im = 3; // Im프로퍼디의 set 엑세스를 불러낸다.
    Console.Write("|{0} + ", c.Re); // Re프로퍼티의 get엑세스를 불러낸다.
    Console.Write("{0}i| =", c.Im); // Im프로퍼티의 get엑서스를 불러낸다.
    Console.Write(" {0}\n", c.Abs); // Abs프로퍼디의 get엑세스를 불러낸다.
  }
}

■get/set에 다른 엑세스레벨을 설정

Ver.2.0
C#2.0에서 부터 프로퍼티 엑세스의 get/set 에 다른 엑세스레벨을 설정하는 것이 가능하게 되었다.
예를 들어,

class A
{
  private int n;

  public int N
  {
    get{ return this.n; }
    protected set{ this.n = value; }
  }
}

■자동프로퍼티

Ver.3.0
C#3.0 에서는 프로퍼티 get/set의 내용을 생략해도 될수있게 되었다.
이 기능을 자동프로퍼티(auto-property,auto-implemented property)라고 한다.
예를 들면,
public string Name { get; set; }
이라고 쓰면,
private string __name;
public string Name
{
  get { return this.__name; }
  set { this.__name = value; }
}
위와 같은 코드가 자동적으로 생성되어진다.(__name의 변수는 프로그래머는 참조할수 있는것은 아니다.)

1. 클라이언트 콜백을 사용하는 페이지의 제작 과정

- ICallbackeventHandler 인터페이스 구현

- 서버로 콜백을 일으키는 클라이언트 스크립트 등록

- 서버의 응답을 처리하는 스크립트

-------------------------------------

2. 콜백 함수를 호출했을때 실행되는 메서드

-RaiseCallbackEvent 메서드

--> 클라이언트에서 전달한 값을 eventArgument 인자로 받아서 처리

- GetCallbackResult

--> 클라이언트로 전달할 데이터를 반환하는 메서드

2.1.

RaiseCallbackEvent 메서드가 먼저 호출됨.

클라이언트에서 전달한 값이 eventArgument 인자로 넘어온다.

이 메서드에서는 필요한 처리를 한 후에 처리결과를 클래스 내부 변수에 저장해야한다.

즉, RaiseCallbackevent는 클라이언트로 전달할 값을 반환하지 못하기 때문이다.

그 다음 GetCallbackResult는 RaiseCallbackEvent에서 저장된 내부 변수 값을 반환한다.

이 메서드에서 반환한 값은 클라이언트로 전달된다.

ICallbackEventHandler 인터페이스는 클라이언트에서 인자를 받아 처리하는 메서드(RaiseCallbackEvent)와 클라이언트로 결과를 반환하는 메서드(GetCallback Result)로 나뉜다는 점을 잘 파악해 두기 바란다. (-0-;)

--------------------------------------

3. 서버로 콜백을 일으키는 클라이언트 스크립트 등록

- 클라이언트 콜백은 XMLHttpRequest 컨트롤을 이용해서 수행

- 클라이언트 콜백용 API를 이용해서 생성

- GetCallbackEventReference

public string GetCallbackEventReference(Control control, string argument, string clientCallback, string context)

- argument의 값을 서버로 전달할 값을 나타내는 클라이언트측 표현

- argumetn의 값은 서버의 RaiseCallbackEvent 메서드 인자로 전달

- clientCallback은 GetCallbackResult 메서드의 반환 값을 받아 처리할 클라이언트 함수의 이름

--------------------------------------

4. 서버의 응답을 처리하는 스크립트

- 서버의 응답을 처리할 스크립트 함수의 이름은 GetCallbackEventReference 메서드의 clientCallback 인자로 지정된다

- 첫번째 인자는 서버의 처리결과 값, 두번째 인자는 context값

--------------------------------------

5. isCallback

페이지가 콜백에 의해 실행중일때 isPostBack 속성도 true값을 반환

- isCallback이 true일 때에는 페이지가 렌더링 처리를 하지 않는다

--------------------------------------

6. 그외

- 클라이언트에서 콜백 요청을 하는 함수는 WebForm_DoCallback

-

--------------------------------------

public partial class _Default : System.Web.UI.Page, System.Web.UI.ICallbackEventHandler
{
    protected string cbReference;
    protected string callbackReturn;
    protected string callbackParam;   

    protected void Page_Load(object sender, EventArgs e)
    {

        if (!IsPostBack)
        {
            txtCount.Text = "0";
        }

        if (!IsCallback)
        {
            //cbReference = Page.ClientScript.GetCallbackEventReference(this, "document.getElementById('" + this.txtClientCallBack.ClientID + "').value", "ReciveFunc", "'콜백성공'");

            cbReference = Page.ClientScript.GetCallbackEventReference(this, "init", "ReciveFunc", "'콜백성공'");
        }
    }

    void ICallbackEventHandler.RaiseCallbackEvent(string eventArgument)
    {

        //eventArgument를 이용한 처리

        callbackParam = "(" + eventArgument + ") 를 입력";

         //ConnectDataBase(int.Parse(eventArgument));
    }

    string ICallbackEventHandler.GetCallbackResult()
    {

       // 처리 결과를 반환
        return callbackParam;
    }

  <script type="text/javascript" language="javascript">
   
    var init = 0;
   
    function ReciveFunc(val, context)
    {
        //<!-- 서버에서 보내준 데이터를 전달 받는 녀석? -->      
       
        div3.innerHTML = val;             
       
        init += 10;       
    }
   
    </script>
</head>

<body>
    <form id="form1" runat="server">   
        <div id="div1">
            <asp:Button ID="btnPostBack" runat="server" Text="포스트백" OnClick="btnPostBack_Click" /> <br />
            <asp:TextBox ID="txtClientCallBack" runat="server" ></asp:TextBox> <br />
            <button onclick = "<%= cbReference %>"> 클라이언트 콜백</button> <br />
            반환값 : <span id="returnValue"></span>          
        </div>

화폐단위나 하드디스크용량등을의 숫자값은 상당히 길때가 있습니다. 이럴 때 보는 사람이 구분하기 쉽게 하기 위해 3자리씩 구분자를 넣어 표시해주는 경우가 있습니다.

예를 들어 1234567890란 값이 있다면 1,234,567,890로 보여주고 하는 경우를 말합니다.

.NET에서는 이런 숫자값을 3자리씩 구분자를 넣어 문자열로 변환하고자 한다면, 정적인 메소드인 Format을 이용하면 간단하게 해결됩니다.

String.Format("{0:#,0} 원", 1234567890);

이 메소드의 2번째 파라미터로 지정된 1234567890는 변환전의 숫자값이고 첫번째 파라미터는 지정한 문자열을 {0:#,0}는 서식을 지정한 항목을 말합니다.

0:#,0의 의미를 설명해보면,

인덱스 0번째는 Argument로 지정된 숫자를 그 정수부분에 각 그룹별 간 단락문자(,)를 넣고 변환한다는 의미입니다.

출력된 문자열로 단락을 구분하는 문자가 넣어지게 되는 것은 서식지정항목으로 단락기호(,)가 지정되어 있기 때문입니다.  ,이전에 #은 자릿수홀더라고 말하며 ,이후에 0은 제로홀더라고 말하는데 이 두가지 조건이 구비되어 있어야지 정확한게 실행됩니다. 그렇기 때문에 #,0이라고 적는 것입니다.

[WonCheck.cs]

using System;
using System.Collections.Generic;

namespace WonCheck
{
    class Program
    {
        static void Main(string[] args)
        {
            int num = 987654321;
            string s = String.Format("{0:#,0} 원", num);
            Console.WriteLine(s);
        }
    }
}

*응용 프로그램에서 구성 요소를 사용하려면 해당 구성 요소에 대한 참조를 추가해야함.

*참조추가 대화상자의 다섯가지 옵션
-.NET : 참조에 사용할 수 있는 .NET Framework 구성 요소를 모두 나열
-COM : 참조에 사용할 수 있는 COM 구성 요소를 모두 나열
-프로젝트 : 로컬 프로젝트에서 생성된 다시 사용가능한 구성 요소를 모두 나열
-찾아보기 : 파일 시스템에서 구성 요소를 찾아볼 수 있음
-최근에 사용한 파일 - 최근에 컴퓨터의 프로젝트에 추가한 구성 요소 목록이 있음

*기본적으로 참조 추가 대화 상자에는 공용 어셈블리 폴더(Program Files\Microsoft Visual Studio .NET\Common7\IDE\Public Assemblies) 또는 GAC(전역 어셈블리 캐시)에 있는 어셈블리의 목록만 표시됨.
-참조 경로를 추가하면 사용자 고유의 어셈블리를 목록에 추가할 수 있음

**동일 솔루션에 있는 다른 프로젝트의 출력에 대한 파일 참조를 추가하면 컴파일 오류가 발생할 수 있으므로 비추천
**참조 추가 대화 상자의 프로젝트 탭을 사용하여 프로젝트 간 참조를 만들면 프로젝트에서 만드는 클래스 라이브러리를 보다 효율적으로 관리할 수 있으므로 개발 팀이 작업하기가 간편해짐
**GAC에 등록되어 있는 사용자 지정 구성 요소에 대한 참조가 포함된 응용 프로그램을 배포/복사하는 경우 구성 요소는 CopyLocal 설정과 상관없이 응용 프로그램과 함게 배포/복사되지 않음

*참조를 추가하려면
1.솔루션 탐색기에서 프로젝트의 My Project 노드를 두 번 클릭합니다.
2.프로젝트 디자이너에서 참조 탭을 클릭합니다.
3.참조 추가 단추를 클릭하여 참조 추가 대화 상자를 엽니다.
4.참조 추가 대화 상자에서 참조할 구성 요소의 종류를 나타내는 탭을 선택합니다.
5.참조할 구성 요소를 위쪽 창에서 선택한 다음 확인을 클릭합니다.

*참조를 제거하려면
1.솔루션 탐색기에서 프로젝트의 My Project 노드를 두 번 클릭합니다.
2.프로젝트 디자이너에서 참조 탭을 클릭합니다.
3.참조 목록에서 제거할 참조를 선택합니다.
4.제거 단추를 클릭합니다.

*참조 경로를 설정하려면
1.솔루션 탐색기에서 프로젝트의 My Project 노드를 두 번 클릭합니다.
2.프로젝트 디자이너에서 참조 탭을 클릭합니다.
3.참조 경로 단추를 클릭합니다.
4.폴더: 필드에서 구성 요소가 포함된 폴더의 전체 경로를 입력합니다.
5.폴더 추가 단추를 클릭한 다음 확인을 클릭합니다.

*외부 구성 요소에 대해 코드를 작성하려면 먼저 해당 구성요소에 대한 참조를 프로젝트에 포함 시켜야함.

*구성 요소에 대한 참조 종류
-.NET Framework 클래스 라이브러리 또는 어셈블리
-COM 구성 요소
-동일한 솔루션에 있는 다른프로젝트의 클래스 라이브러리
-XML WebServices

*공유 구성 요소에 대한 참조
-런타임에 구성 요소는 프로젝트이 출력 경로나 GAC(전역 어셈블리 캐시)중 한 곳에 있어야 함.
-프로젝트에 포함된 개체 참조가 이 위치에 업승면 프로젝트를 빌드할 때 참조를 프로젝트의 출력 경로로 복사해야 함.
-CopyLocal 속성 : 복사 작업이 수행되어야 하는지 여부를 나타냄(true : 참조가 복사, false : 참조 복사 안함)
--어셈블리 구성 요소가 전역 어셈블리 캐시에 있거나 프레임워크 구성 요소인 경우 기본적으로 CopyLocal 속성은 false로 설정. 프로젝트 간 참조는 항상 true로 설정됨.
-GAC에 등록되어 있는 사용자 지정 구성요소에 대한 참조가 포함된 응용프로그램을 배포하는 경우 구성 요소는 CopyLocal설정과 상관없이 응용 프로그램과 함게 배포되지 않음.
-어셈블리를 수동으로 /Bin 폴더에 추가해야 함.(모든 사용자 지정 코드는 정밀하게 조사되고, 익숙하지 않은 사용자 지정 코드를 게시하게 될 위험이 줄어듬.)

*프로젝트 간 참조
-여러 프로젝트를 포함하는 솔루션에서는 한 프로젝트에서 작성된 개체에 대한 참조를 동일한 솔루션의 다른 프로젝트에서 만들 수 있음
-응용 프로그램을 만들고 실행할 때 특별히 고려해야 하는 상호 족속성이 형성됨.

Command.ItemCommand Event
네임스페이스 : System.Web.UI.MobileControls
어셈블리 : System.Web.Mobile(system.web.mobile.dll)
사용자가 ObjectList항목에 연결된 명령을 선택하면 이 이벤트가 발생

ItemCommand 이벤트 처리기가 정의 되어 있는 경우 Command컨트롤은 사용자와의 상호 작용을 통해 항목 이벤트가 생성되면 처리기에 알림.
Click이벤트와 달리 ItemCommand 이벤트는 부모 컨트롤에 버블링 됨.
ItemCommand 이벤트 렌더링은 장치마다 다르다
OnItemCommand 이벤트는 OnClick 이벤트 다음에 발생.
사용자가 명령 단추를 클릭할 때마다 동일한 동작을 반복하는 시나리오에서 Command컨트롤의 CommandName 또는 CommandArgument 속성을 사용하여 어떤 명령 단추가 클릭되었는지 확인할 수 있음.

Hungarian
-소문자 변수 특성에 맞게 소문자 접두어를 사용하고 나머지 Naming은 Pascal형식을 사용하는 Casing
ex) strKoreanName / nCount / txtPostCode

Camel
-첫 시작 단어의 시작 문자는 소문자로 시작하고 새로운 단어의 시작 문자는 대문자로 표기
ex) backColor / postCode

Pascal
-새로운 단어의 시작 문자는 무조건 대문자로 표기 한다.
ex) BackClolr / UserInformation

Upper
-모든 문자를 대문자로 표기 하고 단어 사이의 구문을 _ 혹은 -로 구분한다.
ex)WM_ONKEYDOWN / MAX_VALUE

Lower
-모든 문자를 소문자로 표기하고 단어 사이의 구분을 _혹은 -로 구분한다.
ex)max_value / min_value

Repeater
-웹 서버 컨트롤은 페이지에 사용할 수 있는 데이터로 사용자 지정 목록을 만들 수 있는 컨테이너.
-Rendering 기능 기본 제공되지 않으므로 템플릿을 만들어 Repeater 컨트롤에 대한 레이아웃을 제공해야 함.
-페이지 실행시 Repeater 컨트롤은 데이터 소스의 레코드를 순환하면서 각 레코드에 대한 항목을 렌더링
-다양한 유형의 목록 생성 가능 : 표 레이아웃, 쉼표로 구분된 목록, XML 형식 목록

Repeater 컨트롤에 템플릿 사용
-Repeater컨트롤을 사용하려면 컨트롤 내용의 레이아웃을 정의하는 템플릿을 생성
-태그와 원하는 컨트롤을 원하는 대로 조합하여 템플릿에 포함할 수 있음.
-템플릿이 정의되어 있지 않거나 템플릿에 요소가 포함되어 있지 않으면 응용 프로그램을 실행할 때 컨트롤이 페이지에 나타나지 않음.

Repeater 컨트롤에서 지원하는 템플릿
-ItemTemplate : 데이터 소스의 각 데이터 항목에 대해 한번 렌더링할 HTML 요소 및 컨트롤을 포함함.
-AlternatingItemTemplate : 데이터 소스의 데이터 항목을 하나씩 걸러서 모든 항목을 렌더링할 HTML 요소 및 컨트롤을 포함(일반적으로 ItemTemplate에 지정된 색과 다른 배경색을 지정하는 경우처럼 대체 항목에 대해 다른 모양을 만드는 데 사용)
-HeaderTemplate 및 FooterTemplate : 목록의 처음과 끝에서 각각 렌더링하는 텍스트와 컨트롤 포함.
-SeperatorTemplate : 각 항목 사이에서 렌더링하는 요소를 포함함.

Repeater 컨트롤에 데이터 바인딩
-데이터 소스에 바인딩 되어야 함.
-일반적 데이터 소스 : SqlDataSource, ObjectDataSource 컨트롤과 같은 데이터 소스 컨트롤 들 또는 IEnumerable 인터페이스를 구현하는 클래스에 Repeater 컨트롤을 바인딩 할 수 있음.
-방법 : Repeater 컨트롤 전체에 대한 데이터 소스를 지정
-추가 : 템플릿에 Label 또는 TextBox 컨트롤을 추가할 경우에는 데이터 바인딩 구문을 사용하여 각 컨트롤을 데이터 소스에서 반환된 항목의 필드에 바인딩 함.

ID : 서버측 컨트롤을 인식하기 위한 고유 아이디
ClientID : 렌더링된 페이지의(HTML페이지) 컨트롤을 인식하기 위한 고유 아이디

-단일페이지에서 ID만 사용한다고 해서 일어나는 문제는 없음
-흔히 사용하는 유저 컨트롤과 마스터 페이지 등에서 사용할대 문제 발생
예)test1.aspx 페이지의 TextBox1과 test2.aspx 페이지의 TextBox1이라는 컨트롤이 있을때
TextBox1의 Text값을 가져오라고 할때 test1, test2페이지 중에서 값을 가져올 때 ClientID가 필요

사용 예) <%=아이디명.ClientID%>

PostbackUrl
네임스페이스 : System.Web.UI.Webcontrols
어셈블리 : System.Web(system.web.dll)
-Button 컨트롤을 클릭했을 때 현재 페이지에서 게시할 웹 페이지의 URL을 가져오거나 설정함
-속성값 : Button 컨트롤을 클릭했을 때 현재 페이지에서 게시할 웹 페이지의 URL. 기본값 : 빈 문자열("")이며, 이 경우 자신에게 다시 게시됨
-페이지간 게시를 수행할 수 있음, Button 컨트롤을 클릭할 경우 게시될 위치의 웹 페이지를 PostBackUrl 속성을 사용하여 지정
예)postbackurl="~/page2.aspx"를 지정, Button컨트롤이 포함된 페이지가 Page2.aspx에 게시, 속성 값 미지정시 자신에게 다시 게시됨

Redirect 메서드
네임스페이스:System.Net
어셈블리:System(system.dll)
-클라이언트를 지정된 URL로 리디렉션하도록 응답을 구성
-매개 변수 : url (클라이언트가 요청한 리소스를 찾는데 사용할 URL)
-Redirect 메서드는 클라이언트를 새로운 리소스 위치로 리디렉션 하는데 사용.
-응답의 Location 헤더를 url로 설정, StatusCode 속성을 Redirect로 설정, StatusDescription 속성을 "Found"로 설정

델리케이트,이벤트,어트리뷰트

2009.01.20   c# 세미나   작성자 : 손창효         
서문

윈도우 운영체제는 이벤트 드리븐 방식을 지원
닷넷 환경도 이벤트 드리븐 방식의 윈도우 프로그램을 작성할수 있다.
닷넷 윈도우 프로그램을 작성하려면 델리게이트와 이벤트 개념을 반드시 알고 있어야 할것이다.
델리게이트와 이벤트 개념 및 활용 방법에 대해 알아 보겠다.
또한 프로그램에 필요한 정보를 제공하는 어트리뷰트에 대해서도 살펴보자.
델리게이트

정의 : ‘위임’ 또는 ‘대리자’
c/c++에서 사용하는 함수 포인터와 동일한 개념.
c#에서 델리게이트는 메서드의 포인터(메서드 이름)를 저장할 뿐 내부에 코드를 기술하지는 않는다.
닷넷 프레임워크에서는 이벤트와 함께 사용. 이번트 처리에 많이 이용
인터페이스와 유사
delegate 키워드사용

public delegate [메서드 이름];

델리게이트
델리게이트는 호출 할 메서드와 시그너쳐가 정확하게 일치해야 한다.
두 정수를 입력 받아 그 값을 더해 반환하는 Add()메서드가 있다면

이 메서드의 호출을 대리할 델리게이트는 다음과 같은 형태가 되어야한다.

public int Add(int a, int b)

{

return a + b;

}

delegate int AddDelegate(int a, int b);

델리게이트

주의할점 : 델리케이트는 대리할 메서드와 이름은 같지 않아도 되지만 반환형과 매개변수 타입 및 개수 등은 반드시 일치 해야 한다.
델리게이트 ; 델리게이트 사용하기

시그너처가 동일한 다른 메서드를 호출하고 싶다면 new연산자를 이용해 해당 메서드를 지정

델리게이트 ; static 메서드를 호출하는 델리게이트

델리게이트 ; 델리게이트 등록/제거

델리게이트의 등록/ 제거

델리게이트를  등록하려면 +=연산자
델레게이트를 제거하려면 -=연산자
이벤트 처리

정의 : 특정 사건이 발생됐음을 알리는 메시지 .
마우스 클릭, 키보드 누름 등 특정 사건이 발생하면 운영체제나 해당 프로그램은 사건의 종류에 따라 특정 메시지를 발생.
이벤트는 객체와 같이 사용되며, c#에서는 event 키워드를 통해 이벤트처리

public delegate void MyDelegate();

private event MyDelegate ExamEvent;

이벤트 처리

event는 델리게이트 객체 선언에 덧붙여 선언. +=, -=연산자를 이용해

이벤트 핸들러를 등록 및 제거

event 핸들러는 다음 형태로 정의

object sender : 보통 호출한 객체를 가리키는 this가 사용됨.
EventArgs args : 이벤트 핸들러 파라미터
 
ExampleClass obj = new ExampleClass();

ExamEvent += new MyDelegate(obj.Method);

public delegate void EventHandler(object sender, EventArgs args)

이벤트 처리과정

델리게이트 객체 선언

이벤트 핸들러 구현(처리할 함수 구현)

이벤트에 델리게이트 객체(이벤트 핸들러)등록

이벤트 선언
 
public delegate void Defeat();

private event Defeat EnemyDetected

Defeat라는 델리게이트와 EnemyDetected라는 이벤트 정의.

EnemyDetected라는 이벤트가 발생하면 Defeat 델리게이트를 호출

이벤트 발생을 위한 지침

‘On + 이벤트 명’
OnEvent 메소드는
1.이벤트를 조사하고 어떤 등록 객체가 있는지 검사하고 아무도 없다면 종료
2.등록된 델리게이트에게 전달할 필요가 있는 인자들을 정리하고 적절한 EventArgs 객체에 집어 넣는다.
3.이벤트를 발생하고 자신의 인스턴스를 첫 번째 인자로 그리고 EventArgs 를 두 번째 인자로 전달한다.
이벤트 처리 ; 이벤트 사용하기

어트리뷰트

정의 : 프로그램에 필요한 정보를 제공하는 기능으로, 컴파일타임과 런타임 모두 영향을 미침 어트리뷰트 구문은 대괄호 ([])로 묶어 표현
컴파일러와 구조체 , 클래스 등에 영향을 미치는 범용적인 기능을 제공

대괄호 안에는 지정위치,이름 파라미터 및 명명 파라미터가 들어감

[어트리뷰트명(“positional_parameter”, “named_parameter=value,…)]

[DllImport(Use32.dll”)]

[Obsolete(“메시지를 출력합니다.”)]

[Conditional(“Youngjin.com”)]

어트리뷰트

어트리뷰트는 닷넷이 제공하는 내장 방식과 사용자가 작성한 사용자 정의 방식으로 나뉜다.
닷넷이 제공하는 내장 어트리뷰트는 약 200개 정도 , 모두 Attribute 클래스를 상속받은 sealed 형태의 클래스.

책에서는 DllImport와 Obsolete 어트리뷰트 살펴봄
DllImport 어트리뷰트 ; 사용하기

“User32.dll파일”에 정의된 messagebox

c#에서 내부 메서드 호출하듯이 Win32 API를 사용할수 있다.
DllImport 어트리뷰트 ; 사용하기

Win32 API인 MessageBox 함수 사용법은 다음과 같다.

int MessageBox(HWND hWnd, LPCTSTR lpText, LPCTSTR lpCaption, UINT uType);

Obsolete 어트리뷰트 ; 사용하기

정의 : “폐물이 된, 쓸모없는” . 특정 메서드나 속성을 쓰지 말도록 유도
프로그램의 업그레이드 버전을 작성할 때 기존에 있던 특정 기능을 사용하지못하게 경고하는 용도로 사용된다
summary

델리게이트는 c/c++의 함수 포인터 개념이며
이벤트는 특정 사건을 처리하는 방법
델레게이트 호출 방법과 이벤트 처리하는 방법을 정확히 이해하고 있어야 하겠다.

Tony Patton 이 기고한 글을 ZDNET 에서 번역한 자료이다. 우리는 이 기사에 대한 내용을 우리의 시각에서 정리해 보았다. 이 글은 자유로이 읽고, 배포할 수 있다. 그러나 출처에 대한 공개를 해주는 좋은 습관이 필요하다.

아는 것은 싸움의 절반에 해당한다. 내가 하는 실수를 제대로 알고 있다면, 고치는 것은 시간 문제다. 초보와 베테랑 개발자 모두 전체 프로젝트의 진척에 방해가 될 수 있는 업무의 측면에 대해서 잘 못 알고 있는 경우들이 많다. 범하기 쉬운 실수들을 왜 미리 살펴 보아야 하는지 알아본다.

초보, 중급 개발자들과 함께 일해 왔는데, 베테랑 개발자를 포함해 모든 개발자들이 주의하지 않는다면 쉽게 빠질 수 있는 오해의 함정들을 몇 가지 발견하게 되었다. 여기에는 적절한 도구의 선택부터 웹 서비스의 적절한 사용법에 이르기까지 다양한 아이디어가 포함된다.

개발자들이 갖기 쉬운 6가지 오해에 대해서 설명한다.

1. .NET Application 개발을 위해서는 Visual Studio .NET 이 필수다. ?

이런 생각을 했다면, 버려라. MS .NET 개발을 처음 접해 본 사람들은 .NET Framework를 이용한 Application 개발을 위해서 Visual Studio .NET 이 꼭 필요하다는 오해를 하기 쉽다. 이는 사실이 아니다. 단지 MS Web Site에서 .NET Framework을 무료로 다운로드 받기만 하면 된다.

.NET Framework를 설치한 후 좋아하는 텍스트 편집기와 커맨드-라인 .NET Tool을 사용하면 된다. 또한 이미 나와 있는 SharpDevelop 과 같은 3^rd Party 개발 도구를 사용해도 된다. (현재 시점에 많은 제품들이 상용/오픈으로 나와 있다)

Visual Studio .NET의 대안에 관한 보다 자세한 논의를 담은 이전 기사를 참고하면 좋다. 개발도구의 선택은 개인적인 취향에 달려있지만 많은 개발 팀은 협업을 단순화하기 위해서 도구를 표준화 한다.

<의견>

좋은 의견이다. 충분히 검토할 가치가 있으며 이러한 논지는 개발이 벤더에 종속되지 않는 의미를 가지기도 한다. 그러나 점점 Visual Studio .NET을 벗어나서는 지원되지 않는 장점이 많아지는 것이 문제일 것이다. 이러한 것도 역시 개발에 꼭 필요한 부분이 아닐 수 있기 때문에 판단은 역시 당사자들이 하여야 할 문제일 것이다. 이제 11월 22일에 Visual Studio .NET 2005가 발표된다. 역시 많은 기능과 개발과 디자인을 연결하는 기능이 시도되고 있다. 이런 것들을 어떻게 적응할 것인가가 더 중요한 부분이 아닐까 한다.

2. 내가 습득한 정보, 꼭꼭 숨기기

개발자들이 갖는 독특한 특징의 하나는 정보를 모으는 것이다. 타인이 모르는 것에 대해 알 수 있는 능력은 종종 중요성에 대한 잘못된 인식을 키우게 된다. 반대로 이런 정보를 공유하게 되면 그룹 전체의 지식이 확대되므로 팀에 도움이 된다. 또한 공유된 개념은 다른 팀 멤버의 의견에 따라 발전할 수도 있다. 이 것은 오픈소스 운동의 핵심 측면이기도 하다. 마지막으로 다른 개발자나 개발자들에게 어떤 개념이나 아이디어를 설명하게 되면 많은 경우 당신의 지식도 커진다.

팀워크는 애질 소프트웨어 개발(Agile Software Development)와 같은 운동에 있어서 추진력이 된다. 또한 많은 그룹이 동료가 작성한 코드를 리뷰하고 조언을 주고 있다. 이런 행위는 양측이 서로 배우고 이해를 넓히는 역할을 한다.

3. 코드에서 코멘트 빠뜨리기

코드에 코멘트를 하는 것은 쉬우면서도 단순한 절차이다. 그렇다면 왜 코멘트가 자주 간과되고 무시되는가? 일부 개발자들은 어떤 형태로든 문서화를 하지 않는다면 일자리를 유지하는데 도움이 된다고 생각한다. 이는 바로 전에 다룬 정보 공유에 관한 오류와 밀접한 관계가 있다.

몇 군데 잘 배치된 코멘트는 코드의 판독성과 관리성을 향상시킨다. 그런데 코멘트가 남용될 수도 있다. 기본적으로 코드의 목적, 변수, 메쏘드 등을 짧게 설명하는 코멘트가 있으면 된다. 많은 그룹들은 코드에 변화가 생기면 코멘트를 삽입하기를 원한다. 이는 문제가 생겼을 때 변화의 내용을 파악하기 쉽게 한다.

4. 버전 컨트롤 시스템의 가치를 간과하는 것

많은 개발자들이 다음과 같은 시나리오를 너무나 잘 알고 있다. 중요한 웹 애플리케이션의 새 버전을 내놓았다. 그런데 웹 사이트의 문제점을 항의하는 전화가 다음날 아침부터 줄지어 날아든다.

개발자가 한두 가지 실수를 범했다는 것을 수용할 용의가 있다면, 버전 컨트롤 시스템은 이런 상황에서 최고의 친구가 될 수 있다. CVS, IBM 래쇼날 클리어케이스, MS 비주얼 소스세이프와 같은 버전 컨트롤 시스템을 사용함으로써 기존 버전의 애플리케이션으로 쉽게 돌아가서 이를 기반으로 제품을 생산할 수 있다. 이는 제품 사이트가 가동되는 것과 병행해 개발 환경 내에서 문제를 찾는데 필요한 시간을 벌 수 있도록 해준다. 이는 문제를 찾기 위해 제품 코드를 미친 듯이 찾는 것을 방지한다.

또한 소스 컨트롤 시스템은 병행 개발을 가능하게 하므로 팀 멤버들이 동일한 코드를 작성할 수 있다. 개발자들이 시스템에 변경된 사항을 입력하면 이들 변경사항이 한꺼번에 통합된다.

일부 개발자들이 버전 컨트롤 시스템을 싫어하는 한 가지 이유는 개발 절차에 있어서 하나의 계층을 추가하기 때문이다. 소스 컨트롤 시스템에 코드를 제출하고 추출하는 것이 시간을 잡아먹을 수 있다. 이런 시간이 일부 개발자들의 인내심을 시험할 수 있다.

5. 웹 서비스가 모든 프로젝트에서 필요하다는 생각

웹 서비스에 대한 모든 감언이설 때문인지 많은 개발자들은 프로젝트를 시작하면서 어떤 형태로든 웹 서비스를 사용해야겠다고 생각한다. 웹 서비스가 필요하거나 적절한 방법일 수는 있지만 무조건 써야 되는 것은 아니다. 상황을 분석해 웹 서비스의 구현이 적절한지 검토할 필요가 있다. 예를 들어 원격화와 같은 기술이 보다 적절할 수도 있다.

6. 데이터 확인의 중요성을 자주 잊는 것

데이터는 애플리케이션에서 다양한 방식으로 처리되고 조작된다. 이런 이유 때문에 개발자들은 데이터의 무결성과 유효성을 개발과정에서 확인해야 된다. 데이터는 널 문자를 리턴할 수 있는 백엔드 데이터베이스로부터 읽혀질 수도 있다. 널 문자는 대부분의 경우 예외상황 (exception)을 발생시키므로 실행을 계속하기 전에 데이터는 검사돼야 한다.

당신이 초보 개발자이거나 베테랑 개발자이거나에 상관없이 개발자들이 여섯까지 오해에 빠지기 쉽다는 것을 잘 알아야 한다. 심지어 이런 나쁜 습관에 당신이 빠지지 않는다고 해도 다른 팀원들이 이들 함정에 빠질 수 있다. 잠재적 실수에 대해 경각심을 가진다면 팀 프로젝트를 방해할 수 있는 실수들을 방지하는데 도움이 될 것이다.

C# : 다중 상속의 폐해 등과 같이 복잡한 문제점은 제거. 실용성을 중시. .NET Framework의 클래스 라이브러리딜이 이미 C#으로 작성되어 있음

C# 2.0의 주요 특징
-Generic : 더 많은 코드 재활용성과 컬렉션 클랫의 성능 향상을 꾀하기 위해 추가. 매개 변수에 의해 구분되어지며, 매개 변수는 특정 형식을 갖도록 강제 될 수 있음. 데이터 자장과 처리에 있어서 상당한 속도 향상.
-Iterators : Foreach 루프에 의해 컬렉션의 내용을 어떻게 반복하여 접근하는가를 쉽게 지시
-Patial Type : 여러개의 다른 소스파일을 나누어서 클래스를 저장. 시스템이 생성한 코드와 개발자가 작성한 소스 코드를 분리하여 작성 할 수 있음.
-익명 메서드 : 코드 조각을 인자로 전달하는 것이 가능. Delegate가 필요한 곳이면 메서드를 정의할 필요 없이 코드를 사용 가능.

컬렉션 : 저장 공간의 제약을 반지 않고 데이터를 저장, 다양한 데이터 타입의 데이터를 저장할 수 있음.
-값 타입 : 박싱, 언박싱
-참조 타입 : 상위 캐스팅, 하위 캐스팅
*값 타입을 컬렉션 개체에 저장하기 위해서 참조 타입으로의 박싱이 발생하게 되고, 컬렉션 개체에 저장된 데이터를 리턴 받기 위해서는 언박싱이 발생, 개체를 컬렉션에 저장하기 위해서는 부모 클래스의 형태로 상위 캐스팅이 발생, 저장된 데이터를 리턴 받기 위해서는 하위 클래스로 하위 캐스팅을 해야함.

Generics : 동적으로 저장 공간의 사이즈를 늘려 데이터를 저장하는 기능과 동일한 데이터 타입을 저장하는 특징.
-명확한 타입 지정을 통한 컴파일 시의 에러 체크 및 런타임 시의 에러 방지
-불필요한 박싱, 언박싱 방지를 통한 성능 향상
-상위 캐스팅, 하위 캐스팅 방지를 통한 성능 향상
-System.Collections.Generics 네임스페이스 사용을 통한 편이성 제공
*'로직'과 '로직에 의해 다뤄지는 개체'를 명확하게 구분할 수 있음. 유연성에 있어서 선택의 폭이 상당히 넓어졌다고 할 수 있음.
예) Stack<int> store = new Stack<int>(); : 안에 명시하는 데이터 타입에 의해서 현재 Stack 개체에 저장되는 데이터의 타입이 결정.

**readOnly 한정자
-선언의 일부로 대입 또는 동일한 생성자에서 대입하는 경우에만 선언

Generics의 제약 조건
-Generics코드는 클라이언트가 사용하는 특정 형식과 호환되지 않는 Generics 형식 매개 변수의 메서드, 속성 또는 맴버를 사용할 수 있음.
-결과적으로 형식 안전성을 떨어뜨릴 수 있기 때문에 허용될 수 없음.

제약 조건 | 설명
where T : struct | 형식 매개 변수는 Value Type
where T : class | 형식 매개 변수는 Reference Type
where T : new() | 매개 변수를 지니고 있지 않는 Default 생성자를 지니고 있어야 함.
where T : <base class name> | <base class name>에 해당 하는 클래스를 상속받아야 함.
where T : <interface name> | <interface name>에 해당하는 인터페이스를 구현하고 있어야함
**where 키워드로 제약 조건을 정의, 컴파일러에게 형식 매개 변수가 지니고 있는 제약 조건을 알려줌

Dictionaries : Key와 Value의 쌍으로 데이터를 저장할 수 있는 컬렉션
-Dictionary의 경우는 object형태의 Key 값과 value 값을 저장할 수는 있지만 Key 값의 경우는 간단하고 찾기 빠른 형태의 데이터 타입을 사용하는 경우가 일반적
예)
using System;
using System.Collections.Generic;

namespace GenericDictionary
{
    public class Program
    {
        static void Main()
        {
            Dictionary<string, string> dictionary = new Dictionary<string, string>();
            dictionary.Add("01", "Son");
            dictionary.Add("02", "johnharu");
            dictionary.Add("03", "Lee");
            dictionary.Add("04", "Hong");

            Console.WriteLine("dictionary[\"01\"]:{0}", dictionary["01"]);
        }
    }
}

Iterators
-for, foreach의 단점 : 사용자가 직접 정의하는 컬렉션의 경우 foreach 문을 사용하기 위해서는 IEnumerable 인터페이스를 상속받아 GetEnumerator 메소드를 구현해야 하며, Enumerator는 IEnumerator 인터페이스를 상속 받아 관련 메서드를 구현해 주어야 하는 코드상의 불편함이 있음.
-Iterator : foreach문에서 사용되어 지정된 범위만큼을 반복하면서 지속적으로 결과를 리턴하는 코드 블록을 일컫는 말
-IEnumerable을 상속 받아 구현
-기존의 복잡한 형태의 코드를 간결화 하기 위해 새로운 키워드로 yield return 사용

Anonymous Methods
-메서드를 통해 처리하는 내용을 인라인의 형태로 처리하는 방법을 제공
-델리게이트를 통해 메서드를 호출하는 경우에는 호출할 수 있는 메서드의 타입을 델리게이트를 생성하면서 선언-이벤트 발생하였을 경우에 델리게이트를 통해 선언도니 메서드를 호출하여 원하는 작업을 처리하는 방식의 이벤트 기반 프로그램

델리게이트
-한 번의 호출로 하나의 메서드나 여러 개의 메서드를 동시에 호출 할 수 있음
-대부분의 메서드는 완벽한 형태를 띄고 있는 모습이 일반적.
-특정 클래스의 멤버로서 선언
-저장 공간에 자리 잡고 있는 상태
*이런 경우가 아닌 델리게이트의 경우 특정 클래스의 멤버로 선언하여 굳이 개체를 생성하여 호출할 필요 없이 메서드를 통해 처리하고자 하는 작업을 익명 메서드의 형태로 델리게이트를 통해 호출 가능

Nullable 타입
-.Net Framework CTS(Common Type System)에 정의된 데이터 타입에는 값 타입(Value Type)과 참조 타입(Reference Type)이 있음. 두 타입의 다양한 차이점 중에 NULL 값을 설정할 수 있는지의 여부는 두 데이터 타입을 결정짓는 하나의 기준이 됨. 참조 타입의 경우는 널 값을 설정하여 개체 생성을 나중으로 미뤄둘 수 있지만, 값 타입의 경우는 초기화를 통한 데이터의 할당이 이루어져야 함.
-참조 타입이 아닌 값 타입에도 NULL 값을 저장할 수 있도록 C# 2.0에 새롭게 추가된 개념이 Nullable 타입.
-값 타입이 지닐 수 있는 값의 범위에 Null 값이 하나 추가된 개념.

.NET을 이해하기 전에~
-예전의 DOS는 File I/O와 Console I/O를 처리
-그때의 프로그래밍을 하였을 경우 *.LIB(모듈 단위,각각의 모듈에서 중복 되는 기능이 생겼음)
-*.c와 *.lib를 Compile & link(현재의 Build) 하여 *.EXE파일을 만듬 이것이 *.dll로 변경됨

ActiveX : 특정 웹 사이트에 들어 갈 경우 ActiveX를 설치하라고 하는데, 그것을 클릭하였을 경우
그시점에 .DLL 또는 .ocx를 시스템에 다운로드 및 설치를 한다. 그때 시스템 레지스터에 등록되어 지며 *.DLL이 동적으로 실행 된다. ActiveX--->Activate됨.
이때 .DLL이나 .ocx가 각각의 프로그래밍 언어 마다 다르게 만들어 졌는데 각각의 파일이 운영체제, 각 나라 등
인터페이스가 다른 것을 Framework에서 통합하여 처리를 한다. Framework 안에는 서로 다른 window API들로 구성되어 있음 Framework는 [Compact Framework 또는 일반 Framework][Framework(서로 다른 Window API 통합)]으로 구성

.NET은?
-Microsoft XML 웹 서비스 플랫폼.
-XML 웹 서비스 : 운영체제, 장치, 프로그래밍 언어에 관계 없이 인터넷을 통해 응용프로그램에서 데이터를 통신 또는 공유할 수 있게 해줌.

.Net 플랫폼?
-개발자에게 XML 웹 서비스를 만들고 이들을 서로 통합하는데 필요한 기술 제공.
-일반 사용자아게는 완벽하고 안전한 환경을 제공.

.Net 장점
-언제 어디서나 장치에 관계 없이 통신, 데이터 작업을 할 수 있음.
-분산 컴퓨팅 모델을 사용.
-XML과 같은 개방형 표준에 구축되어 PC 및 다른 스마트 장치를 연결

.NET의 특징
-Java 진영에 대한 전략적 대응책
-Ubiquitous 환경에 대응하기 위한 Any Div. Platform
-Win32, ActiveX기반의 Application 구동 방식의 개선
-개발 환경 및 실행 환경의 복잡성 해결책 요구

개발자 입장에서 바라본 .Net Framework
-JVM(Java Virtual machine)과 같은 안정된 구동 환경 제공.
-언어간 상속, Data교환이 자유로운 .Net언어들을 지원
-모든 시스템 자원(OS, DB)과 interface를 CLR(Common Language Runtime, CTS, CLS)에서 모두 제공
-시스템 레지스트에 등록(CLSID 등)하는 ActiveX가 존재하지 않음(DLL지옥에서 벗어남).
-Web환경, Web Service환경 구축이 .NET 개발 환경에 모두 통합.

*.NET Compact Framework : 스마트 디바이스(PDA 등)에 탑재 되어 동작하는 .NET Framework의 일반 Framework과 사용법은 동일하나 상당 부분의 기능이 제한

.Net CLR(Common Language Runtime)
-기본 Class Lib : 방대한 Lib. 형태 이므로 체계적인 System Namespace로 잘 분류되어 있음
(데이터 접근, GUI, 보안, XML/SOAP, Thread, File IO, Debugging, COM+ 등)
-CLR : CTS(Comm Type System), CLS(Common Language Specification) 두 가지로 구성되어 있음, JAVA의 VM과 같은 역할 수행, 두가지 요소는 .NET언어 들이 교차언어 상속 및 교차 언어 예외 처리를 지원하게 되는 근간을 이룸.
예) [C++]------(->)-------[VB] 두가지 다른 언어를 알아 볼 수 있도록 교차점(인터페이스 관계 설정)을 IDL이라고 한다. 그 역활을 CLR이 함!!

.Net Assembly
[C# Source]------->C# 컴파일러-----┐
[VB.NET Source]--->VB.NET컴파일러--->.NET Assembly(Intermediate Language(IL), Meta Data로 구성)----o
[M.C++ Source]---->C++컴파일러-----┘

o--->클래스 로더--->JIT(Just In Time)컴파일러--->플랫폼이 고려된 명령 바이너리(Xp, 98, 2000등에 맞춰서 설정)--->실행

-.NET기본 Class Lib.(mscorlib.dll) : System.Data, System.IO로 구성
-.NET실행 엔진(mscoree.dll) : 클래스 로더, JIT컴파일러, 플렛폼이 고려된 명령 바이너리로 구성

.NET Assembly의 특징
-Intermediate Language(MSIL) : 중간 바이너리 형태의 실행 코드 집합
-Meta Data : 바이너리 실행에 필요한 리소스, 버전, 기타 자기 설명적 요소
-전용 Assembly, 공용 Assembly : Xcopy를 통해 지역 디렉토리에 복사하여 사용하는 것을 기본
-Version 정책 : Version이 다르면 다른 Assembly로 인식

*GAC(Global Assembly Cache)
-*.DLL을 공유하여 사용하기 위해서 사용되는 공간
-System의 Local영역과 달리 동일한 이름으로 등록 가능, Key를 DLL마다 다르게 생성해주기 때문에 가능
-이름이 같고 버젼이 다르거나 Culture Code(KR, JP, US 등등)에 따라 동일한 이름으로 등록 가능

*Xcopy
-C# Source, VB.NET Source 등---> 컴파일 ---> *.DLL, *.EXE ---> 응용프로그램 실행
이때 응용프로그램 실행 시점에서 필요한 *.DLL 또는 *.EXE를 즉시 복사하여 사용하는 것을 말함.
-*.DLL에 Key등록(GAC)을 하였을 경우 프로그램 실행 시간이 지연됨(Key가 등록되면 실행 시 GAC영역을 검색하여 DLL을 찾고 없을 경우 다시 LOCAL을 검색 후 실행 시키기 때문)

*ildasm : *.dll, *.exe를 재 컴파일 해주는 프로그램, 그래서 .NET으로 보안프로그램은 만들지 않는다.

.NET OOP(Object Oriented Programming)
-캡슐화(Encapsulation) : 한정자(private, public 등)를 이용하여 필요한 것만 보여주도록 하는 것
-상속(Inheritance) : 상위 클래스에서 하위 클래스로 물려 주는 것. 매소드 상속 등
-다형성(Polymorphism) : 하나의 특성을 다른 형태로 변형하여 다른 기능을 수행 하도록 하는 것

-.NET언어들은 JAVA수준의 객체 지향 언어의 조건을 모두 갖추고 있음.
-.NET언어는 파생 Class를 구현 할 때 별도의 정보 파일을 필요로 하지 않음.
-.NET언어는 각 .NET언어 간의 교차 언어 상속이나 Custom Type 사용이 자유 로움.
-교차 언어간 사용을 위해 IDL과 같은 인터페이스 정의 명세가 필요 없음.(CLR을 사용)

.NET의 리소스 관리, Garbage(미아 상태 자원) collection
-리소스 : OS, DB상의 모든 자원들(파일, 메모리, 스크린 영역, Network자원, DB연결 세션 등)
-Garbage : 응용프로그램이 할당하여 사용한 리소스가 사용 후 반환하지도 사용하지도 않고 있는 미아 상태의 자원
-기존 언어들의 리소스 관리 방식 : 명시적인 할당 객체 해제 방식(C++ : Delete, VB : Nothing)

[00OO    Managed heep]
0 - Dispose() --> 명시적 자원 정리 대상(File Handle(close), DB Connection(close), Network Socket(disconnect), Bitmap, Icon(delete object))
O - Root가 끊어진 Resource(Garbage)

유용한 .NET Tools
-C:/>sn : 강력한 이름 유틸리티(공용 어셈블리를 만들기 위해서 Key 생성시 사용)
-C:/>regasm : .net Assembly를 타입라이브러리를 내보내어 레지스트리에 등록(.NET 어셈블리를 ActiveX로 변환)
-C:/>ildasm : .net Assembly를 디 어셈블 해주는 Tools(메니페스트 정보와 il Code를 볼 수 있음)
-C:/>gacutil : 공유(전역) 어셈블리 케쉬(Global Assembly Cache)에 어셈블리 등록하는 Tool

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Default.aspx.cs" Inherits="Menu._Default" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
    <title></title>
</head>
<style type="text/css" runat="server">
    ul#topnav
    {
        margin: 0;
        padding: 0;
        float: left;
        width: 970px;
        list-style: none;
        position: relative; /*--Set relative positioning on the unordered list itself - not on the list item--*/
        font-size: 1.2em;
        background: url(topnav_stretch.gif) repeat-x;
    }
    ul#topnav li
    {
        float: left;
        margin: 0;
        padding: 0;
        border-right: 1px solid #555; /*--Divider for each parent level links--*/
    }
    ul#topnav li a
    {
        padding: 2px 2px;
        display: block;
        color: #f0f0f0;
        text-decoration: none;
    }
    ul#topnav li:hover
    {
        background: #1376c9 url(topnav_active.gif) repeat-x;
    }
    /*--Notice the hover color is on the list item itself, not on the link. This is so it can stay highlighted even when hovering over the subnav--*/
    ul#topnav li span
    {
        float: left;
        padding: 2px 0;
        position: absolute;
        left: 0;
        top: 30px;
        display: none; /*--Hide by default--*/
        width: 970px;
        background: #1376c9;
        color: #fff; /*--Bottom right rounded corner--*/
        -moz-border-radius-bottomright: 1px;
        -khtml-border-radius-bottomright: 1px;
        -webkit-border-bottom-right-radius: 1px; /*--Bottom left rounded corner--*/
        -moz-border-radius-bottomleft: 1px;
        -khtml-border-radius-bottomleft: 1px;
        -webkit-border-bottom-left-radius: 1px;
    }
    ul#topnav li:hover span
    {
        display: block;
    }
    /*--Show subnav on hover--*/
    ul#topnav li span a
    {
        display: inline;
    }
    /*--Since we declared a link style on the parent list link, we will correct it back to its original state--*/
    ul#topnav li span a:hover
    {
        text-decoration: underline;
    }
</style>
<body>
    <form id="form1" runat="server">
    <div style="background-color: Black; width: 960px; height: 110px;">
        <ul id="topnav">
            <li><a href="#">My Home</a></li>
            <li>
                <a href="#">Projects</a>
                <span><a href="#">Subnav Link</a>
                    <a href="#">SubnavLink</a>
                    <a href="#">Subnav Link</a>
                </span>
            </li>
            <li><a href="#">Backlogs</a>
                <span><a href="#">Subnav Link</a>
                    <a href="#">SubnavLink</a>
                    <a href="#">Subnav Link</a>
                </span>
            </li>
            <li><a href="#">Defects</a>
                <span><a href="#">Subnav Link</a>
                    <a href="#">SubnavLink</a>
                    <a href="#">Subnav Link</a>
                </span>
            </li>
            <li><a href="#">Reports</a>
                <span><a href="#">Subnav Link</a>
                    <a href="#">SubnavLink</a>
                    <a href="#">Subnav Link</a>
                </span>
            </li>
        </ul>
    </div>
    </form>

    <script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.3/jquery.min.js"></script>

    <script type="text/javascript">
        $(document).ready(function() {

            $("ul#topnav li").hover(function() { //Hover over event on list item
                $(this).css({ 'background': '#1376c9 url(topnav_active.gif) repeat-x' }); //Add background color and image on hovered list item
                $(this).find("span").show(); //Show the subnav
            }, function() { //on hover out...
                $(this).css({ 'background': 'none' }); //Ditch the background
                $(this).find("span").hide(); //Hide the subnav
            });

        });
    </script>

</body>
</html>

1. 시작->프로그램->VS2005-> VS Tools -> 명령 프롬프트 실행
   
   
2. 역어셈블리 툴인 ildasm.exe 실행

3. 아래와 같이 프로그램 실행

4. 파일 -> 열기 클릭

5. 역어셈블 하고자 하는 *.dll 선택 후 열기

6. 아래와 같이 *.dll 파일이 열림.

7. 파일->덤프 메뉴 클릭

8. 아래와 같은 덤프 옵션창에서 원하는 형식으로 설정 후 확인

9. 확인 버튼을 눌리면 *.dll 파일이 위치한 경로에 *.txt / *.res 파일 생성

10. *.txt 파일의 경우 원래의 코드 형태는 아니지만 클래스, 메소드, 프라퍼티 등 정보가 아래와 같이 생성.

11. *.res 파일의 경우 열기 하였을 경우 아래와 같은 결과를 보여줌

12. 파일->트리 뷰 덤프 클릭 후 *.dll 파일을 열면

13. 아래와 같이 *.txt 파일 생성

14. 파일을 열어 보면 아래와 같이 트리형태로 클래스, 메소드, 프라퍼티 등을 볼수 있음.

15. ILDASM.exe 실행시 심볼 형태로, 덤프한 결과일 경우 축약형으로 참고하여 보면 도움이 될듯..

( 인포북 C#과 .NET플랫폼 참고)

ILDASM.EXE 심볼	축약형	설명
	.(DOT)	이 아이콘은 주어진 타입에서 더 많은 세부 정보를 찾아 볼 수 있음을 의미한다. 더블클릭할 경우에는 아이템은 트리에서 관련된 노드로 점프하게 된다.
	[NSP]	네임스페이스를 의미한다.
	[CLS]	클래스를 의미한다. 중첩된 클래스의 경우에는 <outer 클래스> $<inner 클래스>의 방식으로 표현한다.
	[VCL]	구조체를 의미한다.
	[INT]	인터페이스 타입을 의미한다.
	[FLD]	주어진 타입에서 정의된 필드를 의미한다.(public 데이터).
	[STF]	주어진 타입에서 정의된 정적(static) 필드를 의미한다.(클래스 차원에서).
	[MET]	주어진 타입의 메소드를 의미한다.
	[STM]	주어진 타입의 정적메소드를 의미한다.
	[PTY]	주어진 타입의 프로퍼티를 의미한다.
	[]

• iBatis + SQL 설정
1. 아래와 같이
• IBatisNet.Common.dll : 자세한 내용은 http://ibatis.apache.org/ 참조
• IBatisNet.Common.Logging.Log4Net.dll : 로그를 찍기위한 파일.
• IBatisNet.DataMapper.dll : 데이터 mapping을 하기위한 파일.

위의 3개의 DLL 을 참조 추가 한다.

2. 그리고 두개의 파일이 설정 파일이 있어야 사용 가능 하다.

• provider.config
• SqlMap.config

1. Provider.config 파일은 아래와 같이 SQL, Oracle 등 각종 DB에 대한 공급자 설정이 되어 있다.

사용시 enabled 속성이 기본 false 이므로 true로 바꿔서 사용 한다.

2. SqlMap.config 파일은 DB 접속 정보와 DB의 정보를 mapping 할 수 있는 xml 파일을 설정 한다.

3. provider.config 파일의 provider 엘리먼트의 name 속성의 값이 sqlServer2.0으로 되어 있는데 SqlMap.config의 provider 엘리먼트의 name 속성과 동일해야 DB에 접속 가능하다. resource 속성의 경우 공급자 설정이 되어있는 provider.config 또는 *.config 파일과 동일하게 작성 한다.

-이렇게 하면 기본 사용할 준비는 완료!! 사용을 하기 위해서 mapping 할 Entity class를 별도로 생성하고 아래와 같이

(List<SaNoticeET>)Mapper.Instance().QueryForList<SaNoticeET>("SELECT_SA_NOTICE", param);

한줄이면 원하는 데이터를 조회 할 수 있다.

위에서 설정된 Admin.xml을 보면

<?xml version="1.0" encoding="utf-8" ?>

<sqlMap namespace="ubis.pms.Entity.Admin" xmlns="http://ibatis.apache.org/mapping" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<!-- 사용할 Entity Class의 별칭을 만든다. -->

<alias>

<typeAlias alias="SaNoticeET" type="ubis.pms.Entity.Admin.SaNoticeET, ubis.pms.Entity.Admin" />

</alias>

<resultMaps>

<!-- Notice List Map -->

<!-- DB 컬럼 명과 Entity Class의 변수와 일치하는 property 속성을 설정 한다. -->

<resultMap id="RTMAP_SA_NOTICE" class="SaNoticeET">

<result column="notice_seq" property="NoticeSeq"/>

<result column="title" property="Title"/>

<result column="contents" property="Contents"/>

<result column="fst_regist_id" property="FstRegistId"/>

<result column="fst_regist_date" property="FstRegistDate"/>

<result column="lst_regist_id" property="LstRegistId"/>

<result column="lst_regist_date" property="LstRegistDate"/>

</resultMap>

</resultMaps>

<statements>

<!-- 반환될 resultMap 설정 및 위에서 사용한 QueryForList의 첫번째 인자인 statementName을 id값으로 준다. -->

<select id="SELECT_SA_NOTICE" resultMap="RTMAP_SA_NOTICE"         parameterClass="SaNoticeET">

select notice_seq, title, contents, fst_regist_id, fst_regist_date, lst_regist_id, lst_regist_date

from t_bs_notice

</select>

</statements>

</sqlMap>

1. iBatis.NET은 내부적으로 Log를 남김.
2. 출력용 로그는 개발자가 따로 설정 해야하며 log4net을 사용하여 출력한다.

 

** 설정 하기

1. "IBatisNet.Common.Logging.Log4Net.dll" 을 참조 추가 한다
   

 

2. "Web.Config" 의 <configSections>에 아래와 같이 설정

1. 

 

3. <sectionGroup>의 name이 "iBATIS" 인 Tag 추가


 

4. Log4net을 이용하여 출력되는 파일 크기/옵션 등 세부 설정.

 <level> 의 값 : OFF, FATAL, ERROR, WARN, INFO, DEBUG, ALL



 

5. 설정이 완료되면 아래와 같이 log.txt 파일이 생성되고 상세 옵션에 따라 100KB가 초가 되었을 경우 Log 파일을 자동으로 추가 생성 한다.


 

 

** 링크

http://logging.apache.org/log4net/release/config-examples.html - Log파일 기록 설정 방법

http://logging.apache.org/log4net/index.html - 자세한 사항은 Log4net 페이지 참조~!!