A couple of days ago I posted about programmatically detecting whether UAC is enabled. I was proposing to read a registry entry. Thanks to the power of blogs, my post drew a comment from Andrei Belogortseff, who has posted C++ code that does this properly. His library has functions for detecting whether the current process is elevated, detecting whether UAC is enabled, and running new processes both elevated and non-elevated (the last of these is the hardest to do).

I liked the libary but wanted to use it from .NET. I compiled his code to a DLL and did a C# wrapper; then I considered the hassles of adding a dependency on the Visual C++ runtime libraries. I therefore did a quick C# implementation of the functions I cared about; I haven’t included the code for running new processes. Please go ahead and download the code, and let me know if you have any suggestions, or even if there is a much easier way to do this that I have missed. There is an app called UACElevationCheck, which calls functions in VistaTools.cs.

The code is only intended to be called from Vista and will throw an exception otherwise; of course you can modify it as you like.

I’ve included a function IsReallyVista that looks for a Vista-only API call, rather than relying on the reported version information. This is because the version information is unreliable if the app runs in a compatibility mode. On the other hand, IsReallyVista is a hack; if you don’t like it, use IsVista which uses the version information instead.

You may be able to do this using the System.Security namespace rather than PInvoke. I had a quick look but the PInvoke code seemed easier to me, especially since Belogortseff has already done the real work.

People who should know say not to use managed code custom actions in your Windows Installer setups. Like Rob Mensching of Wix fame who says:

…today the Windows Installer does not support managed code CustomActions and the general direction appears to be to try to reduce the need for CustomActions overall.

Read the blog entry for the reasons. The strange thing is, Visual Studio 2005 has specific support for managed code custom actions; there is an Installer class and an MSDN walkthrough on how to use it. 

Now, I have always avoided managed code custom actions anyway, but only from instinct. Windows Installer setups are problematic enough as it is; adding .NET Framework dependency seems unnecessary. Mensching’s post above explains why it is also error-prone. See also Aaron Stebner’s post from March 2005.

… in summary, I strongly encourage you to not use managed code in your product setup.  I realize that some teams do this here at Microsoft, but please don’t use our bad (in my opinion) examples to justify doing so in your own setup….

Presuming these guys are right, might it not be wise for the Visual Studio folk to remove support for managed code custom actions from the product? A point of confusion is that the managed installer class works with a utility called InstallUtil which is distinct from the Windows Installer; in fact, I believe that Visual Studio setup projects which include managed code custom actions actually call InstallUtil.

I suggest Delphi as a handy alternative, if you would rather avoid Visual C++.

Finally, I hear many good things about Wix, the free XML-based authoring too for Windows Installer setups. If you are embarking on a new setup project it is worth a look.

An application may sometimes need to know whether or not the current user has administrative rights. This is complicated in Windows Vista by User Account Control (UAC) – the user may be in the Adminstrators group on the local machine, but nevertheless running with limited rights. When I came across this blog entry on COM elevation by Christoph Wille(thanks to Daniel Moth) I was interested to see the function he mentions called IsUACEnabledOS. I downloaded his code, but was disappointed to see this:

// a really simple check that does not account for possible UAC-disabledness via group policy
public static bool IsUACEnabledOS()
{
int majorVersion = Environment.OSVersion.Version.Major;
int minorVersion = Environment.OSVersion.Version.Minor;

return (majorVersion >= 6);
}

This just detects Vista or higher; in fact, it won’t always return the correct result, since Vista will lie about the version number if an application is running under compatibility settings. How then do we discover if UAC is enabled? The best I’ve come across so far is to query this registry entry:

HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\EnableLUA

If the entry does not exist or is 0, UAC is not enabled. Of course there is no guarantee that this always work, but it’s unlikely to change. I also haven’t checked that it is there in the base versions of Vista; again, it is probably the same.

Update: See the comments to this post for a better solution from Andrei Belogortseff, using the GetTokenInformation API call.  

I’ve now posted a C# implementation of Andrei’s code.

Vista’s User Account Control (UAC) elevation prompt sometimes appears when it shouldn’t. Here is an example which works every time for me. I have a folder in Documents (within my home directory) called recordings, containing MP3 files. I double-click one of these files and it opens in Windows Media Player. Now let’s say I try to rename the recordings folder. I get a dialog saying I need to confirm this operation, complete with a UAC shield.

I click Continue and get the screen flash and the elvation prompt. It’s not enough though; I now get a dialog that says “Destination Folder Access Denied – You need permission to perform this action.” If I click Try Again, I get the same dialog, for ever.

It’s nonsense of course. I don’t need permission; I need to close the MP3 file. Indeed, if I close the file I can then rename the folder.

Oddly, if I try this with a Word document, Vista correctly reports that the folder in in use by Word. But if I try a second time, I get the inappropriate UAC prompt.

It’s possible that some Windows API call is returning an access denied error, when it should indicate a file or folder in use by another process, or there could be some other explanation. The end result is a poor user experience.

If Microsoft can’t always get this right, it illustrates how hard it is for developers to give users appropriate error messages when working with UAC on Vista.