I'm making an installer in Inno Setup.
I've set my script alright, and it can installed in both administrative mode as well as non-administrative mode.
But the problem here is, I need to add my application's folder to Path environment variable.
If I write to the Registry at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment, it would make non-admin not able to use the Run dialog or cmd or powershell or something to launch my application.
If I write to HKEY_CURRENT_USER\Environment, then all the users may not be able to use the feature when admin privileges are available.
So, I am looking for someone to help me on this.
Related
A very common question about creating (Inno Setup) installers revolves around accessing/modifying a profile of a specific user (the currently logged in user) from an installer that runs with elevated/Administrator privileges.
Doing this has many drawbacks and is error prone.
All the existing answers cover part of the problem (registry, files, desktop icon, etc). A purpose of this question is to collect answers that address the problem globally, with all possible approaches.
Inno Setup does not have any built-in mechanism to access or modify user environment from installer running with elevated/Administrator privileges.
All the attempts to achieve this rely on tricks like:
runasoriginaluser flag or ExecAsOriginalUser function. Some examples:
Modifying or accessing registry of logged in user:
Inno Setup Creating registry key for logged in user (not admin user) or
How to read registry HKCU for logged In user from Inno Setup installer running as administrator
Accessing AppData folder of logged in user:
Inno Setup always installs into admin's AppData directory or
Inno Setup Using {localappdata} for logged in user or
Inno Setup - puts user files in admin documents.
or using {user*} constants.
Though these are not reliable, at least for these reasons:
When the current user does not have Administrator privileges, (s)he needs to enter Administrator credentials on installer UAC prompt. That switches the installer to a different user. So {user*} constants will not refer to the user that initiated the installation.
When the user explicitly runs the installer with elevated privileges, e.g. by right-clicking the installer and selecting "Run as administrator" or running it from another elevated application (file manager), the "original user" for runasoriginaluser flag or ExecAsOriginalUser function will already be elevated.
In corporate environments, applications are installed by Administrator, who is not the user that will be using the application.
The only correct generic solution to this problem is to defer a setup of the user environment only to the actual user session.
Easiest is to have the application itself do the setup on its first run.
The installer can only deploy shared files that the application can use for the setup.
If you cannot modify the application for whatever reason, you would have to iterate all accounts and modify them:
for files: Inno Setup Create individual shortcuts on all desktops of all users
for registry: Uninstall auto-run registry entries for all users
If you need to make sure the settings get distributed to accounts that get created only after installation, see How to install files for each user, including future new users, in Inno Setup?
If you are happy with a fact that the application will be setup for the logged in user only, use PrivilegesRequired=lowest:
[Setup]
PrivilegesRequired=lowest
Then the {user*} constants will correctly refer to the current user's folder.
If you still need Administrator privileges for some sub-task of the installation, you can requests privileges elevation for the sub-task only:
Inno Setup - Register components as an administrator
Inno Setup - Access unprivileged account folders from installer that requires privileges
If you want to prevent user from breaking this by explicitly running the installer with Administrator privileges, see
Can't get Inno Setup postinstall Run item to runasoriginaluser or
my answer to How to write to the user's My Documents directory with installer when the user used 'Run As Administrator'.
Or you can programmatically find out, what is the account of the current Windows logon session:
Determine if Administrator account that runs elevated Inno Setup installer is the same as the account of the current Windows logon session.
Another option is to allow the installer to install for the current user only:
Make Inno Setup installer request privileges elevation only when needed
I have created a small vb6 application which edits the registry in HKLM hive. It makes use of function RegSetValueEx. But when run the exe file in windows 7 and windows 8 pc it does not edit the registry even if run it in administrator user.
In windows XP it works fine.If i run same application as "run as administrator"(by right clicking exe and then run as) in windows 7 and 8 then it works properly.I think the windows 7 and 8 id designed to work like this only. But is there any method i can edit it without running as administrator? Or is there any code in vb6 which does the same.
Here is my small code
Important:
When checking the code create exe and then run the exe and click on button(HKEY_LOCAL_MACHINE\SOFTWARE\Demo registry gets added in wow32 node because vb6 is a 32 bit appliaction).Running the code directly by opening code allows the registry to change.But creating the exe and then running it gives the problem which is the real time scenario in any application.
Microsoft has been warning developers since Windows 2000 that access to the HKLM branch of the registry should not be performed as normal user, as it will sooner or later be restricted to administrators. They also said you should not write to Program Files.
They didn't enforce that rule until Windows Vista, so nobody felt the need to change anything.
Now you have it: don't write to HKLM as normal user - it doesn't work. Don't write your settings to Program Files. It doesn't work.
Application run by the normal user may write their data to user folders and user hives in the registry, nowhere else.
If your application's sole purpose is to write to that value in the HKLM hive then you will need to add a "requiresAdministrator` manifest to the executable, causing Windows to prompt the user for admin access every time it's run.
If this is a small part of a larger project, then you should use COM elevation or just run a small stub executable with the manifest above, allowing windows to only prompt when it's required.
If your application doesn't require admin access at all then you should stop it trying to write to admin restricted locations, and instead use the user's own HKCU hive.
I have made an application that copy the vb components to the system32 folder of the windows and register those components with “regsvr32”. It works well in Window XP, but in Windows Vista and Windows7 it can’t perform its task without right clicking the application .exe file and selecting “Run as administrator”. Is there any code in vb that automatically allows the application .exe file to run as administrator?
To do precisely what you ask you can add an application manifest that specifies an execution level of "requireAdministrator" within it. However this means the application will always run elevated, and the user will also have to provide admin credentials or approve elevated execution for every run (UAC prompt).
Please just do things the right way.
I'm going to second Bob's excellent comment above and suggest that you use a tool like Inno Setup http://www.jrsoftware.org (it's free) to build a proper installer. One of the benefits of using a proper setup tool is that the setup application can request to the OS to run with administrative privileges without using external files and manifests to make that happen. The setup.exe that you build will have the necessary code built in to ask the OS for elevated privilege.
In windows 7, we can go to the properties of the file or an application exe file and then "Compatibility" tab. Then check the "Run this program as an administrator".
It will force the application to be executed under the administrator privilege.
I used this and my problem was solved.
I'm working on an installer for our application. The installer makes some changes to the HKEY_CURRENT_USER\Software\Company\AppName registry key, which the application then looks for the first time it runs. The application then does different things based on the registry keys it finds.
This works great, until you try to install the application as a user account (i.e. non-administrator) on windows 7 (and maybe Vista, I haven't tested that yet).
When the user tries to install the application, Windows elevates to the administrator account's credentials. This means that any changes to HKCU in the registry are made to the administrator's registry, not the launching user's registry. Thus, the keys are not visible to the application when it launches for the first time under the user's account.
We can't be the only people whose installer needs to communicate with the app it installs. Is there no way to reliably use the registry to do this?
We can't rely on the user launching the app after he installs it, so passing the information as a command-line parameter isn't a viable solution. The only way I can see to do it is to have the installer invoke a utility as the original user, which gets or sets the registry key itself; this seems to be a bit of a silly hoop to have to jump through.
Edit: The application needs to delete the keys after it's used them, so I can't just put them in HKEY_LOCAL_MACHINE.
There are 2 recommended approaches for what you want:
Use a per-user installation which
doesn't require Administrator
privileges. You will be able to use
HKEY_CURRENT_USER, but your product
is not installed for all users.
Use a per-machine installation which requires Administrator privileges. In this case you need to redesign your application so it reads its settings from a configuration file. HKEY_CURRENT_USER should be used only when saving user-specific settings, not for global application settings.
Basically, if your application is per-machine, it should use HKEY_LOCAL_MACHINE or a configuration file. If it's per-user, you can use HKEY_CURRENT_USER. Any other combination has limitations and will not work the way you need.
If you need your application's information to be available to all users, use the HKEY_LOCAL_MACHINE hive.
EDIT - 2 alternatives:
Change the security of your registry
keys to allow users to edit/delete
them,
Use the ProgramData directory (instead of the registry) to store
the data.
I have a setup program that I want to install to a local folder. I also do not need it to write any settings to the registry. On Vista, and maybe on Windows 7, executables named similar to setup or install require admin privileges, I would like to be able to run it without admin privileges, to make sure that it does not write to the registry. Is there a way to force this type of mode, sort of in a sandbox?
If you are producing the installer and using MSI, set bit 3 of PID_WORDCOUNT in the MSI package (per this question).
The answer to this question is relevant if you are producing the installer but aren't using MSI - see create a manifest that prevents elevation.