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
<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>
(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...
"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.
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...
"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.
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...
"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
"Rich [Microsoft Windows Installer MVP]" <legaliz...@mail.xmission.com>
wrote in message news:eSgr111u...@TK2MSFTNGP12.phx.gbl...
"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?