Hello
For the past few years I have been using Installshield Professional 6.2 for installations of my applications. (A mix of Visual Basic 6 and .NEt applications)
Installshield Professional 6.2 is now quite old and the aim is to upgrade the installations to be more 'current'.
The plan is to use MSI and/or upgrade to Instalshield 2010? for future installations.
My questions:
How does Installshield or any other 3rd party tool help with MSI installs? Why not just use MSI? Is MSI very difficult to use, I'm guessing it must be?
I think with a tool like Installshield 2010 or similar the installation can be totally independant of MSI? So is the reason for using MSI at all just one of fitting in with a Microsoft way of doing things or is there some real advantage to using MSI?
Thanks in advance and sorry if my questions are obvious ones.
Sean
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.
Some Daft Questions?
Started by
Seany
, Aug 14 2009 11:18
5 replies to this topic
luke_s
-
- Full Members
- 532 posts
Posted 14 August 2009 - 23:55
By all means you can directly create your MSI file without install shield. It's really just a database so installshield just populates this for you instead of you having to add EVERY entry manually.
It all depends on how much experience you have with MSI and how many changes your installation needs to make to the system.
InstallShield gives you a nice wizard and GUI to help pick up you system changes and files, and also gives you a GUI editor you so can create your installation dialogs. Doing this directly inside the MSI is a bit of a pain.
There are also other tools out there that build MSI's not just InstallShield. InstallSite has a list of there somewhere on the site as well.
And yes, you dont HAVE to use and MSI, but it provides built in functiuonality for things like roll back, add/remove programs and all of the little bits and pieces that you would need to code yourself if you didnt create an MSI. Some companies also require the use of MSI when they deploy (i.e. they use active directory) so sometimes you dont have a choice.
There are probably lots of other bits an pieces I can add, but I would recommend reading up a bit on this site, and on google so you can find a bit more out about the MSI technology and what it can do, and how you can create installers with it.
Just my 2 cents :-)
It all depends on how much experience you have with MSI and how many changes your installation needs to make to the system.
InstallShield gives you a nice wizard and GUI to help pick up you system changes and files, and also gives you a GUI editor you so can create your installation dialogs. Doing this directly inside the MSI is a bit of a pain.
There are also other tools out there that build MSI's not just InstallShield. InstallSite has a list of there somewhere on the site as well.
And yes, you dont HAVE to use and MSI, but it provides built in functiuonality for things like roll back, add/remove programs and all of the little bits and pieces that you would need to code yourself if you didnt create an MSI. Some companies also require the use of MSI when they deploy (i.e. they use active directory) so sometimes you dont have a choice.
There are probably lots of other bits an pieces I can add, but I would recommend reading up a bit on this site, and on google so you can find a bit more out about the MSI technology and what it can do, and how you can create installers with it.
Just my 2 cents :-)
VBScab
-
- Full Members
- 436 posts
Posted 17 August 2009 - 11:25
| QUOTE (luke_s @ 2009-08-14 22:55) |
| Doing this directly inside the MSI is a bit of a pain. |
What a gift for understatement you have!
Throwing a newcomer into editing MSIs without a GUI...do you have an interest in a mental health clinic?
My two cents would be:
- read up on Windows Installer. MSDN is a good resource, as ever
- download the WI SDK. It includes a tool called Orca (which by some bizarre irony doesn't get installed per se but dropped as an MSI in the SDK's folder tree).
EDIT:
I just looked to see if I could get a link for you. It seems the WI SDK has now been subsumed into the main Windows SDK. Still, that's no bad thing. Lots of useful info in there. Don't be put off by the 'for Vista' part of the title.
- download InstEdit, an alternative to Orca.
- open up some MSIs and examine the relationships between the tables, where GUIDs are used and so on.
- create a transform for one of the MSIs and see how you can customise MSIs without directly editing them.
- once you have an understanding of the technology, its raison d'etre and so on, get yourself a tool with a GUI. In the corporate space, there are really only 2 players: Altiris (Wise) and Acresso (InstallShield). I prefer the former but that's a personal opinion, as is my view - gleaned from various forum threads, email conversations etc. that Wise is a dead product.
Edited by VBScab, 17 August 2009 - 11:30.
- Don't know why 'x' happened? Want to know why 'y' happened? ProcMon will tell you.
- Try using http://www.google.com before posting.
- I answer questions only via forums. Please appreciate the time I give here and don't send me personal emails.
- Try using http://www.google.com before posting.
- I answer questions only via forums. Please appreciate the time I give here and don't send me personal emails.
RobIsUpside
-
- Full Members
- 10 posts
Posted 04 September 2009 - 20:48
I have to agree with vbscab that pure MSI is a bit tricky.
Best reason I can think of using Installscript MSI is that you have the ability to more easily create a custom UI and actions wrapper for things that you're already familiar with (using installscript which still offers some decent functionality).
I should add that you definitely want to use MSI and not just IS installs for the stability in the windows installer engine which handles updates and rollbacks, feature and components, repair, remove etc. extremely well. It is almost guarenteed also that without using MSI installation you may find it next to impossible to achieve built for windows deployment certification
Just my 2 cents.
Best reason I can think of using Installscript MSI is that you have the ability to more easily create a custom UI and actions wrapper for things that you're already familiar with (using installscript which still offers some decent functionality).
I should add that you definitely want to use MSI and not just IS installs for the stability in the windows installer engine which handles updates and rollbacks, feature and components, repair, remove etc. extremely well. It is almost guarenteed also that without using MSI installation you may find it next to impossible to achieve built for windows deployment certification
Just my 2 cents.
Edited by RobIsUpside, 04 September 2009 - 20:50.
VBScab
-
- Full Members
- 436 posts
Posted 07 September 2009 - 09:05
Building MSIs using a table editor (e.g. InstEdit, Orca, SuperOrca) will drive you to an early grave or, at best, an institution whose walls are padded. You *really* need to know your stuff to do that. These tools are great for QAD edits but not to be recommended for standing-start builds.
Just one of the hassles which the full-blown authoring tools saves you from is the generation of GUIDs for components. If you have 20 files in your project and decide to go with the "one file per component" strategy, you need to generate 20 GUIDs. Doesn't sounds too much of a hassle, written out like that, does it? Now do that every day, for every project...
Once you have a GUID, you need to build the Component table. Then you need to keep the Component ID noted somewhere so that you can copy it to the File table. Oh, don't forget to add the Component to the FeatureComponent table.
Shall I go on?
Just one of the hassles which the full-blown authoring tools saves you from is the generation of GUIDs for components. If you have 20 files in your project and decide to go with the "one file per component" strategy, you need to generate 20 GUIDs. Doesn't sounds too much of a hassle, written out like that, does it? Now do that every day, for every project...
Once you have a GUID, you need to build the Component table. Then you need to keep the Component ID noted somewhere so that you can copy it to the File table. Oh, don't forget to add the Component to the FeatureComponent table.
Shall I go on?
- Don't know why 'x' happened? Want to know why 'y' happened? ProcMon will tell you.
- Try using http://www.google.com before posting.
- I answer questions only via forums. Please appreciate the time I give here and don't send me personal emails.
- Try using http://www.google.com before posting.
- I answer questions only via forums. Please appreciate the time I give here and don't send me personal emails.
Stefan Krueger
-
- Administrators
- 13,269 posts
InstallSite.org
Posted 07 September 2009 - 16:35
May I put it this way:
You should use Orca to create your MSI only if you created your application with a hex editor. But if you use Visual Studio for your application then you should use a similar tool for your msi. InstallShield is a very popular tool, but there are others as well. See http://www.installsi...g/go/msidev.htm for a list.
You should use Orca to create your MSI only if you created your application with a hex editor. But if you use Visual Studio for your application then you should use a similar tool for your msi. InstallShield is a very popular tool, but there are others as well. See http://www.installsi...g/go/msidev.htm for a list.
Stefan Krüger
InstallSite.org twitter facebook