With ListBox1
  ' If we have some selected items.
  If .SelectedIndices.Count > 0 Then
    ' Loop through selected indicies to get the index number of
    ' the selected item.
    ' We need to cound back through the list to avoid reindexing the
    ' the list as we go.
    For i As Integer = .SelectedIndices.Count - 1 To 0 Step -1
      ' Remove the item.
      .Items.RemoveAt(.SelectedIndices(i))
    Next
  End If
End With

데이터베이스 연동관련 프로그래밍을 할 때 DBNull 관련 예외를 처리하는것이 가장 중요하다고 생각합니다. 여기에서는 3가지 방법으로 DBNull 예외를 제어하는 방법을 살펴보도록 하겠습니다.

1. 데이터와 DBNull을 직접 비교하는 방법

가장 일반적인 방법입니다. 닷넷에서 DBNull은 정확히 System.DBNull.Value 값입니다. 읽으려하는 데이터를 System.DBNull.Value 와 비교하여 아래와 같이 처리 할 수 있습니다.

if item("고객이름") is System.DBNull.Value then
    ' DBNull 일 경우 처리
else
    ' DBNull 이 아닐경우 처리
end if

위와같이 처리하는 방법이 가장 일반적인 방법이지만, 코드 작성에 상당한 시간을 소요해야 할 것입니다.

2. ToString() 함수를 이용하는 방법

이 함수를 이용하면 간단하게 System.DBNull.Value 예외를 피할 수 있습니다. 아래와 같이 각 데이터에 .ToString() 함수만 적어주면 System.DBNull.Value 항목은 “” 즉, String.Empty 값으로 반환됩니다.

item("고객이름").ToString()

이 방법으로 가장 간단하게 DBNull 예외를 피할 수 있지만, 데이터를 파싱해야 하는 경우에는 에러가 발생할 여지가 남아있습니다. 예를 들어 Double.Parse() 등의 함수를 이용하여 변환을 시도할 때 DBNull 이여서 인자로 String.Empty 값이 입력된다면 에러가 발생합니다.

3. IsNull() 함수를 이용하는 방법

DataRow 클래스와 관련된 변수로 데이터를 받아서 처리하는 경우에는 IsNull() 함수를 이용해서 예외를 피할 수 있습니다. 읽으려고 하는 데이터의 컬럼에 대해 IsNull() 함수를 실행하여 DBNull 여부를 먼저 체크하는 방법입니다.

if row.IsNull("고객이름") = true then
    ' DBNull 일 경우
else
    ' DBNull 이 아닐경우
end if

1번과 유사한 방법이지만 iif 등의 조건문과 결합한다면 상당히 간결한 코드를 구성할 수 있는 장점이 있습니다.

Dim x as Double
x = System.String.Format("{0:F3}", IIF(row.IsNull("고객번호"), 0, row.item("고객번호")))

위와 같이 처리하면 예외를 피할 수 있습니다.

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

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

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

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

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

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

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 함수에 위에서 정의한 함수가 확장되어 들어가 있는 것을 볼 수 있다.

이번에 기존에 개발중이던 Shell Extension 프로그램의 코드를 C#으로 변경하면서 계속 내용을 찾아보던중 좀 미심쩍은 부분이였는데, 마이크로소프트 MSDN에 명시가 되어 있었다.. ㅠㅠ

Shell extensions should not include managed code. Shell extensions are loaded into all processes that use the Shell namespace and run in-process by definition. Managed code built against one version of the common language runtime might not run in a process running a different version of the common language runtime. At this time, only one version of the common language runtime can be loaded into a process at one time. Therefore, Microsoft recommends against writing managed Shell extensions and does not consider them a supported scenario.

For instance, if you wrote a managed Shell extension, then every application on the computer that has a file Open dialog box would have that managed code and its attendant common language runtime dependency injected into the application’s process. The application or extension that is first to load its required version of the Microsoft .NET Framework into that process restricts the process to using that particular version of Framework. If a managed application with an Open dialog box is built on an older version of the Framework than your Shell extension requires, then your extension could fail to run correctly and could cause errors in the application. Conversely, if your Shell extension is the first to load in a process and managed code tries to launch after that (perhaps a managed application or a running application loads the common language runtime on demand), the later code has to use the version of the Framework that was loaded by the Shell extension, whether compatible or not, again leading to the possibility of an application failure.

Developers will be tempted to devise schemes to mitigate the issue, including Component Object Model (COM) wrappers for managed objects, but in the end, each, no matter how convoluted or careful, comes back to the potential for a version conflict in an in-process object. Therefore, we strongly recommend against using any single-instance-per-process runtime or library (such as the Framework, Microsoft XML (MSXML), or Java) in a Shell extension. If you are developing a Shell extension, do so with unmanaged code.

내용을 요약하자면, 하나의 프로세스에서는 한번에 1개 버전의 CLR(Common Language Runtime)만 로드될 수 있기 때문에, 마이크로소프트에서는 관리되는 Shell Extension을 개발하는 것을 지향하고 있다는 내용이다.

그동안 몇시간동안 바꿨었던 내용을 다시 돌려야 하나보다..

정말 VC++ 과 C#의 생산성이란 비교할 수가 없건만 ㅠㅠ

참고 : http://msdn.microsoft.com/en-us/library/dd758089%28VS.85%29.aspx

.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>

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

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

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 를 이용한 파일 쓰기

// 파일 생성
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가 가능하다.

클래스에서 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 클래스의 인스턴스를 넘겨주면 복제가 된다.

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에 등록하는것이 불가능하게 된다는 뜻입니다.

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

.NET Assembly를 운영체제에 등록할때는 regasm 명령어를 사용하면 된다.

등록할 때

\windows\microsoft.net\framework\v2.0.50727\regasm Test1.dll /tlb:Test1.tlb /codebase

제거할 때

\windows\microsoft.net\framework\v2.0.50727\regasm Test1.dll /unregister

이걸 못찾아서 또 몇십분을 헤맸다…….