Client & Server MSI packages
How would you package software that is divided into client and server? The server installs files/DLLs but does not register anything. The client registers the DLLs which the server installed.
1. Server MSI installs plugin.dll to \\SERVER\SHARE\
2. Client MSI runs from another computer and registers plugin.dll which is located on \\SERVER\SHARE\plugin.dll (The client knows that plugin.dll is located on \\SERVER\SHARE\)
Running regsvr32 is not an option. I have solved it now by extracting the registry keys for registering plugin.dll and importing it to the client MSI, replacing the path with \\SERVER\SHARE\ (a property called SERVERPATH).
It's the registration of DLLs that is a bit tricky. Installing EXEs and other resources that does not require registration is easy. Any input/experience on this subject is welcome!
1. Server MSI installs plugin.dll to \\SERVER\SHARE\
2. Client MSI runs from another computer and registers plugin.dll which is located on \\SERVER\SHARE\plugin.dll (The client knows that plugin.dll is located on \\SERVER\SHARE\)
Running regsvr32 is not an option. I have solved it now by extracting the registry keys for registering plugin.dll and importing it to the client MSI, replacing the path with \\SERVER\SHARE\ (a property called SERVERPATH).
It's the registration of DLLs that is a bit tricky. Installing EXEs and other resources that does not require registration is easy. Any input/experience on this subject is welcome!
0 Comments
[ + ] Show comments
Answers (1)
Please log in to answer
Posted by:
jmaclaurin
13 years ago
Just to clarify, the first MSI (server side install) creates or puts files in a share so that when the second MSI (client side install) runs, it can perform the actual install.
If this is the case, it sounds like the first MSI is creating an Administrative install point so that the second MSI can perform the actual installation. This is fairly typical for mass deployment type scenarios using servers like SMS, LANDesk, SCCM, etc, which is a server push - client pull type relationship in software distribution from a network share. For example, MS Office is designed to be mass deployed in exactly this way.
It doesn't sound like a problem unless this isn't case.
If this is the case, it sounds like the first MSI is creating an Administrative install point so that the second MSI can perform the actual installation. This is fairly typical for mass deployment type scenarios using servers like SMS, LANDesk, SCCM, etc, which is a server push - client pull type relationship in software distribution from a network share. For example, MS Office is designed to be mass deployed in exactly this way.
It doesn't sound like a problem unless this isn't case.
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
so that the conversation will remain readable.