Hi!
I am new to installations and I am looking for best practices with the help of WISE and windows Installer 4.0. We have 5 diffrent projects running with diffrent developer teams. We want to end up with a simple MSI installation for all these products/Programs. We have been looking for a simple way of doing this and mergeModules looks like it's the bestway. But is it? I think you can do this with MSM files merged into a MSI file. The MSI will only be a shell for the MSM's.
I know that you loose the concept of using patches but we do not have to use that in our product. Is it also possible to make command line installations of features built with only MSM's? That is if I want to only install one of my modules/features MSM's from the list.
I know that mergemodules are ment to be shared by a bunch of MSI's but I want to implement a way of releasing and packing in a simple way. Every project/developer is now responsible for packing the MSM to suit the release MSI.
My MSI project will then only house 5 MSM's.
Is there anything I miss and will have problems with this form of developing MSI installtions?
I hope you understand my question and can answer.
This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.
Best practices?
Started by
masterjonte
, Dec 07 2007 14:04
3 replies to this topic
Zweitze
-
- Full Members
- 522 posts
Posted 10 December 2007 - 00:01
I did some work that way, it works great if these MSMs just contain files, registry keys etc. I was using InstallShield and found out that this method has some advantages in building, just creating a test build was much faster when InstallShield can include pre-built MSMs, because the including is faster than InstallShield's compression engine.
There are a few downsides you'll need to take care of:
- An MSM cannot include UI, so if any feature needs to communicate with the user you'll need to solve that in the MSI.
- If an MSM contains DLL or VBScript Custom Actions, beware that certain property names and component names will be mangled when the MSM is merged into the MSI.
- MSMs may install shortcuts into the Start menu, but when multiple MSMs install shortcuts in the same Start menu you'll have a really hard time to control their order.
- If the MSM contains information in the Class or ProgId table, then you can assign that MSM to just one feature in the MSI. This may get nasty when other MSMs depend on this particular MSM, eg. when it contains some core files used by other MSMs.
The reason is that the information in the Class and ProgId tables will be linked to a feature.
Hope this helps
There are a few downsides you'll need to take care of:
- An MSM cannot include UI, so if any feature needs to communicate with the user you'll need to solve that in the MSI.
- If an MSM contains DLL or VBScript Custom Actions, beware that certain property names and component names will be mangled when the MSM is merged into the MSI.
- MSMs may install shortcuts into the Start menu, but when multiple MSMs install shortcuts in the same Start menu you'll have a really hard time to control their order.
- If the MSM contains information in the Class or ProgId table, then you can assign that MSM to just one feature in the MSI. This may get nasty when other MSMs depend on this particular MSM, eg. when it contains some core files used by other MSMs.
The reason is that the information in the Class and ProgId tables will be linked to a feature.
Hope this helps
masterjonte
-
- Full Members
- 8 posts
Posted 10 December 2007 - 10:58
Okej! Thanks for the answer.
Yes, my MSM's include alot of DLL:es and cutom actions. They will be mangled, broken for certain property names ??? I have to test this further...
I hope shortcuts will be no problem, we will have a organized shortcuts in a specific MSM build document, telling how to organize all.
- If the MSM contains information in the Class or ProgId table, then you can assign that MSM to just one feature in the MSI. This may get nasty when other MSMs depend on this particular MSM, eg. when it contains some core files used by other MSMs.
The reason is that the information in the Class and ProgId tables will be linked to a feature.
Okej I think I understand, If a feature is dependent of another and I split them at install time an the user install one of them it will not work. So I have to tell everyone to think of this when they build MSM's.
Thanks... I think I will test this and give it a try
Yes, my MSM's include alot of DLL:es and cutom actions. They will be mangled, broken for certain property names ??? I have to test this further...
I hope shortcuts will be no problem, we will have a organized shortcuts in a specific MSM build document, telling how to organize all.
- If the MSM contains information in the Class or ProgId table, then you can assign that MSM to just one feature in the MSI. This may get nasty when other MSMs depend on this particular MSM, eg. when it contains some core files used by other MSMs.
The reason is that the information in the Class and ProgId tables will be linked to a feature.
Okej I think I understand, If a feature is dependent of another and I split them at install time an the user install one of them it will not work. So I have to tell everyone to think of this when they build MSM's.
Thanks... I think I will test this and give it a try
Zweitze
-
- Full Members
- 522 posts
Posted 11 December 2007 - 00:31
| QUOTE |
| Yes, my MSM's include alot of DLL:es and cutom actions. They will be mangled, broken for certain property names ??? |
The idea is, when your MSM has an entry in the property table like this:
Name: TEST
Value: "some value"
then this property will be renamed to
Name: GUID.TEST
Value: "some value"
where GUID is the ModuleID of the MSM. This behaviour allows merging of multiple (different) MSMs that all have this property. The renaming is OK, eg. if you use the same property for a component condition, then that condition will be changed too. But the big exception is VBScript and DLL custom actions, since the merging process of your MSM does not know whether you use that property etc. Therefore you should be prepared.
The same thing happens with Component names - they get renamed in a similar way, so if you have a Custom Action that retrieves a component state then that CA must be aware of the renaming.
This renaming situation is also the reason it's hard to predict the order of the shortcuts in the start menu. The items are ordered by the Shortcut value in the Shortcut table, and guess what... just like properties, all shortcuts get an identifier at the beginning of its name.
To test this yourself, just create a simple MSM with a component, file, shortcut, and public property, then include this MSM in an empty MSI project with just one feature. Build the MSM, then the MSI, and open the MSI in Orca.
| QUOTE |
| Okej I think I understand, If a feature is dependent of another and I split them at install time an the user install one of them it will not work. So I have to tell everyone to think of this when they build MSM's. |
No, the fact is that you can link classes and progids to exactly one feature. But an MSM may be linked to multiple features. If you do create a MSI with one MSM linked to multiple features, and that MSM contains a class or progid, the stuff may break. The workaround is to create a top level feature (eg. "Software") and link the 'shared' MSM to that feature.
I hope this clears the issues up.
Edited by Zweitze, 11 December 2007 - 00:31.