I’ve been writing a hands-on style article on using the Packaging API and Office Open XML. It all works smoothly, but its glaringly apparent that Microsoft needs to provide some wrapper classes for Open XML documents to make the API more usable. You can download some code snippets, which is a start, but these only scratch the surface. After all, Office developers are used to the COM automation API which makes it relatively easy to create and manipulate documents. By contrast, to get anywhere with Open XML you have to understand the raw XML. It is still miles better than working with RTF, or with the binary Office formats, but more difficult than it should be.

By way of illustration, look no further than the official code snippet for XLInsertStringIntoCell, which does what its name suggests: writes a string into the specified cell of an Excel spreadsheet. It is over 200 lines of code and comment (in fairness, more comment than code). That would be just 2 or 3 lines in VBA. Of course, once you have the wrapper function, it is just as easy. Unfortuntely there is a lot to wrap, but it is not necessary to be comprehensive. A simplified DOM that enabled the creation of basic formatted documents and spreadsheets without having to write thousands of lines of code would meet most needs.

I realise that you can write a “Hello world” document fairly easily; I’ve done it myself. But “Hello World” is not particularly useful. After all, you could output plain text or CSV, and Word and Excel will open them happily enough. The point of Open XML is to enable documents that have a little more to them: headers and footers, specified margins, rich formatting with fonts and paragraph styles, tables and graphics. Doing all that in Open XML is not trivial.

I am not the first to think along these lines. For example, here’s some code posted to CodePlex for working with Excel. Good stuff, but personally I’d like to see some official libraries, or even a well-run (WIX-style) officially endorsed open source project for this. It’s badly needed.

A couple of years ago I wrote a piece on why Visual Basic 6 was frozen.

The topic is still of interest, and some reason reddit.com picked this link up recently, so the article has thousands of new readers.

If nothing else, it proves that developers still miss the old Visual Basic. Perhaps not so surprising; as I pointed out, it once had a reasonable claim to be the most popular programming language. That would not be true now; C# seems to be more popular than VB.NET, certainly among professionals, and I suspect Java is the number one overall (though these things are hard to measure intelligently).

Would I write the same article today? More or less, though the arrival of Vista and Office 2007 would make me state more forcibly that neither COM nor the Win32 API is dead. I still think that maintaining old-style VB would not have been feasible for Microsoft, except like FoxPro as a legacy thing and sadly now a dead end.

It’s also worth noting that VBA lives on, even though Microsoft is focusing on VSTO in its place. Except on the Mac, which is another story.

PS: I’ve fixed the comment feature on the article, so you can now have your say.

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.