Mon, Oct 5, 2009
I have a bit of a problem with “cross platform” development at the moment. I’m running Windows XP inside an ActiveDirectory forest using VMware Fusion from OSX. A nasty experience a while ago means writing code on a virtual machine’s hard disk is insanity itself. If something happens to the slice you lose everything. OK, you won’t if it’s in source control but using subversion or git from Windows is a pain. Also, why duplicate backup/vss options on a slice when I’m already using everything just fine from OSX? So instead, I develop via a shared folder. I write all the C# code via VisualStudio which points to the “network” share.
This was all fine and dandy until I started to get into NUnit. Whereas in Java/Maven/Ant you run the tests from either the commandline or the IDE for debugging, in NUnit, you load the project itself from a standalone application and it picks up the test cases and runs them. Sounds OK so far. To debug, it’s a simple case of attaching to the NUnit process from VisualStudio. The problem comes when NUnit tries to inspect the DLL for test cases. It can’t if the DLL is on a network share, i.e. my OSX shared folder.
You can jump through all sorts of hoops to get round that, adding the shared path to the local trusted intranet zone and telling .NET to trust that zone but Fusion mounts the shared folder under \.host\Shared folders and the security settings in XP refuse to recognise it as a valid path due to the “.” in .host! So I added “osx” to C:\Windows\System32\drivers\etc\hosts to mimic the path but without a “.” but XP then forces me to authenticate to the shared path without success. Fusion is obviously doing stuff behind the scenes which I have neither the time nor inclination to duplicate.
So the simplest workaround is to copy the bin\Debug directory to the local filesystem and load the DLL from there. That works fine and attaching to the NUnit process in VisualStudio lets me debug it.