2010-01-25 13 views
5

Mam podstawowe WIX niestandardową akcję:WIX C++ klienta Action

 UINT __stdcall MyCustomAction(MSIHANDLE hInstaller) 
     { 
      DWORD dwSize=0; 
      MsiGetProperty(hInstaller, TEXT("MyProperty"), TEXT(""), &dwSize); 
      return ERROR_SUCCESS; 
     } 

dodany do instalatora:

<CustomAction Id="CustomActionId" FileKey="CustomDll" DllEntry="MyCustomAction"/> 
    <InstallExecuteSequence> 
     <Custom Action="CustomActionId" Before="InstallFinalize" /> 
    </InstallExecuteSequence> 

Problemem jest to, że bez względu na to, co zrobisz, hInstaller uchwyt nie jest ważny. Ustawiłem akcję, aby zatwierdzić, odłożyć, zmienić miejsce w sekwencji InstallExecute, hInstaller jest zawsze niepoprawny.

Każda pomoc zostanie doceniona. Dzięki.

+0

W jaki sposób jest ona nieważna? Czy otrzymujesz błąd z połączenia API? –

+0

Jeśli wykonam wywołanie, które używa uchwytu, funkcja zwróci komunikat o błędzie Invalid_Handle. –

+0

ignorując uchwyt, czy sama funkcja jest wywoływana poprawnie? – saschabeaumont

Odpowiedz

7

Musisz wyeksportować zwaną funkcję tak MSI można nazwać użyciem undecorated C nazwę stylu

Wymień kod z tego

extern "C" _declspec(dllexport) UINT __stdcall MyCustomAction(MSIHANDLE hInstall); 

    extern "C" UINT __stdcall MyCustomAction(MSIHANDLE hInstall) 
    { 
     DWORD dwSize=0; 
     MsiGetProperty(hInstaller, TEXT("MyProperty"), TEXT(""), &dwSize); 
     return ERROR_SUCCESS; 
    } 
3

jak wspomniano here, jedynym sposobem przezwyciężenia maglowania od a __stdcall jest użycie:

#pragma comment(linker, "/EXPORT:[email protected]@@23mangledstuff#@@@@")

to tworzy drugi ENTR y w tabeli eksportu DLL.

+2

Innym sposobem na zapewnienie niezmianej nazwy funkcji jest uwzględnienie w eksporcie biblioteki DLL, wyeksportowanie jej do pliku DEF i dodanie jej do właściwości programu Linker (Linker -> Input -> File Definition File). – Pierre