스스로 체험하기도 했고, 주변을 보기도 했지만, 보통 Burn-out라는 것은 자신이 허용하는 그 이상의 업무나 작업을 하다가 완료를 짓기는 했는데, 그 뒤에 오는 공황과 같은 상황을 의미하는 것으로 안다.

현재 내 상태는 Burn-out.은 아니다. 한 2018년 말? 아니, 2019년 초에 있었던 프로젝트 중간 완료 때 진짜 오긴 했다. 만사가 귀찮았고, 누구도 만나고 싶지 않았으며, 어떤한 일에도 자극이 안되었다. 더욱이 당뇨라는 실질적인 장애가 오니 그 정도는 더 심했다. 나날히 시간이 지나면서 이런 점은 조금씩 사라지고, 몇몇 가지 하기 싫은 일도 스스로 할 정도로 변해왔다.

그런데 조금 이상한 것은 극복이라기 보다, 만성질환 처럼 계속 끌고가는 모양새 같다. 무기력까지는 아닌데, 굳이 앞에 서고 싶어하지 않고, 누구도 만나지 않으려 하고 있지 않지만, 새로운 만남은 최대한 안하고 싶어하고, 굳이 받을 필요가 없다고 판단된 전화는 아예 무시한다. 무슨 일에도 자극이 안되는 것은 아니지만, 갑자기 화가나기도 하고 갑자기 우울하기도 하다. 내 주변 물건 정리에 있어도 예전 같으면 1~2주 정도 주변 정리를 하거나 청소를 하는데, 지금은 1~2개월은 거뜬하게 지낸다. 정리를 안하니, 무슨 물건이 있는지 기억도 안난다. 치매의 초기 증상 처럼 단기 기억은 매우 안 좋아져서 코드 분석 중 내가 어디를 보고 있었는지 까먹을 정도다.

심리적 발란스가 엉망진창이 된듯.

결과적으로 나에게 ADHD(Attention deficit hyperactivity disorder) 아동 처럼 집중력이 매우 결여되어 업무를 제대로 수행하지 못하고 있다. 모든게 난색 상태. 도무지 환타지와 상상의 나래를 펼치다가 현실로 돌아오는게 매우 힘들어졌다. 당연히 해야 될 일들은 모조리 뒤로 미뤄지거나 수행 자체를 하지 않게 되는 경우도 있다.

Burn-Out 으로 보기 힘든, Burn-Out 상태.

무얼해도 만족하지 못하고, 그래놓고서는 원인 불명의 불만을 터트리고, 쓸데없는 게임이나 동영상에 온 시간을 낭비한다. 거기에 더해 그 활동 자체도 집중을 못해서 대충 몇번 하고 다른 것 하고 힜기도 하다.

작년부터 추수려야 된다, 추수려야 된다 라고 읇조리지만, 당최 실천을 할 의지를 보이고 있지 않다.

총체적 난국 상태다.

제작년 즈음...

Tistroy에서 자신들의 보호 차원에서 많은 부분에 대해 제약을 걸기 시작했는데, 맨 처음 하나는 blog meta 데이터를 이용한 Windows Live Writer 같은 블로그 포스트 프로그램을 사용하지 못하는 것이였고, 제일 중요한 이유 중 중 하나가 백업이다.

이 백업 부분은 나로써는 매우 민감한 부분이였는데, 내 Contents에 대한 보호를 어떻게 해야 할지 걱정이 될 수 밖에 없었다.

이런저런 고민 속에 있다가, Open Live Writer 라는 프로그램을 접하게 되었고, 이 프로그램이 Blogger와 직접적으로 연결해서 쓸 수 있다는 점에 한눈에 넘어가버리게 되었다.

맨 먼저 Tistory를 강제로 백업하는 도구인 Tistroy Saver를 알게되어, 일단 급한 대로 모든 포스트를 내려보았다.
모든 포스트를 내리고 보니, 각종 텍스트 파일과 이미지 파일이 떨어졌다. 그 백업 내용을 기반으로 하나씩 하나씩 Open Live Writer를 이용해 올려보았다. 그런데, 처음에 100개정도는 어떻게 해보겠는데, 나머지 1000여개 넘개는 도무지 할 여력이 안났다. 시일 차일 미루다, Google API를 이용해 올리는 도구를 만들어보았다.

그런데 이 방법에도 한계가 보였다. 하루에 100개 이상을 올리지 못했다. 더욱이 초기화 시간은 UTC 기준 00:00 이였다.몇일을 띄워서 해보긴 했는데, 이미지를 넣는 구조로 만들지 못해 이번엔 이미지를 담아보도록 했다. 근데, 내가 짠 프로그램에 문제가 있어 빈 포스트가 올라가게 되었고, 이 복구 작업을 위해 페이지 마다 태그를 달았다. 다시 올리려 했는데, 다시 100개 포스트 제한이 걸리는....

결국 포기했다.

그냥 기존 Blogger 쪽에 올린 포스트를 이 곳에도 올리면서 종료했다.

다행인지 모르겠지만, 기존 블로그 작성기와는 다른 깔끔한 구조의 도구를 제공하는 점은 마음에 들었다. 심지어 이 쪽에서 제공하는 API를 이용하면 블로그 작성기 정도는 쓸 수 있지 않을까 싶기도 했다.

어쨌든... 저  Tistory Saver를 이용해 종종 백업을 할까 고민 중이다.

다시 여기서 차근 차근 포스팅을 해볼 요량이다.

처음에는 Keeper를 쓰다가, 나중에 1password로 변경해서 사용했다.

그런데, 매년 45,000 원 상당을 지불하려다가 보니, 과연 내가 그정도의 보안이 필요한가라는 미묘한 현타가 오기 시작했다. 물론 중요는 하지만 그래도 45,000 원을 지불해 가면서 해야 할까 라는 생각이 들었다.

그러다가 여러가지 솔루션들을 보았는데 신박한 제품이 보였다.

Bitwarden(https://bitwarden.com/) 이라는 제품인데, 가장 매력적인게, Volt를 저장하기 위한 서버를 자기가 구성할 수 있다는 점이였다.

문제는 서버를 구축하기 위해서는 SSL 및 Docker 기반으로 구축해야하는데, Docker에 대한 이해가 부족한 상황이라..

나중에 여유가 되면 서버나 구축해서 집에다 이 저장소를 만들어 구성해봐야 겠다.

1password도 내년 3월까지는 사용할수 있으니까.. 당장은 1password로 유지해야 겠다.

2020. 4. 3. 오전 11:29

SyntaxHighlighter 3.0.83 (http://alexgorbatchev.com/SyntaxHighlighter/manual/configuration/) 의 설정 값 중, 블로그에서 사용되는 값들을 정리한다.

보통 pre 안에 class 값으로 brush:xxxxx 로 표시하는 내용들이다.

• C# 코드용  ['c#', 'c-sharp', 'csharp'];
• XML, HTML용  ['xml', 'xhtml', 'xslt', 'html'];
• 파워쉘 등 ['powershell', 'ps'];
• 일반 텍스트  ['text', 'plain'];
• C/C++ ['cpp', 'c'];
• Javascript ['js', 'jscript', 'javascript'];
• SQL  ['sql'];

만약 내용이 Javascript라면 아래와 같이 HTML 소스에 넣으면 된다.

<pre class=”brush:js”> 내용 …. </pre>

2020. 4. 2. 오후 3:34

.bat 혹은 .cmd 파일을 만들 때, 간혹 특수 문자가 포함되는 암호를 입력하게 할 때 그냥 그대로 입력하면 안될 때가 있다.

그 이유를 확인해본 결과 cmd.exe 내에서 특수 문자중 “%”와 “^” 때문이다.

%의 경우 간혹 환경변수 값 조회하는 구조와 유사할 경우 적용이 안되고, ^ 인 경우에는 아예 ESC 형태의 값이라고 파싱해서 발생되는 문제다.

%만 단독으로 쓰면 상관 없지만, %???% 로 쓰면 환경 변수로 치환된다. 
^인 경우에는 바로 뒤에 오는 글자가 ESC 로 전환되어 화면 표시 방법이 달라지게 된다.

이 경우 해결방법은 다음과 같다.

% –> ^%
^ –> ^^

위와 같이 변환을 하면 된다.

그러면 원하는 특수 문자가 화면에 제대로 표시된다.

2020. 4. 2. 오후 3:24

Original : https://www.freertos.org/FreeRTOS-Coding-Standard-and-Style-Guide.html

Kernel > About FreeRTOS Kernel > Coding, Testing, & Style

Coding Standard, Testing and Style Guide

On this page:

• Coding Standard
• Testing
• Naming Conventions
• Data Types
• Style Guide

Coding Standard / MISRA Compliance

The core FreeRTOS source files (those that are common to all ports, but not the port layer) conform to the MISRA coding standard guidelines. Compliance is checked using pc-lint with the linked lint configuration files. As the standard is many pages long, and is available for purchase from MISRA for a very small fee, we have not replicated all the rules here.

Deviations from the MISRA standard are listed below:

• Two API functions have more than one exit point. A deviation was permitted in these two cases for reasons of critical efficiency.
• When creating tasks, the source code manipulates memory addresses to locate the start and end addresses of the stack allocated to the created task. The code has to work for all the architectures to which FreeRTOS has been ported – which includes architectures with 8, 16, 20, 24 and 32-bit buses. This inevitably requires some pointer arithmetic. When pointer arithmetic is used, the arithmetic result is programatically checked for correctness.
• The trace macros are, by default, empty, so do not generate any code. Therefore, MISRA compliance checking is performed with dummy macro definitions.
• MISRA rules are turned off on a line by line basis, as deemed appropriate (that is, complying with the rule is deemed to create less appropriate code for a deaply embedded system than carefully not complying). Each such occurrence is accompanied by a justification using the special pc-lint MISRA comment mark-up syntax.

FreeRTOS builds with many different compilers, some of which are more advanced than others. For that reason FreeRTOS does not use any of the features or syntax that have been introduced to the C language by or since the C99 standard. The one exception to this is the use of the

stdint.h

header file. The

FreeRTOS/Source/include

directory contains a file called

stdint.readme

that can be renamed

stdint.h

to provide the minimum stdint type definitions necessary to build FreeRTOS – should your compiler not provide its own.

Testing

This section describes the tests performed on common code (the code located in the FreeRTOS/Source directory, that is built by all FreeRTOS kernel ports), and the tests performed on the portable layer code (the code located in subdirectories of the

FreeRTOS/Source/portable

directory).

• Common code

  The standard demo/test files attempt to provide ‘branch’ test coverage (in most cases this actually achieves ‘condition’ coverage because the kernel’s coding style deliberately keeps conditions simple specifically for this purpose), whereby tests ensure both ‘true’ and ‘false’ paths through each decision are exercised. ‘branch’ coverage is measured using GCOV by defining the mtCOVERAGE_TEST_MARKER() macro to a NOP (no operation) instruction in the ‘else’ path of each ‘if()’ condition if the ‘else’ path would otherwise be empty. mtCOVERAGE_TEST_MARKER() is only defined while measuring test coverage – normally it is an empty macro that does not generate any code.

• Port layer

  Port layer code is tested using ‘reg test’ tasks, and, for ports that support interrupt nesting, the ‘interrupt queue’ tasks.

  The ‘reg test’ tasks create multiple (normally two) tasks that first fill all the CPU registers with known values, then continuously check that every register maintains its expected known value as the other tests execute continuously (soak test). Each reg test task uses unique values.

  The ‘interrupt queue’ tasks perform tests on interrupts of different priorities that nest at least three deep. Macros are used to insert artificial delays into pertinent points within the code to ensure the desired test coverage is achieved.

It is worth noting that the thoroughness of these tests have been responsible for finding bugs in silicon on multiple occasions.

Naming Conventions

The RTOS kernel and demo application source code use the following conventions:

• Variables
  • Variables of type uint32_t are prefixed ul, where the ‘u’ denotes ‘unsigned’ and the ‘l’ denotes ‘long’.
  • Variables of type uint16_t are prefixed us, where the ‘u’ denotes ‘unsigned’ and the ‘s’ denotes ‘short’.
  • Variables of type uint8_t are prefixed uc, where the ‘u’ denotes ‘unsigned’ and the ‘c’ denotes ‘char’.
  • Variables of non stdint types are prefixed x. Examples include BaseType_t and TickType_t, which are portable layer defined typedefs for the natural or most efficient type for the architecture and the type used to hold the RTOS tick count respectively.
  • Unsigned variables of non stdint types have an additional prefix u. For example variables of type UBaseType_t (unsigned BaseType_t) are prefixed ux.
  • Variables of type size_t are also prefixed x.>
  • Enumerated variables are prefixed e
  • Pointers have an additional prefixed p, for example a pointer to a uint16_t will have prefix pus.
  • In line with MISRA guides, unqualified standard char types are only permitted to hold ASCII characters and are prefixed c.
  • In line with MISRA guides, variables of type char * are only permitted to hold pointers to ASCII strings and are prefixed pc.
• Functions
  • File scope static (private) functions are prefixed with prv.
  • API functions are prefixed with their return type, as per the convention defined for variables, with the addition of the prefix v for void.
  • API function names start with the name of the file in which they are defined. For example vTaskDelete is defined in tasks.c, and has a void return type.
• Macros
  • Macros are pre-fixed with the file in which they are defined. The pre-fix is lower case. For example, configUSE_PREEMPTION is defined in FreeRTOSConfig.h.
  • Other than the pre-fix, macros are written in all upper case, and use an underscore to separate words.

Data Types

Only stdint.h types and the RTOS’s own typedefs are used, with the following exceptions:

• char

  In line with MISRA guides, unqualified char types are permitted, but only when they are used to hold ASCII characters.

• char *

  In line with MISRA guides, unqualified character pointers are permitted, but only when they are used to point to ASCII strings. This removes the need to suppress benign compiler warnings when standard library functions that expect char * parameters are used, especially considering some compilers default unqualified char types to be signed while other compilers default unqualified char types to be unsigned.

There are four types that are defined for each port. These are:

• TickType_t

  If configUSE_16_BIT_TICKS is set to non-zero (true), then TickType_t is defined to be an unsigned 16-bit type. If configUSE_16_BIT_TICKS is set to zero (false), then TickType_t is defined to be an unsigned 32-bit type. See the customisation section of the API documentation for full information.

  32-bit architectures should always set configUSE_16_BIT_TICKS to 0.

   

• BaseType_t

  This is defined to be the most efficient, natural, type for the architecture. For example, on a 32-bit architecture BaseType_t will be defined to be a 32-bit type. On a 16-bit architecture BaseType_t will be defined to be a 16-bit type. If BaseType_t is define to char then particular care must be taken to ensure signed chars are used for function return values that can be negative to indicate an error.

• UBaseType_t

  This is an unsigned BaseType_t.

• StackType_t

  Defined to the type used by the architecture for items stored on the stack. Normally this would be a 16-bit type on 16-bit architectures and a 32-bit type on 32-bit architectures, although there are some exceptions. Used internally be FreeRTOS.

•  

Style Guide

• Indentation

  Tab characters are used to indent. One tab equals four spaces.

• Comments

  Comments never pass column 80, unless they follow, and describe, a parameter.

  C++ style double slash (//) comments are not used.

   

• Layout

  The FreeRTOS source code lay out is designed to be as easy to view and read as possible. The code snippets below show first the file layout, then the C code formatting.

  /* Library includes come first… */
  #include <stdlib.h>
  /* …followed by FreeRTOS includes… */
  #include “FreeRTOS.h”
  /* …followed by other includes. */
  #include “HardwareSpecifics.h”
  /* #defines comes next, bracketed where possible. */
  #define A_DEFINITION	( 1 )
  
  /*
   * Static (file private) function prototypes appear next, with comments
   * in this style – with each line starting with a ‘*’.
   */
  static void prvAFunction( uint32_t ulParameter );
  
  /* File scope variables are the last thing before the function definitions.
  Comments for variables are in this style (without each line starting with
  a ‘*’). */
  static BaseType_t xMyVariable.
  
  /* The following separate is used after the closing bracket of each function,
  with a blank line following before the start of the next function definition. */
  
  /*———————————————————–*/
  
  void vAFunction( void )
  {
      /* Function definition goes here – note the separator after the closing
      curly bracket. */
  }
  /*———————————————————–*/
  
  static UBaseType_t prvNextFunction( void )
  {
      /* Function definition goes here. */
  }
  /*———————————————————–*/
  
  File Layout

  
  
  

  /* Function names are always written on a single line, including the return
  type.  As always, there is no space before the opening parenthesis.  There
  is a space after an opening parenthesis.  There is a space before a closing
  parenthesis.  There is a space after each comma.  Parameters are given
  verbose, descriptive names (unlike this example!).  The opening and closing
  curly brackets appear on their own lines, lined up underneath each other. */
  void vAnExampleFunction( long lParameter1, unsigned short usParameter2 )
  {
  /* Variable declarations are not indented. */
  uint8_t ucByte;
  
      /* Code is indented.  Curly brackets are always on their own lines
      and lined up underneath each other. */
      for( ucByte = 0U; ucByte < fileBUFFER_LENGTH; ucByte++ )
      {
          /* Indent again. */
      }
  }
  
  /* For, while, do and if constructs follow a similar pattern.  There is no
  space before the opening parenthesis.  There is a space after an opening
  parenthesis.  There is a space before a closing parenthesis.  There is a
  space after each semicolon (if there are any).  There are spaces before and
  after each operator.  No reliance is placed on operator precedence –
  parenthesis are always used to make precedence explicit.  Magic numbers,
  other than zero, are always replaced with a constant or #defined constant.
  The opening and closing curly brackets appear on their own lines. */
  for( ucByte = 0U; ucByte < fileBUFFER_LENGTH; ucByte++ )
  {
  }
  
  while( ucByte < fileBUFFER_LENGTH )
  {
  }
  
  /*  There must be no reliance on operator precedence – every condition in a
  multi-condition decision must uniquely be bracketed, as must all
  sub-expressions. */
  if( ( ucByte < fileBUFFER_LENGTH ) && ( ucByte != 0U ) )
  {
      /* Example of no reliance on operator precedence! */
      ulResult = ( ( ulValue1 + ulValue2 ) – ulValue3 ) * ulValue4;
  }
  
  /* Conditional compilations are laid out and indented as per any
  other code. */
  #if( configUSE_TRACE_FACILITY == 1 )
  {
      /* Add a counter into the TCB for tracing only. */
      pxNewTCB->uxTCBNumber = uxTaskNumber;
  }
  #endif
  
  A space is placed after an opening square bracket, and before a closing
  square bracket. 
  ucBuffer[ 0 ] = 0U;
  ucBuffer[ fileBUFFER_LENGTH – 1U ] = 0U;
  
  Formatting of C Constructs

•  

2020. 3. 24. 오후 1:29

Original : https://www.freertos.org/RTOS.html

Kernel > About FreeRTOS Kernel

The FreeRTOS™ Kernel

마켓 리딩, 사실상 표준, 크로스 플랫폼 RTOS 커널

15년 넘게 세계 대표 칩 회사 간의 파트너쉽 속에서 개발된 FreeRTOS 는 마이크로 컨트롤로 및 작은 마이크로프로세서용 마켓 리딩하는 리얼타임 OS(RTOS)이다. MIT 오픈 소스 라이선스 하에서 자유롭게 배포된 FreeRTOS는 커널을 포함해 전방위적인 산업에 걸처 다양한 라이브러리가 만들어지고 확대 적용되고 있다.  하루 평균 500회 다운로드 되고 있는 FreeRTOS는 안정성, 접근성 및 사용 편의성을 기준으로 구성되었습니다. 

알고 있나요?

FreeRTOS 는 하루 평균 500회의 다운로드를 기록하고 있음 (2018년 기준).

FreeRTOS 는 2011동안모든 EETimes Embeded Market Suvey 내 교육 클래스 중 최고의 자리에 올랐읍니다.

FreeRTOS 는 타 상업용 RTOS에 비해 낮은 프로젝트 위험도 및 소유에 대한 전체 비용을 낮추는데 도움을 드립니다.그 이유는 다음과 같습니다.:

• 전체적인 지원 및 문서화가 되어 있습니다.
• 대부분은 우리와의 연락없이도 시장에 제품을 출시해도 됩니다. 다만, 완벽한 마음의 평화가 필요하시다면, 언제든지 완전 면책형 상업라이선스(직접적 지원을 포함)으로 전환할 수 있는 변경도 가능합니다.

일부 FreeRTOS ports never completely disable interrupts.

For strict quality control purposes, and to remove all IP ownership ambiguity, official FreeRTOS code is separated from community contributions.

FreeRTOS has a tick-less mode to directly support low power applications.

FreeRTOS is designed to be simple and easy to use: Only 3 source files that are common to all RTOS ports, and one microcontroller specific source file are required, and its API is designed to be simple and intuitive.

The RL78 port can create 13 tasks, 2 queues and 4 software timers in under 4K bytes of RAM!

Why choose FreeRTOS?

“It’s probably safe to say at this point that FreeRTOS goes through more ‘peer-review’ than any other RTOS available on the planet. I have used it in several projects – one of which was a multiprocessor environment that used more than 64 processors and needed to run for months reliably. The RTOS core performed well. Take FreeRTOS for a spin.” – John Westmoreland

FreeRTOS provides the best of all worlds: FreeRTOS is truly free and supported, even when used in commercial applications. The FreeRTOS open source MIT license does not require you to expose your proprietary IP. You can take a product to market using FreeRTOS without even talking to us, let alone paying any fees, and thousands of people do just that. If, at any time, you would like to receive additional backup, or if your legal team require additional written guarantees or indemnification, then there is a simple low cost commercial upgrade path. Your peace of mind comes with the knowledge that you can opt to take the commercial route at any time you choose.

Here are some reasons why FreeRTOS is a good choice for your next application – FreeRTOS…

• Provides a single and independent solution for many different architectures and development tools.
• Is known to be reliable. Confidence is assured by the activities undertaken by the SafeRTOS sister project.
• Is feature rich and still undergoing continuous active development.
• Has a minimal ROM, RAM and processing overhead. Typically an RTOS kernel binary image will be in the region of 6K to 12K bytes.
• Is very simple – the core of the RTOS kernel is contained in only 3 C files. The majority of the many files included in the .zip file download relate only to the numerous demonstration applications.
• Is truly free for use in commercial applications (see license conditions for details).
• Has commercial licensing, professional support and porting services available in the form of OPENRTOS from our partner WITTENSTEIN high integrity systems.
• Has a migration path to SafeRTOS, which includes certifications for the medical, automotive and industrial sectors.
• Is well established with a large and ever growing user base.
• Contains a pre-configured example for each port. No need to figure out how to setup a project – just download and compile!
• Has an excellent, monitored, and active free support forum.
• Has the assurance that commercial support is available should it be required.
• Provides ample documentation.
• Is very scalable, simple and easy to use.
• FreeRTOS offers a smaller and easier real time processing alternative for applications where eCOS, embedded Linux (or Real Time Linux) and even uCLinux won’t fit, are not appropriate, or are not available.

2020. 3. 24. 오후 1:22

log4net의 설정방법은 매우 다양하고 많다.

이중 가장 기본적인 설정 방법을 설명한다. nuget을 이용하여 개발하는 경우가 있는데, 이는 개발자가 모두 인터넷에 잘 연결된 사용자들이나 쓰는 방법이고, Offline 환경에서는 잘 맞지 않는다. 특히나 공동 작업일 때는 package 폴더도 공유해야 하는데, 이게 사이즈가…

여기서는 Assembly DLL 만 연결하는 방법으로 소개한다.

Assembly 폴더 만들고 log4net.dll 복사하기.

제일 먼저 하는 것은 Solution 폴더 위치에 Assembly라는 폴더를 만든다. 보통 Visual Studio를 써서 프로젝트를 만들면 Solution 폴더 하위에 Project 폴더들이 박히는데, 여러 개의 Project를 만든 후 모든 Project들이 log4net을 쓴다면, 이 방법이 제일 좋은 것 같다.

그 안에 log4net.dll 을 복사해서 넣는다.

Project 내 참조 추가.

Project 폴더 내에 있는 참조 위에서 참조추가를 시도한다.

참조 폴더에서 위에 넣었던 파일을 Browse로 찾아서 넣도록 한다. 만일 캐쉬로 있다고 해도 다른 위치의 파일일 수 있으니 반드시 직접 Browse 해서 찾아서 넣도록 한다. 그 이유는 여러개의 프로젝트 작업을 수행한 경우 파일 이름은 같을지 몰라도 전혀 다른 프로젝트의 DLL을 참조할 수 있다.

AssemblyInfo.cs 수정

Properties 폴더 안에 AssemblyInfo.cs 파일이 있는데 이 파일을 연다.

그 안에 여러가지 내용이 있지만, 맨 밑에다가 다음 한 줄을 추가한다.

[assembly: log4net.Config.XmlConfigurator(Watch = true)]

app.config 설정

이 부분은 내용이 참 많은데, 자세한 설명없이 단순하게 추가할 내용만 정리한다.

먼저 XML의 configuration 엘리멘트 안에 다음과 같은 섹션을 추가한다. 이전에 이미 만들어 넣었다면, section만 추가할 수도 있다. 이 항목이 들어가야 log4net 이라는 엘리멘트를 만들어 넣을 수 있다.

<configSections>
  <section name="log4net" type="System.Configuration.IgnoreSectionHandler"/>
</configSections>

section을 추가했다면 이제 아래 쪽에(보통은 appSettings 밑) 다음과 같은 항목을 추가한다.

<log4net>
  <appender name="Appender" type="log4net.Appender.RollingFileAppender">
    <file value="service.log"/>      
    <rollingStyle value="Date"/>      
    <datePattern value="_yyyyMMdd'.log'"/>
    <layout type="log4net.Layout.PatternLayout">
      <conversionPattern value="%date %-5level %logger - %message%newline"/>
    </layout>
    <lockingModel type="log4net.Appender.FileAppender+MinimalLock"/>
  </appender>    
  <root>
    <level value="ALL"/>
    <appender-ref ref="Appender"/>
  </root>
</log4net>

위와 같이 설정할 때, Appender 쪽만 잘 잡아주면 되는데, 파일 저장 위치나, 로그가 쌓일 때 텍스트 형식등을 정의할 수 있다. file과  conversionPatten 이라는 엘리멘트를 수정하면 된다.

log 개체 소스에 박기

실제 로그를 쌓기 위해 소스에 박기전에 각 소스 클래스 내 로그 관련 인스턴스를 생성한다. 그렇다고 매번 클래스 만들어질 때마다 만들 수 없으므로 1회안에 활성화 될 수 있도록 static 으로 구성한다.

모든 클래스 최 상단에 다음과 같은 코드를 담도록 한다.

private static readonly log4net.ILog log = log4net.LogManager.GetLogger(System.Reflection.MethodBase.GetCurrentMethod().DeclaringType);

위와 같이 넣으면 코드안에서 다음과 같이 코드를 작성할 수 있다.

log.Error("Service started");

정리하며

매번 코드 내에 적용하면서 다른 프로젝트 내의 코드를 복사해서 처리하는 것만 했지 별도로 정리한적이 없어서 정리해봤다.

나중에, 설정 관련된 특이하게 응용했던 것들도 정리해보려고 한다.

2020. 3. 11. 오전 9:41