Microsoft MVP성태의 닷넷 이야기
디버깅 기술: 8. COM+ 서버 응용 프로그램에 대한 F5 디버깅 방법 [링크 복사], [링크+제목 복사],
조회: 28447
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 
(연관된 글이 2개 있습니다.)
다들 아시는 것처럼, COM+ 개체는 라이브러리 유형의 프로젝트로 생성되어지고, COM+ 서버 응용 프로그램은 dllhost.exe에 의해서 호스팅되어집니다. 즉, 일반적인 "F5" 디버깅으로는 시작할 수가 없습니다. 물론, "일반적인" 방법으로 안될 뿐 조금만 설정을 더 해주면 가능해집니다. 어떻게 할 수 있는지 그럼 한번 살펴볼까요? ^^



1. COM+ 서버 응용 프로그램에 들어갈 "CpServer"라는 C# 라이브러리 유형의 프로젝트를 만들고 다음과 같은 클래스를 추가해 줍니다.

[assembly: ApplicationName("ComPlusServerSample")]
[assembly: ApplicationActivation(ActivationOption.Server)]
[assembly: ApplicationAccessControl(true)]
[assembly: ApplicationID("A6E997C2-8197-4658-849C-86ABEEC91D79")]

    [
		ComVisible(true),
		Transaction(TransactionOption.Required),
		JustInTimeActivation(true),
		Guid("CBFE34C5-88F2-45f6-ACF1-DFA2C1612F00"),
    ]
    [ComponentAccessControl(false)]
    public class Employee : ServicedComponent
    {
        [AutoComplete]
        public string DoMethod()
        {
            return "DoMethod";
        }
    }

2. 위의 COM+ 개체를 사용하는 또 다른 프로젝트를 "HostApp"라는 C# 윈폼 응용 프로그램을 생성해서 다음과 같이 코드를 추가해 줍니다.

	private void Form1_Load(object sender, EventArgs e)
	{
		CpServer.Employee employee = new CpServer.Employee();
		employee.DoMethod();
	}

3. 일단, 한번 "HostApp" 프로그램을 실행시켜서 "ComPlusServerSample" COM+ 응용 프로그램이 생성되게 합니다. 보시는 것처럼, "Application ID"가 우리가 지정해 준 "{A6E997C2-8197-4658-849C-86ABEEC91D79}"인 것을 확인할 수 있습니다.

생성된 COM+ 응용 프로그램

4. 자, 이제 사용하는 측과 사용 당하는 측 모두에 대해서 "F5" 키 한 번으로 디버깅을 시작해야 하는데요. 계속하기 전에, 다중 프로젝트 디버깅에 대해서 모르시는 분은 잠시 다음의 토픽을 먼저 읽어보십시오.

VS.NET 2003/2005의 다중 프로젝트 디버깅
; https://www.sysnet.pe.kr/2/0/334

그럼, 각각의 프로젝트에 대해서 어떻게 설정을 해야 할까요? 우선, "HostApp"와 "CpServer" 프로젝트에 대해서 "Start" 유형으로 설정하는 것은 기본이겠지요. 그다음 HostApp는 어차피 WinForm EXE 프로젝트이니 생각할 필요가 없겠고요. 문제는 라이브러리 유형인 CpServer에 대해서 실행될 수 있도록 조정을 해주어야 하는데요. 프로젝트 속성창을 열어서 다음과 같이 시작 프로그램을 설정해 줍니다.

COM+ 프로젝트 속성창

값을 정리해 보면

Start exterenal program : C:\WINDOWS\system32\dllhost.exe
Command line arguments : /Processid:{A6E997C2-8197-4658-849C-86ABEEC91D79}

입니다. 어렵지 않지요? ^^



모든 준비는 위의 단계로 끝입니다. 이제 "F5" 디버깅 키를 누르면 정상적으로 2개의 프로젝트 모두에 지정한 BP(Break Point)에 의해서 실행이 멈추고 소스 코드의 라인 단위로 모든 디버깅 기능을 이용할 수 있습니다.

여기서 마치지 말고 한 가지 더 경우의 수를 생각해 볼까요? 바로, GAC에 등록된 COM+ Server 개체는 어떻게 디버깅을 하느냐는 점입니다. 이 경우, 해당 프로젝트가 같은 솔루션에 있느냐 그렇지 않느냐에 따라 달라집니다. 같은 솔루션에 있으면 CpServer 참조를 해도 다음과 같이 "Copy Local" 속성이 "True"로 되어서 PDB 정보를 정상적으로 로드가 가능해집니다.

같은 솔루션 내의 COM+ 개체 참조

그렇지 않고, 솔루션에 포함되지 않은 COM+ 개체를 DLL 파일 경로를 통해서 참조를 하게 되면 다음과 같이 "Copy Local"이 기본으로는 "False"로 되어집니다.

CpServer 속성

사실, 이제부터는 이 값이 "True"라고 해도 그다지 영향력이 없습니다. 왜냐하면, ^^ 솔루션에 설정한 다중 프로젝트 디버깅 설정이 "CpServer"에 대해서 해제되기 때문입니다. 현실적으로 해제된다기보다는 아예 설정 자체가 안되는 것이죠.
그런데, 정말 방법이 없는 것일까요? ^^ 만약 여러분이 "VS.NET 2003/2005의 다중 프로젝트 디버깅"을 정독하셨다면 방법을 생각해 내셨을 수도 있습니다. ^^

그쵸! 바로 "Attach to process"를 통해서 가능합니다. 한번 해볼까요? 다음 화면에서처럼, COM+ 메서드를 부르기 전에 BP를 설정하고, "F5" 키를 눌러서 "HostApp"를 실행시킵니다.

HostApp에 BP 설정

BP에서 실행이 멈추었으면, "Debug" / "Attach to process..." 메뉴를 선택해서 다음과 같이 "dllhost.exe"에 대해서 디버거를 붙입니다.

dllhost.exe에 디버거 붙이기

이제, BP 지점에서 "F11" 키를 누르면, (정상적으로 PDB 파일이 있고, 소스 경로에 올바른 소스파일이 있다면) 다음 화면과 같이 성공적으로 디버거가 Step into 한 것을 확인할 수 있습니다.

F11 Step Into

휴~~~ 이제 설명이 그럼 다 끝난 건가요? ^^ 근데, 이대로 끝내면 좀 섭섭하지요. ^^; 혹시 위의 글들을 읽다가 뭔가 궁금한 사항을 발견하시지 않으셨나요? 모르시겠다면 ^^ 그럼, 제가 반대로 물어볼까요? 도대체 제가 어떻게 dllhost.exe에 /Processid:...와 같은 식으로 명령행 인자가 들어간다는 것을 알 수 있었을까요? ... 라는 점에 대해서 궁금하지 않으세요?

구글을 찾아봤을 수도 있지만, ^^ 그럴 필요가 없었습니다. 왜냐하면, 저에겐 sysinternals에서 다운로드 받은 "Process Explorer"가 있기 때문입니다. 이쯤에서, 무릎을 탁 치시는 분들이 계실 것 같은데요. ^^ 맞습니다. Process Explorer의 기능 중에서 명령행 라인을 확인하는 것이 있지요. 아래의 화면은 제가 process explorer로 잡은 dllhost.exe의 명령행 입니다.

Process Explorer로 확인하는 명령행 인자

여기가 그럼 끝일까요? ^^ 자꾸만 생각이 꼬리를 물고 이어집니다. 그렇다면, 이것을 활용하면 ISAPI 필터 같은 경우에 w3wp.exe에 대한 실행 방식을 알아내서 "F5" 디버깅 방법이 가능해지겠구나.... 라는 것까지 이어지게 됩니다.
아쉽게도, 제가 이 방법에 대해서는 ^^ 답을 낼 수가 없군요. 저도 ^^ 모르기 때문입니다.

처음에 저는 w3wp.exe에 대해서 쉽게 접근할 수 있으리라 여겼습니다. 실제로 명령행 라인을 확인해 보면 다음과 같은 식입니다.

Path : c:\windows\system32\inetsrv\w3wp.exe
Command Line :  c:\windows\system32\inetsrv\w3wp.exe -a \\.\pipe\iisipmb90dcbb2-5cb6-4793-ab4f-9788ccee3de1 -t 20 -ap "ASP.NET V2.0"

잘 보시면, Named Pipe 설정하는 부분에서 왠지 불안하게(!) ^^ Guid 유형의 값이 사용된 것을 볼 수 있습니다. 그렇습니다. w3wp.exe의 다양한 Recycling 정책으로 인해 그 인자값은 무작위로 변할 수 있습니다. 또한 변한다고 해서 다 되는 것이 아니고, IIS 서비스에서도 실제 그 인자를 이용해 주어야 합니다. 확인을 위해 w3wp.exe와 통신하는 svchost.exe가 가진 Handles 목록을 살펴보면 동일한 값의 named pipe 값이 열려있는 것을 확인할 수 있습니다.

어쩔 수 없군요. ^^ 이렇게 되면 일단 현 시점에서는 w3wp.exe에 대한 F5 디버깅은 포기해야 할 것 같습니다. 혹시나 이것과 관련해서 좋은 의견을 가지신 분들은 댓글 좀 부탁드리겠습니다. ^^

이제 정말 끝입니다. ^^





[이 토픽에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]
[연관 글]






[최초 등록일: ]
[최종 수정일: 7/7/2021]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 




... 61  62  63  64  65  66  67  68  69  70  71  72  73  [74]  75  ...
NoWriterDateCnt.TitleFile(s)
12086정성태12/20/201921074디버깅 기술: 144. windbg - Marshal.FreeHGlobal에서 발생한 덤프 분석 사례
12085정성태12/20/201919039오류 유형: 586. iisreset - The data is invalid. (2147942413, 8007000d) 오류 발생 - 두 번째 이야기 [1]
12084정성태12/19/201919451디버깅 기술: 143. windbg/sos - Hashtable의 buckets 배열 내용을 모두 덤프하는 방법 (do_hashtable.py) [1]
12083정성태12/17/201922397Linux: 27. linux - lldb를 이용한 .NET Core 응용 프로그램의 메모리 덤프 분석 방법 [2]
12082정성태12/17/201920603오류 유형: 585. lsof: WARNING: can't stat() fuse.gvfsd-fuse file system
12081정성태12/16/201922491개발 환경 구성: 465. 로컬 PC에서 개발 중인 ASP.NET Core 웹 응용 프로그램을 다른 PC에서도 접근하는 방법 [5]
12080정성태12/16/201919658.NET Framework: 870. C# - 프로세스의 모든 핸들을 열람
12079정성태12/13/201921579오류 유형: 584. 원격 데스크톱(rdp) 환경에서 다중 또는 고용량 파일 복사 시 "Unspecified error" 오류 발생
12078정성태12/13/201921393Linux: 26. .NET Core 응용 프로그램을 위한 메모리 덤프 방법 [3]
12077정성태12/13/201920446Linux: 25. 자주 실행할 명령어 또는 초기 환경을 "~/.bashrc" 파일에 등록
12076정성태12/12/201918972디버깅 기술: 142. Linux - lldb 환경에서 sos 확장 명령어를 이용한 닷넷 프로세스 디버깅 - 배포 방법에 따른 차이
12075정성태12/11/201919780디버깅 기술: 141. Linux - lldb 환경에서 sos 확장 명령어를 이용한 닷넷 프로세스 디버깅
12074정성태12/10/201919481디버깅 기술: 140. windbg/Visual Studio - 값이 변경된 경우를 위한 정지점(BP) 설정(Data Breakpoint)
12073정성태12/10/201920955Linux: 24. Linux/C# - 실행 파일이 아닌 스크립트 형식의 명령어를 Process.Start로 실행하는 방법
12072정성태12/9/201917717오류 유형: 583. iisreset 수행 시 "No such interface supported" 오류
12071정성태12/9/201921268오류 유형: 582. 리눅스 디스크 공간 부족 및 safemode 부팅 방법
12070정성태12/9/201923195오류 유형: 581. resize2fs: Bad magic number in super-block while trying to open /dev/.../root
12069정성태12/2/201919627디버깅 기술: 139. windbg - x64 덤프 분석 시 메서드의 인자 또는 로컬 변수의 값을 확인하는 방법
12068정성태11/28/201928272디버깅 기술: 138. windbg와 Win32 API로 알아보는 Windows Heap 정보 분석 [3]파일 다운로드2
12067정성태11/27/201919680디버깅 기술: 137. 실제 사례를 통해 Debug Diagnostics 도구가 생성한 닷넷 웹 응용 프로그램의 성능 장애 보고서 설명 [1]파일 다운로드1
12066정성태11/27/201919320디버깅 기술: 136. windbg - C# PInvoke 호출 시 마샬링을 담당하는 함수 분석 - OracleCommand.ExecuteReader에서 OpsSql.Prepare2 PInvoke 호출 분석
12065정성태11/25/201917625디버깅 기술: 135. windbg - C# PInvoke 호출 시 마샬링을 담당하는 함수 분석파일 다운로드1
12064정성태11/25/201920595오류 유형: 580. HTTP Error 500.0/500.33 - ANCM In-Process Handler Load Failure
12063정성태11/21/201919539디버깅 기술: 134. windbg - RtlReportCriticalFailure로부터 parameters 정보 찾는 방법
12062정성태11/21/201918946디버깅 기술: 133. windbg - CoTaskMemFree/FreeCoTaskMem에서 발생한 덤프 분석 사례 - 두 번째 이야기
12061정성태11/20/201919416Windows: 167. CoTaskMemAlloc/CoTaskMemFree과 윈도우 Heap의 관계
... 61  62  63  64  65  66  67  68  69  70  71  72  73  [74]  75  ...