.NET 3.5 Base Programming With C#

Click Once Get Current Version Info

2009-02-23T19:41:41Z

Click Once Get Current Version Info

클릭원스를 사용하여 배포한 프로그램은 일반적으로 실행 시 버전체크 과정을 거치게 됩니다.

그림 처럼 자신의 버전과 배포 주소의 버전을 비교하는 과정을 항상 거치게 됩니다.

아래 그림처럼 클릭원스의 업데이트 설정에 따라 실행 후 또는 실행 전에 버전검사를 실시할수 있고 매번 혹은 주기를 두고 버전 검사작업을 하게도 설정이 가능합니다.

배포 시 업데이트 옵션 설정 화면 - 파이 참조

이 모든 버전검사는 클릭원스로 배포가 된 후 바탕화면의 바로가기를 클릭하거나 프로그램메뉴에서 실행을 할경우 즉 정상적인 경로로 실행하는경우에 한합니다.

만약 클릭원스로 배포된 실행파일을 콘솔에서 바로 실행시킨다면 위의 버전검사 과정을 거치지 않고 프로그램은 실행될것입니다.

이 경우 버전검사는 직접 코딩을 통해 수행해 주어야 합니다.

클릭원스로 배포된 사이트의 내용을 살펴보면 아래 그림처럼 Application Files라는 폴더에 이제까지의 배포버전이 저장되어 있고 Applicationname.application 파일에 배포파일에 대한 정보가 들어있습니다.

클릭원스 배포 웹사이트의 파일구성 - 파이 참조

실제로 배포된 폴더의 내용을 들여다 보면 아래와 같습니다. - 파이 참조

클릭원스로 배포가 되면 배포버전 마다 localsettings 아래 임의의 폴더가 자동 생성되고 그곳에 인스톨이 됩니다.

따라서 다른프로그램에서 클릭원스로 배포된 프로그램을 호출하는 것이 용이하지는 않지만 아주 불가능한 부분은 아닙니다.

현재 배포된 자신의 버전에 관한 정보는 리소스 및 여러

가지 방법으로 알아낼수 있지만 현재 어떤버전이 배포되어 있는지 알기는 어렵습니다.

결국 클릭원스로 배포된 사이트에서 현재버전을 알아올수 밖에는 없는데 클릭원스 자체로는 배포된 버전에대한 정보를 제공하는 어떤 루틴도 가지고 있지 않습니다.

배포 사이트의 Applicationname.application파일을 까보면 대략 아래와 같은 내용을 보실 수 있습니다. - 파이 참조

정확한 현재 배포 버전에 대한 정보가 존재합니다.

아래는 현재 배포된 버전의 정보를 가져오기 위해 WebRequest로 Applicationname.application파일을 요청하고 XMLdocument를 parsing 하여 버전정보를 가져오는 코드입니다.

private string GetCurrentVersion(string strDeployUrl)

{

string version = "";

XmlDocument xmlDoc = new XmlDocument();

Uri site = new Uri(strDeployUrl);

try

{

HttpWebRequest wReq = (HttpWebRequest)WebRequest.Create(site);

wReq.ReadWriteTimeout = 1000;

wReq.UserAgent = ".NET FrameworkExample Client";

HttpWebResponse wResp = (HttpWebResponse)wReq.GetResponse();

Stream respStream = wResp.GetResponseStream();

StreamReader reader = new StreamReader(respStream, Encoding.Default);

String respHTML = reader.ReadToEnd();

reader.Close();

wResp.Close();

xmlDoc.LoadXml(respHTML);

version = xmlDoc.ChildNodes[1].FirstChild.Attributes["version"].Value;

xmlDoc = null;

}

catch (Exception)

{

version = "";

}

return version;

}

콘솔에서 Applciaton이 호출 될시에 강제로 버전 검사를 수행합니다.

private void Window_Loaded(object sender, RoutedEventArgs e)

{

string DeployUrl = "http://127.0.0.1/ClickOnceApplicationTest/ClickOnceApplicationTest.application";

string CurrentVersion = GetCurrentVersion(DeployUrl);

if(Versionheck())

{

… 업데이트 처리

}

클릭원스가 가지는 매력적이고 강력한 기능들(Full Trust Aplication Deploy, 병합모듈 체크 및 배포, 손쉬운 작업 등...)은 클릭원스를 사용할수 밖에 없게 만들지만 특수한 경우에 대해서는 유연하지 못한 대처는 우리를 절망하게 합니다.

그렇지만 사용할수 밖에 없는 클릭원스.... 애증의 클릭원스.....

tag : C#, 배포, Click Once Get Current Version Info

Int32.Parse(), Convert.ToInt32(), Int32.TryParse() 비교

2009-01-08T17:14:10Z

Int32.Parse(string), Convert.ToInt32(string), Int32.TryParse(string, out result) 의 비교

문득 string을 Integer type으로 변환을 하다 Convert를 쓸까? Parse를 쓸까? 고민하는 자신을 발견했습니다.

대부분의 경우는 아래 처럼 utillity에 static 함수를 만들어 놓고 사용합니다만 참조를 걸어야만 사용이 가능할 경우 참조를 걸까? 말까? 고민하게 됩니다.

public static int ToInt(string str, int def)
{
    try
    {
    return int.Parse(str);
    }
    catch
    {
      return def;
    }
}

대표적인 형변환함수를 비교해 보았습니다.

참고로 Int32 값 형식은 값이 음수 2,147,483,648에서 양수 2,147,483,647 사이인 부호 있는 정수를 나타냅니다.

약 21억정도입니다. ^^

Int32.Parse(item)

Int32.Parse(12345) : SUCCESS : 12345

Int32.Parse() : FAIL System.FormatException 입력 문자열의 형식이 잘못되었습니다.

Int32.Parse(null) : FAIL System.ArgumentNullException 값은 null일 수 없습니다.

Int32.Parse(1234567890123456789012345678901234567890) : FAIL System.OverflowException 값이 너무 크거나 작아 Int32 형식에 맞지 않습니다.

Int32.Parse(ABCDEFG) : FAIL System.FormatException 입력 문자열의 형식이 잘못되었습니다.

Int32.Parse( -12345 ) : SUCCESS : -12345

Convert.ToInt32(item)

Convert.ToInt32(12345) : SUCCESS : 12345

Convert.ToInt32() : FAIL System.FormatException 입력 문자열의 형식이 잘못되었습니다.

Convert.ToInt32(null) : SUCCESS : 0

Convert.ToInt32(1234567890123456789012345678901234567890) : FAIL System.OverflowException 값이 너무 크거나 작아 Int32 형식에 맞지 않습니다.

Convert.ToInt32(ABCDEFG) : FAIL System.FormatException 입력 문자열의 형식이 잘못되었습니다.

Convert.ToInt32( -12345 ) : SUCCESS : -12345

Convert는 System.ArgumentNullException을 걸러내는게 이체롭습니다.

Int32.TryParse(item, out result)

Int32.TryParse(12345, out result) : SUCCESS : 12345

Int32.TryParse(, out result) : SUCCESS : 0

Int32.TryParse(null, out result) : SUCCESS : 0

Int32.TryParse(1234567890123456789012345678901234567890, out result) : SUCCESS : 0

Int32.TryParse(ABCDEFG, out result) : SUCCESS : 0

Int32.TryParse( -12345 , out result) : SUCCESS : -12345

세가지 함수 전부 공백을 알아서 제거해주는 기특함을 보였습니다. 참장합니다.

Int32.TryParse(item, out result)는 모든 경우 Exception을 발생시키지 않습니다.

리턴값으로 실패 성공을 알려주고 디폴트 값으로 넘겨주기까지 합니다.

굳이 utillity에 static 함수를 만들어 쓰지 않아도 될만하지만 리턴값으로 성공여부인 bool값을 넘기므로 정밀하다 칭찬할만 하지만 한줄로 끝날일을 두세줄 쓰기가 여간 번거로운게 아닙니다.

tag : Int32.Parse(string), Convert.ToInt32(string), Int32.TryParse(string out result), 형변환

WPF에서의 KeyBoard Input의 처리

2008-12-16T15:22:15Z

WPF에서의 KeyBoard Input의 처리

대부분의 경우 Key input의 처리는 private void control_KeyDown(object sender, KeyEventArgs e) 이벤트에서 처리를 합니다.

일반적인 경우 KeyEventArgs e 의 e.Key 값을 System.Windows.Input.Key 값과 비교 하여 처리 합니다.

동시에 눌러진 키를 체크하기 위해서는 Keyboard.Modifiers 값을 체크하여 처리합니다.

Control + V 키를 눌렀을 경우 private void control_KeyDown(object sender, KeyEventArgs e) 이벤트 핸들러에서 e.Key 값은 Key.V 가 되고 Keyboard.Modifiers는 ModifierKeys.Control이 됩니다.

한글 입력의 경우는 어떻까요?

Ascii 코드를 입력 받을 경우 KeyDown 이벤트에서는 체크가 되지 않습니다.

KeyUp 도 마찬가지로 체크가 되지 않습니다.

다만 private void inkCanvas_PreviewKeyDown(object sender, KeyEventArgs e) 에서는 Ascii 코드를 키입력을 감지 합니다.

아래와 같이 KeyEventArgs의 ImeProcessed를 체크하여 한글키 입력일경우 ImeProcessedKey값으로 입력 키값을 체크할수 있습니다.

private void inkCanvas_PreviewKeyDown(object sender, KeyEventArgs e)

{

Key inputKey = e.Key.Equals(Key.ImeProcessed) ? e.ImeProcessedKey : e.Key;

}

tag : WPF, PreviewKeyDown, ImeProcessed, ImeProcessedKey, Keyboard.Modifiers, KeyBoard Input, KeyDown

ImageBrush를 통한 BackGround의처리

2008-11-04T10:52:34Z

객체의 BackGround를 Image로 처리하고 싶을 경우가 있습니다.

대부분의 객체에서 Background는 기본이 Brush이며 특별히 이미지를 빈번히 사용하는 컨트롤(ComboBox, Label, ListBox, RichTextBox, Splitter, StatusBar, TabControl, ToolStrip, TreeView …)들은 BackgroundImage 속성을 가지고 있습니다.

의외로 Layout과 관련된 컨트롤들은 BackgroundImage 속성을 가지지 않는 경우가 많습니다.

Brush로 표현되는 BackGround를 그림으로 대체할 수는 없을까요?

ImageBrush는 이런 질문에 해답을 제시합니다.

ImageBrush myBackGroundImage = new ImageBrush();

Uri imageUri = new Uri(@"C:\temp\test.png");

BitmapImage myBitmapImage = new BitmapImage(imageUri);

myBackGroundImage.ImageSource = myBitmapImage;

myBackGroundImage.Stretch = Stretch.Fill;

myGrid.Background = myBackGroundImage;

tag : WPF, Background, BackgroundImage, ImageBrush

WMI .NET 기술 요약

2008-10-28T10:05:41Z

WMI .NET 기술 요약

WMI(Windows Management Instrumentation)는 응용 프로그램, 서비스 및 기타 컴퓨터 구성 요소에 대한 관리 정보(예: 구성 설정 및 속성 값)에 프로그래밍 방식으로 액세스할 수 있도록 하는 Windows 운영 체제의 구성 요소입니다.

.NET Framework의 WMI는 원래의 WMI 기술 위에 구축되어 있으며 .NET Framework의 프로그래밍 장점을 활용하여 동일한 응용 프로그램 및 공급자를 개발할 수 있도록 합니다.

자세한 내용은 .NET Framework의 WMI 장점을 참조하십시오.

WMI를 사용하는 .NET Framework 클래스는 System.Management 및 System.Management.Instrumentation 네임스페이스에 포함되어 있습니다.

그러나 .NET Framework를 기반으로 한 관리 코드 응용 프로그램은 원래 WMI 공급자 및 응용 프로그램과는 달리 몇 가지 제한 사항을 갖습니다.

자세한 내용은 .NET Framework의 WMI 제한 사항을 참조하십시오.

키워드

한정자, 공급자, WMI 쿼리 언어, 이벤트 소비자, Common Information Model, 비동기적, 일부 동기적, Win32 스키마, 관리 응용 프로그램

네임스페이스

System.Management, System.Management.Instrumentation

관련 기술

WMI(Windows Management Instrumentation)

.NET Framework의 WMI는 원래 WMI 기술을 기반으로 합니다. 원래 WMI에 대한 자세한 내용은 MSDN Library의 WMI(Windows Management Instrumentation) 설명서에서 "About WMI"를 참조하십시오.

배경

관리되지 않는 WMI 버전은 Microsoft에서 구현한 WBEM(Web-Based Enterprise Management)으로, 엔터프라이즈 컴퓨팅 환경을 관리하기 위한 기술을 표준화하기 위해 개발된 업계 이니셔티브입니다. WMI는 CIM(Common Information Model) 업계 표준에 기반한 클래스를 사용하여 시스템, 프로세스, 네트워크, 장치 및 기타 컴퓨터 구성 요소를 나타냅니다.

WMI는 스크립팅 언어 C#, VB .NET 또는 C++로 작성한 스크립트나 응용 프로그램으로 응용 프로그램, 시스템 또는 네트워크 구성 요소, 컴퓨터 하드웨어를 모니터링하고 구성할 수 있도록 하는 미리 설치된 클래스 스키마를 제공합니다.

예를 들어, Win32_Process 클래스의 인스턴스는 컴퓨터의 모든 프로세스를 나타내며 Win32_LogicalDisk 클래스는 모든 디스크 장치를 나타낼 수 있습니다. 사용 가능한 WMI 클래스에 대한 자세한 내용은 MSDN Library의 WMI(Windows Management Instrumentation) 설명서에서 "Win32 Classes"를 참조하십시오.

WMI 아키텍처는 다음 계층으로 구성되어 있습니다.

클라이언트 소프트웨어 구성 요소는 WMI를 사용하여 관리 세부 정보 읽기, 시스템 구성 및 이벤트 알림 신청과 같은 작업을 수행합니다.

개체 관리자는 WMI 공급자와 클라이언트 간 broker로, 표준 이벤트 게시 및 알림 신청, 이벤트 필터링, 쿼리 엔진 및 기타 서비스와 같은 일부 핵심 서비스를 제공합니다.

공급자 소프트웨어 구성 요소는 라이브 데이터를 캡처하여 클라이언트 응용 프로그램으로 반환하고, 클라이언트의 메서드 호출을 처리하고, 클라이언트를 관리되는 시스템 구성 요소에 연결합니다.

WMI 아키텍처에 대한 자세한 배경 정보는 WMI .NET 아키텍처 및 WMI 및 .NET Framework 스키마를 참조하십시오.

WMI 클래스 사용

WMI는 해당 클래스를 WMI 네임스페이스로 구성합니다. root\cimv2 및 root\default와 같은 WMI 네임스페이스는 System.Management 및 System.Management.Instrumentation와 같은 .NET Framework 네임스페이스와 혼동하지 않아야 합니다.

System.Management 네임스페이스에는 WMI 작업을 수행하기 위한 .NET Framework 클래스가 포함되어 있습니다. System.Management.Instrumentation 네임스페이스에는 응용 프로그램에 WMI 공급자를 추가하기 위한 클래스가 포함되어 있습니다.

관리자와 IT 개발자는 System.Management의 클래스를 사용하여 WMI 데이터에 액세스하는 응용 프로그램을 ASP.NET, C#, Visual Basic .NET 또는 J#과 같은 .NET 언어로 작성할 수 있습니다. 이러한 응용 프로그램은 다음을 수행할 수 있습니다.

네트워크의 모든 컴퓨터에서 모든 Win32_LogicalDisk 인스턴스의 FreeSpace 속성과 같은 WMI 클래스 속성 값 컬렉션을 열거하거나 검색합니다.

WMI는 SQL의 하위 집합인 원래 WMI WQL 쿼리 언어를 사용하여 클래스 속성 값을 쿼리합니다. WQL에 대한 자세한 내용은 MSDN Library의 WMI(Windows Management Instrumentation) 설명서에서 "WQL query language"를 참조하십시오.

WMI 클래스 메서드를 호출하여 관리 관련 작업을 수행합니다. 예를 들어, 클라이언트는 Win32_Service 클래스의 StartService 메서드를 호출하여 서비스를 시작할 수 있습니다.

이벤트 클래스 인스턴스로 정의된 이벤트에 대해 알림을 신청합니다.

계측 응용 프로그램(공급자)이 이벤트 클래스 중 하나의 인스턴스를 만들 때 이벤트가 발생합니다.

개발자는 또한 WMI를 사용하여 응용 프로그램을 관리 및 모니터링할 수 있도록 응용 프로그램 또는 시스템 구성 요소에 대한 속성 및 메서드를 노출하는 WMI 공급자를 만들 수도 있습니다. WMI 공급자를 만들려면 WMI 공급자 확장을 사용하십시오.

공급자 생성 중에는 응용 프로그램에 대한 데이터를 저장하고 해당 데이터를 WMI에 노출하는 속성 및 메서드로 자체의 클래스 및 인스턴스를 만드는 과정이 포함됩니다.

클래스에 대해 특정 특성을 설정하여 WMI 클래스에 지정할 수 있습니다. 예를 들어, 응용 프로그램이 상태 및 성능 또는 리소스 사용에 대한 데이터를 노출할 수 있습니다.

또한 응용 프로그램은 상호 작용하는 장치에 대한 데이터를 WMI에 제공할 수도 있습니다. 클래스를 만든 후 WMI에 등록하여 해당 데이터를 다른 스크립트 및 응용 프로그램에서 사용하도록 할 수 있습니다.

.NET Framework의 WMI 기능은 Microsoft Visual Studio .NET 개발 환경에 기본 제공된 WMI 도구 집합에서 사용할 수 있습니다. 예를 들어, Visual Studio .NET 서버 탐색기 관리 확장(http://go.microsoft.com/fwlink/?LinkId=98239&clcid=0x409에서 다운로드)을 사용하여 관리 인식 응용 프로그램의 개발을 지원할 수 있습니다.

WMI .NET 클래스 개요

다음 표에서는 지정한 각 작업 영역에 사용해야 하는 주 클래스에 대해 보여 줍니다.

또한 관련된 해당 인터페이스 및 구성 요소도 보여 줍니다.

이 표는 각 네임스페이스에 있는 모든 클래스를 포함하는 포괄적인 목록이 아니라 사용 방법 항목에서 설명한 모든 클래스를 포함합니다.

System.Management 네임스페이스

기술 영역	클래스/인터페이스/구성 요소
WMI 클래스 정보 수집	ManagementObject, ManagementClass
데이터 쿼리 비동기적으로 데이터 쿼리	SelectQuery, ManagementObjectSearcher, WqlObjectQuery, ObjectQuery ManagementObjectCollection, ManagementOperationObserver
메서드 실행 비동기적으로 메서드 실행	ManagementBaseObject ManagementOperationObserver
이벤트 수신 비동기적으로 이벤트 수신	WqlEventQuery, ManagementEventWatcher EventArrivedEventArgs, EventArrivedEventHandler, CompletedEventArgs, CompletedEventHandler
원격 컴퓨터에 연결	ConnectionOptions, ManagementScope

System.Management.Instrumentation 네임스페이스

기술 영역	클래스/인터페이스/구성 요소
데이터 공급자 만들기	Instance, InstrumentationClassAttribute, InstrumentedAttribute
이벤트 공급자 만들기	BaseEvent, Instrumentation
공급자 등록	ManagementInstaller

tag : wmi, WMI .NET

응용 프로그램 환경에서 Google API를 사용한 날씨정보 처리

2008-10-09T17:00:52Z

개발중인 Application의 Main화면에 Display 할 날씨정보를 처리하기 위해 Open API 뒤지다 구글의 날씨 정보 API를 찾게 되었습니다.

한글로 서비스 되며 일일 트래픽에 제한이 없는 게다가 특별한 가입절차도 필요 없습니다. 브라보~~

http://www.google.co.kr/ig/api?weather=seoul

<xml_api_reply version="1">

<forecast_information>

<postal_code data="seoul" />

<latitude_e6 data="" />

<longitude_e6 data="" />

<forecast_date data="2008-10-09" />

<current_date_time data="2008-10-09 06:00:00 +0000" />

<unit_system data="SI" />

forecast_information>

<current_conditions>

<temp_f data="75" />

<temp_c data="24" />

<wind_condition data="바람: 남풍, 6 km/h" />

current_conditions>

<forecast_conditions>

<day_of_week data="오늘" />

forecast_conditions>

<forecast_conditions>

<day_of_week data="금" />

forecast_conditions>

<forecast_conditions>

<day_of_week data="토" />

forecast_conditions>

<forecast_conditions>

<day_of_week data="일" />

forecast_conditions>

weather>

xml_api_reply>

위 XML의 내용을 보시면 아시겠지만 리턴하는 정보는 크게 자세한 오늘의 날씨와 4일간의 기본날씨정보를 리턴합니다.

기왕이면 여러날의 데이터를 읽어와서 표현하는것이 좋을것 같습니다.

WeatherInfo 라는 Data class를 정의 하고 아래와 같이 APP에서 날씨정보를 읽어오는 메서드를 코딩합니다.

public class WeatherInfo

{

public string imageUrl;

public string condition;

public string low;

public string heigh;

public string dayOfWeek;

public WeatherInfo(string dayOfWeek_in, string imageUrl_in, string condition_in, string low_in, string heigh_in)

{

dayOfWeek = dayOfWeek_in;

imageUrl = imageUrl_in;

condition = condition_in;

low = low_in;

heigh = heigh_in;

}

입력값은 조회될 URL을 받습니다.

private List<WeatherInfo> GetWeatherData(string strCityUrl)

{

XmlDocument xmlDoc = new XmlDocument();

Uri site = new Uri(strCityUrl);

HttpWebRequest wReq = (HttpWebRequest)WebRequest.Create(site);

wReq.UserAgent = ".NET Framework Client"; //Agent를 설정

HttpWebResponse wResp = (HttpWebResponse)wReq.GetResponse();

//인코딩 처리를 위해 Response에서 스트립을 얻어 리더에 넣습니다.

//StreamReader는 생성시 인코딩 값을 지정가능합니다.

Stream respStream = wResp.GetResponseStream();

StreamReader reader = new StreamReader(respStream, Encoding.Default);

//스트림 리더를 전부 읽어 스트링으로 뺍니다.

String respHTML = reader.ReadToEnd();

reader.Close();

wResp.Close();

//스트림에서 생성된 스트링으로 부터 XmlDocument를 생성합니다.

//간단히xmlDoc.Load()함수로 URL이나 스트림에서 바로 XmlDocument를 생성할수 있으나 WEb App가 아닌 응용프로그램에서는 인코딩으로 인해 에러가 발생하는 경우가 빈번합니다. 특히나 현재 사용하는 API는 보편적인(UTF-8)인코딩이 아닌 EUC_KR로 인코딩된 XML을 리턴합니다.

xmlDoc.LoadXml(respHTML);

List<WeatherInfo> list = new List<WeatherInfo>();

//제네릭을 사용 원하는 노드들을 읽어 저장합니다.

XmlNodeList xmlNodeList = xmlDoc.SelectNodes("xml_api_reply/weather/forecast_conditions");

foreach (XmlNode xmlNode in xmlNodeList)

{

string dayOfWeek_in = xmlNode.SelectSingleNode("day_of_week").Attributes["data"].Value;

string imageUrl_in = GoogleUrl + xmlNode.SelectSingleNode("icon").Attributes["data"].Value;

string condition_in = xmlNode.SelectSingleNode("condition").Attributes["data"].Value;

string low_in = xmlNode.SelectSingleNode("low").Attributes["data"].Value;

string heigh_in = xmlNode.SelectSingleNode("high").Attributes["data"].Value;

list.Add(new WeatherInfo(dayOfWeek_in, imageUrl_in, condition_in, low_in, heigh_in));

}

return list;

}

마지막으로 가장 중요한 인증 처리가 남았습니다.

확인해본결과 구글에서 서비스 되는 날씨아이콘파일은 SSL을 사용하여 서비스되도록 고쳐져 있었습니다. 따라서 기본 인증모드로는 파일에 access하는것이 불가했습니다.

WEB응용 프로그램이였다면 사용자는 IE가 표시하는 SSL표시 선택창에 YES를 하겠지만 응용프로그램의 Process에서 작성된 Request는 SSL인증서의 Trust처리를 코딩해 주어야 합니다.

System.Net NameSpace의 ServiePointManager는 ServerCertificateValidationCallback을 통해 Process에서 작성된 WebRequest의 SSL Trust를 처리합니다.

//ServicePointManager.CertificatePolicy = new CertPolicy(); 작동은 하지만 MSDN에 더이상 사용하지 않는 속성이라고 표시됨

//폼 로딩시에 한번 수행

TrustAllCert ValCallback = new TrustAllCert();

ServicePointManager.ServerCertificateValidationCallback = new System.Net.Security.RemoteCertificateValidationCallback(ValCallback.OnValidationCallback);

//Trust처리 CallBack 함수 구현

public class TrustAllCert {

public TrustAllCert() { }

public bool OnValidationCallback(object sender, X509Certificate cert, X509Chain chain, SslPolicyErrors errors)

{

return true;

}

아래는 작성된 예제 화면입니다.

* 구글 날씨 API는 서비스되는 도시가 제한적입니다.

     경주
     구미
     군산
     대구
     대전
     부천
     부산
     서울
     안양
     울산
     인천
     전주
     제주
     진주
     청주
     춘천
     포항

tag : C#, SSL, Trust, 구글 API, webRequest

사용자 정의 Attribute의 사용

2008-09-02T20:38:48Z

Help System을 구축하기 위한 사용자 정의 Attribute의 사용

로드된 인스턴스의 정보에 따라 여러가지 다양한 반응을 할수 있는 구조를 설계한다면 사용자 정의 어트리뷰트는 고려할만한 선택중 하나입니다.

자기 설명 메타데이터, 즉 어트리뷰트는 코드안에 관리되기 때문에 해독이 용이하며 부가적인 기능확장으로 인해 발생할수 있는 구조적 위험으로 부터 안전하게 코드를 구합니다.

아래 클래스는 클라이언트 프로그램에서 현재 포커싱된 윈도우에 해당하는 도움말을 디스플레이 하기 위한 사용자 어트리뷰트입니다.

먼저 어트리뷰트 클래스로 부터 상속을 받아 사용자 클래스를 하나 생성합니다.

using System;

namespace core

{

[AttributeUsage(AttributeTargets.Class, AllowMultiple=false, Inherited=false)]

public class HelpAttribute : Attribute

{

public HelpAttribute(string Description_in)

{

this.description = Description_in;

}

protected string description;

public string Description

{

get

{

return this.description;

}

[AttributeUsage(AttributeTargets.Class, AllowMultiple=false, Inherited=false)]

어트리 뷰트는 클래스 단에서만 사용되고 중복설정이 안되며 상속되지 않도록 설정했습니다.

다음은 테스트로 만든 윈도우 입니다.

사용자 정의 어트리뷰트를 선언하고 구동후 자신의 어트리 뷰트를 디스플레이 합니다.

namespace Test

{

[HelpAttribute("Attribute Checking Test")]

public partial class Window1 : Window

{

public Window1()

{

InitializeComponent();

System.Type type = this.GetType();

foreach (HelpAttribute helpAttribute in type.GetCustomAttributes(false))

{

MessageBox.Show("helpAttribute.Description: " + helpAttribute.Description);

// do something ....

}

리플랙션으로 로드된 인스턴스에서 어트리뷰트 정보를 읽어 처리합니다.

tag : 사용자 정의, attribute, 어트리뷰트

Assert를 통한 코드 디버깅

2008-08-29T10:36:36Z

프로그램 개발시 validation check나 try catch문들을 비웃는 에러들은 개발자들이 피해갈수 없는 숙명같습니다.

에러와 오류코드에 대한 이러한 문제들을 효과적으로 해결하고자 개발시 Test 모듈을 병행하여 개발하는 Test dreven 방식이 대두되기도 했습니다.

이러한 개발방식은 프로젝트 개발주기에서 효율적일수 있겠지만 막상 수많은 요구분석서 안에 파묻혀 사는 개발자로서는 여간 부담이 아닌것도 사실입니다.

Assertion은 코드 개발시 코드를 검사하는데 필수적인 요소이며 개발이 끝난후 코드를 접하는 유지보수자에게도 코드 해독의 방향성을 제시하므로 꼭 사용해야 하는 요소라고 생각됩니다.

Assertion을 사용하여 코드 디버깅을 처리 할때의 규칙은 아래와 같습니다.

1. 한번에 한 항목에 대해서만 Assert를 시행한다.

2. Assert를 수행해야 하는 첫번째 항목은 메서드의 매개변수이다.

3. Assert를 수행해야 하는 두번째 항목은 메서드의 리턴값이다.

4. 절대 에러처리를 대신해서는 안된다.

using System.Diagnostics;

....

Debug.Assert(UserInput > 0);

Debug.Assert(UserInput > 0, "UserInput > 0" );

Debug.Assert(UserInput > 0, "UserInput > 0", UserInput.ToString());

....

Debug.Assert(UserInput > 0);

Debug.Assert(UserInput > 0, "UserInput > 0" );

Debug.Assert(UserInput > 0, "UserInput > 0", UserInput.ToString());

tag : c#, Assert, Debug

WPF에서의 Window상속 처리

2008-08-28T20:54:51Z

WPF에서의 상속

조금 규모가 있는 프로젝트에서는 일반적으로 베이스 레이아웃을 가진 몇 가지 부모폼을 만들고 프로젝트내의 폼들은 부모폼에서 상속을 받아 작성하도록 처리합니다.

이런 방법을 사용하는 이유는 두가지 정도 이유가 있는데... 첫째로 반복 작성되는 코드들을 줄일수 있습니다.

기본 권한처리 같이 모든폼에 동일하게 적용되는 코드들을 부모폼에서 처리해 준다면 매번 새폼을 추가할 때 마다 처리해야 하는 기본 코드의 양이 줄것이고 그에 따라 에러도 줄것입니다.

두번째는 확장성을 위한 처리입니다.

첫번째와 비슷한 이유에서 많은 폼들에 한꺼번에 적용해야 하는 코드가 있다면 베이스폼을 수정함으로써 빠르게 전파가 가능합니다. 특히나 부모폼과 자식폼을 다른 dll로 분리한다면 자식폼들의 컴파일 없이도 각폼들에게 동일한 작업을 처리하게 수정이 가능한 장점이 있습니다. 우선 부모폼을 위한 프로젝트를 하나 만듭니다.

지금까지 알아본 바(?)에 의하면 디자인(xaml)에 대한 상속의 처리는 지원되지 않고 상속될 베이스 폼은 클래스 라이브러리로 작성하여 처리하는 방식으로 상속이 가능합니다.

namespace WpfInheritTest

{

public class WindowBase : System.Windows.Window

{

public WindowBase()

{…}

}

윈도우를 상속받은 WindowBase 클래스를 하나 만들었습니다.

다음으로 상속받을 자식이 위치할 프로젝트를 하나 만들고 폼을 하나 생성합니다.

<Window x:Class="WpfInheritTarget.Window1"

xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

Title="Window1" Height="300" Width="300">

<Grid>

Grid>

Window>

참조에서 부모폼이 있는 프로젝트를 참조로 걸고 Xaml 코드에서 상속을 위한 처리를 합니다.

<src:WindowBase x:Class="WpfInheritTarget.Window1"

xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

xmlns:src="clr-namespace:WpfInheritTest;assembly=WpfInheritTest"

Title="WindowsApplication1" Height="300" Width="300">

src:WindowBase>

비하인드 코드는 아래와 같이 수정됩니다.

namespace WpfInheritTarget

{

///

/// Interaction logic for Window1.xaml

///

public partial class Window1 : WpfInheritTest.WindowBase

{

public Window1()

{ }

}

부모폼의 생성자에 코드를 넣어서 자식폼에서 실행되는지를 확인합니다.

public class WindowBase : System.Windows.Window

{

public WindowBase()

{

MessageBox.Show("public class WindowBase : System.Windows.Window");

}

부모폼의 디자인 요소에 대한 처리 부분은 테스트 중에 있습니다만… 부모폼의 UIElement 요소는 상속된 폼의 레이아웃 컨트롤이 존재할 경우 표시되지 않았습니다.

디자인적인 처리는 무리일까요?

Xaml코드가 마크업 언어이므로 어느 정도 웹 언어의 처리방법을 생각해 볼 수 있을 것 같습니다.

Asp의 태그 라든지 이런 요소들은 상속이 아니라 첨가의 방식으로 처리됩니다.

따라서 공통적인 코드에 대한 처리부분은 사용자 컨트롤로 만들어 상속으로 처리할 폼에 첨가 시키고 그 사용자 컨트롤을 다른 프로젝트에서 만들어 처리한다면 디자인적인 처리를 어느 정도 커버해줄 수 있을 것 같기도 합니다.

물론 상속과 사용자 컨트롤을 다 같이 사용해야 할 경우도 필요합니다.

tag : 상속, C#, WPF, Xaml