If you've run a unit test in Visual Studio 2008 that utilizes database connectivity, you may have seen this error when creating a connection object:
Instance names used for writing to custom counters must be 127 characters or less.
The problem crops up when you're running the test within a directory structure with a fairly long name, i.e. you're organizing your code well and giving your projects descriptive names. Well, this error is punishment for being organized.
There are several Microsoft bug reports on the issue. One has been ignored, the other closed.
There are posts on the web with some workarounds, but none worked for me, perhaps because I'm using Visual Studio 2008? No matter what I tweaked in .testrunconfig I was still getting the error. The other approach--shortening the pathname--was really a non-starter. I wasn't going to compromize well-thought-out organization to get around a Microsoft bug.
So I took a peek at the source of the problem as hinted by the call stack when the error appeared. It's a method in the internal DbConnectionPoolCounters class in the System.Data.ProviderBase assembly. Here's the code:
private string GetInstanceName()
{
string assemblyName = this.GetAssemblyName();
if (ADP.IsEmpty(assemblyName))
{
AppDomain currentDomain = AppDomain.CurrentDomain;
if (currentDomain != null)
{
assemblyName = currentDomain.FriendlyName;
}
}
int currentProcessId = SafeNativeMethods.GetCurrentProcessId();
return string.Format(null, "{0}[{1}]", new object[] { assemblyName, currentProcessId }).Replace('(', '[').Replace(')', ']').Replace('#', '_').Replace('/', '_').Replace('\\', '_');
}
The instance name of the performance counter is being built, in part, from the name of the AppDomain. When running tests in Visual Studio, this name can be very, very long, especially if your project's home has a long pathname.
The workaround I pursued, then, is to shorten the name of the app domain. While AppDomain.FriendlyName is a read-only property, and there's no private field of the AppDomain class to change it, there is a private extern method of AppDomain called nSetupFriendlyName. And, like magic, if you invoke this method and give the app domain a shorter name, problem solved!
Here's the workaround, utilizing a little reflection magic:
[ClassInitialize]
public static void ClassInitialize(TestContext testContext)
{
typeof(AppDomain).GetMethod("nSetupFriendlyName", BindingFlags.NonPublic | BindingFlags.Instance).Invoke(AppDomain.CurrentDomain, new object[] { "Test" });
}
Subscribe