10 replies to this topic

[felixmat]

Hi

What is the difference Standard Dll Vs MSI Dll when creating a custom action, when would you use them?

Thanks!

[mpento]

Hello felixmat,

This is vague, so I am providing this information based on what I can glean from the IS2008 IDE.

I am interpreting "standard DLL" as a library that either exists on the target system (hence, the reason why when creating a CA of this type, the drop down provides the option "Destination machine search path" and it does not provide this option for MSI DLL's) or a library which was developed potentially with another purpose in mind.

I guess an example might be: I often use the OutputDebugMsgA() Windows Kernel32.dll function in my installs to provide runtime debug messages. This might be what they mean by standard dll.

On the other hand, the MSI DLL, would appear to be a DLL developed specifically for use by the MSI engine for install purposes, i.e. adopting the rules outlined in the InstallShield sample documentation for function exporting and return values in MSI based custom libraries.

I think my explanations are correct, the IS docs seem to be a bit sparse on this topic. If someone else has any information, please feel free to correct me.

Thanks,
Mike

[felixmat]

Thanks Michael!

Differences that you mentioned makes sense, but I have also used standard dll to call a function which is in a dll that is packaged with a product, so I guess you can also use a standard dll as a MSI dll ....here are some more differences that I found...

MSI DLL Standard DLL
------- ------------
32/64-bit Only 32-bit
Can pass only one argument Can pass multiple arguments
to a function call. to a function call.

[Zweitze]

I only use MSI dlls. Using an MSI dll you pass a handle, with that handle you can access anything in MSI, eg. properties, features, feature states, install folders, tables etc.

A long time ago using an older version I experienced the following problems with standard dlls:
1. Only Ansi, no unicode - although that could be better now.
2. Poor support for string arguments passed 'by reference'. A buffer is generated, but it is not always sufficient, and it's impossible to manipulate its size.
3. You can't change the arguments in major upgrades (meaning, in a higher version you cannot change the number of arguments and type of arguments). The installshield framework gets confused and applies the newest definition on the old version - so when the old version calls the CA it crashes. This took me a long time to find out! A blatant bug which could be fixed by now, at least you can workaround it by not changing the parameters of the function, but create a new function with the desired parameters.
4. Only immediate custom actions are supported, no deferred CAs, roll back CAs etc.

[Stefan Krueger]

A "MSI DLL" is a DLL that exports a function that mateches the prototype defined in the MSI documentation. This is the only type of DLL that Windows Istaller can use directly as a custom action.

A "Standard DLL" can have (virtually) any prototype. InstallShield adds a wrapper around it that shaows Windows Installer only the MSI DLL interface and translates all additional parameters into properties. So essentially your cuatom action calls a DLL (provided by InstallShield) which calls another DLL (your Standard DLL).

[felixmat]

Stefan

What does "matches the prototype defined in the MSI documentation" mean?

By prototype are you referring to the arguments passed to the *dll?

When I create a standard or MSI dll, I see options to pass multiple arguments. Can you pls. give more information?

[Stefan Krueger]

For a "MSI DLL" custom action, the exported function must match the prototype documented at http://msdn2.microso...y/aa368338.aspx

The only argument that gets passed to a MSI DLL is a handle. sing this handle the DLL can then read properties using MsiGetProperty.

[felixmat]

Ok.

But, what confuses me is that when I create a MSI dll, I am given the option to pass multiple arguments (I am using the Custom action wizard) and once the custom action is created I see all the arguments that I defined being passed to the dll in the property tab of that custom action.

If the MSI handle is the only argument what are these other arguments that we define when creating the custom action?

[Zweitze]

If you look in the docs for Custom Action (see http://msdn2.microso...y/aa368062.aspx ) you'll see that any CA has a definition of four fields, where Action is identifying the CA, Type defines the CA type (like a DLL call), and the meaning of Source and Target depend on the CA type.
In the case of a DLL call (see http://msdn2.microso...y/aa368075.aspx ) they are the name of the DLL and the name of the function in the DLL.

This function is called with one parameter and it should return one value. The parameter is a handle, and the DLL function can use that handle to access the installation information. For instance, if you want to retrieve the product code, your DLL could call MsiGetProperty(hMSI, "ProductCode", szBuf, lenBuf). If you want to access a table in the database, you call MsiGetActiveDatabase etc. etc.
The DLL function must return a 32-bit value, this is interpreted by the installer - it can tell everything went OK, that the user asked to cancel the install, or that the installation has failed.

InstallShields' Standard DLLs use this route too, but they are rerouted to an included DLL by InstallShield. This DLL looks up the other information (name of standard DLL to load, name of function in standard DLL to call, argument of this function) and then it attempts to load the DLL, retrieve the arguments, call the function, write the changed arguments back, and unload the dll.

[memetb]

I must be missing something crucial. I have a DLL which for all intents and purposes is an MSI dll. I have three functions in it:
UINT __stdcall ConfigureService( MSIHANDLE hInstall )
UINT __stdcall UnregisterServe( MSIHANDLE hInstall )
UINT __stdcall ShowClientInfoDialog( MSIHANDLE hInstall )

Yet, when I compile my InstallShield Express (14) project, it complains that deferred actions are not supported by Standard DLLs (same error as above).

Is there a flag somewhere that notifies that a dll is an MSI dll in particular?


This is doubly annoying because this is a project which worked and compiled just fine until I upgraded from an earlier version of InstallShield Express.

[Stefan Krueger]

There's no auto-detection. You define the custom action type (MSI-DLL or Standard-DLL) when you create it.
Maybe the custom action type got changed during the conversion? Can you switch the project file format from Binary to XML in Express? If yes: switch to XML and then look at the custom action type number. If not: rename the project file to *.msi and open it in Orca. In any case: make a backup of the project file first.