Re: One package, three uninstalls

From: Terry M (Nospam_at_hotmail.com)
Date: 03/09/04 

Date: Tue, 9 Mar 2004 15:44:11 -0800

Actually it would only take a couple min. if you already have the install
scripts. Just copy and paste into a separate script and compile. Then
create a simple wrapper that just does and execute and waits until it is
finished to setup the next one. Literally it would take just a couple min.

Another question is you said it is optional to have all three components,
but does that mean that it would hurt anything if the three were always
installed together? Even if the other two aren't needed, it might just be
easier to install all?

Terry

<anonymous@discussions.microsoft.com> wrote in message
news:6f5101c4061c$f72f4e20$a601280a@phx.gbl...
> So with all that said... does anyone have any suggestions
> as to what the problem might be? I'd really rather get
> it working structured the way I have it now, as opposed
> to breaking it down into separate .EXE's and wrapping
> those in one "master" installation. That's a viable
> alternative, if I have no other choice - thanks for the
> suggestion, Terry. I just don't have the time to totally
> restructure the installation. I've got a customer who is
> fairly ticked off that they can't uninstall my product
> from a test server, and they're not willing to move to
> production until uninstall works. (Yes, we tested
> uninstall before release. I have no idea how this
> problem slipped past in testing.)
>
> >-----Original Message-----
> >
> >To expand a bit... the first component is my main
> >software package; the second component is a collection
> >of "runtime" files, supporting DLL's and such; the
> third
> >component is some communications software to assist the
> >main application with, uh, communicating. Depending on
> >the situation, the second and third components may or
> may
> >not be needed for a particular delivery. All three
> >components are conditionally compiled into the package.
> >For reasons difficult to explain, I cannot leave it up
> to
> >the user at the other end to decide which components to
> >install.
> >
> >Upon further experimentation, it is only the main
> >component's logfile that disappears. If this particular
> >compilation includes only the main applicatoin software,
> >its logfile is created properly. If the second and/or
> >third components are also included, they get their
> proper
> >logfiles, but the main application does not.
> >
> >Finally, this is unrealistic but theoretically possible,
> >if I don't include the main application, but include the
> >second and third components, they both get their proper
> >logfiles - so it doesn't seem to be a situation where
> the
> >first logfile used is discarded if subsequent logfiles
> >are also used. It appears to be something directly
> >related to my main component and its logfile. Darned if
> >I can figure out what, though.
> >
> >
> >>-----Original Message-----
> >>Hmm, interesting.
> >>You could create three scripts, one for each component,
> >compile them as
> >>exe's with the correct add/remove and uninstall info.
> >Then create another
> >>SMSI script that is just a wrapper script and contains
> >the three other
> >>setups and launch from within that?
> >>
> >>Or even just create the three scripts and deploy them
> to
> >the client
> >>separately??
> >>
> >>As for the modifications you are trying to make, I have
> >not tried to do that
> >>before. But I think the method above will work.
> >>
> >>Terry
> >>
> >>"Chad"
> ><chad.varnerREMOVE_CAPS_BUT_DONT_OFFER_ME_AN_SMS_JOB@eds.
> c
> >om> wrote
> >>in message news:9cf801c405e6$28bc69f0
> $a101280a@phx.gbl...
> >>> I have a single SMS Installer script that installs
> >three
> >>> separate components; I want the components to be
> >totally
> >>> separate applications, each with its own entry
> >>> on "Add/Remove Programs", each to be logged and
> >>> uninstalled separately.
> >>>
> >>> I've tried to accomplish this by slightly modifying
> >>> UNINSTAL.IPF, changing it to use a regular variable %
> >>> LOGFILE_PATH% instead of the default global variable %
> >>> _LOGFILE_PATH_% (note leading and trailing
> underscores.
> >>>
> >>> As I enter each section of the install, I set the
> >>> APPTITLE and LOGFILE_PATH variables appropriately,
> >>> I "open new installation log file %LOGFILE_PATH%",
> then
> >>> call uninstal.ipf.
> >>>
> >>> At the end of each section, I "Stop writing to
> >>> installation log".
> >>>
> >>> The end result is that sometimes it writes a log file
> >and
> >>> sometimes it doesn't. I tried adding a "Open new
> >>> installation log file" with no filename specified, at
> >the
> >>> end of each section, to try to force the old one
> closed
> >>> and flush it to disk. That had no effect.
> >>>
> >>> What am I missing?
> >>>
> >>>
> >>
> >>
> >>.
> >>
> >.
> >

Relevant Pages

  • Re: Compact SQL - Any CPU Build
    ... After the install, I confirmed the keys were created under ... our application can be installed on both of the x86 and x64 platform. ... But if we want to compile it as x64 version, ... Microsoft Online Community Support ...
    (microsoft.public.dotnet.general)
  • Re: Linux vs FreeBSD vs SCO
    ... >> often you install an upgrade, and you find it needs something else, ... >> package, from packages otherwise it has to compile Ruby, and some ... in a Maynard Sandstar floppy controller and hung 8" DD floppies ... The official IBM DOS 2.0 manuals and disks are there too. ...
    (comp.unix.sco.misc)
  • Re: Suse 10.3 and DVD::RIP
    ... Gnome began to sort of fork off and became increasingly unfriendly to ... As we are a openSUSE group, that is what I am talking about. ... be problematic to compile is none of my business. ... I have to install 75 MB of stuff to run a 2 ...
    (alt.os.linux.suse)
  • =?ISO-2022-JP?B?UmU6IGEgcHJvYmxlbSBhYm91dCBOUEIgTVBJIGJlbmNobWFyayAsIHBhdGhzY2FsZRskQiEnGyhC
    ...   Recently, I compile the benchmark of NPB3.3-MPI, and my platform is ... When I install my mpich like belows: ... the compiler or the object file hello++.o generated by it are failing ... But there are another error now when compile simpl.o as ...
    (comp.lang.fortran)
  • Re: MDE and runtime
    ... if your clients has versions 2000, xp, 2003 installed - then you have to install at least Access 2000 and compile MDE using it. ... Of course you can also install Access 2003 runtime at each PC. ... I may be involved with clients that simply want to purchase the software with none of my involvement in their infrastructure. ... Or are you saying that I can just convert to Access 2000 format, and then compile MDE, and it will work? ...
    (microsoft.public.access.devtoolkits)
Loading