7

I have a program that needs to create files in the My Document directory on installation. This is a strict fixed requirement, there is no changing this. Problem is that if the user does 'Run As Administrator' on the Setup file, innosetups constant {userdocs} points to the Administrator's document directory not the original logged in user.

So, Googled and found this:

Install files to original user's My Docs folder via Inno Setup on Windows Vista/7

The answer is wrong, however, because innosetup even states that

If a user launches Setup by right-clicking its EXE file and selecting "Run as administrator", then this flag, unfortunately, will have no effect, because Setup has no opportunity to run any code with the original user credentials. The same is true if Setup is launched from an already-elevated process. Note, however, that this is not an Inno Setup-specific limitation; Windows Installer-based installers cannot return to the original user credentials either in such cases.

I guess I can encourage the user to not use Run As Administrator but I don't know how to prevent him from not coming in elevated.

I was thinking of maybe having the program itself set up the My Documents\Program name directory on first run (after being installed). Would this workaround work? It'd have to copy files from its program files directory as potentially limited user. Is it possible or will I run into priveleges problems?

Community
  • 1
  • 1
hd112
  • 279
  • 2
  • 15

3 Answers3

6

The answer to the original is valid but not recomended. When the setup is run, RunAsOriginalUser will run as the user currently logged into Windows. This is done by having part of the setup run unelevated, and then run another copy that is elevated to do the actual install.

When the user explicitly does "Run as admin", the "unelevated stub" runs elevated as well, in which case, there is nothing the setup can do to access the original user as that information has already been replaced.

The accepted practice is to do any profile specific work in the application itself as you suggested, which also means it will work for other users and in a LUA environment in pre Vista (Where you would have had exactly the same situation that you're seeing now).

Deanna
  • 23,876
  • 7
  • 71
  • 156
1

First, make sure the installer won't require privileges elevation on its own, by setting PrivilegesRequired=lowest:

[Setup]
PrivilegesRequired=lowest

To abort the installer, when the installer is running "As Administrator" explicitly by the user, on Windows Vista and older, use IsAdmin function (or IsAdminInstallMode or IsAdminLoggedOn [in older versions]) in InitializeSetup:

[Code]

function InitializeSetup(): Boolean;
begin
  Result := True;

  if (GetWindowsVersion >= $05010000) and
     IsAdmin then
  begin
    MsgBox('Do not run this installer "As Administrator".', mbError, MB_OK);
    Result := False;
  end;
end;

For more discussion on the topic, see Install files to original user's My Docs folder via Inno Setup on Windows Vista/7.

Martin Prikryl
  • 188,800
  • 56
  • 490
  • 992
0

This article might provide you some guidance on how to work around the elevation,

http://www.codeproject.com/Articles/18946/High-elevation-can-be-bad-for-your-application-How

Generally speaking, it gives you a chance to execute your executable (which creates files under My Documents) at the end of installation without elevation.

Lex Li
  • 60,503
  • 9
  • 116
  • 147
  • That approach looks way too complicated to attempt in a commercial app. I wouldn't know where to start if there are issues. Thanks though, it's a creative solution. – hd112 May 10 '12 at 05:41