I'm fairly proficient with the installshield products and am currently using Installshield 2009. My question has more to do with what to use than how to use it, so please move this into the correct topic if I've picked the wrong one.
I have a product I'm ready to release, but I want to separate out the core files from the application and make them redistributable.
I have a C++ NT service and 2 VB classic activex COM dlls I want to give my customers, but allow them to incorporate these files into their installation (I sell software tools and libraries to other developers) so they can use these files in their products regardless of what type of installation product they want to use. This would include all the dependencies they need - runtime files, librarys, etc.
I started to make a merge module, but it looks like you can't add merge modules to merge modules projects. So, if I want to include the Microsoft C++ 6.0 runtime library, I need to identify each file in that library and add them (something that a basic MSI project won't allow). Further, I'm not sure a merge module can be used by someone who might be a decent programmer, but weak on professional installation packages. And I have no idea of whether all installation products can use merge modules.
So, I think the best thing I can do is to create a separate installation package, but I would like for it to be completely silent - no screens, dialogs, prompts, etc.
I could create a custom action in my program to launch another setup while allowing my customers to deploy these installation files any way they choose. If it weren't for installing the service, this wouldn't be that big of deal.
If someone could point me in the right direction in terms of how I should do this, I would really appreciate it. Maybe it's as simple as creating a basic MSI project with no dialogs - I don't know. Any input would really be appreciated.
Thanks!
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.
Need advice...
Started by
Wired2Jam
, Nov 20 2009 15:29
5 replies to this topic
Stefan Krueger
-
- Administrators
- 13,269 posts
InstallSite.org
Posted 20 November 2009 - 17:22
| QUOTE |
| you can't add merge modules to merge modules projects |
That's correct, but you could specify module dependencies.
| QUOTE |
| whether all installation products can use merge modules. |
While Windows Installer is a standard, not all setup tools are using it. And while even some non-MSI setup tools can at least consume merge modules, some cannot.
Merge Modules are becoming less popular, especially for more complex redistributable packages, because you (as the developer of the redist) can service them. This is a problem if there's a security issue. All companies that redistributed your files need to ship updates for their products in order to distribute the fix to end users.
On the other hand, support for chained installations has improved, and tools verndors like InstallShield support prerequisites that can install a redist package before (instead of "inside") an msi setup.
So ypu should have a stand-alone redist install package. If you want to support merge modules in addition, you could ship the merge modules and create a stand alone redist setup that basically consists of these modules (so you don't have to maintain two projects).
Stefan Krüger
InstallSite.org twitter facebook
Stefan Krueger
-
- Administrators
- 13,269 posts
InstallSite.org
Posted 20 November 2009 - 17:23
For added bonus, create and ship a .prq file for those fo your customers who are using InstallShield. Thus you easily plug into InstallShield's prerequisite mechanism.
Stefan Krüger
InstallSite.org twitter facebook
Wired2Jam
-
- Full Members
- 3 posts
Posted 20 November 2009 - 19:08
I think I understand and that sounds like a great idea.
What I failed to mention (but still doesn't get in the way of your idea) is that I do not want my customer's end users to see my stuff.
For example, I make a widget other developers purchase because it's cheaper than them doing it themselves. They write their software using my widget and sell software to their customers who actually are the end users of everything all of us have done.
I want my widget to make my customer - the developer - look good and sell more product. But I don't want his/her user to see any references to my libraries while installing. The customer bought from him - not me. I don't care if the user is saavy enough to look under the hood to see those kinds of details. But I want the user to see my customer's stuff only as if that developer has done everything.
I love the prerequisite idea and will do that. And also, make the .prq file available for download on my support page.
Just thinking out loud, maybe I can avoid the hidden installation by removing all my product/company text from dialogs and make it something very generic that anyone can use (including me). Or should I keep it hidden?
The prerequisite idea was definitely the silver bullet answer I was looking for. I haven't been here for a while as I took a job with a different company where I don't do as many installations, but I can promise that without your help, there would be a lot less good installation packages out there. Once again, thanks very much for your help and advice.
What I failed to mention (but still doesn't get in the way of your idea) is that I do not want my customer's end users to see my stuff.
For example, I make a widget other developers purchase because it's cheaper than them doing it themselves. They write their software using my widget and sell software to their customers who actually are the end users of everything all of us have done.
I want my widget to make my customer - the developer - look good and sell more product. But I don't want his/her user to see any references to my libraries while installing. The customer bought from him - not me. I don't care if the user is saavy enough to look under the hood to see those kinds of details. But I want the user to see my customer's stuff only as if that developer has done everything.
I love the prerequisite idea and will do that. And also, make the .prq file available for download on my support page.
Just thinking out loud, maybe I can avoid the hidden installation by removing all my product/company text from dialogs and make it something very generic that anyone can use (including me). Or should I keep it hidden?
The prerequisite idea was definitely the silver bullet answer I was looking for. I haven't been here for a while as I took a job with a different company where I don't do as many installations, but I can promise that without your help, there would be a lot less good installation packages out there. Once again, thanks very much for your help and advice.
Stefan Krueger
-
- Administrators
- 13,269 posts
InstallSite.org
Posted 20 November 2009 - 21:21
The problem with prerequsites is that they will be listed in the prerequisite installation dialog. Maybe you can put some generic name there.
Stefan Krüger
InstallSite.org twitter facebook
Wired2Jam
-
- Full Members
- 3 posts
Posted 23 November 2009 - 22:23
I just wanted to follow up to let you (and/or anyone else paying attention) that the prerequisite is the perfect solution. I was able to create a Basic MSI installation project (the easiest type for me) with more generic labeling, wrap that installation up in a package for the web executable, and add that as the only file needed in a prerequisite. So, my end user can use either method (the pftw on it's own, or integrate the pftw through the prerequisite file).
Please accept another "well done" by a grateful member of this web site.
Please accept another "well done" by a grateful member of this web site.