2011-02-11 9 views
13

Szukałem listy akcji i ich sekwencji podczas uruchamiania konfiguracji WiX. W jakiś sposób oficjalna strona internetowa nie wydaje żadnych informacji.Sekwencja działań WiX

Podstawowym problemem jest prawidłowe planowanie działań niestandardowych. Zazwyczaj muszę zarejestrować DLL z regsvr32.exe, a to można zrobić tylko po skopiowaniu plików na dysk twardy. Jednak niestandardowe działanie nie powiodło się z komunikatem o błędzie "nie znaleziono pliku".

To, co zrobiłem, to analizowanie dziennika mojego MSI za pomocą Edytora WiX i odkryłem, że Action InstallFiles istnieje więcej niż jeden raz. Skutecznie pliki są zapisywane dopiero po raz drugi. Więc zmieniłem niestandardową akcję do następujących elementów:

<Custom Action="RegisterShellExt" Before="InstallFinalize"> 

Oto sekwencja Mam pochodzących z dzienników mojego MSI:

Action start 15:16:49: INSTALL. 
Action start 15:16:49: PrepareDlg. 
Action start 15:16:49: AppSearch. 
Action start 15:16:49: LaunchConditions. 
Action start 15:16:49: ValidateProductID. 
Action start 15:16:49: DIRCA_NEWRETARGETABLEPROPERTY1.5D429292039C46FCA3253E37B4DA262A. 
Action start 15:16:50: CostInitialize. 
Action start 15:16:50: FileCost. 
Action start 15:16:50: CostFinalize. 
Action start 15:16:50: WelcomeDlg. 
Action 15:16:51: LicenseAgreementDlg. Dialog created 
Action 15:16:53: CustomizeDlg. Dialog created 
Action 15:16:55: VerifyReadyDlg. Dialog created 
Action start 15:16:56: ProgressDlg. 
Action start 15:16:56: ExecuteAction. 
Action start 15:16:58: INSTALL. 
Action start 15:16:58: AppSearch. 
Action start 15:16:58: LaunchConditions. 
Action start 15:16:58: ValidateProductID. 
Action start 15:16:58: CostInitialize. 
Action start 15:16:59: FileCost. 
Action start 15:16:59: CostFinalize. 
Action start 15:16:59: InstallValidate. 
Action start 15:17:00: InstallInitialize. 
Action start 15:17:08: ProcessComponents. 
Action 15:17:09: GenerateScript. Generating script operations for action: 
Action ended 15:17:09: ProcessComponents. Return value 1. 
Action start 15:17:09: UnpublishFeatures. 
Action start 15:17:09: RemoveShortcuts. 
Action start 15:17:09: RemoveFiles. 
Action start 15:17:09: InstallFiles. 
Action start 15:17:10: CreateShortcuts. 
Action start 15:17:10: RegisterUser. 
Action start 15:17:10: RegisterProduct. 
Action start 15:17:10: PublishFeatures. 
Action start 15:17:10: PublishProduct. 
Action start 15:17:10: ConfigureInstaller. 
Action start 15:17:10: InstallFinalize. 
Action 15:17:10: ProcessComponents. Updating component registration 
Action 15:17:12: InstallFiles. Copying new files 
Action 15:17:21: CreateShortcuts. Creating shortcuts 
Action 15:17:21: RegisterProduct. Registering product 
Action 15:17:23: ConfigureInstaller. [[note: CustomAction]] 
Action 15:17:22: PublishFeatures. Publishing Product Features 
Begin CustomAction 'ConfigureInstaller' 
Action 15:17:28: RollbackCleanup. Removing backup files 
Action ended 15:17:28: InstallFinalize. Return value 1. 
Action start 15:17:28: RegisterShellExt. [[note: CustomAction]] 
Action ended 15:17:33: INSTALL. Return value 1. 
Action start 15:17:35: ExitDialog. 

Czy ktoś wie notowane?

Odpowiedz

13

Krótka odpowiedź - powinieneś zrobić odłożoną akcję i zaplanować po InstallFiles (jeśli zależy od zainstalowanego pliku, co myślę, że robi).

Długa odpowiedź - powinieneś zapoznać się z terminem wykonania skryptu. Read more about it on MSDN. Gdy zobaczysz plik InstallFiles za pierwszym razem w pliku dziennika, to wtedy, gdy natychmiastowe akcje zostaną uruchomione, a odroczone akcje zostaną zapisane i zaplanowane w skrypcie instalacyjnym. Drugi raz to czas, kiedy faktycznie wykonuje (i instaluje pliki). Jeśli sprawisz, że Twoje działanie zostanie odroczone, zobaczysz takie samo zachowanie w pliku dziennika.

Może to zabrzmieć niezbyt wyraźnie, ale nie może tak długo, dopóki nie przeczytasz więcej o sposobie, w jaki ma działać.

+0

dzięki! na razie trzymam się krótkiej odpowiedzi :) właściwie odpowiedź jest dla mnie jasna. najpierw przygotowują zadania, jednak jeśli zrobisz to natychmiast, nie zaczekasz, aż rozpocznie się właściwa praca. –

+1

Ale czy istnieje oficjalny wykaz sekwencji działań? W przeciwnym razie mamy po prostu próbę i błąd, który wydaje się śmieszny ?! – markmnl

5

Do rejestrowania plików DLL najlepiej jest unikać samodzielnej rejestracji.

Używamy polecenia HEAT do wygenerowania fragmentu WiX, który rejestruje dla nas.

Zastosowanie

heat file myfile.dll -o myfile.wxs 

Zaletą jest to, że wpisy w rejestrze są zainstalowane i prawidłowo usunięte i nie ma problemów z tym, czy plik został zainstalowany lub nie w momencie rejestracji jest wykonywana.

+0

dzięki za wejście. Nie wiedziałem, że istnieje specjalny skrypt do rejestrowania bibliotek dll. na razie zachowam akcję niestandardową, ale gdy tylko reszta mojego instalatora będzie działać poprawnie, zobaczę, jak działa polecenie ogrzewania. –

+0

Próbowałem użyć narzędzia do ogrzewania, ale nie mogę pominąć ostrzeżenia HEAT5150. Domyślam się, że w wyniku tego ostrzeżenia wynikowy plik wxs nie zawiera żadnego użytecznego kodu, tylko fragment "Directory" i "Component". tutaj jest pełny komunikat ostrzegawczy: 'heat.exe: ostrzeżenie HEAT5150: Nie można zebrać danych z pliku, który miał być plikiem SelfReg DLL: (...) Cel wywołania został zgłoszony. " –

+1

Niektóre rzeczy, które znalazłem na liście adresowej WiX: 1) Może nie działać z 64-bitowymi plikami DLL. 2) Spróbuj uruchomić ciepło jako Administrator 3) Spróbuj uruchomić RegSpy, jak wspomniano na tej stronie http://www.installsite.org/pages/en/msi/tips.htm, która utworzy plik .reg dla ciepła do konwersji. wxs. 4) Upewnij się, że nie brakuje brakujących zależności. – AntonyW