vshost.exe 둘러보기 Computer Code

(강좌 준비차원에서 작성한 '미리 한번 써본'글 입니다. 다듬어지지 않은 부분은 양해바랍니다.)

VS 2005에서는 이전 버전과는 달리 bin 폴더에 .vshost.exe(그리고 경우에 따라 .vshost.exe.config도 포함을 해서) 파일이 생기는 것을 볼 수 있습니다. 처음 이 파일을 보신 분은 지워도 되는 파일인지, 아니면 배포를 할 때 같이 배포를 해야 하는 파일인지 고민해보신 적도 있을 겁니다.. ^^

vshost.exe는 프로젝트를 빌드할 때 출력 폴더에 생기며 디버깅 향상을 위한 호스팅 프로세스입니다. 당연히 호스팅 대상은 우리가 개발하고 있는 어플리케이션이 되겠지요. 즉, VS IDE에서 디버깅을 할 때 어플리케이션은 자기 프로세스에서 작동하는 것이 아니라 vshost.exe 프로세스를 통해서 작동하게 됩니다. 'VS IDE → vshost.exe → 어플리케이션'의 구조라고 생각하시면 쉬울 것 같습니다. 물론 호스팅 프로세스를 통하지 않고 예전처럼 디버깅을 할 수도 있습니다. (프로젝트 속성 → Debug → Enable Debuggers 항목에서 'Enable the Visual Studio hosting Process'의 체크 항목을 해제하면 됩니다.)
이런 이유로 vshost.exe는 디버깅시에는 최상위 어셈블리가 되어야 하고 그래서 vshost.exe 파일은 실행 파일이 배포된 폴더에 같이 배포됩니다. 실질적으로는 Common7IDE에 있는 vshost.exe 파일을 이름을 바꿔 복사한 것이죠. VS IDE의 Output 창을 보시면 vshost.exe를 통해서 디버깅이 이루어진다는 것을 확인하실 수 있습니다. ^^

이렇게 vshost.exe 파일이 디버깅시에만 사용되는 파일이고 배포할 필요는 없습니다. 오히려 잘못 배포되는 경우에는 보안상 위험이 생길 수도 있으니 배포할 필요가 없다기 보다는 배포를 하지 않는 것이 정답이겠죠.. ^^


호스팅 프로세스를 둠으로써 얻을 수 있는 이점을 MSDN에서는 다음과 같이 얘기하고 있습니다.

1. 디버깅 성능 향상
2. 부분 신뢰(Partial Trust) 디버깅
3. 디자인타임 수식 평가

1. 디버깅 성능 향상
Managed 어플리케이션이 실행될 때는 어플리케이션 도메인을 생성하는데 이것은 상당한 수행 작업이 걸리는 시간입니다. 이전 버전에서 개발을 해보신 분들은 F5 키를 누르고 한참 후에야 디버깅이 시작되는 걸 종종 경험하셨을 겁니다. 이것은 디버깅을 시작할 때마다 어플리케이션 도메인을 새로 생성하는 과정을 반복하기 때문이죠. VS 2005에서 디버깅을 해보면 상당히 빨라졌다는 느낌을 받게 되는데 이것은 어플리케이션 도메인을 생성하는 등의 작업을 호스팅 프로세스가 백그라운드에서 수행을 하고 있기 때문입니다.

2. 부분 신뢰 디버깅
개인적으로는 호스팅 프로세스를 분리함으로써 가장 큰 이득을 본 부분이라고 생각합니다. 아마 스마트 클라이언트를 개발해보신 분들은 개발할 때와 배포할 때의 권한이 틀려서 애를 먹은 적이 있으실 겁니다. 이전 버전에서는 이를 해결하기 위해서는 원격 디버깅을 설정한다거나 하는 등의 까다로운 작업이 많았는데, VS 2005부터는 호스팅 프로세스에 따로 권한을 줄 수 있게 됨으로써 제한된 또는 허용된 권한에서 디버깅을 할 수가 있습니다. 실로 유용한 기능이라고 할 수 있죠.. ^^

3. 디자인타임 수식 평가
어플리케이션을 실행하지 않고 즉시 코드를 테스트 해볼 수 있습니다. 호스팅 프로세스가 해당 코드를 실행시키기 때문이죠. 물론 모든 상황을 커버할 수는 없겠지만 간단한 부분에서는 유용한 기능이라고 생각합니다. ^^


vshost.exe는 다음과 같이 진입점만을 가진 간단한 구조로 되어 있습니다.
호스팅 할 프로세스를 기다리고 실행 어셈블리가 준비되기를 기다리는 간단한 구조죠. 물론 프로세스 및 어셈블리를 셋팅하는 것은 VS IDE에서 할 겁니다. ^^

[DebuggerNonUserCode]
public static void Main()
{
   if (Synchronize.HostingProcessInitialized != null)
   {
       Synchronize.HostingProcessInitialized.Set();
       if (Synchronize.StartRunningUsersAssembly != null)
       {
           Synchronize.StartRunningUsersAssembly.WaitOne();
       }
   }
}

Synchronize 클래스에도 뭔가 있을 거 같지만 사실 간단합니다. ;;

namespace Microsoft.VisualStudio.HostingProcess
{
public sealed class Synchronize
{
   // Methods
   private Synchronize();

   // Properties
   [DebuggerNonUserCode]
   public static EventWaitHandle HostingProcessInitialized
   {
       get
       {
           return Synchronize.m_HostingProcessInitialized;
       }
       set
       {
           Synchronize.m_HostingProcessInitialized = value;
       }
   }

   [DebuggerNonUserCode]
   public static ManualResetEvent StartRunningUsersAssembly
   {
       get
       {
           return Synchronize.m_StartRunningUsersAssembly;
       }
       set
       {
           if (Synchronize.m_StartRunningUsersAssembly == null)
           {
               Synchronize.m_StartRunningUsersAssembly = value;
           }
       }
   }

   // Fields
   internal static EventWaitHandle m_HostingProcessInitialized;
   internal static ManualResetEvent m_StartRunningUsersAssembly;
}
}

참고로 vshost32.exe 라는 파일도 있는데 내부적으로는 vshost.exe와 똑같은 파일이고 파일 이름만 다릅니다. vshost32.exe와 vshost.exe의 차이점을 설명해놓은 자료를 찾을 수가 없어서 일단 그냥 그런가보다.. 하고 있는 상태입니다. ^^; 아마 64bit 환경으로 옮겨갈 때를 대비해서 미리 저런 식으로 만들어놓은 것이 아닐까 짐작만 할 뿐이죠..


덧글

  • 반닫이 2010/04/14 10:12 # 삭제 답글

    아 관련 자료를 찾고 있었는데 감사합니다 ^^
댓글 입력 영역