[UninstallDelete] use code for some files

[Sam Oxigen]

My install package is a single setup exe file for initial install, and update scenarios. The update is called with /verysilent command line switch. The installer internally determines which scenario to play by reading the command line. For very-silent installation (update mode), I uninstall the application first, then install the application by escaping number of input prompts, and use some existing/pre-installed files to handle my update (created during the initial installation etc.).

What I needed on my very-silent mode, is to prevent few files from deleting while uninstalling (e.g. installing in very-silent mode). That said, I use below pattern (see: [UninstallDelete]) to prevent file deletion during my "intermediate" uninstall. The IsInstallMode()  function on check returns false, however files are still deleted (e.g. appdata.bin is deleted regardless of IsInstallMode()  function return value). 

Also, this file (e.g. appdata.bin), for instance, is not part of my [Files]; it is created dynamically during the installation. I knew that such files do not go to uninstall package, however this file still deleted, regardless...

Anyone has any idea where I do incorrect codding?

[UninstallDelete]
Type: files; Name: "{app}\appdata.bin"; Check: IsInstallMode();

P.S.
very-silent mode uninstall then install pattern is a requirement.

[Gavin Lambert]

On 11/01/2022 13:33, Sam Oxigen wrote:
> My install package is a single setup exe file for initial install, and
> update scenarios. The update is called with /verysilent command line
> switch. The installer internally determines which scenario to play by

> reading the command line. For *very-silent* installation (update mode),

> I uninstall the application first, then install the application by
> escaping number of input prompts, and use some existing/pre-installed
> files to handle my update (created during the initial installation etc.).

The mistake is uninstalling the previous version first.

The correct way to handle upgrades is to install directly over the top.
Usually this will just work; if you do need to delete some files
during the upgrade (this is rare) then you can list them using
[InstallDelete], but you should only list the smallest set of files
possible and ideally without using any wildcards; to avoid catching any
unintended files, or deleting a file only to reinstall the same file.

[Gavin Lambert]

On 11/01/2022 13:33, Sam Oxigen wrote:

> [UninstallDelete]
> Type: files; Name: "{app}\appdata.bin"; Check: IsInstallMode();

But more specifically: [UninstallDelete] Check functions are called at
install time, not uninstall time. They control whether the entry is
written to the uninstall log or not. As such, the file will be deleted
on a subsequent uninstall if this returns true during *any* install or
upgrade.

[Sam Oxigen]

Thanks Gavin for your quick reply.

I was hopping to see other solution ;), as I mentioned, "uninstall first" is a requirement for a silent install scenario.

This is an explanation from our product manager:

First: We a have power shell scripts to collect all required files/folders- to copy over inno installer content directory, and compile inno scripts to an executable.

"We won't modify inno script/project file(s) with every update. We want to make sure that we re-install the product with no left over files from previews installations, also preserving some config/database files installed or generated during the initial installation."

 

That said, I had to stick with this design pattern, and I worked around the issue:

I move my "delete/preserve" files/folders logic to DeinitializeUninstall built-in event procedure (Called just before uninstall terminates).

It did work too.

Thank you again for your correct direction tip on this matter. It is always good to know the "right" way, at least for future discussion with my team on this subject.

Sam 

[Gavin Lambert]

On 11/01/2022 19:16, Sam Oxigen wrote:
> I was hopping to see other solution ;), as I mentioned, "/uninstall
> first/" is a requirement for a silent install scenario.

> This is an explanation from our product manager:

> /First: We a have power shell scripts to collect all required

> files/folders- to copy over inno installer content directory, and

> compile inno scripts to an executable./

> "We won't modify inno script/project file(s) with every update. We want
> to make sure that we re-install the product with no left over files from
> previews installations, also preserving some config/database files
> installed or generated during the initial installation."

At that point, you bounce the requirement back and tell them why they're
wrong. You don't implement something silly just because they don't know
what they're actually asking for.

Or you get creative with ISPP to read their scripts/files and do the
right thing even if they won't.

> That said, I had to stick with this design pattern, and I worked around
> the issue:
> I move my "delete/preserve" files/folders logic to

> *DeinitializeUninstall* built-in event procedure (Called just before
> uninstall terminates).

That is completely incorrect. If you really must do some conditional
uninstall logic, do it in CurUninstallStepChanged(usUninstall) (or in
rarer cases usPostUninstall).

But it is still inappropriate for an upgrade to run the uninstall in the
first place.

[Bill Stewart]

On Monday, January 10, 2022 at 11:24:45 PM UTC-7 Gavin Lambert wrote:

But it is still inappropriate for an upgrade to run the uninstall in the
first place.

I agree with this as a general principle, but a change in an application's architecture and/or design might be a justification for an uninstall before upgrading.

Bill

[Sam Oxigen]

You might be right but surprisingly the outcome of the result is very satisfactory.

a. When I run the installer in an ordinary way then I see all my input pages, and I'm getting installed all I need.

b. When I run the installer through a command line with a switch "/verysilent" then 1st, I see my preserved few files, then the rest of newly installed  content.

c. When I uninstall the software then I see very few files that I never delete on uninstallation.

All files that I preserver and mentioned above (few files, very few files) are created dynamically, and if I do not manipulate these files anyway then these files will be staying on the target machine after uninstallation.

So,

1. very few files that I never delete on uninstallation I do not manipulate in any way.

2. few files that I have to preserve in the update scenario I handle inside the [DeinitializeUninstall] event.

procedure DeinitializeUninstall();

var

  AppData, ..., ErrMessage: String;

begin

  AppData := ExpandConstant('{app}') + '\appdata.bin';

  ...

  ...

  ...

  ErrMessage := ' was not able delete.';

  if IsInstallMode() then begin

    if FileExists(AppData) then

      if not DeleteFile(AppData) then

        Log(AppData + ErrMessage);

    ...

    ...

    ...

  end;

end;

--
You received this message because you are subscribed to the Google Groups "innosetup" group.
To unsubscribe from this group and stop receiving emails from it, send an email to innosetup+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/innosetup/5c74bf1f-93d5-23ef-cea0-393d1fc73e25%40mirality.co.nz.

[Sam Oxigen]

I'll play with your recommendations, and see if I can meet my requirements. I'll let you know. That sounds more clear for me. Thanks.
(By the way, I saw number of approved similar discussions on stackaverflow in regard to software update approach with uninstall)

That is completely incorrect. If you really must do some conditional
uninstall logic, do it in CurUninstallStepChanged(usUninstall) (or in
rarer cases usPostUninstall).

[Sam Oxigen]

Gavin, you are right. My detail debugs on different install and uninstall scenarios showed that I must separate install and uninstall streams in order to set my "global" variables and handle tasks separately. That said I use following events to control my "global" variables to perform file preservations and install cleanups in case of successful or error installs/uninstalls, including install/uninstall cancelations. Variables set up in each group of events do not cross over... 

1. InitializeSetup, CurStepChanged, and DeinitializeSetup 

2. InitializeUninstall CurUninstallStepChanged, and DeinitializeUninstall