Today my work computer started behaving badly…

and SQL Server Management Console…

Nice error… “The file exists.”  Fortunately the details were actually helpful…

Calls to “GetTempFileName “ are failing and the word on the Intertubes is that will happen if you end up with > 65,000 files in your temp folder.

Which, apparently, I have accumulated.  Cleaning those out and everything works wonderfully again.

FAIL to all the developers of the software I use that are leaving all these files here…

We’re working on redesigning our licensing code and part of that involved generating a unique installation ID for each installation of our software.  The goal is for this identifier to be absolutely unique for each client while still being small enough that it would be feasible for them to read it over the phone to us. 

The identifier is generated from hashing together a lot of system data and converting that into a N digit code, where N is large enough to be unique but small enough not to be cumbersome.

That got us thinking…

For various identifier lengths, how many identifiers could we generate before we had, say, a 1% chance of a collision?

This is an implementation of the birthday paradox (ie. what are the chances two students in a class of 30 share the same birthday). 

It turns out that the math to solve this problem produces some absolutely ginormous numbers.  Excel gave up rather quickly as did Python’s built-in numeric types but fortunately the add-on mpmath library can handle such ridiculous numbers with ease.

A lunch hour of poking at it yielded the following chart.

From this you can see that with a key size of only 10 digits and only a few thousand identifiers you are risking a collision while for  a 12 digit key one can safely handle 100,000 + identifiers.  Moving to 15 or 20 digit identifiers makes the chance of collision insignificant unless we are dealing with enormous numbers of identifiers (which we are not).

I’ve created an online calculator for the birthday paradox here.

from mpmath import *
def collisionProbability(nKeys, nEntities):
    t1 = mpf(1)
    for i in range(nKeys-nEntities+1, nKeys+1):
        t1 *= i
    return 1 - t1 * power(mpf(1)/nKeys,nEntities)

We just migrated our project to Visual Studio 2008 today and… it stopped working.  Our application is a VB.NET/C# hybrid that makes use of a number of legacy ActiveX controls.  When we ran the freshly migrated project the ActiveX controls would fail with “Invalid Access to Memory Location” errors.

This is a side effect of the C# compiler now generating executables with the NXCOMPAT bit set (with no option in the IDE to turn that off).  This setting on the EXE enabled DEP (Data Execution Protection) on our program which prevents the legacy DLLs from doing what they need to do.

We’ve encountered this before here with our build machine and were able to resolve it by tweaking the build script.  Unfortunately the IDE was now failing and that’s more complicated.

On of our developers came up with a fix:

Turn of NXCOMPAT bit on build output

There is a utility called “editbin” that lets you modify the EXE and turn the NXCOMPAT bit off.  You can add it to the post-build events and that fixes the generated EXEs.  Unfortunately, the application still will not run under the IDE because it’s inheriting DEP from the vshost process.

Turn off NXCOMPAT bit on vshost32.exe

To make the application run under the IDE we can turn of NXCOMPAT on the vshost32 executable using “editbin”.

At this point the application seems to run like it always did under the IDE.

<grumble>

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\*\shell]

[HKEY_CLASSES_ROOT\*\shell\openwemacs]
@="Edit with &GNU Emacs"

[HKEY_CLASSES_ROOT\*\shell\openwemacs\command]
@="C:\\Program Files\\emacs-23.1\\bin\\emacsclientw -n –a \"C:\\Program Files\\emacs-23.1\\bin\\runemacs.exe\" \"%1\""

I’ve come up with a somewhat odd (but awesome) approach to templates for my static HTML pages that makes authoring/maintenance trivial and allowed for functional offline copies.

(article and code here)

I posted a short little how-to on bundling up a .NET program in a NSIS self-extracting installer to make writing .NET based utilities (single EXE with no installer) a little bit nicer.

It handles:

• Unpacking to a temporary directory, invoking the program, and cleaning up when it’s done
• Installing .NET 3 if it’s not on the machine already
• Passing through command line parameters to the .NET app

Article Here

Our product build machine is running Windows XP.  On September 1st we ran Windows update which installed 28 updates (we were a bit behind) on that machine.  From that point forward builds on that machine no longer run on Windows Vista machines.

KB970653, KB970653, KB970653, KB890830, KB890830, KB973540, KB973354, KB973507, KB973507, KB973869, KB971633, KB971633, KB951847, KB973346, KB956744, KB971557, KB971557, KB961371, KB970483, KB960859

This error is encountered when loading any of our 3rd party Active X controls and is triggered by Digital Execution Protection (DEP).  If I turn off DEP on my machine completely the build works just fine (don’t do this though, it makes a mess).

c:\> bcdedit.exe /set nx AlwaysOff

Also curious is that, in the build immediately prior to the update, I can go into “System Properties / Advanced / Performance / Data Execution Prevention” and add an exclusion for our program binary.  For the build immediately after the updates I get the following:

From this forum post it looks like you would not be able to turn off DEP if the EXE is one of the following:

There are three possible causes for why you cannot add the app to the
exceptions list:
1.) This is a 64-bit application.
2.) The application is in the Windows directory.
3.) The application has been compiled for Vista and, therefore, DEP is
enforced for it.

Our application is compiled for Any-CPU and is not in the Windows directory and I have no idea what a “Vista” build is.

After way too much searching I came across this article that states:

The C# compiler in Visual Studio 2008 and the .NET 3.5 Framework (csc.exe) is now generating PE files with the NXCOMPAT bit set. What is that bit and who cares, you ask? You may very well care if your application interops with native binaries or exposes a plugin model to 3rd parties.

…

The .NET 2.0 and VS 2005 compilers are also affected

The fix seems to be to turn off the NXCOMPAT bit for our application until we can get rid of our ActiveX dependencies.

Naturally VC++ includes a setting for turning of this NXCOMPAT feature but C# and VB.NET do not:

We can execute the following command on our EXE after the build process and it seems to fix things up for us.

c:\> editbin.exe /NXCOMPAT:NO <insert EXE here>

Unfortunately our EXE is strong named because we use ClickOnce.  So doing this after the build invalidates our signed executable.

So now we need to turn resign the EXE after doing this.

c:\> sn –Ra <exe> <keyfile>

Trying to add editbin.exe to a post build action raised some error code that isn’t documented anywhere that I could find.  Grumble…

I settled on adding the following to our MSBuild script and that seems to have worked… for now.

<!– NX Hack –>
<Exec Command="editbin /NXCOMPAT:NO &amp;quot;$(BinDir)\Program.exe&amp;quot;" />
<Exec Command="sn -Ra &amp;quot;$(BinDir)\Program.exe&amp;quot; &amp;quot;$(MSBuildProjectDirectory)\Port\keypair.snk&amp;quot;"  />

That was a lot of work rummaging around to find this.  Why Microsoft would sneak this change into a hotfix and is beyond me.  Surely Visual Studio can tell if the assembly is using ActiveX controls and could, at least, warn me that it is going to break my build.  Go Microsoft!

Everyone always says that in your unit tests you want to aim for 100% code coverage.  Doing this the usual way, by writing thoughtful test cases, is painstakingly slow.  This way is faster.  The idea is you create one simple class that is easy to use and so incredibly massive that it skews your reporting metrics thus making you look like a hero to management.

One big class:

using System;
using System.Collections.Generic;
using System.Text;

namespace Eni.AfeNavigatorServer.Services
{
    public class Big
    {
        public int Number()
        {
            int i;
            i = 0;
            i = 1;
            i = 2;
		.... AND THIS FOR 10,000 LINES
            i = 9997;
            i = 9998;
            i = 9999;
            return i;
        }
    }
}

The Unit Test:

using System;
using System.Collections.Generic;
using System.Text;
using NUnit.Framework;

namespace Eni.AfeNavigatorServer.Services
{
    [TestFixture]
    public class BigTest
    {
        [Test]
        public void NumberTest()
        {
            Big big = new Big();
            Assert.AreEqual(9999, big.Number());
        }
    }
}

The Results:

In a few short minutes I took this assembly from < 10% code coverage to 77%.  With that type of efficiency I should get a bonus!

Our application uses the “System.Data.OracleClient” library to connect to our Oracle database.  Something like this:

OracleConnection connection = new OracleConnection(     "Data Source=prod8a;User Id=bugnav;Password=bugnav");
DateTime startTime = DateTime.Now;
connection.Open();
Console.WriteLine(DateTime.Now - startTime);

Normally code like this would connect to Oracle in WELL under one second.  However, under Vista, the first time I run this it takes 12 seconds!  Subsequent executions are sub-second but, if I wait 60 seconds, the following connections are back up to 12 seconds.  Very odd!

It turns out that I see this behaviour if connection pooling is enabled (and it is my default) or if the “Min Pool Size” is not specified in the connection string. The following two snippets work perfectly.

OracleConnection connection = new OracleConnection(     "Data Source=prod8a;User Id=bugnav;Password=bugnav;Pooling=false");
DateTime startTime = DateTime.Now;
connection.Open();
Console.WriteLine(DateTime.Now - startTime);

OracleConnection connection = new OracleConnection(     "Data Source=prod8a;User Id=bugnav;Password=bugnav;Min Pool Size=10");
DateTime startTime = DateTime.Now;
connection.Open();
Console.WriteLine(DateTime.Now - startTime);

I have no idea why this is happening but at least it`s easy enough to work around.

It is apparently difficult to determine what version of ADO (not the .NET one) is installed on a machine.  I needed to do this for a client and can’t for the life of me find any easy way to do this outside of code so I wrote a little utility to do it.

Download it here (16 kb)