Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

how to avoid using parameters with msiexec

0 views
Skip to first unread message

anon...@discussions.microsoft.com

unread,
Dec 3, 2003, 4:48:12 PM12/3/03
to
I have a new release that is a minor upgrade to a
previous release. Some user's will have the old version
and some won't. I'm trying to figure out how I can
upgrade existing users without uninstalling first
version. I want to know if it is possible to build the
functionality this command line into the msi:

msiexec /i new.msi REINSTALL=ALL REINSTALLMODE=vomus

I would like to end up with a "service pack" like
installation where only the files are refreshed.

Thanks,
Shawn

Rich [Microsoft Windows Installer MVP]

unread,
Dec 4, 2003, 1:02:12 PM12/4/03
to
[Please do not mail me a copy of your followup]

<anon...@discussions.microsoft.com> spake the secret code
<032001c3b9e7$26300110$a401...@phx.gbl> thusly:

>I want to know if it is possible to build the
>functionality this command line into the msi:
>
>msiexec /i new.msi REINSTALL=ALL REINSTALLMODE=vomus

You can set a property indicating the presence of the old product
using AppSearch. Then you can use this property in the condition of a
custom action that sets the REINSTALL and REINSTALLMODE properties.
--
"The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ:
<http://www.xmission.com/~legalize/book/>
Pilgrimage: Utah's annual demoparty
<http://pilgrimage.scene.org>

Alek Davis

unread,
Dec 4, 2003, 7:13:56 PM12/4/03
to
Thank you for posting this suggestion, Rich. Would you (or someone else) be
able to point me to the info explaining how to implement it in VS.NET
installer or InstallShield Dev? I have a suspicion that someone somewhere
must have done this before, since it is a very common functionality. I have
a rudimentary understanding of MSI and I used it for simple installations
only (I haven't done it in a while, though, but I would really like to
figure this one out). So what I am wondering is:

(1) How to set up a property indicating a presence of the old product using
AppSearch? Is it a specific property? Does it need a specific value?
(2) How to reset the values of REINSTALL and REINSTALLMODE from a custom
action?

Sorry if these are basic questions, but I'm probably not the only MSI
beginner who is puzzled by this.

Thanks in advance,

Alek

"Rich [Microsoft Windows Installer MVP]" <legaliz...@mail.xmission.com>
wrote in message news:%2384G$CpuDH...@TK2MSFTNGP10.phx.gbl...

Rich [Microsoft Windows Installer MVP]

unread,
Dec 4, 2003, 7:49:30 PM12/4/03
to
[Please do not mail me a copy of your followup]

"Alek Davis" <alekDOTdavisATintelDOTcom> spake the secret code
<eDMquSsu...@TK2MSFTNGP11.phx.gbl> thusly:

>Thank you for posting this suggestion, Rich. Would you (or someone else) be
>able to point me to the info explaining how to implement it in VS.NET
>installer or InstallShield Dev?

In VS.NET you can implement AppSearch stuff by doing view launch
conditions and then adding a new search on the target machine. (Don't
add a launch condition, just a search.)

InstallSUCK also has a search machine thing.

>(1) How to set up a property indicating a presence of the old product using
>AppSearch? Is it a specific property? Does it need a specific value?

You can set the property to something you scrape out of hte registry
or to the full path of a file you searched for on the target machine.
In your condition just test for the property not being the empty
string to test if the search was successful.

>(2) How to reset the values of REINSTALL and REINSTALLMODE from a custom
>action?

This is a "set property" type of custom action (51, I think it is).
Unfortunately, VS.NET doesn't provide a way to insert these kinds of
custom actions, so you may want to prepare a very simple merge module
with Orca and add a merge module reference to your setup.

>Sorry if these are basic questions, but I'm probably not the only MSI
>beginner who is puzzled by this.

No problem, everyone starts out as a beginner.

Alek Davis

unread,
Dec 4, 2003, 8:07:47 PM12/4/03
to
Rich,

Thanks for a quick response. Why Microsoft made such a simple (and needed)
operation so complex is totally beyond my comprehension...

InstallSUCK :-) Actually, I am totally with you on this one. Out of three
months I spent trying to convert a rock-solid installer from InstallShield
Professional 6.x to InstallSuck Developer 7.x, I wasted close to 80% of time
dealing with bugs, some of which were so basic that I had a hard time
believing that they used QA/V&V in any shape or form. Eventually, I had to
abandon the idea and get back to ISP 6.x. It is amazing, but some of the
bugs reported and confirmed 2-3 years ago are still unresolved, so I am
trying to stay away from it as far as possible (although, I do not have a
viable alternative for 64-bit setups). I was a huge fan though (at the times
of ISP 5/6). Not any more...

Thanks again,

Alek

"Rich [Microsoft Windows Installer MVP]" <legaliz...@mail.xmission.com>

wrote in message news:OtiMlmsu...@TK2MSFTNGP12.phx.gbl...

Rich [Microsoft Windows Installer MVP]

unread,
Dec 4, 2003, 11:45:35 PM12/4/03
to
[Please do not mail me a copy of your followup]

"Alek Davis" <alekDOTdavisATintelDOTcom> spake the secret code

<#YjR0wsu...@TK2MSFTNGP10.phx.gbl> thusly:

>Thanks for a quick response. Why Microsoft made such a simple (and needed)
>operation so complex is totally beyond my comprehension...

If you mean the VS.NET deployment projects, yeah, I'm not too
impressed with them for anything but "copy the files" style installs.

To be honest with you, I generally use Orca as an editor (even though
I have an InSUCK license) in conjunction with izfree, a tool I wrote.
I put stuff in izfree that I found to complement using Orca as an
editor. I add to izfree as I need new tools.

Lately I have been using the deployment project support in VS.NET
more, mostly for building merge modules. I'm beginning to think that
sometimes the best way to get more bang out of VS.NET is to augment
its capabilities with a set of merge modules that do more custom
things. You do a minimal amount of editing in Orca on the merge
module and then add a reference to it in VS.NET.

Alek Davis

unread,
Dec 5, 2003, 12:32:31 PM12/5/03
to
Actually, I meant MSI (I understand why VS.NET deployment projects have such
a limited functionality: MS probably does not want to compete with IS, WISE
in this space, which sort of makes sense). What I am saying is that allowing
installer to perform hassle-free minor upgrades/repairs via the same MSI
file as an initial installation (i.e. not using patches and without asking
customers to specify any specific command-line switches) is a basic feature,
which should not be hard to implement. I mean, when MSIEXEC detects that a
product is already installed, why (instead of displaying an error message)
doesn't it simply prompt the user for the type of operation to perform (i.e.
repair/upgrade/uninstall)? This is the way IS (prior to ISD 7) worked for
years. The advantage here is that I can deploy just one (most recent)
version of installer to the customers without having to explain them which
command-line switches to use in which particular case (they can simply
double-click the setup.exe and follow the prompts). In an enterprise
environment (with lots of teams/people involved in
development/deployment/support) this makes a lot of difference.

I have to check out your tool, but if it is just a complement to Orca, I
don't think it will fit the needs/skill set/dev process of my team. I am
also afraid it will still require a lot of manual changes and understanding
of MSI internals. I am absolutely sure that it has fewer bugs - per lines of
code - than ISD or Wise, though.

We are currently using 3 installation tools. For simple deployments (file
copy, GAC registration) VS.NET suffices. For a complex installation
(building databases, installing ISAPI filters, Web site creation, adding
printers, COM/NT service registration, etc), we still use ISP 6.x. I tried
to convert it to ISD 7.x but could not find workarounds for all bugs, so it
is still on ISP 6.x (by the way, the customers are quite happy with it).
However, I have to use ISD 7.x to install a small subset of features of the
ISP 6.x project on 64-bit Windows. It has its share of problems (mostly
bugs), but I don't have any other alternative. I hope that someday someone
will come up with a reasonably bug-free version of easy-to-use MSI dev tool,
but I will probably have to wait long (hey, do you want to take izfree to
the next level? ;-) ).

Thanks for the info.

Alek

"Rich [Microsoft Windows Installer MVP]" <legaliz...@mail.xmission.com>

wrote in message news:u9mZgquu...@tk2msftngp13.phx.gbl...

Rich [Microsoft Windows Installer MVP]

unread,
Dec 5, 2003, 1:27:36 PM12/5/03
to
[Please do not mail me a copy of your followup]

"Alek Davis" <alekDOTdavisATintelDOTcom> spake the secret code

<ebsvEX1u...@TK2MSFTNGP10.phx.gbl> thusly:

>[...] What I am saying is that allowing


>installer to perform hassle-free minor upgrades/repairs via the same MSI
>file as an initial installation (i.e. not using patches and without asking
>customers to specify any specific command-line switches) is a basic feature,
>which should not be hard to implement.

It has been my experience (and the experience of others who have
worked on creating robust installs) that other developers routinely
underestimate the difficulty of writing a robust install.

Alek Davis

unread,
Dec 5, 2003, 4:33:12 PM12/5/03
to
Agree, but "difficult" does not mean "impossible". If a major company (e.g.
Microsoft) designing a major technology (MSI) or a big company (IS/Wise)
developing a flagship product, follows the motto "we are not implementing
useful features because they are too difficult," we should forget about
usability, and this is not right. It does not work this way in an enterprise
space (at least, where I work), where the level of difficulty is not an
issue: it is either possible or impossible, which - in the former case -
means that if a customer needs a feature, s/he will get it (of course, being
a subject to budgetary constraints). Anyway, this is probably a topic for a
different newsgroup. ;-)

Alek

"Rich [Microsoft Windows Installer MVP]" <legaliz...@mail.xmission.com>

wrote in message news:eSgr111u...@TK2MSFTNGP12.phx.gbl...

Rich [Microsoft Windows Installer MVP]

unread,
Dec 5, 2003, 4:55:18 PM12/5/03
to
[Please do not mail me a copy of your followup]

"Alek Davis" <alek_xDOTx_davis_xATx_intel_xDOTx_com> spake the secret code
<ejS8jd3u...@tk2msftngp13.phx.gbl> thusly:

>Agree, but "difficult" does not mean "impossible".

Non-sequitor. Who is saying its impossible?

0 new messages