Udostępnij za pośrednictwem

Odporność aplikacji: odblokowywanie ukrytych funkcji Instalatora Windows

  • Artykuł

 

Michael Sanford
Oprogramowanie 701

Marzec 2005 r.

Krótki opis: Instalator Windows ma kilka funkcji, które w dużej mierze nie zostały niezauważone przez społeczność deweloperów. Te funkcje umożliwiają aplikacji naprawianie się w czasie wykonywania lub instalowanie opcjonalnych składników na podstawie interakcji użytkownika z aplikacją. (10 drukowanych stron)

Pobierz plik MSI Integration Sample Code.msi.

Zawartość

Wprowadzenie
Odporność za pośrednictwem integracji powłoki
Wprowadzenie do interfejsu API Instalatora Windows
Kluczowe interfejsy API aplikacji
Wyzwanie nr 1: odporność Self-Invoked
Wyzwanie nr 2: Instalowanie na żądanie
Podsumowanie

Wprowadzenie

Jako deweloperzy mamy tendencję do myślenia o naszych aplikacjach działających w idealnych środowiskach, w idealnych systemach i przez idealnych użytkowników korzystających z aplikacji po pomyślnej instalacji. Rzeczywistość polega na tym, że po pomyślnym zainstalowaniu naszych aplikacji ich okres istnienia dla tego użytkownika dopiero się rozpoczął. Wyzwania, z którymi nasza aplikacja może zmierzyć się w pozostałych stabilnych i funkcjonalnych, to wiele, ale większość aplikacji nie jest przygotowana do radzenia sobie ze zmianami w środowisku operacyjnym, które mogłyby spowodować, że aplikacja będzie działać.

Instalator Windows zapewnia funkcje odporności, które poczyniły znaczne postępy w utrzymaniu stabilności naszych aplikacji, ale ta funkcja jest oparta na pewnych akcjach, które użytkownik podejmuje podczas interakcji z powłoką w celu zapewnienia "punktów wejścia", za pośrednictwem których Instalator Windows może wykryć problemy z konfiguracją aplikacji i podjąć kroki w celu jego naprawy.

Oto krótka lista "punktów wejścia" Instalatora Windows:

  • Skróty. Instalator Windows wprowadza specjalny typ skrótu, który, choć niewidoczny dla użytkownika, zawiera dodatkowe metadane używane przez Instalatora Windows za pośrednictwem integracji powłoki w celu zweryfikowania stanu instalacji określonej aplikacji przed uruchomieniem aplikacji.
  • Skojarzenia plików. Instalator Windows udostępnia mechanizm przechwytywania wywołań skojarzonej aplikacji dokumentu lub pliku, dzięki czemu gdy użytkownik otworzy dokument lub plik przy użyciu powłoki, Instalator Windows może zweryfikować aplikację przed uruchomieniem skojarzonej aplikacji.
  • Reklama COM. Instalator Windows udostępnia mechanizm podłączony do podsystemu COM, dzięki czemu każda aplikacja tworząca wystąpienie składnika COM zainstalowanego przez Instalatora Windows (i skonfigurowanego do korzystania z tej funkcji) otrzyma wystąpienie tego składnika po zweryfikowaniu stanu instalacji tego składnika przez Instalatora Windows.

W pewnych okolicznościach wbudowane funkcje odporności Instalatora Windows mogą nie być w stanie wykryć wszystkich problemów z konfiguracją aplikacji lub aplikacja może działać w taki sposób, że wymagane punkty wejścia nie są aktywowane. Na szczęście inteligentni faceci w zespole Instalatora Windows zrozumieli to wyzwanie i udostępnili nam dodatkowe funkcje odporności za pośrednictwem bogatego interfejsu API Instalatora Windows.

Odporność za pośrednictwem integracji powłoki

Zanim przejdziemy do zaawansowanych funkcji odporności oferowanych przez interfejs API Instalatora Windows, przyjrzyjmy się typowemu scenariuszowi odporności, który zwykle jest pobierany bezpłatnie podczas wdrażania aplikacji za pomocą Instalatora Windows.

W tym scenariuszu wdrażamy prostą aplikację do edycji tekstu, która będzie wywoływać aplikację SimplePad. Aby utworzyć instalację, użyjemy zestawu narzędzi Open Source WiX firmy Microsoft (aby uzyskać więcej informacji, zobacz https://sourceforge.net/projects/wix/.), ale możesz wykonać to samo za pomocą dowolnego wybranego narzędzia.

<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>

Jak widać w powyższym fragmencie XML, utworzyliśmy bardzo prostą instalację z jednym plikiem (SimplePad.exe) i jednym skrótem znajdującym się w menu Start użytkownika. Należy pamiętać, że w tym przykładzie tworzonym skrótem jest punkt wejścia, którego instalator Windows użyje do wykrywania stanu aplikacji i naprawy go zgodnie z potrzebami.

W tym momencie możemy skompilować instalatora, zainstalować aplikację i użyć nowo utworzonego skrótu menu Start, aby go uruchomić. Zgodnie z oczekiwaniami aplikacja będzie działać dokładnie zgodnie z oczekiwaniami. Aby przetestować wbudowane funkcje odporności Instalatora Windows, możemy usunąć plik SimplePad.exe i spróbować uruchomić aplikację ze skrótu menu Start. Ponownie, zgodnie z oczekiwaniami, Instalator Windows wykrywa, że brakuje SimplePad.exe i zostanie uruchomiona naprawa. Podczas operacji naprawy Instalator Windows odczytuje wymagane informacje o konfiguracji z wewnętrznie buforowanej kopii pakietu instalacyjnego, a na koniec zastępuje brakujący plik, monitując użytkownika o nośnik instalacyjny źródłowy, jeśli nie znajduje się w oryginalnej lokalizacji, z której została zainstalowana. Po zakończeniu operacji naprawy aplikacja zostanie uruchomiona normalnie.

Rysunek 1. Operacja naprawy w toku

Odporność aplikacji jest również dostarczana przez Instalatora Windows za pośrednictwem kilku innych mechanizmów, o których warto również wspomnieć tutaj. Drugą najczęściej spotykaną metodą zapewnienia wysokiej dostępności aplikacji jest skojarzenia plików Instalatora Windows. Ten mechanizm działa tak samo jak skróty Instalatora Windows, ale zamiast bezpośredniego łączenia z plikiem wykonywalnym aplikacji skojarzenie jest wykonywane przez zarejestrowany typ pliku. Jak widać na rysunku 2, skojarzenia plików Instalatora Windows są definiowane przy użyciu tego samego mechanizmu, którego używają standardowe skojarzenia plików z jednym wyjątkiem. Zwróć uwagę na rysunek 2, że dodatkowa wartość znajduje się na liście typowego klucza rejestru "shell\Open\command". Dodatkowa wartość (nazywana również "poleceniem") to miejsce, w którym Instalator Windows wygląda za każdym razem, gdy dwukrotnie klikniesz plik z poziomu powłoki systemu Windows. Ten tajemniczy ciąg, czasami nazywany "deskryptorem Darwina", jest w rzeczywistości zakodowaną reprezentacją określonego produktu, składnika i funkcji. Jeśli ta dodatkowa wartość istnieje, Instalator Windows zdekoduje dane i użyje go do przeprowadzania kontroli względem tego produktu i składnika. Jeśli składnik zostanie znaleziony lub uszkodzony, Instalator Windows uruchomi naprawę w celu przywrócenia brakującego pliku lub danych, a na koniec uruchomi przywołyną aplikację w normalny sposób, przekazując odpowiednie opcje wiersza polecenia do niego.

Rysunek 2. Wyświetlanie deskryptora Darwina dla skojarzenia pliku

Ostateczny mechanizm odporności, który omówimy dzisiaj, jest powszechnie znany jako reklama COM. Zanim przyjrzymy się mechaniki reklamy COM, ważne jest, aby zrozumieć przypadek użycia. Załóżmy, że jesteś dostawcą składników, który udostępnia udostępnioną bibliotekę opartą na modelu COM, która zapewnia stawki pocztowe w czasie rzeczywistym. Ponieważ ten składnik może być używany przez wiele różnych produktów, jest instalowany w jednej udostępnionej lokalizacji w systemie użytkownika końcowego. Aby upewnić się, że składnik zawsze jest instalowany w tej samej lokalizacji i aby upewnić się, że składnik pozostaje wysoce dostępny, należy wysłać go do klientów w module scalania prawidłowo skonfigurowanym w celu skorzystania z reklamy COM. Oczywiście, ponieważ rozwiązanie jest dostarczane jako pojedynczy plik .dll bez interfejsu użytkownika, inne mechanizmy odporności po prostu nie wystarczy. W takim przypadku możemy polegać na reklamie COM, aby upewnić się, że nasz składnik pozostaje prawidłowo zainstalowany i zarejestrowany w systemie użytkownika. Gdy aplikacja tworzy wystąpienie tego składnika za pomocą normalnych mechanizmów COM, Instalator Windows "zaczepia" proces w taki sam sposób, jak w przypadku skojarzeń plików. Zwróć uwagę na rysunek 3, że tym razem "Deskryptor Darwina" jest przechowywany w wartości rejestru InprocServer32 dla rejestracji MODELU COM naszego składnika. Te informacje są ponownie dekodowane i używane przez Instalatora Windows, aby upewnić się, że nasz składnik jest poprawnie zainstalowany i skonfigurowany, wykonując wszelkie naprawy zgodnie z potrzebami, przed zwróceniem wystąpienia składnika do aplikacji wywołującej.

Warto zwrócić uwagę, że ta unikatowa funkcja działa całkowicie niezależnie od aplikacji przy użyciu składnika. Innymi słowy, nawet jeśli aplikacja używająca składnika nie została zainstalowana przy użyciu Instalatora Windows, reklama COM używana przez składnik będzie nadal działać prawidłowo, nawet jeśli aplikacja wywołująca jest tylko VBScript.

Rysunek 3. Wyświetlanie deskryptora Darwina dla serwera COM

Do tej pory wszystko, o czym mówiliśmy, skorzystało z możliwości Instalatora Windows bez konieczności pisania pojedynczego wiersza kodu, ale teraz nadszedł czas, aby przejść do bogatszej, bardziej niezawodnej implementacji.

Wprowadzenie do interfejsu API Instalatora Windows

Domyślne zachowanie Instalatora Windows działało dobrze w poprzednim scenariuszu, ale często w świecie rzeczywistym mamy nieco bardziej zaawansowane aplikacje. Rozszerzmy nasz przykładowy scenariusz, aby poradzić sobie z bardziej trudnym scenariuszem.

Często aplikacja składa się z więcej niż jednego pliku wykonywalnego. Przykładem może być aplikacja, która używa pliku wykonywalnego programu uruchamiającego do sprawdzania i instalowania aktualizacji aplikacji, jak pokazano w bloku aplikacji aktualizatora. W takim przypadku pierwszym plikiem wykonywalnym jest ten, który jest wywoływany, gdy użytkownik kliknie skrót w menu Start. Z kolei uruchamia drugi plik wykonywalny zawierający główny interfejs użytkownika aplikacji. W zależności od konfiguracji instalacji istnieje prawdopodobieństwo, że problemy z głównym plikiem wykonywalnym aplikacji zostaną niezakryte przez aparat Instalatora Windows. Chociaż jedną z opcji może być napisanie kilku kodu uruchamianego podczas uruchamiania, który sprawdza środowisko uruchomieniowe, to po prostu nie zadziała, jeśli sam plik wykonywalny nie jest uszkodzony i, co więcej, nie będzie mógł łatwo naprawić problemu. Znacznie bardziej skutecznym rozwiązaniem jest wykorzystanie wiedzy Instalatora Windows o konfiguracji aplikacji, która jest już zdefiniowana w pakiecie wdrożeniowym.

Interfejs API Instalatora Windows uwidacznia te same mechanizmy sprawdzania integralności aplikacji, która jest używana podczas interakcji użytkownika z powłoką. Korzystając z tych wywołań interfejsu API z poziomu naszej aplikacji, możemy mieć pewność, że nadal uzyskujemy te same korzyści bez konieczności wcześniejszego polegania na omówionych wcześniej "punktach wejścia".

Oto lista scenariuszy, które nie są objęte funkcjami odporności integracji powłoki Instalatora Windows:

  • Aplikacje rozpoczynające się od systemu operacyjnego (uruchamiane lub uruchamiane raz klucze rejestru)
  • Usługi systemowe
  • Zaplanowane zadania
  • Aplikacje wykonywane przez inne aplikacje
  • Aplikacje wiersza polecenia

Jestem pewien, że istnieje wiele innych scenariuszy, które możemy dodać do powyższej listy, ale myślę, że masz pomysł. W poniższym przykładzie przedstawimy, jak możemy uzyskać korzyści wynikające z odporności Instalatora Windows bez polegania na funkcjach integracji powłoki omówionych wcześniej. Gdy wszystko będzie gotowe, będziesz w stanie podjąć te koncepcje i łatwo zastosować je do niemal każdego scenariusza, który obejmuje uruchamianie kodu wykonywalnego.

Kluczowe interfejsy API aplikacji

Zanim zapoznamy się z przykładowymi scenariuszami, przyjrzyjmy się niektórym kluczowym interfejsom API Instalatora Windows, których można użyć z poziomu aplikacji. Aby uzyskać szczegółowe informacje na temat użycia każdego z tych interfejsów API, zapoznaj się z dokumentacją dotyczącą finction Instalatora Windows w zestawie SDK platformy.

Kluczowe funkcje Instalatora Windows Opis
MsiProvideComponent Pobiera zainstalowaną lokalizację składnika, instalowanie lub naprawianie zgodnie z potrzebami, aby upewnić się, że składnik jest dostępny.
MsiQueryFeatureState Zwraca stan instalacji danej funkcji. Na przykład ta funkcja informuje, czy funkcja jest zainstalowana, nie zainstalowana lub anonsowana.
MsiQueryProductState Zwraca stan instalacji produktu. Na przykład ta funkcja informuje, czy produkt jest zainstalowany, anonsowany, zainstalowany dla innego użytkownika, czy w ogóle nie zainstalowany.
MsiConfigureProduct
MsiConfigureProductEx		 Te dwie funkcje umożliwiają programowe instalowanie lub odinstalowywanie aplikacji. Funkcja MsiConfigureProductEx zapewnia większą kontrolę, umożliwiając określenie opcji podobnych do tego, co zwykle można zrobić w wierszu polecenia.
MsiConfigureFeature Ta funkcja umożliwia instalowanie, odinstalowywanie lub anonsowywanie określonej funkcji aplikacji.
MsiGetUserInfo Ta funkcja zwraca nazwę użytkownika, organizację i numer seryjny produktu zebrany podczas sekwencji instalacji produktu.
MsiGetComponentPath
MsiLocateComponent		 Te dwie funkcje ułatwiają określenie fizycznej lokalizacji pliku składnika lub klucza rejestru w systemie docelowym. MsiGetComponentPath zwraca ścieżkę wystąpienia składnika zainstalowanego przez określony produkt, podczas gdy msiLocateComponent zwraca pierwsze wystąpienie składnika zainstalowanego przez dowolny produkt.

Wyzwanie nr 1: odporność Self-Invoked

Wcześniej rozmawialiśmy o bardzo podstawowym scenariuszu, w którym możemy w rzeczywistości usunąć plik wykonywalny naszej aplikacji z systemu i użyć skrótu, aby spowodować, że Instalator Windows wykryje i naprawi problem, ponownie zainstalując brakujący plik. Chociaż ten scenariusz dobrze sprawdzał się w przypadku demonstrowania integracji powłoki używanej przez Instalatora Windows, aby bardziej szczegółowo poznać te koncepcje, przyjrzymy się nieco bardziej zaawansowanemu scenariuszowi.

W tym scenariuszu nasza aplikacja składa się z jednego pliku .exe i kilku plików tekstowych, które dostarczają aplikacji krytyczne informacje o konfiguracji.

Pracownicy pomocy technicznej w naszej hipotetycznej firmie zajmującej się oprogramowaniem otrzymują wiele żądań pomocy technicznej, które ujawniają, że problemy z konfiguracją aplikacji nie są rozwiązywane przez Instalatora Windows ze względu na fakt, że użytkownicy uruchamiają aplikację bezpośrednio, klikając dwukrotnie plik wykonywalny w Eksploratorze Windows zamiast używać skrótu menu Start utworzonego przez naszą instalację.

Po konsultacji z ekspertem ds. wdrażania rezydentów zespołu nasz zespół inżynierów decyduje, że aplikacja znacznie skorzystałaby, wykonując własną kontrolę odporności podczas uruchamiania, aby upewnić się, że jest ona prawidłowo skonfigurowana. W tym celu zespół po prostu dodaje wywołanie interfejsu API MsiProvideComponent , aby upewnić się, że krytyczne składniki zdefiniowane w pakiecie instalacyjnym aplikacji są prawidłowo zainstalowane i skonfigurowane.

<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

Aby lepiej hermetyzować ten kod, do projektu dodawana jest nowa klasa o nazwie WIHelper , która zawiera deklaracje metod interfejsu API Instalatora Windows i metody otoki. Wywołanie tego kodu było prostą kwestią dodania kilku wierszy do programu obsługi zdarzeń ładowania formularza głównego.

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

W powyższym przykładowym kodzie najpierw testujemy, aby sprawdzić, czy nasza aplikacja została rzeczywiście zainstalowana za pośrednictwem pakietu instalacyjnego, czy nie. Jest to ważna koncepcja, ponieważ chcemy mieć pewność, że nawet jeśli debugujemy w środowisku programistycznym, nasza aplikacja nadal będzie działać prawidłowo. W tym celu wywołamy metodę w naszej klasie pomocniczej o nazwie IsProductInstalled. Ta metoda po prostu wywołuje metodę MsiQueryProductState , aby określić, czy produkt został zainstalowany w systemie. Jeśli nasze wywołanie metody IsProductInstalled ujawni, że nasz produkt został zainstalowany, wykonamy serię wywołań metody ProvideComponent w naszej klasie pomocniczej. Ta metoda jest ponownie prostą otoką interfejsu API MsiProvideComponent , który zwraca pełną ścieżkę do określonego składnika i zapewnia, że składnik jest poprawnie zainstalowany i gotowy do użycia. W zależności od potrzeb określonych produktów można wywołać metodę ProvideComponent tyle razy, ile chcesz, aby aplikacja jest w pełni dostępna dla użytkownika.

Wyzwanie nr 2: Instalowanie na żądanie

Nasi hipotetyczni kierownicy sprzedaży firmy słyszeli wiele opinii klientów, że chcą zobaczyć zestaw standardowych szablonów dostarczanych za pomocą rozwiązania SimplePad. Podczas gdy niektórzy klienci wyrazili silne pragnienie tej funkcji, inni wyrazili zaniepokojenie instalowaniem nadmiarowych danych, których większość użytkowników może nie potrzebować.

Po podsłuchaniu inżynierów omawiających, jak radzić sobie z tym nowym wymaganiem, nasz nietrwały inżynier instalacji wskakuje i zwraca uwagę, że Instalator Windows może łatwo poradzić sobie z tym za pomocą zaledwie niewielkiej ilości dodatkowego kodowania.

Po szybkim planowaniu zespół decyduje, że zaimplementuje nowy element menu Szablony w menu Plik aplikacji. Jeśli funkcja szablonów jest zainstalowana lokalnie w systemie użytkownika, zostanie wyświetlone menu wysuwane zawierające listę wszystkich dostępnych szablonów oraz opcję odinstalowania funkcji szablonów. Jeśli funkcja szablonów nie została zainstalowana, menu wysuwane szablonów będzie zawierać pojedynczy wpis, co umożliwi użytkownikowi zainstalowanie dodatkowych szablonów.

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

Jak widać, najpierw sprawdzamy, czy funkcja szablonów jest zainstalowana. Jeśli tak jest, to wyliczamy za pomocą plików w folderze aplikacji, które mają rozszerzenie "tpl" i dodajemy nazwę każdego szablonu do menu. Jeśli tak nie jest, po prostu dodamy użytkownikowi opcję zainstalowania szablonów. Zanim przyjrzymy się temu, najpierw przyjrzyjmy się temu, jak określamy, czy funkcja szablonów jest zainstalowana.

<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

W tej prostej funkcji po prostu wywołujemy funkcję MsiQueryFeatureState Instalatora Windows, przekazując kod produktu aplikacji i nazwę funkcji, o której pytamy. Jeśli Instalator Windows zwróci INSTALLSTATE_LOCAL zwraca wartość true, ponieważ oznacza to, że funkcja jest zainstalowana lokalnie.

Instalowanie i odinstalowywanie funkcji szablonów odbywa się tak samo łatwo.

<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

Gdy użytkownik kliknie element menu "Zainstaluj szablony", zostanie wykonane wywołanie pliku MsiConfigureFeature z kodem produktu, nazwą funkcji, którą chcemy skonfigurować, oraz wartością wyliczenia wskazującą, że chcemy zainstalować funkcję lokalnie. Podczas instalowania funkcji szablonów zostanie wyświetlone okno dialogowe postępu Instalatora Windows. Gdy okno dialogowe zniknie, szablony zostaną zainstalowane i będą gotowe do użycia. Gdy użytkownik wróci do menu Plik, podmenu templates wypełni nazwy szablonów zgodnie z powyższym opisem.

Podsumowanie

Korzystanie z "bezpłatnych" funkcji i interfejsu API uwidocznionego przez Instalatora Windows zapewnia nam kilka ciekawych możliwości, które znacznie pomagają zmniejszyć koszty pomocy technicznej, zwiększyć stabilność aplikacji i zwiększyć środowisko użytkownika. Przedstawione tutaj przykłady są nieco trywialne w naturze, ale miejmy nadzieję, że stworzy świetny punkt wyjścia do implementowania własnych unikatowych rozwiązań. Przyjrzeliśmy się niektórym dostępnym interfejsom API, ale z pewnością nie omówiliśmy ich wszystkich. Poświęć trochę czasu, aby zapoznać się ze wszystkimi funkcjami interfejsu API Instalatora Windows i wiem, że będziesz przyjemnie zaskoczony, jak łatwo można wykorzystać te stosunkowo niewykorzystane funkcje Instalatora Windows.

 

Informacje o autorze

Michael Sanford jest prezesem i głównym architektem oprogramowania dla 701 Software (http://www.701software.com). Przed utworzeniem 701, Michael był prezesem i dyrektorem generalnym ActiveInstall Corporation, który został nabyty przez Zero G Software. Usługa ActiveInstall osiągnęła rozgłos dla swoich rozwiązań do tworzenia Instalatora Windows. Michael jest certyfikowanym deweloperem rozwiązań firmy Microsoft (MCSD), certyfikowanym inżynierem systemów firmy Microsoft (MCSE) i MVP Instalatora Windows. Możesz przeczytać blog Michaela na stronie http://msmvps.com/michael.