수학적 공식을 C#에서 그대로 표현했을 때, 간혹 잘못된 결과를 산출하는 경우가 있다. 이 아티클에서는 간단한 예제를 통해 이러한 경우를 살펴보고, 어떤 방식으로 문제를 파악할 수 있는지 그 접근 방식을 설명한다.

한 개발자가 아래와 같은 코드를 작성하였다. 이 코드는 작업쓰레드에서 실행되었는데, 파일을 복사하면서 ProgressBar를 가진 폼에 복사 진척 정도를 표시하는 일을 하는 것이다.

LINQ TO Entitiy 혹은 LINQ TO SQL에서 조건식에 변수값을 사용하는 것과 .NET 클래스를 직접 사용하는 것은 경우에 따라 다른 결과를 초래할 수 있다. 이는 Framework이 런타임시 그 값이 결정되는 .NET 클래스를 (런타임 값이 아닌) SQL의 내장함수로 직접 변환할 수 있기 때문이다.

데이타베이스 특히 SQL Server의 데이타를 읽어 와서 이를 핸들링할 때, DB 테이블의 NULL 필드에 대한 처리에서 흔히 혼동하는 경우가 있다.

문자열 리스트(혹은 문자열 배열)를 DataGridView 와 같은 그리드에 데이타 바인딩할 경우 흔히 다음과 같이 코딩할 수 있다.

다음 C# 코드는 무엇이 잘못 되었을까?

C# 개발자들이 간혹 실수하는 것 중에 하나는 컬렉션을 리턴하는 속성(Property)에 대한 것이다. 만약 컬렉션을 리턴하는 속성이 Getter 즉 get 만 가지고 있을 때, 이 속성은 진정한 읽기 전용(Read Only)이라고 볼 수 있을까?

동료인 Steve가 웹 API 하나가 동작하지 않는다고 조사해 줄 것을 요청하였다. API를 좀 더 단순화 하면 아래와 같은 형태가 되는데, 몇 가지 값들을 입력받아 이를 DB에 저장하게 된다. 테스터가 이미 테스트를 완료한 API인데, 어디선가 오류가 발생한 듯하여 디버깅을 실행하였다.

SQL Injection 관련 이전 아티클들은 ADO.NET에서의 Dynamic SQL과 SQL Stored Procedure에서의 Dynamic SQL이 만들어 지는 과정과 그 실행과정에서 발생하는 SQL Injection 문제를 집어 보았다. 그렇다면, 요즘 많은 개발자들이 사용하고 있는 Entity Framework (혹은 LINQ To SQL)과 같은 프레임워크를 사용했을 때, SQL Injection 문제는 없는 것일까?

지금까지의 SQL Injection 관련 아티클에서 설명한 바와 같이, C#에서 SQL문을 문자열 병합 (string concatenation)으로 처리하는 것은 SQL Injection을 야기하는 주요 원인이 되며, 따라서 SqlParameter를 사용한 Parameterized Query를 이용해야 함을 알 수 있었다. 그러면 다음과 같이 SQL Stored Procedure를 C#에서 호출하는 것은 어떤 문제가 있을 수 있을까?

이전 아티클 해커들의 백도어 SQL Injection에 이어 이번 아티클에서는 SQL의 LIKE문에서 흔히 발생하는 SQL Injection 문제를 다루어 본다. 기본적으로 이전 아티클과 동일한 원칙을 적용한다고 볼 수 있지만, 한편으로는 약간의 특별한 문법을 갖고 있기 때문에 여기서 별도의 예제를 들어 본다.

.NET Framework에 LINQ 가 도입된 이후, 많은 C# 개발자들이 점점 더 LINQ를 애용하고 있다. 이는 LINQ를 사용하지 않으면 별도의 작은 함수들을 여러 개 만들어야 하는 불편함들을 LINQ가 해소해 주기 때문일 것이다. 그런데, 자주 LINQ를 사용하는 개발자들도 흔히 하는 실수가 있는데, 이는 Single(), SingleOrDefault(), First(), FirstOrDefault() 와 같은 메서드를 잘못 사용하는 경우이다.

Type.GetType() 메서드는 .NET 어셈블리의 특정 클래스를 사용할 수 있도록 해당 클래스 Type명을 문자열로 받아들여 Type객체를 리턴한다. 동일한 클래스가 여러 DLL에 존재할 수 있으므로, GetType()에 쓰이는 파라미터는 네임스페이스.클래스, 어셈블리명, 버젼, Culture, PublicKeyToken 등 여러정보를 사용하여 (이를 AssemblyQualifiedName 이라 부른다) 특정 어셈블리의 클래스 타입을 지정하게 된다.

C#에서 구조체(struct)는 인터페이스를 가질 수 있는가? 흔히 struct는 인터페이스를 가질 수 없다고 생각하기 쉬우나, C#은 이 기능을 지원하고 있다. 하지만 구조체에 인터페이스를 구현할 때, 종종 사용상 문제를 발생시킬 수 있는데, 이 아티클에서는 인터페이스를 가진 구조체가 어떻게 데이타 오류를 발생시킬 수 있는 예를 들어 알아 본다.

해커들이 가장 애용하는 해킹 기법들 중의 하나로 SQL Injection 기술을 들 수 있다. SQL Injection이란 SQL 쿼리를 해커가 조작함으로써 일반적으로 노출되지 말아야 하는 정보를 해커가 얻어 내는 것이다. 그런데, 이러한 SQL Injection 문제는 개발자가 흔히 하는 데이타베이스 코딩을 통해 쉽게 노출되기 때문에, 개발자가 특히 주의해야 하는 부분이다.

클래스 계층 구조에서 동일한 메서드명을 갖는 메서드들이 상속 구조 내에서 존재할 때, 어떤 메서드가 호출되는지 혼동될 경우가 있다. Base 클래스의 메서드를 호출하고자 했는데, 파생클래스의 메서드가 호출될 수도 있고, 또 그 반대의 경우도 발생할 수 있다.

문자열 처리는 프로그래머들이 가장 먼저 배우는 영역이고 거의 모든 어플리케이션에 사용되므로 대부분 능숙하게 다루는 분야이다. 하지만, 그럼에도 불구하고 예기치 못한 버그가 잘 발생하는 분야이기도 하다. 이의 한 예로 String 클래스의 IndexOf() 메서드 사용에 있에 주의해야 할 점을 들어 보겠다.

C# 클래스를 작성할 때, 필드(field) 멤버를 public으로 지정하여 외부에서 해당 멤버를 직접 읽고 쓰는 일을 허락할 수 있다. 흔히 간단한 데이타 멤버를 이런 방식으로 외부에 노출시키는데, 이러한 코딩 방식은 올바른 것일까?

C# 키워드인 ref는 해당 Type 객체가 호출되는 메서드에서 변경될 수 있다는 의미한다. Value 타입의 객체의 경우 해당 값이 호출되는 메서드에서 변경될 수 있고, 이를 호출하는 쪽에서 사용하기 위해서는 ref를 반드시 사용해야 한다.

날짜를 받아들이는 입력 컨트롤이 문자열을 리턴하는 경우, 혹은 콘솔로부터 날짜를 입력 받는 경우 등 종종 문자열을 날짜로 변경해야 하는 경우가 있다. 그런데 언뜻 보기에는 문제없어 보이는 날짜 범위 지정이 데이타 누락으로 이어지는 경우가 있다.

한 메서드 안의 로컬 변수들은 그 메서드가 끝날 때 해제되게 된다. Value 타입의 변수는 함수 리턴과 동시에 스택에서 해제되고, Reference 타입의 변수는 GC (Garbage Collector)에 의해 힙상에서 자동 해제되게 된다. 프로그래머들이 흔히 범하는 실수중의 하나는 레퍼런스 타입의 객체를 불필요하게 너무 많이 만드는 것이다.

흔히 읽기 전용 레퍼런스 객체를 외부에서 사용토록 위해 Getter 속성을 사용하여 읽기 전용 속성을 제공할 수 있다. 하지만, 이 속성은 개발자의 순수한(?) 의도와 상관 없이 외부에서 해당 객체 데이타를 변경 혹은 삭제할 수 있는 기능을 제공할 수 있다.

C#에서 간단한 데이타 구조를 표현할 때 종종 struct 를 사용한다. 함수 안에서 사용되는 struct는 Value 타입으로 스택에 생성되고, class는 Reference 타입으로 인스턴스가 힙에 생성된다. 이러한 구조적인 차이는 때로 실무 코딩상에서 버그를 발생시키곤 하는데, 여기서는 그것의 대표적인 한 예를 들고자 한다.