menos161.5524908181319658E12 asked a question.
Dinamic components
Hello everybody.
I'm a software developer with a medium knowledge level about MSI standart ... more or less .... and I bring you a very interesting question:
The software that I package usually works 'typically' with the following tree structure:
INSTALLDIR
|
|_ "Main service program.exe"
|_ "Secundary program1.exe"
|_ "Secundary program2.exe"
|_ "Dependency1.dll"
|_ "Dependency2.dll"
|_ "config file1.ini"
|_ "config file2.ini"
Usually the main service program receives data through TCP/IP and process them with the secundary programs, for send back later the processed data (again using tcp/ip protocol).
Well, this isn't matters is only for contextualize ...
But now, some kind of customers want to work with the following 'multiple' structure:
INSTALLDIR
|
|--Subdirectory1
| |
| |_ "Main service program.exe"
| |_ "Secundary program1.exe"
| |_ "Secundary program2.exe"
| |_ "Dependency1.dll"
| |_ "Dependency2.dll"
| |_ "config file1.ini"
| |_ "config file2.ini"
|
|
|--Subdirectory2
| |
| |_ "Main service program.exe"
| |_ "Secundary program1.exe"
| |_ "Secundary program2.exe"
| |_ "Dependency1.dll"
| |_ "Dependency2.dll"
| |_ "config file1.ini"
| |_ "config file2.ini"
|
|--Subdirectory3
| |
| |_ "Main service program.exe"
| |_ "Secundary program1.exe"
| |_ "Secundary program2.exe"
| |_ "Dependency1.dll"
| |_ "Dependency2.dll"
| |_ "config file1.ini"
| |_ "config file2.ini"
.
.
.
Basically they want to work with multiple and parallel instances and environments of the software... so I'm looking for a way to make that the installer manage all this crazy design.
For the single installation I already have (since a few years) a good designed BASIC-MSI with all its components well organized. But now, I would like write some kind of magic script that reorganize the number of the components - and its {GUID}- to get a MSI internal database flexible and - for my case - dynamics, because maybe one customer will want only 3 instances of my software, other will want 20 instances... and others only one instance.
I'm thinking in some kind of scripts that will reorganize the internal MSI database to adapt the number,guids and destiny of defined components with the selected parameters in user interface at installation time. I think that it's possible but I'm not sure.
The problems of the maintenance and the upgrades will come, but for the moment I would like to know if It is a good idea to try the design that I'm thinking or if that isn't a good idea under the BASIC-MSI legacy and with Installscript language.
Should I try with Installscript projects?? It could be more realizable? I hope you have understood me at least
Best regards.
http://blog.deploymentengineering.com/2006/10/multiple-instance-msis-and.html
http://msdn.microsoft.com/en-us/library/aa369528(v=vs.85).aspx
You need to isolate each instance. So look deep intothose issues.