c#

필자는 윈도우즈 OS에서 동작하는 프로그램의 형태를 총 3가지로 나눈다. Windows(UI) 프로그램 / Windows Service 프로그램 / Web 응용프로그램으로 크게 분류한다. 같은 Windows 프로그램인데 Winform기반이나 WPF기반이냐 그도 아니면 MFC를 작성 했는가는 그저 구현 기술로 본다. *nix OS에서는 Windows Service와 같은 프로그램을 데몬(Demon)이라고 칭한다. Windows service 형태는 SQL Server나 IIS와 같이 사용자 인터페이스(UI)가 없이 이를 사용하는 Client프로그램에 서비스를 제공하는 프로그램이다. 필자가 오늘 논하고자 하는 형태는 Windows UI 프로그램이나 때로는 Service와 같이 UI없이 Background로 ..

응용 프로그램의 예외 처리-1편의 마지막에 독자에게 던진 질문이 "Main함수에서 조차 예외를 throw를 한다면 또는 애시당초 그 어디에서도 예외를 헨들링 하지 않는다면 그 예외는 어떻게 될까?"였다. 이런 예외를 Unhandled Exception이라고 부른다. 누구도 헨들링(처리 하지 않은 오류) 이런 예외는 다양한 방법으로 사용자에게 불안감 불쾌감으로 다가온다. 예외가 발생한 프로그램의 종류에 따라 혹은 발생한 오류에 따라 이 예외라는 녀석의 표현은 다양하다. 이 시점에서 .NET으로 작성 할 수 있는 프로그램 종류를 정리 해보자. Visual Studio에서 생성할 수 있는 프로젝트중 클래스 라이브러리를 제외한 모든 프로젝트가 프로그램의 종류라고 볼 수 있다. 작금의 .NET은 프레임워크가 전통..

필자는 일단 웹이 싫다. 다양한 브라우저가 싫고 마크업 언어에 의존하는 UI구성이 싫다. 젊은 시절 그래서 입에 달고 살았다. "난 웹이 싫어" 그런데 싫다고 피해지나 ... 온 천지 웹이고 심지어 초년시절에는 ERP용 전용브라우저를 개발 했다. 요즘에 화려한 ES6기반의 다양한 JS라이브러리에 비할바는 아니지만 적어도 이런 이유로 브라우저 컨트롤과 JavaScript간의 상호작용에 어느정도의 이해는 갖게 되었다. 그 시절의 브라우저는 IE가 전부였고 당연히 전용브라우저를 만들려면 IE의 컨트롤을 사용 해야 했다. 그리고 한참 이 존재에 대해 잊고 살았다. 얼마전 회사 후배가 고충을 토로하면서 기술 문의를 해왔다. 이유는 이렇다. 우리 회사의 웹기반의 솔루션이 불가피 하게 고객사의 어플리케이션 내에서 I..

요즘 필자가 연재 하겠다고 뻥뻥 거렸던 예외에 대한 글도 마무리를 못지을 만한 일이 있다. (사실 엄격히 말하면 이 역식 변명인데 ^^) 수년을 끌어온 모 병원정보 시스템을 드디어 오픈 했기 때문이다. 현장에 주니어 개발자 한 분과 시니어 개발자 한 분이 몇 개월동안 오픈 준비를 했다. 워낙 그간 경험 해왔던 사이트 보다 병원 사이즈가 커서 이번에는 나도 몇 주간 시스템 오픈 지원 및 상황 통제를 하기 위해 현장에 나와 있다. 상당 기간동안 준비를 해왔고 기존 시스템과 연동하여 우리 제품의 사용 검증이 끝났음에도 불구하고 차세대 시스템에 적용중에 생기는 문제는 또 다른것 이였다. 현재 크고 작은 이슈들이 지나가고 있는 중이다. 그런데 몇 일 전에 이상한 이슈가 제기 되었다. 사용자가 우리 솔루션이 적용된..

고객사에 윈도우 응용서비스 응용프로그램을 공급했다. 이 서비스 프로그램은 코어 모듈들에 대한 자가 업데이트 기능이 있고 서비스는 핵심이 되는 이 파일(어셉블리)들을 플러그인 하는 구조를 가지고 있다. 이 실행을 매 서비스가 기동하는 시점에 한다. 일반 사용자가 서비스를 중지 했다 시작하는 일이 흔하지 않고 결국 시스템이 처음 부팅하는 시점에 서비스가 시작된다. 헌데 아주 아주 느린 고객 PC들에서 WebClient를 이용한 File Download시 예외 로그가 보이는 것이다. 현장 PM의 증언으로는 이런 PC들은 윈도우 로그인 하고나서 한참이 지나도 인터넷 접속 상태 트레이 아이콘이 계속 보인다는 것이다. 윈도우 로그온 세션이 시작된 후 10초가 지나서 다운로드를 시도 한건데.. 아직도..... (윈도..

10년 이상을 닷넷과 C#을 사용하여 개발한 경험을 바탕으로 응용 프로그램 예외 처리에 대한 글을 연재 하려 한다. 예전에 예외라는 개념이 없었던 언어들은 함수를 호출해서 잘 처리 되었는지를 보통 함수의 반환 값으로 넘겨 줬다. 그리고 막상 결과는 Call by Reference방식으로 반환 하는 경우가 많았다. 초기 윈도우즈를 발표했들 당시 MS가 개발자들에게 공개한 API(Win32 API)들이 그러 했다. 원래 함수라는 것이 수학에서 나온 것일 터인데 먹은데로 다시 값을 넘겨서 그것을 활용하는 구조가 프로그램 언어론 학자가 아니더라도 보기 좋지 못했을 뿐더러 반환 값으로 함수의 정상 처리 여부의 상태를 반환한다는 것도 한계가 있다. 예를들어 어떤 함수가 Http Request를 이용하여 원격 요청을..

결론부터 말하면 아래 어트리뷰트를 설명하려고 한다. 닷넷 어셈블리를 구현을 할 때 이와 대응되는 테스트 프로젝트를 별도로 작성하게 된다. 근데 우리가 테스트 하려는 대상의 접근 한정자가 internal이면 어쩌지 테스트를 하려고 public으로 바꿔야 하나? 나만의 고민이 아니였고 이미 해법은 있었다. 보통 나는 구현하려는 어셈블리가 "OOO"이라는 이름을 갖게 되면 테스트는 "OOO.Test"라고 명명을 한다. 다른 분들도 그렇게 보통 하는 듯 하다. 아래 어트리뷰는 즉 "OOO"어셈블리의 AssemblyInfo.cs에 지정하는 것이다. "OOO.Test"에게 나의 Internal을 보여줘!!! [assembly: InternalsVisibleTo("OOO.Test")]

어느날 오픈소스 프로젝트 하나를 다운받아서 살펴보는데 C#프로젝트에서는 볼수 없었던 아니 여태 이런 방법으로 쓸생각 조차 못했는데 이상한 모양이 하나 보였다. C++같이 외부에 참조된 아이콘이 보이지 않는가?? 요즘 노안으로 눈치 침침 해졌다고 해도 아무리 봐도 뭐 하나가 더 붙어 있는거다. 나 같이 눈이 침침해진 4~5십대 개발자를 위해 그림을 확대 했다. 이 화살표 사각형 이거.... 속성을 보니 진짜 다른 위치를 가르키고 있었다. 뭐터러 이렇게 참조를 하나 싶다가... 다음과 같은 아련한 기억이.... "Class하나 참조 하려고 본 프로젝트 보다 더 큰 프로젝트를 참조 하는 경우 ... 근데 이거 아주 라이트하게 웹을 통해서 배포 해야 하는데 .... ", 그렇다고 소스를 이중화 하긴 더 싫었다...

회사에 주니어들 한테 교육을 진행 하다 보면 처음으로 약간의 난관에 부딛히는 주제가 바로 이것 Call by Value, Call by Reference이다. 이 주제가 언어 별로 조금씩 틀리고 같은 언어라도 C++같은 경우에 인자로 넘기는 것이 값 형인지, 포인터인지에 따라 작용이 다르게 보이니 더더욱 언어별로 정리 하고 가야 한다. C#은 MS에서 아니라고 할지도 모르겠지만 분명 자바를 동경 했다. (지금은 그럴것도 없다.) 그래서 많은 부분을 차용하였는데 그러면서 MS답게 기존 MS개발자들을 고려 했다. 해서 C#에 함수 호출은 Call by Value에요 Call by Reference에요라고 질문을 하면 "둘다"라고 해야 정답이다. C#에서는 ref라고 하는 지시자를 함수의 선언과 호출에 명시적..

10년 전이나 지금이나 기업용 솔루션 개발을 하는 일이 어찌 보면 비슷한 패턴의 연속이다. 다만 나를 비롯한 개발자들은 이를 좀더 간결한 코드로 만들어 내느냐에 노력 해온거 같다. 3-tier 구조 역시 그러하다. 물론 오늘 다룰 주제가 3-tier 구조에 국한되는 이야기는 아니다. 3 tier던 2 tier던 UI에서 서비스 호출 또는 DB Access를 하고 나서 UI가 할일은 대기 하는 것이다. 결과가 올때 까지 무작정 (사실은 정해진 시간 내에서 기다린다. 우린 이것을 보통 Timeout이라고 한다. ) 기다린다. 이렇게 호출을 해놓고 기다리면 화면이 얼어 버린다. 얼어 버린 화면을 이리 끌고 저리 끌고 해봐야 화면은 아무런 응답을 하지 못한다. 왜 이러냐면 UI를 가지고 있는 윈도우 프로그램은 ..