3 replies to this topic

[Christoph]

Hi,

i've a question concerning the organization of components within Devstudio 9.0(Basic MSI project).

I would like to make a basic MSI project that can install two main applications, lets say application X and application Y. Application X exist out of 1 exe and 30 dll's. Application Y exists out of 1 exe and also 30 dll's. Some dll's have the same name but are not the same(different compile).

I've read within the help of Devstudio9.0 that every dll need to have his own compenent. Is this true?? I find this not a good way because every dll is then the keyfile within his own component and every key file needs to be linked static to his component.

Since we make every day an automatic build of application X and application Y and need to build also automatically the installer, it is difficult to do this automatically with the 'Setup best practices'-rules.

I would like to know how you people organize your component structures of your Devstudio(...developer)-projects?!!

Thanks for any information.

[KathyMorey]

You read correctly - every dll should have its own component. If you choose to ignore this "rule", you could cause yourself problems if you intend your customers to use the "modify" or "repair" features in the Add/Remove Programs applet, and problems when you try to do updates, unless you intend to *always* do major upgrades (uninstall and reinstall).

It's just a "limitation" of using MSI that you have to live with....

HTH
Kathy Morey
Installation Developer
SER Solutions

[Christoph]

I find this a serious 'limitation' of a MSI project. Within this way, a project is almost not maintanable.
It is for me impossible to build a MSI project automatically then because you always have to look that their are no extra dll's are dll's removed out of the project.

I find this a good way of working for applications with 5 dll's but projects with moren than 50 dll's and a whole help library like we have, ... I need to define more than 100 components!?

Are there people who also need to make installers for big projects and organize their components within another way as the way menioned by 'setup best practises'??

Any feedback is welcome.

[Zweitze]

I have a project of approx. 30 DLLs and 8 EXEs, plus some other stuff like help files, TLBs, etc. This must be packaged in eight different setups (the DLLs and EXEs are the same over the setups that include them).

Instead of defining over 200 components, I am using merge modules: all related components are packaged in an MSM, and this MSM is included in every setup that needs it. I have 12 merge module projects.

BTW I would never define components with a dynamic link to a folder, for installing DLLs or EXEs. In my experience, every time one is added, it needs some attention anyway: sometimes an extra registry key, a special install folder, a shortcut, etc.

In my experience, if you deviate from the 'best practices' suggestions, you will run into trouble if you try to get the following features:
- Install on demand / install at first use / advertizing.
- Repair of broken components.
- Future upgrades (higher versions).
As long as you don't define key paths, turn advertizing off, and know certain that a higher version will never see the day, you can consider leaving the recommended practises.

Hope this helps