In addition to concurrency, the 64bit realm is another obvious place where the PC/Server world is going. It’s faster than 32bit, we can address more memory, and we can have more accurate hardware floating point. Ideally, it should be easy for everyone except low-level framework authors, device driver authors, and the like to migrate their applications to 64bit. I mean this for Native applications too. If you had to support both “interface X” and “interface Y” in your application, you’d create a level of indirection to do so, perhaps a Strategy pattern.
If you are a .NET developer, all of your programs should magically become real 64bit applications when running on a 64bit .net framework on a 64bit machine. Handy!
I have not written a non-trivial C program in quite some time, so I preface this statement with the disclaimer that it may be total crap: If you are a native developer you should also be able to effortlessly port your app to work with 64bit systems. If you are NOT hard-coding any address sizes, struct sizes and the like, a simple recompile should work. Using sizeof(), size_t, etc. the compiler becomes your level of indirection in a way.
Today I sat down to start testing TestDrivenàxUnitàNCover; I pretty much need TestDriven and NCover to do serious work. xUnit.Net ships with an easy installer that tells TestDriven it exists. It reports success. It doesn’t work. I happen to have the xUnit code on hand so I run it through the debugger. TestDriven looks at a registry key (HKEY_LOCAL_MACHINE\SOFTWARE\MutantDesign\TestDriven.NET\TestRunners) for a list of assemblies containing a class that implements its test runner interface and their locations. The following code returns “true”:
public static bool IsRunnerInstalled
{
get
{
using (RegistryKey runnerKey = Registry.LocalMachine.OpenSubKey(@"SOFTWARE\MutantDesign\TestDriven.NET\TestRunners\xunit", true))
return (runnerKey != null);
}
}
The problem is, inspection using Regedit shows that the key is clearly not there. What’s going on? Just on a hunch, I thought I’d google for some 64bit issues. Since there’s \Program Files\ and \Program Files(x86)\ on my 64bit machine, I wondered if there was a second 64bit/32bit registry somewhere. Almost…
Microsoft, in their wisdom, decided that the registry needs a layer of indirection for 32bit applications. What purpose this serves I cannot fathom, but you can read all about it here:
http://support.microsoft.com/kb/305097
So, something you THINK is in one place may really be below a “Wow6432Node” registry key. As I’ve already stated, though, .NET programs should magically be 64bit on a 64bit framework. There is a way to break this though, and sure enough, the xunit.installer assembly is marked with a Platform Target of x86 in its build properties. Since the default is the magical “Any CPU” I assume there was a good reason to change this. My missing registry key, sure enough, is being created in HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\MutantDesign\TestDriven.NET\TestRunners. TestDriven is looking in the Correct location and not finding what it needs. I copied the Wow6432 data up into the 64bit area of the registry, disabled and re-loaded TestDriven in the VS2008 add-in manager, and now I’m in business. Xunit does not appear in the “Test With” menu but Run Tests and Test with debugger now run my XUnit tests.
Test withàCoverage using NCover works too. I can now ditch NUnit. Looking at the xUnit à TestDriven code, I’m sure I can get concurrent xUnit tests running from Visual Studio using TestDriven whenever I’m ready.
Native Windows developers may know what issue this registry redirection practice solves, but it’s lost on me. Maybe it’s a thunking limitation, I don’t know. At any rate, it’s something to be aware of when combining 32 and 64 bit code.