11

I need to get the username of the user running the installer for my custom install action. Because the installer gets special priviledges, Environment.UserName just gives "SYSTEM".

Environment.SpecialFolders.ApplicationData returns the current users appdata folder, but I can't reliably dig the username out of it.

More case specifics:

Using a Visual Studio 2008 Setup Project The custom action is an installer class run after install and is the only one in the project.

Septih
  • 1,436
  • 17
  • 40
  • Can you give some more information? Are you using a setup project? Building based on WiX? Can you add where (sequence, position) you schedule your custom action? Is it running deferred? Immediate? – Benjamin Podszun Dec 21 '09 at 17:19
  • I've added a bit more detail to the question. I've not touched WiX. Pretty sure it's immediate. – Septih Dec 22 '09 at 08:52

5 Answers5

9

You can get some information from Environment variables. I am using

Environment.GetEnvironmentVariable("USERNAME");

to get current user name.

Ankit Verma
  • 91
  • 1
  • 2
  • This answer worked for me -- it returns the logged-in user and NOT the elevated installer user from within the custom action. – John Kroetch Mar 11 '14 at 16:50
  • I also obtain the domain using this method: Environment.GetEnvironmentVariable("USERDOMAIN") + "\\" + Environment.GetEnvironmentVariable("USERNAME") – John Kroetch Mar 11 '14 at 17:02
3

Basically, you can't.

UAC in MSI Notes: Credential Prompt and Permissions explains some of this is more detail, but effectively once you've elevated your credentials the currently logged in user is SYSTEM from the installers point of view (you can have multiple people logged in and running applications on a machine, so you have to think from the context of the process itself rather than who is sitting in front of the physical machine).

saschabeaumont
  • 22,080
  • 4
  • 63
  • 85
2

Use WindowsIdentity.GetCurrent().Name from the System.Security.Principal namespace. This will include the domain portion as well so if you don't need that add a split to the end of it. WindowsIdentity.GetCurrent().Name.Split('')[1].

using System.Security.Principal;

this.nametext = WindowsIdentity.GetCurrent().Name.Split('')[1];
Scott Boettger
  • 3,657
  • 2
  • 33
  • 44
  • There were other answers that suggested this too, but seem to have been deleted. This doesn't return the users name in vista, it still returns SYSTEM – Septih Dec 22 '09 at 11:49
  • take a look at this post. http://stackoverflow.com/questions/400872/c-active-directory-check-username-password. It's more about validating but it might be useful. – Scott Boettger Dec 22 '09 at 13:05
2

First, make sure you have the Impersonate bit set to OFF. Here is how.

Unfortunately, there is not a way to directly set this flag for a custom action in the UI for the setup project in the Visual Studio IDE. In Visual Studio 2005, you can use a post-build step that modifies the MSI to set this bit using a strategy previously described in this blog post.

Second, I assume you are running Vista because people seem to have this problem with Vista and someone asked this question on MSDN and his solution was to follow the blog post linked here.

Robert Flaming's Blog post on UAC in MSI Notes: The NoImpersonate Bit Mistake also gives some insight into these issues.

  • Right, I already have the Impersonate bit turned off. I looked at the blog which answered the msdn question and tried the manifest solution, but that doesn't seem to have changed anything. I basically just copied the manifest from the blog and saved it as setup.exe.manifest – Septih Dec 21 '09 at 16:00
  • Sorry but I dont have anymore info atm –  Dec 22 '09 at 03:42
2

I've never touched VS setup projects (played with WiX though and can recommend it). Looking at your problem it seems that your CA runs deferred (and with elevated privileges).

Searching the net for VS setup projects I came across a lengthy article 1 that contained this paragraph (search for "deferred"):

In other words, the Visual Studio design restricts you to custom actions that are called when your files are on the system (deferred custom actions), which means that you must use the CustomActionData property. Other tools that generate MSI files are often more flexible, so if you anticipate complex setups, investigate those tools.

1: http://www.simple-talk.com/dotnet/visual-studio/visual-studio-setup---projects-and-custom-actions/

Benjamin Podszun
  • 9,679
  • 3
  • 34
  • 45