Nick Umanski recently asked on InstallShield Community this question:
"I did a Basic MSI course at Macrovision earlier this year and there it was mentioned that Installscript projects would be dropped at some point. This was not an official comment I might add, just some speculation. Does anybody have any knowledge of whether this is going to happen in the near future or not."
My response is:
The use of the word `InstallScript` is overloaded these days. I can think of atleast three possible meanings:
1) Basic MSI with InstallScript Custom Actions
2) InstallScript MSI ... an MSI installation which uses InstallScript as it's External UI handler
3) InstallScript project .. no MSI at all. Completly script/InstallShield framework driven.
#1 is my favorite. Lean and mean, using InstallScript CA's only where needed.
#2 gives a nice framework for people who want a fancier, more extensible UI. It also supports Setup Types alot easier then #1
#3 is particularly useful for situations that MSI doesn't support well. Two examples would be multipleinstance installation and another would be you don't want resilency. ( In certain server based situations the overhead of scanning keyfiles can have a negative effect on application performance )
Personally I doubt `InstallScript` ( in either context ) is going away anytime soon.
5 comments:
Another reasond for installscript installs is when you ship Gigabytes of data of which selected sections are installed (controlled by a licence key) and you need the data to be encrypted.
May eventually get around to writing that encryption tool to allow us to move completely to MSI. We currently ship the client application in an MSI and the server data installer as an InstallScript install.
I did Macrovision course in July 2005 and we've been told the same thing - InstallScript is being moved down in the list of company's priorities. But look at IS12 - completely redesigned InstallScript engine.
The way I understood the statement is that:
1) support for (or rather compliance with) Basic MSI projects is the top priority for the company.
2) InstallScript MSI projects were NOT recommended by the lecturer, since there were too many issues with that kind of setups.
3) InstallScript projects (not MSI) will continue to evolve since they provide more options, especially on the GUI side. Though new Vista requirements might push developers to move towards clean MSI setups.
I did Macrovision course in July 2005 and we've been told the same thing - InstallScript is being moved down in the list of company's priorities. But look at IS12 - completely redesigned InstallScript engine.
The way I understood the statement is that:
1) support for (or rather compliance with) Basic MSI projects is the top priority for the company.
2) InstallScript MSI projects were NOT recommended by the lecturer, since there were too many issues with that kind of setups.
3) InstallScript projects (not MSI) will continue to evolve since they provide more options, especially on the GUI side. Though new Vista requirements might push developers to move towards clean MSI setups.
Christopher, what is your current opinion about InstallScript and pure InstallScript projects?
I really like to use InstallScript Custom Actions in Basic MSI projects since IS2008.
But I still like to author big pure InstallScript projects. For example, you can include 32bit AND 64bit driver packages in one InstallScript setup using DIFx functions to install them. Installing a lot if files and folders is much easier to handle.
What is the future of pure InstallScript and what are the advantages and main reasons to use Basic MSI only?
I've read that MSI only has about 60% of the market. There are still a lot of groups that still prefer to use other script technologies like InstallScript and NSIS.
If your installs are meeting your customers needs, reliable and sustainable, then I belive you still have a viable platform to develop on.
If you are having problems in these areas, Baisc MSI may be the way to go as it forces you into it's best practice patterns.
When MSI can't do something you want, then InstallSript CA's are a good language to code in ... provided that you follow the same best practice patterns that you would follow in C++ such as Deffered CA's, Data Driven CA's ectera.
Post a Comment