응용 프로그램 복원: Windows Installer의 숨겨진 기능 살펴보기

목차

시작
셸의 연동을 통한 복원
Windows Installer API 소개
주요 응용 프로그램 API
문제 #1: 자기 호출에 의한 복원
문제 #2: 온디멘드로의 설치
결론

시작

개발자는 이상적인 환경에서 이상적인 시스템에 정상적으로 설치된 응용 프로그램을 이상적인 사용자에 의해 실행될 것이라고 생각하는 경향이 있습니다. 실제로는 정상적으로 설치 되면 사용자에게는 응용 프로그램의 유효기간 시작에 불과합니다. 응용 프로그램의 안정성 및 기능성 유지에 직면한 많은 과제가 있지만, 대부분의 응용 프로그램은 실행을 불가능하게 하는 조작 환경의 변화에 대처할 준비되지 않았습니다.

Windows Installer는 응용 프로그램의 안정성 유지에 놀라운 진보를 가져온 복원 기능을 제공합니다. 이 기능은 Windows Installer에 “진입점”을 나타내는 셸과 상호작용하여 사용자가 실시한 특정 조작에 기반한 진입점에 의해 Windows Installer의 응용 프로그램의 구성에 관한 문제를 검색하여 복원할 수 있습니다.

다음은 Windows Installer의 “진입점” 의 간단한 목록을 나타냅니다.

• 바로 가기. Windows Installer에서는 사용자에 대해 Transparent한 추가의 메타데이터가 포함되어 있는 특별한 바로 가기가 있습니다. Windows Installer는 지정한 응용 프로그램의 실행 전에 그 설치 상태를 확인하기 위해서 셸 통합을 통한 메타데이터를 사용합니다.
• 파일 연결. Windows Installer는 문서 또는 파일에 관련된 응용 프로그램의 호출을 제어하는 메커니즘을 갖추어져 있으며 이것으로 사용자가 셸을 사용하여 문서 또는 파일을 열 때, 그 문서 또는 파일에 관련된 응용 프로그램이 실행되기 전에 그 응용 프로그램을 검증할 수 있습니다.
• COM의 Advertising 기능. Windows Installer는 COM 하부조직에 기본제공 메커니즘을 제공합니다. Windows Installer에 의해서 설치 된 (및 이 기능을 사용하도록 구성된) COM 구성 요소의 인스턴스를 작성하는 응용 프로그램은Windows Installer에 의해서 그 구성 요소의 설치 상태가 확인된 후, 그 구성 요소의 인스턴스를 받습니다.

특정한 환경에서 Windows Installer에 기본 제공되는 복원 기능이 응용 프로그램의 구성에 관한 모든 문제를 검색할 수 없거나, 필요한 진입점이 액티브 하지 않기 때문에 응용 프로그램이 동작하지 않는 경우가 있습니다. 다행히Windows Installer의 개발 팀에서는 이 문제를 인지하고 Windows Installer API 에 추가의 복원 가능하도록 하였습니다.

셸 통합에 의한 복원

Windows Installer API 에서 제공하는 개선된 복원 기능에 살펴보기 전에, Windows Installer로 응용 프로그램을 배포할 때에 추가 비용 없이 가능한 일반적인 복원의 시나리오에 대해 봅시다.

이 시나리오에서는 SimplePad 라는 간단한 텍스트 편집 응용 프로그램을 배포합니다. 설치의 작성에는Microsoft 의 Open Source WiX Toolkit (상세한 내용은 http://sourceforge.net/projects/wix (영문)를 참조하세요.)를 사용하지만 어떤 툴을 선택하든지 같은 설치를 작성할 수 있습니다.

<Directory Id="TARGETDIR" Name="SourceDir">
<Component Id="SimplePad" Guid="BDDFA5DC-BD69-4232-998E-5167814C21B9" 
  KeyPath="no">
  <File Id="SimplePadConfig" Name="SP.cfg"
    src="$(var.SrcFilesPath)SimplePad.exe.config"
    LongName="SimplePad.exe.config" Vital="yes" KeyPath="no" DiskId="1" />
  <File Id="SimplePad" Name="Simple~1.exe"
    src="$(var.SrcFilesPath)SimplePad.EXE" LongName="SimplePad.exe" Vital="yes"
    KeyPath="yes" DiskId="1" >
  <Shortcut Id="SC1" Advertise="yes"  Directory="ProgramMenuFolder"
    Name="SimpPad" LongName="Run SimplePad"  />
  </File>
</Component>
<Directory Id="ProgramMenuFolder" Name="ProgMenu"></Directory>
</Directory>

상기의 XML 코드에서 알 수 있듯이 하나의 파일 (SimplePad.exe) 과 사용자의 [시작] 메뉴에 1 개의 바로 가기를 포함한 매우 간단한 설치를 작성했습니다. 예에서 작성된 바로 가기는 Windows Installer가 응용 프로그램 상태를 검색하여, 필요할 경우 복원을 위해 사용하는 진입점이 된다는 점에 주의해 주세요.

이것으로 Installer를 작성하여 응용 프로그램을 설치 하여, [시작] 메뉴에 새롭게 작성되는 바로 가기를 사용하여 응용 프로그램을 실행할 수 있습니다. 예상대로, 응용 프로그램은 의도한 동작을 실시합니다. Windows Installer에 기본제공 복원 기능을 테스트하기 위해 SimplePad.exe 파일을 삭제하고, [시작] 메뉴의 바로 가기에서 응용 프로그램을 실행해 보겠습니다. 예상했던 대로 Windows Installer는 SimplePad.exe 에 없어진 것을 검색하여 복원 기능을 실행합니다. 복원 작업을 하는 동안, Windows Installer는 설치 패키지의 내장형 캐시 카피로부터 필요한 구성 정보를 읽어 없어진 파일을 옮겨놓거나, 소스 설치 미디어가 최초 설치 된 장소에 없는 경우, 이를 입력하도록 사용자에게 요구합니다. 복원 작업이 완료하면, 응용 프로그램은 일반적으로 실행됩니다.

그림 1. 진행중의 복원 작업

Windows Installer에 의한 응용 프로그램의 복원은 그 밖에도 몇 가지 메커니즘에 의해 가능합니다. 응용 프로그램의 높은 가용성을 유지할 수 있는 일반적인 두 번째 방법은 Windows Installer의 파일연결에 의한 것입니다. 이 메커니즘의 동작은 바로 가기와 거의 같지만, 응용 프로그램의 실행 가능 파일에 직접 링크하는 대신에, 등록한 파일의 종류와 연계됩니다. 그림 2 와 같이 Windows Installer의 파일 연계는 표준적인 파일 연계와 같은 메커니즘을 사용해 정의됩니다만, 예외가 한가지 있습니다. 그림 2는 일반적인 "shell\Open\command" 레지스트리 키 아래에 추가 값이 표시되어 있는 것에 주목해야 합니다. "command" 라는 이름이 붙일 수 있었던 추가 값은 사용자가 Windows 의 셸에서 파일을 더블 클릭 했을 때에 항상 Windows Installer에 의해 참조됩니다. 이 문자열은 "Darwin Descriptor" 로, 특정 제품, 구성 요소 및 기능을 encode 표시한 것입니다. 이 값이 존재하면 Windows Installer는 데이터를 디코드하여, 제품이나 구성 요소 체크를 실시합니다. 구성 요소에 부족이나 파손이 발견되었을 경우는 부족한 파일이나 데이터의 복원을 실시하는 복원 기능이 Windows Installer에 의해 실행되어 적절한 명령줄 옵션을 응용 프로그램에 전달하여 그 응용 프로그램이 일상적으로 동작됩니다.

그림 2. 파일연결 에서 "Darwin Descriptor" 의 표시

마지막으로 복원 메커니즘은 일반적으로 COM 의 Advertising 기능으로서 알려져 있는 방법입니다. 다만 COM 의 Advertising 기능의 메커니즘을 알기 전에, 이 메커니즘을 사용하는 사례를 이해하는 것이 중요합니다. 예를 들어, 즉시에 우편 요금을 알릴 수 있는 COM기반의 공유 라이브러리를 제공하는 구성 요소 벤더가 있다고 합니다. 이 구성 요소는 많은 다양한 제품에 사용될 가능성이 있기에, 최종 사용자의 시스템상 단일의 공유 위치에 설치 됩니다. 구성 요소가 항상 같은 장소에 설치하여 높은 가용성을 유지할 수 있도록 COM 의 Advertising 기능을 이용하여 적절히 구성된 머지 모듈에 설치 하여 고객에게 납품합니다. 물론, 납품한 솔루션은 사용자 인터페이스를 가지지 않는 단일의 .dll 파일이기 때문에, 다른 복원 메커니즘만으로는 불충분합니다. 이러한 사례에서는 COM 의 Advertising 기능을 이용하는 것으로, 구성 요소가 사용자의 시스템에 올바르게 설치 및 등록 됩니다. 응용 프로그램이 통상의 COM 메커니즘을 통하여 이 구성 요소의 인스턴스를 작성할 때, Windows Installer는 파일 연계로 설명한 것과 완전히 같은 방법으로 프로세스에 확인하는 스텝과 같습니다. 그림 3의 납품된 구성 요소의 COM 등록에 대해, 이번은 "Darwin Descriptor" 는 InprocServer32 레지스트리 값에 보관된다는 것에 주목해 주세요. 여기에서도 Windows Installer가 이 정보를 해독하여, 그 정보를 기본으로 납품한 구성 요소를 적절히 설치 및 구성하여 필요할 경우 복원을 실시하면서 확인하여, 최종적으로 구성 요소의 인스턴스를 호출하여 응용 프로그램에 돌려줍니다.

이 특수한 기능이 구성 요소를 사용하는 응용 프로그램으로부터 완벽히 독립하게 해줍니다. 즉, 그 구성 요소를 사용하는 응용 프로그램이 Windows Installer를 사용해 설치 되지 않은 경우에 호출하여 응용 프로그램이 단지 VBScript 의 경우에서도 구성 요소에 사용된COM 의 Advertising 기능은 계속 올바르게 동작합니다.

그림 3. COM 서버에서 "Darwin Descriptor" 의 표시

지금까지는 코드를 전혀 사용할 필요가 없는 Windows Installer기능을 이용한 복원에 대해 설명했습니다만, 다음은 보다 강력해진 복원의 구현에 대해 설명하겠습니다.

Windows Installer API 소개

지금까지의 시나리오에서는 Windows Installer 동작이 잘 기능했지만, 현실에는 좀 더 고도의 방법으로 Windows Installer를 사용하는 경우가 있습니다. 좀 더 복잡한 시나리오에 대처할 수 있도록 시나리오의 예를 발전 시켜보겠습니다.

응용 프로그램이 두 개 이상의 실행 가능 파일로부터 구성되어 있는 경우가 자주 있습니다. 이 일례로서Updater Application Block에서 볼 수 있듯이, 갱신 체크와 설치를 실시하는 bootstrap 실행 가능 파일을 사용하는 응용 프로그램을 생각할 수 있습니다. 이 경우 최초의 실행 가능 파일은 사용자가 [시작] 메뉴의 바로 가기를 클릭했을 때에 나오는 파일입니다. 이것에 의해, 응용 프로그램의 메인 사용자 인터페이스를 포함하는 두 번째 실행 가능 파일이 실행됩니다. 설치의 구성에 따라 메인 응용 프로그램 실행 가능 파일에 관한 문제가 Windows Installer의 엔진에 의해서 검색되지 않고 그대로 남을 가능성도 충분히 있습니다. 일련의 코드를 작성하여 동작 시에 실행하여, 런타임 환경을 검증한다고 하는 옵션도 생각할 수 있습니다만, 실행 가능 파일 자체가 부족하거나 또는 파손된 상황에서는 도움이 되지 않고, 또 문제를 쉽게 복원할 수 없습니다. 보다 효과적인 솔루션으로서 배치 패키지에 이미 정의된 응용 프로그램의 설정에 관해서 Windows Installer가 취득한 정보를 이용하는 방법이 있습니다.

Windows Installer API 에서는 응용 프로그램의 완전성을 확인하는 방법으로서 사용자가 셸을 조작할 때에 사용되는 것과 같은 메커니즘을 사용합니다. 응용 프로그램 내에서 API를 호출하는 것으로, 이미 설명한 셸의 “진입점” 에 의존하지 않고 같은 결과를 얻을 수 있습니다.

이하에Windows Installer의 셸 통합 복원 기능에서는 대처할 수 없는 시나리오의 목록을 나타냅니다.

• OS 에서 개시하는 응용 프로그램 (실행 레지스트리 키 또는 한 번만 실행하는 레지스트리 키)
• 시스템 서비스
• 정기적인 작업
• 다른 응용 프로그램에 의해서 실행되는 응용 프로그램
• 명령줄 응용 프로그램

상기 이외에도 많은 시나리오가 있지만, 전반적으로 이해할 수 있다고 생각합니다. 다음의 예는 지금까지 설명한 셸 통합에 의지하지 않고 Windows Installer복원 기능을 이용하는 방법을 살펴봅니다. 읽어 보시고 개념을 잘 활용하면 다른 시나리오에서도 쉽게 적용할 수 있습니다.

주요 응용 프로그램 API

시나리오의 예를 진행하기 전에, 응용 프로그램 내에서 사용할 수 있는 주요 Windows Installer API를 몇 가지 봅시다. 이러한 API 의 사용 방법의 상세한 내용은 Platform SDK 의 Windows Installer Finction Reference (영문)를 참조해 주세요.

문제 #1: 자기 호출에 의한 복원

처음 시스템으로부터 응용 프로그램의 실행 가능 파일을 실제로 삭제하여 바로 가기를 사용하여 Windows Installer로 문제의 검색과 복원을 실시하고, 삭제한 파일을 재설치 하는 매우 간단한 시나리오에 대해 설명했습니다. 이 시나리오는Windows Installer를 이용한 셸 통합을 소개하는 좋은 예이지만, 개념을 한층 더 깊게 하기 위해 좀 더 복잡한 시나리오를 살펴봅시다.

이 시나리오에서는 응용 프로그램은 하나의 .exe 파일 물어 구두인가의 텍스트 파일로 구성되어 텍스트 파일은 그 응용 프로그램에 있어서 매우 중요한 구성 정보를 포함하고 있다고 합니다.

어느 가공의 소프트웨어 회사의 기술 기술 스탭은 응용 프로그램의 구성에 관한 문제가 Windows Installer에 의해서 해결되지 않은 많은 기술 요구를 받았는데, 그것은 사용자가, 설치에 의해서 작성된 [시작] 메뉴의 바로 가기 대신에 Windows 익스플로러로 실행 가능 파일을 더블 클릭하여 직접 응용 프로그램을 실행하는 것이 원인이었습니다.

사내의 응용 프로그램 전개 담당자와 상담한 후, 이 회사의 엔지니어 팀은 응용 프로그램 독자적인 복원 체크를 실행할 때 그 구성이 적절할지를 확인하는 것이 유리하다라고 판단하였습니다. 이것을 간단하게 실현하기 위해, 그 팀은 MsiProvideComponent API 호출을 추가하여, 응용 프로그램의 설치 패키지로 정의된 중요한 구성 요소가 적절히 설치 및 구성되도록 하였습니다.

<DllImport("msi.dll")> _
Private Shared Function MsiProvideComponent(ByVal szProduct As String, ByVal _
 szFeature As String, ByVal szComponent As String, ByVal dwInstallMode As _
 MSI_REINSTALLMODE, ByVal lpPathBuf As System.Text.StringBuilder, ByRef _
 pcchPathBuf As IntPtr) As Integer
End Function

Public Shared Function ProvideComponent(ByVal productCode As String, ByVal _
 featureName As String, ByVal compID As String) As String
  Dim iRet As Integer
  Dim cbBuffer As Integer = 255
  Dim buffer1 As New System.text.StringBuilder(cbBuffer)
  Dim pSize As New IntPtr(cbBuffer)
  iRet = MsiProvideComponent(productCode, featureName, compID, _
   MSI_INSTALLMODE.INSTALLMODE_DEFAULT, buffer1, pSize)
  Return buffer1.ToString
End Function

한층 더 이 코드를 캡슐화하기 위해 WIHelper라는 새로운 클래스를 프로젝트에 추가하고, Windows Installer API 메소드 지정 및 래퍼 메소드를 보관합니다. 이 코드 호출은 메인 폼의 Load 이벤트 처리기에 몇 가지만 추가하는 간단한 작업입니다.

Private CONST PRODUCTID As String = "PRODUCT_GUID_HERE"
Private CONST MAIN_FEATUREID As String = "DefaultFeatureKey"
Private CONST COMPID_1 As String = "COMP1_GUID_HERE"
Private CONST COMPID_2 As String = "COMP2_GUID_HERE"
Private Sub MainForm_Load() Handles MyBase.Load
  If WIHelper.IsProductInstalled(PRODUCTID) Then
    WIHelper.ProvideComponent(PRODUCTID, MAIN_FEATUREID, COMPID_1)
    WIHelper.ProvideComponent(PRODUCTID, MAIN_FEATUREID, COMPID_2)
  End If
End Sub
 

상기의 샘플 코드에서는 설치 패키지를 통해 응용 프로그램이 실제로 설치 되었는지를 확인하는 테스트를 최초로 가고 있습니다. 이것은 개발 환경에서 디버그를 실시하고 있어도, 응용 프로그램이 적절히 기능하는 지 한번 더 확인하는 것이 중요합니다. IsProductInstalled 로 불리는 헬퍼 클래스내의 메소드를 호출하여 MsiQueryProductState 가 제품이 시스템에 설치 되었는지를 판단합니다. IsProductInstalled 를 호출하여 제품이 설치된 것이 확인되면, 도우미 클래스내의 일련의 ProvideComponent 메소드를 호출합니다. 이 메소드 역시 MsiProvideComponent API 의 단순한 래퍼 클래스에서 지정된 구성 요소의 완전한 패스를 반환하여, 그 구성 요소가 적절히 설치 되어 사용 가능한 것을 확인합니다. 특정 제품에서 필요에 따라 ProvideComponent 메소드를 여러 번 호출하여 사용자가 응용 프로그램을 완전히 이용 가능한 상태인지 확인 가능합니다.

문제 #2: 요청 설치

어느 가공 회사의 판매 담당 임원은 고객으로부터 SimplePad 에 일련의 표준 템플릿을 추가해 달라는 요청을 받아 왔습니다. 고객 중에는 이 기능을 강력하게 요구하는 고객도 있지만, 대부분의 사용자에게는 필요하지 않은 관계없는 데이터를 설치 하는 것에 대해 염려하는 의견도 있었습니다.

고객의 새로운 요건에 대한 대응방안에 관한 엔지니어의 대화를 들은 설치 엔지니어는 Windows Installer에 약간의 코드 추가로 이 문제를 해결할 수 있다고 알려주었습니다.

단시간에 계획을 세운 후, 팀은 응용 프로그램의 [파일] 메뉴에 새롭고 [템플릿] 메뉴 항목을 구현하는 것을 결정합니다. 이 템플릿 기능이 사용자의 시스템에 로컬로 설치 되는 경우, 이용할 수 있는 템플릿을 목록 표에 나와있는 플라이 아웃 메뉴와 템플릿 기능을 제거하는 옵션이 응용 프로그램에 표시됩니다. 템플릿 기능이 설치 되지 않았던 경우, 템플릿의 플라이 아웃 메뉴는 하나의 엔트리만을 가져와 사용자가 템플릿을 추가 설치 할 수 있게 됩니다.

Private Sub mnuFile_Popup(ByVal sender As Object, ByVal e As System.EventArgs) _ Handles mnuFile.Popup
  Dim newItem As MenuItem
  With mnuTemplates.MenuItems
    .Clear()
    If WIHelper.IsFeatureInstalled(PRODUCTID, TEMPLATES_FEATUREID) Then
      Dim dirInfo As New DirectoryInfo(Application.ExecutablePath)
      For Each dirFile As FileInfo In dirInfo.Parent.GetFiles("*.tpl")
        Dim mi As New MenuItem(Path.GetFileNameWithoutExtension(dirFile.Name))
        AddHandler mi.Click, AddressOf OpenTemplate
        .Add(mi)
      Next
      .Add("-")
      newItem = New MenuItem("Uninstall Templates")
      AddHandler newItem.Click, AddressOf UninstallTemplates
      .Add(newItem)
    Else
      newItem = New MenuItem("Install Templates")
      AddHandler newItem.Click, AddressOf InstallTemplates
      .Add(newItem)
    End If
  End With
End Sub

이 코드에서는 템플릿 기능이 설치 되어 있는 것을 우선 확인합니다. 설치 된 경우는, 응용 프로그램 폴더 내에 있는 "tpl" 확장자가 붙은 파일을 열거하여 각 템플릿 명을 메뉴에 추가합니다. 설치 되지 않은 경우는 템플릿을 설치 하는 옵션을 사용자를 위해 추가해야 합니다. 그 방법을 보기 전에, 템플릿 기능이 설치 되어 있는지 확인하는 방법을 우선 봅시다.

<DllImport("msi.dll")> _
Private Shared Function MsiQueryFeatureState(ByVal szProduct As String, 
ByVal szFeature As String) As MSI_INSTALLSTATE
End Function    
Public Shared Function IsFeatureInstalled(ByVal pid As String, ByVal fid As String) As Boolean
  Return MsiQueryFeatureState(pid, fid) = MSI_INSTALLSTATE.INSTALLSTATE_LOCAL
End Function

이 단순한 함수에서는 단지 Windows Installer의 MsiQueryFeatureState 함수를 호출하여 응용 프로그램의 ProductCode 와 조회하는 기능 명을 알려줍니다. Windows Installer가 INSTALLSTATE_LOCAL 에 반환하면, 그 기능이 로컬에 설치 되어 있다는 것을 의미의 true를 반환합니다.

템플릿 기능의 설치 및 제거도 이와 같이 간단하게 실시할 수 있습니다.

Copy Code

<DllImport("msi.dll")> _
Private Shared Function MsiConfigureFeature(ByVal szProduct As String, ByVal szFeature As String, ByVal eInstallState As MSI_INSTALLSTATE) As Integer
End Function

Public Shared Function InstallFeature(ByVal pid As String, ByVal fid As String)
  As Boolean
  Return MsiConfigureFeature(pid, fid, MSI_INSTALLSTATE.INSTALLSTATE_LOCAL) = ERROR_SUCCESS
End Function

Public Shared Function UninstallFeature(ByVal pid As String, ByVal fid As String) As Boolean
  Return MsiConfigureFeature(pid, fid, 
MSI_INSTALLSTATE.INSTALLSTATE_ABSENT) = ERROR_SUCCESS
End Function

사용자가 "템플릿 설치" 에서 메뉴 항목을 클릭하면, 해당 호출은 ProductCode라는 로컬에 그 기능을 설치하는 열거 값을 포함하는 MsiConfigureFeature 를 만듭니다. 템플릿 기능의 설치 중에는 Windows Installer의 진행 상황 대화 상자가 단시간 표시됩니다. 대화 상자가 사라지면, 템플릿이 설치 되어 사용 가능해집니다. [파일] 메뉴로 돌아오면, 상기에 설명한 것처럼 템플릿의 부메뉴가 템플릿명과 함께 작성되어 있습니다.

결론

Windows Installer의 새로 알려진 기능과 API를 활용하여 획기적인 기능을 이용할 수 있습니다. 이러한 기능은 기술 비용 삭감, 응용 프로그램의 안정성 증대 및 사용자 경험(experience) 향상에 공헌합니다. 여기에 제시된 예들은 흔히 있을 수 있지만, 독자적인 솔루션 구현의 큰 출발점이 될 수 있습니다. 여기서는 이용 가능한 API의 몇 가지만 살펴보았을 뿐 모든 API에 대해 설명한 것이 아닙니다. Windows Installer 및 API 의 모든 기능을 살펴보면 Windows Installer에서 사용하지 않았던 많은 기능을 간단하게 활용할 수 있다는 사실을 알게 될 것 입니다.

Michael Sanford는 701 Software (http://www.701software.com (영문))의 사장 겸 수석 소프트웨어 아키텍트로서, 마이크로소프트 공인 솔루션 개발자 (MCSD), 마이크로소프트 공인 시스템 엔지니어 (MCSE) 및 Windows Installer부분 MVP 입니다. Michael's 블로그 http://msmvps.com/michael (영문)에서 만나실 수 있습니다.