Tafiti – Microsoft Live Search with Silverlight

This is pretty cool: http://www.tafiti.com/

I think my favorite feature is the newspaper layout for the news results. This might actually get me to use Live search once in while instead of Google, although I’m not so sure about the usability. The font size for the web results seems a bit small and I’m not so sure about the two-column layout (but this might be because I’m so used to seeing the summary below each result). The tree view seems to be there purely as eye candy, I can’t how this is usable at all…

Email Was Broken

My apologies to anyone who may have tried to contact me though this site. I just discovered that sending mail from the site has been broken. My hosting provider (who shall remain nameless) has this annoying habit of changing things without notification. What’s even more annoying is that their changes often are breaking changes and I usually discover them by accident.

If this was a business site I’d be really pissed.

End of rant.

Office 2007 Sucks Too

Well, to be fair, Outlook 2007 sucks. I haven’t used the other Office apps enough to say they suck, yet.

Outlook seems to throw a hissy fit anytime I send email to someone from my address book. The message gets stuck in the outbox and the little icon down in the task tray goes spastic, flickering between the “send/receive” icon and the “normal” Outlook icon. I’m not alone with this problem:


The RTM versions of Vista and Outlook feel like beta versions. Wait for the service packs, people!

Vista Sucks – Ditto

I’ve been running Vista for less than two months and I already have to reinstall it. I’ve had almost the same experience as Milan Negovan:

The Lethal Shutdown

The day before yesterday, I pressed the Shutdown button expecting a prompt (something you can configure in XP). Vista neatly closed the few applications that were running, logged me out and shut down, nice and easy.

Imagine my surprise when I booted it up tonight only to see a Windows 2000-style GÇ£flatGÇ¥ user interface with everything I installed missing, no glass, nothing. Somehow I got downgraded to a non-privileged user, unable to even see anything in the Control Panel. To add insult to injury, every GÇ£zoneGÇ¥ in IE 7 became locked. I was locked out and not given any options to do anything about it.

Vista tells me it can’t load my profile after I log in. I tried creating a second admin user account from scratch and logging in with that, but the result was the same. I cannot enable the “true” administrator account, because Vista won’t let me run the “computer management” applet. It’s like UAC is broken. In a bad way. Instead of prompting me, I just get an access denied message.

When Vista was working, I’ve had a bad experience with the only game I tried to play on it: Halo. The sound is very choppy and it’s almost unplayable because of it. And this is a Microsoft game! I read in few places that the old DirectSound API no longer supports hardware acceleration under Vista, and as a result, sound in pre-DirectX 10 games is handled completely in software (i.e. slow). I set the machine up to dual boot into XP and Halo works great there.

You may have read this advice elsewhere, but I have to agree with it and say it again: If you have a stable computer that’s running XP, DON’T UPGRADE IT. Vista is not worth upgrading to. If you’re going to buy a new computer anyway, consider getting it with XP (Dell still offers XP), especially if you have old (or not so old) games you want to run on it. Microsoft is cutting off supplies of XP at the end of year, so the next few months will be your last chance to get it if you don’t have a license you can transfer. Hopefully by then they’ll have released a service pack (or two) and the story will be better.

On the other hand, part of me thinks Vista is another Windows ME – an unstable OS that earned a bad reputation and one that a lot of people skipped…

Another Workaround for Expired ClickOnce Code Signing Certificates

Daniel Margetic has posted a workaround for updating a ClickOnce application that has been deployed with an expired Authenticode certificate.  I wrote about this problem back in January and came up with a kludge that involved automatically uninstalling the app and reinstalling from a new location.

Daniel’s solution uses a newer version of the code signing tool, included in the Windows Server R2 SDK, that allows you to sign with two different keys – one for Authenticode and one for the manifest’s “strong name”.  Basically, you continue to sign the manifest using the key from the expired cert and generate the Authenticode signature using the renewed certificate.

Details at Daniel’s blog:

ASP.NET Version Mismatch

A colleague was modifying an in-house ASP.NET 1.1 application this past week to use a corporate authentication service. This service works via HTTP redirects from the application to the service and then back to the application, once the user is authenticated. A “ticket” is returned to the calling application, where it is validated and stored in a cookie using ASP.NET Forms Authentication.

My colleague modified the web.config file of his app to use Forms Authentication (it had previously used Windows authentication) and setup a login page that redirected to the corporate authentication service. Everything worked fine, until the next day when he reopened his Visual Studio 2003 solution for this app and was greeted by an “ASP.NET Version Mismatch” dialog that claimed his web server was configured for ASP.NET 1.0. The choices where to cancel opening the web project or make the application “1.0” compliant (whatever that means).

ASP.NET Version Mismatch

He then sought out my assistance and I suggested we use aspnet_regiss.exe to re-register ASP.NET 1.1 with his web server (thinking that the IIS configuration somehow got mangled). That didn’t help. We then turned to Google for answers and after following several wrong turns, each providing clues as to what the real problem was, came up with a solution.

This MS knowledge base article provides some clues as to what is really going on: http://support.microsoft.com/kb/827074

Although the suggested workaround didn’t work, the important piece of information is the reference to the Get_aspx_ver.aspx ASP.NET page. See, Visual Studio 2003 does a GET on this non-existent page using your web project’s virtual folder. You can verify this by examining the IIS logs. Since my colleague had enabled Forms Authentication, this request got redirected to the login page which in turn REDIRECTED VISUAL STUDIO TO A SITE THAT WAS NOT EVEN RUNNING ASP.NET (the corporate authentication server). Visual Studio checks for the ASP.NET version in the HTTP response headers and displays the dialog above when the version doesn’t match the expected ASP.NET 1.1 version.

The fix is simple. Add the following to the web.config file to allow anonymous users (in this case, Visual Studio) to access get_aspx_ver.aspx:

<location path=”get_aspx_ver.aspx”>
       <allow users=”?”/>

(this goes after the system.web section)

iTunes 7.1.x Causes LoaderLock Exceptions When Running Windows Forms in the Debugger

I got burnt by this today.  Seems that the latest version of iTunes for Windows (which I installed this morning) really messes with Visual Studio 2005.  The 1st keystroke entered into a Windows Forms app running in the VS debugger causes VS to throw a “LoaderLock” exception.  This only happens if iTunes is running – shut it down and everthing works normally.

Here’s a discussion about the problem on the MSDN forums:


The last comment is from someone at Microsoft pointing the finger at one particular iTunes DLL, named iTunesKeyboardCompatibility.dll.  Maybe they should have named it iTunesKeyboardIncompatibility.dll.

Taking this bit of info, I tried deleting the file and running iTunes.  But the self-healing Windows Installer technology restores the dll on startup.  I shut down iTunes and deleted the file once more, but this time I created a zero-length file of the same name to take its place.  This prevented the original file from being restored when iTunes was started back up.  It immediately complained about the “dll” I created, but after dismissing the error, iTunes and Visual Studio both worked just fine.

I could once again listen to The LOST Podcast with Jay and Jack while debugging my code.

ClickOnce and Expiring Code Signing Certificates

There’s a really nasty bug in .NET 2.0’s ClickOnce deployment technology. If you deploy a smart client as availaible “off line” (launchable from the start menu) and you sign your manifest with a certificate from an official certificate authority (such as Thawte or VeriSign), you cannot renew your certificate and deploy to the same location! If you do, the next time someone starts your client it will barf up an error and won’t start. Examining the log will reveal the problem in the somewhat cryptic message “The deployment identity does not match the subscription”.

The problem is that the certificate authorities issue “renewed” certificates with a different private key. This makes up part of the ClickOnce app’s “identity” and ClickOnce validates this when starting an app to prevent tampering.

The only workaround is to uninstall and reinstall the app via the add/remove programs control panel applet. This really puts a kink in the whole “click once” thing, doesn’t it? I ran into this issue recently at work, as our code signing certificate was set to expire. Since I’m experienced enough to never trust Microsoft to do the right thing, I tested the “renewed” certificate in a test environment. Several Google searches later, I see that I’m not alone in discovering this problem.

To avoid having over 200 users fart around in the “add/remove programs” control panel applet, I came up with a kludge to have the client application uninstall itself and launch the ClickOnce installer, signed with the new certificate, from a new location. So after deploying the client signed with the new certificate, I deploy an update with the old certificate that contains the “reinstall” logic. Part of this trickery involves obtaining the “Public Key Token” for your app (I believe this comes from the certificate used to sign the ClickOnce manifest). The following snippet illustrates how to determine the public key token programmatically:

/// <summary>
/// Gets the public key token for the current ClickOnce app.
/// </summary>
private static string GetPublicKeyToken()
    ApplicationSecurityInfo asi =
        new ApplicationSecurityInfo(
    byte[] pk = asi.ApplicationId.PublicKeyToken;
    StringBuilder pkt = new StringBuilder();
    for (int i = 0; i < pk.GetLength(0); i++)
        pkt.Append(String.Format("{0:x}", pk[i]));
    return pkt.ToString();

Next, we need to find the uninstall string in the registry, based on the PublicKeyToken:

/// <summary>
/// Gets the uninstall string for the current ClickOnce app from the
/// Windows Registry.
/// </summary>
/// <param name="PublicKeyToken">The public key token of the app.
/// </param>
/// <returns>The command line to execute that will uninstall the app.
/// </returns>
private static string GetUninstallString(string PublicKeyToken, 
  out string DisplayName)
    string uninstallString = null;
    string searchString = "PublicKeyToken=" + PublicKeyToken;
    RegistryKey uninstallKey = Registry.CurrentUser.OpenSubKey(
    string[] appKeyNames = uninstallKey.GetSubKeyNames();
    DisplayName = null;
    foreach(string appKeyName in appKeyNames)
        RegistryKey appKey = uninstallKey.OpenSubKey(appKeyName);
        uninstallString = (string)appKey.GetValue("UninstallString");
        DisplayName = (string)appKey.GetValue("DisplayName");
    return uninstallString;

I then launch the uninstaller, using the Process class, and use some Interop calls to the Win32 API to find the uninstaller window and automatically “push” the “OK” button (would have been nice if the was a /silent switch so I wouldn’t have to do this). Finally, I launch ClickOnce for the new version of the client, signed with the new certificate, to update the user’s workstation. A zip file with this source code can be found here: ClickOnceReinstall.zip Using these utility classes, I just insert the following code into the client’s startup routine to make it reinstall itself:

// Self-uninstall

Windows Explorer Periodically Hangs with High CPU Utilization

So my PC at work has been giving me trouble this week. Every so often things would just sort of hang for several seconds. Sometimes it would be when I tried to open an email message in Outlook, sometimes when I was working with a web application in IE, sometimes when killing the screen saver after being away from my desk. There just wasn’t any rhyme or reason to it. One thing I did notice was that each time it happened, the Windows Explorer process, explorer.exe, would be consuming 99 – 100% of the CPU.

My first fear was that Windows had been infected by some nefarious bit of code. I checked the system with a couple virus scanners and anti-spyware tools, but found nothing. I tried using Windows XP’s restore points to roll back to a time before this problem starting happening. All that did was screw up Visual Studio 2005 (which I then had to repair). I tried uninstalling that last couple of applications I had installed. I tried disabling IE add-ons. Nothing helped.

Finally I tried to make some sense of what was going on inside explorer.exe when it was gobbling up CPU cycles by using the Visual Studio debugger and Sysinternals’ Process Explorer. There were enough clues there that led me to think that whatever was happening was centered around the Windows desktop folder. Hmmm. Desktop. I had set my desktop to hide all icons months ago (FYI: right-click the desktop, click “Arrange Icons by”, and then uncheck “Show Desktop Icons) in an effort to unclutter things (and I got tired of fighting every little app that feels it’s important enough to put itself on my desktop). So, I made the desktop icons visible again to see what was there.

Bazillions of files. Covering both my displays and then some. XML files. I knew immediately where they had come from. The application I maintain and support has an option to save the XML requests/responses to and from the server. Where does it save them? To your “working directory”. Where’s the working directory? By default, the Windows desktop. Ugh. I had enabled this logging months ago and forgot to turn it off. It appears that things hit critical mass this week and was causing Explorer to choke (explorer.exe runs the XP desktop, taskbar, and start menu as well as the file explorer).

Things got much faster after nuking all those files. I also checked the utilization of the MFT using defrag c: -a -v and since it was over 90%, I ran this batch file to expand it a bit:

md c:MFT-folder
md C:MFT-files
cd c:MFT-folder
FOR /L %%f in (1,1,5000) do md %%f
cd C:MFT-files
FOR /L %%f in (1,1,50000) do echo Creating files >%%f
cd c:
rd /s c:MFT-folder
rd /s C:MFT-files

It’s usually best to do this after defragging the drive. Basically, you’d like there to always be some space available in the MFT so you don’t have to wait for Windows to expand it, and if you use this method with Windows defrag it will also help prevent the MFT from becoming fragmented.