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.

I wrote a little Windows utility that updates a file. It’s safe and harmless; it just modifies a file which is in my user documents folder. I called the utility UpdateMSI. Under Vista with UAC enabled, running this app throws up a dialog:

An unidentified program wants access to your computer

But why? Simple: Vista inspects the name of the executable, notes that it includes the word “update”, and concludes that it needs local administrator rights.

On the face of it, this is silly. First of all, Vista is wrong: my app does not need admin rights. Second, it is infuriating that I am not given any choice in the matter. The UAC dialog says “Cancel” or “Allow”. It does not include the option to run with my normal user rights.

Microsoft did this in an effort to detect setup applications; the word “setup” has the same effect. It will trigger if the word is anywhere in the executable name. I tried it with WorldCupDatePicker.exe – same result.

Surely it would not have been too hard to give the user a say in this? Just a checkbox that says “Let me run this how I want on my computer”? You can disable UAC of course; but I’m not going to do that; overall it’s a good feature.

If you wrote the app, there is a fix. You have to embed a UAC manifest in your application. There are simple instructions here, though note that these explain how to force the UAC prompt, not how to suppress it. If you don’t want to run as admin, modify the line:

<requestedExecutionLevel level=”requireAdministrator”/> 

to read instead:

<requestedExecutionLevel level=”asInvoker”/>

Bottom line: always include a manifest.

The Register has my piece on software factories, based on an interview with Jack Greenfield, a Microsoft software architect. Greenfield talks about a 40% – 80% productivity gain.

If you’re not familiar with this stuff, a bit of orientation may help. When Greenfield talks about software factories, he means both factory instances, which automate the building and customization of specific types of application, and also factory-making tools, which let you create or adapt factories to suit your specific needs. And when Greenfield talks about the factory “runtime”, he means the infrastructure in Visual Studio and its SDK that lets you put your factory to work.

You can actually play with this stuff now. The runtime is called the Guidance Automation Extensions and the authoring tool is the Guidance Automation Toolkit; perhaps one should add the Domain-Specific Language tools. All can be downloaded. You can also download the first four software factory instances. If anyone has tried these and has comments, I’d love to hear from you.

I was intrigued by the internal debates Greenfield mentions. He says it was a mistake to ship the “White Horse” modeling tools in Visual Studio 2005 (Design for Deployment) as a fixed set which are used only occasionally. He is now focused on shipping tools to make and customize tools, a strategy which he believes has more future.

We will always need tools; improvements are welcome. That said, I am also reflecting on the lesson from Qcon: the human factor counts most.

Why would you want to run Visual Studio 6 on Vista? Two reasons. First, because it includes Visual Basic 6.0, the last version not based on .NET. Second, because Visual C++ 6.0 is still widely used to avoid issues with the C runtime library. There is little point in installing the other products in Visual Studio 6.0.

Visual Basic 6.0 is supported on Vista, but Visual Studio 6 is not. One reason is that it includes the Microsoft Java Virtual Machine which Microsoft promised Sun it would withdraw. This is the stated reason why Visual Studio 6.0 is no longer available for download, even for MSDN Universal subscribers. Fortunately I still have some old MSDN DVDs, so I dug these out and ran setup for the Enterprise edition of Visual Studio 6.0, installing on Vista Professional.

I can’t pretend it went smoothly. First there were compatibility warnings, which I ignored. I deselected applications other then Visual C++ and Visual Basic. Then setup appeared to hang on the screen where it detects installation components, and Vista popped up its “Program not responding” dialog. I believe this is just a matter of patience. My tip is to run task manager and see if the ACMSETUP process is taking up CPU time. If it is, give it more time.

So setup completed, but with an error towards the end:

RegCreateKey failed for \Interface\OLEViewerIViewerCLSID. Access is denied

followed by a DLLREgisterServer failure. I was informed that setup had failed, but nevertheless VB 6 and VC++ were installed and seemed to run OK.

Naturally I wanted to apply the service pack – SP5 or SP6. This is where I had the biggest problems. I could run SETUPSP6.EXE, but the install always failed. If I logged the install, I found this entertaining error:

Do not ship. Error message to log function that detects what VS products are installed in what language unable to function.

Hmmm. I Googled to no avail, though I found this thread where several others report the same problem. Then I tried removing Visual Studio 6.0 for a reinstall, but got the same error from add/remove programs. I finally twigged. The problem was that the first install never completed. Although the product was mostly installed, some part of the Microsoft Installer database had not been updated. The error message actually makes sense: the products were not installed.

Therefore I re-ran the original setup. This time I went into the Tools part of custom setup, clicked Change Option, and deselected the OLE/COM object viewer. Setup now completed without error; so too did SP6. Success.

The apps seem to work OK too – so far so good, though I’m resigned to having to use Run as administrator.

Try this at your own risk; as I mentioned above, Visual C++ 6.0 is not supported on Vista; in fact, I don’t think it is supported at all.