Jump to content


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.
Photo

Same component to different destinations


9 replies to this topic

andrei_bejan

andrei_bejan
  • Full Members
  • 3 posts

Posted 25 October 2007 - 10:52

Hello,
I would like to create an install application that has two features:
Feature1 with the destination propriety set to “[INSTALLDIR]MyApp/Feature_1”
Feature2 with the destination propriety set to “[INSTALLDIR]MyApp/Feature_2”
Each feature should have two components:
Feature1
“Comp1_common” with the destination propriety set to [INSTALLDIR] MyApp/Feature_1/Common
“Comp2” with the destination propriety set to [INSTALLDIR] MyApp/Feature_1/Resources
Feature2
“Comp1_common” with the destination propriety set to [INSTALLDIR] MyApp/Feature_2/Common
“Comp3” with the destination propriety set to [INSTALLDIR] MyApp/Feature_2/Resources

I am able to associate each component to its feature. I am able too to set the destination property for the “Comp1_common” and “Comp2” components inside the “Feature1” and for the “Comp3” component inside the Feature2.
But I am unable to set two different destination properties for the “Comp1_common” component!
This component is common to both features but each feature has a different path on the target disk so I need to put different destination paths for the “Comp1_common” component, one for the Feature1 and one for the Feature2
In the documentation I can read:
“A component can be associated with as many features or subfeatures as necessary.”
Or
“Each component can have a different destination location for its files.”

But I didn’t find how to associate two different paths to only one component.

Thank for your help.

Regards,


MrSmersh

MrSmersh
  • Full Members
  • 48 posts

Posted 25 October 2007 - 13:15

Is bad practice so is not readily possible.
In any case you will not be able to trick msi to install the same component twice and on different paths.
Maybe you can create a duplicate component and have feature 1 component feature 2 duplicate, but even so is bad practice...


Zweitze

Zweitze
  • Full Members
  • 522 posts

Posted 26 October 2007 - 13:22

I know one method to install one component multiple times in multiple folders:
1. Create a Merge Module with your component, installing the component in INSTALLDIR.
2. Include that Merge Module in multiple products. So you need multiple projects using your Merge Module, every product installing your component once.

The component will be installed in the folder(s) of the feature(s) containing the merge module.

Either way it's a bad practice.
Consider installing the files only once in ProgramFiles\Company\App or ProgramFiles\CommonFiles\Company.
If the files will be modified by the app (eg. they are some kind of data files or sample files), your app should copy the file to a data location like MyDocuments\Company\App and modify that copy, so the user data is not lost when your app is repaired.

Edited by Zweitze, 26 October 2007 - 13:23.


Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 29 October 2007 - 17:18

You could use the DuplicateFile table to copy the files to the other directory.

MrSmersh

MrSmersh
  • Full Members
  • 48 posts

Posted 29 October 2007 - 19:26

I'm not familiar with DuplicateFile it works with features also?
I needed something similar, even just at file level, and if I knew about DuplicateFile my life would have been a lot easier.


Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 29 October 2007 - 20:08

The DuplicateFile table is documented at http://msdn2.microso...y/aa368335.aspx
In InstallShield you can access it from the Direct Editor.

andrei_bejan

andrei_bejan
  • Full Members
  • 3 posts

Posted 02 November 2007 - 13:16

Hello,
Thanks for all your advices.

I don’t understand why it is a bad practice to copy one component to two different paths?
In my opinion it is a very usual situation. Let’s say that with my installer I would like to install two applications that have some common parts. It should be very easy. The meaning of a component should be to put inside some common code that can be used by more than one application. Or maybe I didn’t understand the scope of the component in an InstallShield project?

Thanks for clarifications.

Regards,


andrei_bejan

andrei_bejan
  • Full Members
  • 3 posts

Posted 02 November 2007 - 13:23

Hello,

And something else:
I am not thinking to put into a component some code that I expect to change. In a component I would like to put only read-only data, some code (useful routines) that I use on all other applications, it is some kind of a common nucleus to all my applications.


MrSmersh

MrSmersh
  • Full Members
  • 48 posts

Posted 02 November 2007 - 13:57

Usually when you have more application with common parts the usual way is to create a merge module that you will use on the setups of those applications. It has some issues on upgrade but this is another discussion, and yes for time being is the recommended way.

A component is meant to be use by features, for example program component cam be associated with main program feature and reporting feature, it is a way to make let’s say modular, maybe is not a good term… You choose what features to install, features use components to avoid adding the same files and logic on in each feature, you just add the component and that’s it.


Zweitze

Zweitze
  • Full Members
  • 522 posts

Posted 03 November 2007 - 02:05

QUOTE
I don’t understand why it is a bad practice to copy one component to two different paths?
In my opinion it is a very usual situation. Let’s say that with my installer I would like to install two applications that have some common parts.

That's Windows programming for you. On a normal Windows Installation you find hundreds, maybe thousands of programs. Every single program uses a file called NTDLL.DLL. Now if you look on your computer you will find one copy of NTDLL.DLL, not hundreds. (Actually you'll find some more, these copies are uninstall information for some hot fixes and service packs).

Apparently it's good practice to put shared code in one place.

The alternative was exercised in DOS, every piece of software had to include hundreds of printer drivers because there was no central location for this stuff. Further it had to support multiple types of graphics devices, modems etc.etc.

Edited by Zweitze, 03 November 2007 - 02:05.