Category Archives: .NET

All things Microsoft .NET related

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:

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1332045&SiteID=1

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(
                    AppDomain.CurrentDomain.ActivationContext);
    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(
        "SoftwareMicrosoftWindowsCurrentVersionUninstall");
    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");
        appKey.Close();
        if(uninstallString.Contains(searchString))
            break;
    }
    uninstallKey.Close();
    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
Utils.DeploymentUtils.UninstallMe();
Utils.DeploymentUtils.AutoInstall(
  "http://host-name/deployment-folder/MyApp.application");
Application.Exit();
return;

Napkin Look & Feel for Java Prototypes

Java Swing is often criticized for its lack of native widgets. Controls in Swing are rendered by Java code, rather than the underlying OS. This can create problems like having a Java app that doesn’t have the same “look & feel” as applications that run natively on any given OS. Java Swing addresses this issue by supporting pluggable “look & feel” libraries. Basically, for each operating system/windowing system that you want to support with a native look & feel, you have to obtain/write a look & feel library. There are a few that come with the Java runtime, depending on what OS the runtime is for (i.e. the Apple OS X Aqua look & feel only come with Apple’s JRE). Swing has also had a bad reputation for being slow, although in the latest JRE this seems to be a thing of the past.

The “Napkin Look & Feel” project uses Swing’s lack of native widgets to it’s advantage. It’s a Java pluggable look and feel that makes your application’s UI look like it was scrawled on a napkin. Novelty of it aside, this is great for making prototype UIs that really convey the message: “This is a prototype and nowhere near a completed application”. Kathy Sierra wrote a great post about the various reasons you want to send this message.

Anyway, I thought this was a great example of turning a weakness (or perceived weakness) into a strength. Now I wish I could do this in .NET…

Microsoft Access + OleDb ADO.NET provider + LIKE = puzzlement

I haven’t worked with Access much in a while and I ran into something today that drove me nuts for about a half hour. In SQL Server, Oracle, and probably every other major database the wildcard character used with LIKE comparisons is the percent sign (%).-á In Microsoft Access you use asterisks (*).-á UNLESS YOU RUN YOUR QUERY FROM A .NET APPLICATION USING THE OLEDB ADO.NET PROVIDER. Then you use %. Ugh. I thought I was going crazy. I couldn’t figure out why the same query worked from inside Access, but not my .NET code.

It’s actually probably a good thing it works like that. I could see where you might want to support multiple back-end databases without having to change all your SQL. If you were careful to stay away from vendor-specific features, you could (theoretically) just change your connection string…

Windows 2003 Server/IIS6 Kicks Windows 2000 Server/IIS5’s Butt

This is probably old news to many, but believe Microsoft when they say that there are significant performance and scalability improvements in Windows 2003 Server and IIS 6. I’ve been wondering why my “puny” Athlon XP development system at work has seemed so much faster than the “beefy” dual-Xeon production server at work. Besides the hardware differences, the production box runs Windows 2000 Server while the dev box is running Window 2003 Server.

I set up a test environment to compare 2000 vs. 2003 on identical hardware and found that, for my application (.NET smart client that uses a Web Service on the server), that start-up times where 3-4x faster when the server was running Windows 2003. Other operations where at least 2x faster. Needless to say, I’ll be pushing for an OS upgrade…