TestDriven.NET by Jamie Cansdale

Pocket Dashboard

Unit Testing Windows Forms Applications

Process.GetProcesses() as Non-Admin

Update: Thanks to Kevin Driedger and Arild Fines for pointing out the pitfalls of using 'tasklist.exe' on Win2k.  On Win2k it is called 'tlist.exe' and is apparently an optinal component.  In the end Trey Hutcheson saved the day by giving me the PInvoke code I needed (thanks Trey!!).  It will work on all platforms now, for admins and regular users.

I posted yesterday that I've been experiencing strange exceptions when using the 'System.Diagnostics.Process' class. It turns out this class it a bit of a mine field and there is a lot that can go wrong with it. With an inspired bit of lateral thinking, Peli suggested I parse the output of 'tasklist.exe'. The advantages being; it works for non-admin users, it takes a fraction of a second to execute and it doesn't cause the floppy drive to light up (see #2 here). I've uploaded a new version to the AutomatedBuilds page. If you get a chance to try it and/or experience any problems, could you let me know?  BTW, you can install and run TestDriven.NET as a non-admin user. I maybe forgot to mention this. ;o)

Process Performance Disabled

I've started getting the following exception when a I call pretty much any method on the 'System.Diagnostics.Process' class.

System.InvalidOperationException: Process performance counter is disabled, so the requested operation cannot be performed.

I need to call 'Process.GetProcessesByName' to detect running instances of Visual Studio before installing TestDriven.NET. There are other ways such as using the GIT (Global Interface Table), but I've gone back to using 'GetProcessesByName' because it seemed to work more consistently on different machines. Now that this method doesn't work on my machine, I'm worried that it might be a common problem.

Has anyone experienced this issue before?  I have found a couple of KB articles, but on one case the fix doesn't work and the other is pretty involved and not the sort of thing you would want to refer users to.  Is there an easier way to fix it?

It looks like Scott Willeke experinced a similar issue when using an old version version of MbUnit.  Peli has since removed all references to the Process class because of this issue.  The Process FAQ has the following to say about it.

Why does the Process class have a dependency on the performance counter?
The Process class exposes performance information about processes. In order to get performance information about remote processes, we need to query performance information on a remote machine. We used the same code to get performance information about processes on a local machine in Everett. That's why the Process class has a dependency on the performance counter. However, this approach has several problems:

1. Performance information is not available to a non-admin account, which is not in the Performance Counter Users Group on Windows Server 2003. So the Process class could not get process performance information in this case.
2. Getting performance data from all the processes on the machine is pretty expensive. The operating system (OS) might load lots of DLLs and it might take seconds to complete. The floppy drive light will be on when the OS tries to find the index for some performance counter.
3. If the performance counter data was corrupted for any reason, the Process class could throw an exception while trying to convert some raw performance information into DateTime.
4. The Process class could not be used to get process information on machines without the process performance counter. Performance counters can be disabled in Windows. See the following link for details: http://www.microsoft.com/windows2000/techinfo/reskit/en-us/default.asp?url=/windows2000/techinfo/ reskit/en-us/regentry/94214.asp

The good news is that we have changed the implementation of the Process class in Visual Studio 2005 (our next release, code-named Whidbey). The Process class doesn't have a dependency on performance counter information any more (this is only true for local processes).

This leaves me looking for a good alternative to the Process API in .NET 1.x.

Equivalent MSBuild/NAnt Tasks

I've just added a new page to the MSBuild Wiki that compares equivalent NAnt and MSBuild tasks.  The page contains links to all of the MSBuild and NAnt task documentation I could find. I'm sure there will be some errors or tasks in there that I've missed.  It's a Wiki, so please jump in there and fix any mistakes!  You'll need to create a Channel9 account before you can start editing.

Alex has added a load of great content already. I have found subscribing to the feed it the best way to consume a Wiki.  You can find the MSBuild Wiki feed here.  The MSBuild/NAnt task comparison is here.

There is now also an MSBuild aggregated feed that contains posts from the MSBuild team and various people who have an MSBuild category on their blog.  As I appear to be the only one subscribed to it at the moment, here's a  button, and here's the [rss].

Feeling the Bounce (RC7 Bug)

Note: This bug only effects people who downloaded TestDriven.NET RC7 on 05 Nov and are seeing "System.IO.FileNotFoundException: File or assembly name '...', or one of its dependencies, was not found."

I was a little over zealous chasing a rare bug earlier on today. The bug only shows itself if you change the output directory of a compact framework project. The problem originates from compact framework projects returning null instead of a configuration object. As a workaround I make an educated guess as to where the build output will be. I assume it will be '$(ProjectPath)\out\$(ConfigurationName)\'. Unfortunately this doesn't work if a non-default output directory is being used.

Ian Fraser noticed this issue earlier on today. I explained the situaction and updated the FaqList. I thought I'd have one more go at finding a better workaround. I knew it was possible to get the paths of various output group items (things like SourceFiles, ContentFiles, Built and Symbols). The idea was to look for any 'Built' DLL or EXE files and use this as the target assembly.

I did a new build, ran my unit tests, installed the new version and ran a few manual tests. Everything seemed to be working. I then uploaded it to the server as a new build. I should have left it at that, but stupidly I decided to make it RC7. In the past I've always dogfooded new builds for a while before making them release candidates. Some of my unit tests do execute inside an instance of Visual Studio, but these tend to use single project solutions. Only tests run on a multi-project solution would have shown up this bug.

This is the worst bug I have let out for a long time. You can tell if you've been bitten by executing the following ad-hoc test. Just right click inside the 'check' method and 'Run Test(s)'.

using System.Diagnostics;

class AdHoc
{
 void check()
 {
 string codeBase = GetType().Assembly.CodeBase;
 bool isBuggy = codeBase.IndexOf("/obj/") != -1;
 Debug.WriteLine(isBuggy ? "You've Been Bitten" : "You're Safe");
 }
} 

If you have ended up with a buggy version, you can pick up a fix from the AutomatedBuilds page. I'll make sure this doesn't happen again.

State of Play

I'm afraid our source control database is still out of action.  The whole point of aiming for V1.0 was to mark a stable branch in the database.  It would be crazy to take a snapshot from my development machine and call that V1.0.  Because of this I have decided to go with the last automated build until the database is back up and running.  This is set to time out on the 30th of November.  The golden version should be available well before then.

The positive side to all this is a bit of extra time to get feedback on the installer.  The latest version comes wrapped in a bootstrapper EXE that is capable of uninstalling any previous versions.  I have also hardened the installation and uninstallation code.  If you find any issues at all, please let me know.

You can find the latest build here.

TestDriven.NET Build 841 RC6

This was so nearly V1.0!  Unfortunately my Subversion source control database wedged itself with immaculate timing - I was in the middle of the last couple of checkins!  It has been repairing itself for the last 24 hours.  I don't know exactly when I'll be able to do the final build.  I've only had a problem with SVN once before (in over a year of heavy use).  It was able to repair itself last time - it just took a while.

Luckily I have an automated build from the checkin before.  I have tackled every reported issue and done a lot of work on the installer.  It will now automatically uninstall any previous versions and warn if there are open instances of Visual Studio.  If the uninstall should fail for any reason you can always use the MsiZap GUI.  Let me know if you have any issues.

One good thing that came out of the delay is support for debugging C++ projects. Support for C++ had always been a bit flaky. I'm happy to say it now works in Visual Studio 2002, 2003 and 2005!

You can download RC6 here.  Support for debugging mixed mode C++ projects will be in the final version. Watch this space.