How do I get the current users name in a custom action for windows installer?

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 curren开发者_如何转开发t 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.

---

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

Environment.GetEnvironmentVariable("USERNAME");

to get current user name.

---

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).

---

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];

---

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.

---

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/