For the level of uninstaller functionality you are talking about, I suggest you get familiar with pascal scripting in Inno Setup (if you are not already). It offers incredible customisation, but has the caveat of making your projects a lot more complex.
To answer your third question first:
Yes, you should do this. In order to do it properly, you need to add this functionality to the uninstaller of the second application (i.e. the one your app is dependent on). See Uninstall event functions
in the Inno Setup help. You need to check in that uninstaller if your app is installed (by checking if HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\SecondAppName
exists, for example) and in that case show an additional warning.
As for your second question:
If it is remotely possible that your customer wants to continue using the second app, even if he decides that he wants to uninstall the first one, you should offer him the choice. I would do this with a seperate wizard page in the uninstaller for your app, after your app is uninstalled.
And finally, your first question:
You need to determine the name (full path) of the other app's uninstaller exe. You can retrieve it from the registry key HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\SecondAppName\UninstallString
. For executing it from a script in the [CODE] section, see Exec
in the Inno Setup help.
Inno Setup 6 has a built-in support for non-administrative install mode.
Basically, you can simply set PrivilegesRequiredOverridesAllowed
:
[Setup]
PrivilegesRequiredOverridesAllowed=commandline dialog
Additionally, you will likely want to use the auto*
variants of the constants. Notably the {autopf}
for the DefaultDirName
.
[Setup]
DefaultDirName={pf}\My Program
The following is my (now obsolete) solution for Inno Setup 5, based on @TLama's answer.
When the setup is started non-elevated, it will request elevation, with some exceptions:
- Only on Windows Vista and newer (though it should work on Windows XP too)
- When upgrading, the setup will check if the current user has a write access to the previous installation location. If the user has the write access, the setup won't request the elevation. So if the user has previously installed the application to user folder, the elevation won't be requested on upgrade.
If the user rejects the elevation on a new install, the installer will automatically fall back to "local application data" folder. I.e. C:\Users\standard\AppData\Local\AppName
.
Other improvements:
- the elevated instance won't ask for language again
- by using
PrivilegesRequired=none
, the installer will write uninstall information to HKLM
, when elevated, not to HKCU
.
#define AppId "myapp"
#define AppName "MyApp"
#define InnoSetupReg \
"Software\Microsoft\Windows\CurrentVersion\Uninstall\" + AppId + "_is1"
#define InnoSetupAppPathReg "Inno Setup: App Path"
[Setup]
AppId={#AppId}
PrivilegesRequired=none
...
[Code]
function IsWinVista: Boolean;
begin
Result := (GetWindowsVersion >= $06000000);
end;
function HaveWriteAccessToApp: Boolean;
var
FileName: string;
begin
FileName := AddBackslash(WizardDirValue) + 'writetest.tmp';
Result := SaveStringToFile(FileName, 'test', False);
if Result then
begin
Log(Format(
'Have write access to the last installation path [%s]', [WizardDirValue]));
DeleteFile(FileName);
end
else
begin
Log(Format('Does not have write access to the last installation path [%s]', [
WizardDirValue]));
end;
end;
procedure ExitProcess(uExitCode: UINT);
external 'ExitProcess@kernel32.dll stdcall';
function ShellExecute(hwnd: HWND; lpOperation: string; lpFile: string;
lpParameters: string; lpDirectory: string; nShowCmd: Integer): THandle;
external 'ShellExecuteW@shell32.dll stdcall';
function Elevate: Boolean;
var
I: Integer;
RetVal: Integer;
Params: string;
S: string;
begin
{ Collect current instance parameters }
for I := 1 to ParamCount do
begin
S := ParamStr(I);
{ Unique log file name for the elevated instance }
if CompareText(Copy(S, 1, 5), '/LOG=') = 0 then
begin
S := S + '-elevated';
end;
{ Do not pass our /SL5 switch }
if CompareText(Copy(S, 1, 5), '/SL5=') <> 0 then
begin
Params := Params + AddQuotes(S) + ' ';
end;
end;
{ ... and add selected language }
Params := Params + '/LANG=' + ActiveLanguage;
Log(Format('Elevating setup with parameters [%s]', [Params]));
RetVal :=
ShellExecute(0, 'runas', ExpandConstant('{srcexe}'), Params, '', SW_SHOW);
Log(Format('Running elevated setup returned [%d]', [RetVal]));
Result := (RetVal > 32);
{ if elevated executing of this setup succeeded, then... }
if Result then
begin
Log('Elevation succeeded');
{ exit this non-elevated setup instance }
ExitProcess(0);
end
else
begin
Log(Format('Elevation failed [%s]', [SysErrorMessage(RetVal)]));
end;
end;
procedure InitializeWizard;
var
S: string;
Upgrade: Boolean;
begin
Upgrade :=
RegQueryStringValue(HKLM, '{#InnoSetupReg}', '{#InnoSetupAppPathReg}', S) or
RegQueryStringValue(HKCU, '{#InnoSetupReg}', '{#InnoSetupAppPathReg}', S);
{ elevate }
if not IsWinVista then
begin
Log(Format('This version of Windows [%x] does not support elevation', [
GetWindowsVersion]));
end
else
if IsAdminLoggedOn then
begin
Log('Running elevated');
end
else
begin
Log('Running non-elevated');
if Upgrade then
begin
if not HaveWriteAccessToApp then
begin
Elevate;
end;
end
else
begin
if not Elevate then
begin
WizardForm.DirEdit.Text := ExpandConstant('{localappdata}\{#AppName}');
Log(Format('Falling back to local application user folder [%s]', [
WizardForm.DirEdit.Text]));
end;
end;
end;
end;
Best Answer
No, there's no way to do that while still keeping the functionality your customers are 'implicitly' asking for. The only 'wrapping' in MSI you can do is to extract it on installation and start your InnoSetup installer from the temporary location where you extracted to. MSI is a fundamentally different way of working: InnoSetup (& NSIS & most other installers) take a code-centric approach: you 'program' the 'steps' to install your data. MSI is a database and takes a 'data-centric' approach: you indicate what files should be installed and the MSI 'runtime' does the rest. This gives you versioning and exact control of what goes where.
In short, to give your customers what they want (i.e., the ease of deployment that MSI brings with AD), you'll need 'proper' MSI's. Good luck with that, it's a major pain IMHO. But it does give good results once you master MSI & WiX.