Slow walking man

64bit 로 빌드된 윈도우 서비스 등록시 BadImageFormatException

윈도우 서비스 프로그램을 개발하고 윈도우 인스톨러를 추가하여 설치 패키지를 만들고 나서 실행하려고 하면 다음과 같이 BadImageFormatException이라는 에러가 발생하면서 윈도우 서비스가 등록 안되는 이슈가 발생했다.

BadImageoFormatException은 실행파일이 참조한는 파일이 다른 bit로 빌드된 경우 발생하는 에러라고 하는데, 이미 윈도우 인스톨러로 설치 하고자 하는 윈도우 서비스 프로젝트와 기타 프로그램 프로젝트들 모두 64bit로 빌드하기로 한 것은 확인 했고, 윈도우 인스톨러 또한 64bit를 target으로 빌드되도록 한 것도 확인 했기 때문에 당췌 어디서 에러가 발생했는지 감을 잡을 수 없었다.

하지만 세상에 착하면서도 똑똑한 프로그래머들이 많은지, 이미 이런 문제에 대한 원인과 해결책까지 스택오버플로우에 나와있었다.

(http://stackoverflow.com/questions/10275106/badimageformatexception-x64-issue)

결론부터 말하자면, 이 문제는 윈도우 인스톨러가 빌드된 윈도우 서비스 프로그램을 타겟 파일 시스템에 복사한 뒤 InstallUtill.exe라는 프로그램을 이용해서 서비스 등록을 시키는데, 이 InstallUtill.exe 파일이 참조하는 InstallUtillLib.dll의 bit가 윈도우 서비스의 타겟 비트와 달라서 발생하는 이슈라고 한다.

따라서 윈도우 인스톨러가 서비스 등록에 사용할 (정확히는 InstallUtill.exe가) InstallUtillLib.dll을 윈도우 서비스의 타겟 비트와 동일하게 선정해주면 된다.

C:\Windows\Microsoft.NET\Framework64\v4.0.30319 그리고

C:\Windows\Microsoft.NET\Framework\v4.0.30319 에는

각 bit에 맞는 64bit, 32bit 짜리 InstallUtill.exe와 InstallUtillLib.dll이 있다고 한다.

그런데 이 과정은 Visual Studio에서는 설정할 방법은 없고 Orca.exe라는 외부 프로그램을 사용해야 하는데 ( Visual Studio에서 설정할 수 있는지는 나중에 더 찾아 봐야 하겠지만..) 그 과정은 아래와 같다.

step1. Orca.exe를 설치한다.

C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin 에 있는 Orca.msi를 이용해서 설치한다. Next만 누르면 된다.

step2. Orca상에서빌드한 msi파일을 연다.

Orca.exe의 돌고래 아이콘이 앙증맞다.

step3. Tables에서 Binary탭을 클릭하여 오른쪽 창의 InstallUtill의 binary data부분을 더블클릭한다. "read binary from file name"을 클릭해 놓고 brows버튼을 눌러 원하는 비트의 InstallUtillLib.dll파일을 찾아 설정한 후 Orca.exe에서 msi파일을 저장하고 종료한다.

이렇게 하면, 정상적으로 윈도우 서비스가 윈도우 인스톨러를 가지고 등록되는 것을 볼 수 있었다. 세상엔 참 착하고 능력있는 프로그래머가 많다.

1. 공유설정 변경

네트워크 및 공유 센터를 열고 아래와 같이 고급 공유 설정 변경에 들어간다.

파일 공유를 위한 공유 폴더 설정을 위해서 아래와 같이 설정을 변경한다.

공용 폴더 공유를 사용함으로 변경한다.

그리고 암호로 보호된 공유를 사용함으로 해 놓으면 공용 리소스에 접근할 때 미리 지정해 놓은 윈도우 계정을 물어보게 된다.

요번 프로젝트에서는 보안성 때문에 공용폴더에 접근 권한을 설정하지 않을까 하여 미리 접근권한을 설정한 공용폴더를 사용하기 때문에 암호 보호 공유는 사용함으로 설정했다.

그리고 아무 폴더나 하나 만들고 속성-공유 창으로 들어간다.

고급 공유에 보면, 권한이 있는데 이 부분에서 공유폴더에 접속할 윈도우 계정을 설정한다.

Everyone을 사용이름에 넣어두면 아무나 암호 설정 없이 접근 할 수 있게 된다. (Everyone이 있으면 다른 계정이 포함되어 있는 것과 상관 없이 그냥 아무나 접속 할 수 있게 된다.)

 만일 윈도우 사용자 계정만 넣어두면 다른 컴퓨터에서 해당 공유폴더로 접속을 시도할 때, 아래와 같이  ExportSystemUser 계정의 암호와 아이디를 물어보는 창이 뜨게 된다.

Trouble Shooting 1. 가끔 공유사용자가 잘 변경이 안되어 Everyone이 계속 껴 있는 경우가 있는데, 이런 경우에는 고급 공유설정에서 공유 체크박스를 한번 지우고 확인을 눌러서 공유안됨 상태로 돌린다음에 다시 설정하면 정상적으로 공유 설정이 된다.

Trouble Shooting2. 윈도우에서 공유 폴더에 접속할 때, 아무 설정이 없는 경우 자동으로 Guest계정으로 접속을 시도한다고 한다. 그래서 공유 폴더 설정시 Guest 계정을 공유에 포함시키지 않는 경우, 혹은 Everyone이 없어서 아무나 접속이 불가능 한 경우 아래와 같이 접속 권한이 없다고 접속이 안되는 경우가 있다.

이런 경우는, 아래와 같이 CMD창에서 "net use" 명령어를 이용해 해당 연결에 대한 계정을 지우고 계정정보 유지 여부를 no로 설정해 주면 정상적으로 접속이 된다.

계정 유지 정보 유지 여부를 no로..

연결정보 조회 및 제거

참고로 윈도우 자격증명 관리자에 해당 공유폴더에 접속할 계정정보가 이미 입력되어 있는 경우에 이 window 계정으로 자동으로 접속을 시도하기 때문에 접속 로그인창을 보고 싶다면 "제어판-자격증명 관리자"에서 자격증명을 지워주면 된다.

공유 폴더 설정 끝!

GPS620은 NMEA 프로토콜을 따른다.

NMEA 0183 프로토콜은 The National Marine Electronics Association 에서 정한 지리 정보의 전송과 관련된 규약으로 물리, 데이터링크, 어플리케이션 레벨의 규약의 집합체다. 물리, 데이터 링크 계층의 규약은 일반적인 RS232 시리얼 통신을 따르기 때문에 본 블로그의 시리얼 통신 관련 포스트를 보면 될 것 같다. 

어플리케이션 레벨의 규약은 여러가지가 있는데 그 중에 알아야 할 사항은 사실 몇가지 되지 않는다.. $GPGGA, $GPMRC 등 여러가지 머릿말을 달고 GPS수신기로부터 시리얼 통신을 통해 컴퓨터로 수신되는 정보들이 있지만 실상 알아야 할 정보는 아래에 있는 $GPGGA정보면 충분하다. 실제 GPGGA 정보를 가지고 각 값들이 의미하는 바를 알아보도록 하겠다.

1.     전송 캐릭터 셋 : 시리얼 통신을 통해 전송되는 바이트 열은 모두 ASCII코드다.

2.     중요 정보 문자열 : $GPGGA, … <CR><LF>

$GPGGA로 시작해서 <CR><LF>로 종료되는 이 문자열 안에 실제로 GPS장치가 수신한 GPS정보가 들어있다. 각 정보는 쉼표 ‘,’ 로 구분되며 위도 경도 값은 ,로 구분되는 각 문자열 중에 3번 5번째에 들어가 있다. (Index는 2, 4)

3.     GPGGA값에 들어가 있는 위경도 값의 형식 (Degree, Minute)

$GPGGA 문자열에 들어가 있는 위경도 값은 도,분 값으로 표현되어 있다. 위도의 경우 앞의 2개가 도, 나머지 값이 분이다. 경도의 경우 앞의 3개가 도, 나머지 값이 분이다. 예를 들어 위도 3834.0753의 경우 38도 34분 0.0753*60 초다. 그리고 경도의 경우 12705.124의 경우 127도 5분 0.124*60 초 이다. 그리고 각 위경도 값 다음에 쉼표 ‘,’ 가 나오고 이 위경도 값이 북위(N), 남위(S), 인지 동경(E), 서경(W) 인지 아스키 코드가 한 개 들어가 있다.

4.     위도 1초 당 30.828미터, 그리고 경도 1초 당 24.697미터의 거리 차이가 있다.

5.     GPGGA 문자열의 7번째 (Index 6) 의 값이 0인 경우 수신한 문자열의 위경 도 값이 신뢰 할 수 없음을 뜻한다. 1, 2 ,3 .. 각 숫자에 따라 위경도 값이 수정된 방식을 뜻하나 사실상 0이 "신뢰할 수 없음" 이라는 것만 알아도 상관 없다.

6.     구글맵을 이용한 테스트 방법

도분초 위경도로 위치 검색

37°33'58.35"N,126°58'40.30"E 을 검색창에 입력하면 해당 위치를 구글맵으로 표시해줌

 지능형 영상분석 개발을 위한 첫걸음으로 배경학습을 이용한 블롭 검출을 이용해서 트래킹 기능을 구현했다. 이름대로 뭐든 다 찾아 내는 지능형 영상분석 기능을 만들 수 있기를 바라며 "다찾어 1호" 라고 이름지었다. 블롭검출은 GMG 배경 학습을 이용하고 각 프레임간 블롭정합은 각 프레임간 검출 블롭들의 겹침 영역을 비교하여 일정수준 이상의 영역이 겹치면 두 블롭이 유사하다고 판단했다. 따라서 검출 하고자 하는 Object가 일부분 가려지는 폐색 이나 블롭 추출시에 에러로 인해 한 블롭이 두개 내지 다수의 블롭으로 쪼개지는 현상을 어느정도는 커버 할 수 있었다. 위 영상에서 일부 프레임의 네모쳐진 블롭도 사실은 2개로 나눠진 블롭을 이전 프레임의 블롭위치와 비교하여 하나로 합친 결과이다.

 칼만 필터를 써볼까도 생각해 봤지만, 오히려 매번 블롭 검출을 통해 state vector의 중요 요소인 블롭 사각형의 위치, 너비, 높이등을 직접 얻을 수 있고 프레임률이 높아 상대적으로 오브젝트의 이동범위가 제한적인 환경이라고 한다면 칼만 필터를 쓰는 것이 오히려 성능을 떨어트리는 결과를 가져 올수도 있다고 판단하여 일단 배제하고 순전히 블롭간 겹침 영역비율만을 이용하여 프레임간 블롭 정합을 했다. (칼만필터 쓰는방법을 까먹기도 했다..)  

 배경학습을 이용한 블롭을 추출하는 것을 바탕으로 하다보니 여러 오브젝트들이 겹치거나 해서 블롭 추출시 하나의 블롭으로 검출되면 각각의 오브젝트들을 추적 할 수 없다는 한계가 있다는 점이 아쉽다. (다른 방법이 있는 것으로 알고 있지만 아직 모른다.) N모 VMS업체의 IVS기능을 봐도 여러 오브젝트들이 뭉쳐있는 곳은 하나의 검출 결과로 뭉퉁그려서 표기하는 걸 보면 거기서도 배경학습을 이용한 블롭검출을 하는 것 같다. 다만 거기서는 정합 할 수 있는 블롭을 더이상 찾을 수 없을 때, 이동 경로를 따라 계속 검출 표시를 이동시키는데 이것은 칼만 필터를 이용한 estimation을 하고 있는 것으로 보인다. 지금 이 결과 영상은 칼만 필터를 쓰지 않았지만 FPS가 낮은 환경이거나 물체의 이동속도가 매우 빨라 블롭 겹침만으로 블롭간 정합하기가 어려울 때에는 칼만 필터를 적용해야할 필요성이 있을 것 같다.

 전혀 모르던 분야를 시작해서 이제 발걸음을 떼고 있다. 구현한 트래킹 수준은 거의 한 1990년대 초반 수준인것 같아 부끄럽다. 하지만 비로소 나름 구색을 갖춘 기능 구현이라는 점에서 스스로 의의를 찾아본다. 부디 지치지 않고 꾸준히 정진해서 좋은 성과를 얻을 수 있다면 좋겠다.

7월 24일 저녁 12시 39분