TestDriven.NET by Jamie Cansdale

Keyboard Shortcuts

[Xai comments] I just started using your tool and I have to say that I love it. Only one thing I'd improve, give us a keyboard shortcut! By that I mean let us know what we should map keyboard shortcuts to. For instance, I want to map a keyboard short cut to running tests on the solution. What command would I map it to? Or can I?

Indeed you can! Infact I even make sure your keyboard shortcuts don't get trampled when you install a new version.  Here is how you would go about assigning a keyboard shortcut to the 'Run Test(s)' command.  This shortcut will work when you have the cursor inside a method, class or namespace.  It will also execute all tests in a project if a project is selected in the solution explorer.  I've chosen Ctrl+Alt+F5 because of the semantic similarity to Ctrl+F5 (Start Without Debugging).

1. Right click on a tool bar or menu and select 'Customize...'.
2. On the 'Toolbars' tab click 'Keyboard...'.
3. Show commands containing 'Client'.
4. Select 'NUnitAddIn.ManagedAddIn.Connect.Client'.
5. Press shortcut keys: Ctrl+Alt+F5
6. Click Assign

I apologize about the slightly odd command naming.  The reason for this is that it's built from NUnitAddIn's ProgId (which is 'NUnitAddIn.ManagedAddIn.Connect') combined with the name of the command.  If the ProgId changes in future, you will have to redo your key mappings.

There are the commands that are most likely to be of interest.  They all start with the 'NUnitAddIn.ManagedAddIn.Connect.' prefix.

• Client - Build and execute test(s) in a cached external process (this is the default Run Test(s) test runner).
• Project - Build and execute tests in the current project.
• Solution - Build and execute tests in the current solution.
• Restart - Restart the last executed test(s).
• Debugger - Build and execute test(s) in the debugger.
• DebugString - Build and execute test(s) showing all OutputDebugStrings (including in spawned app domains and processes).
• DllLoad - Build and execute test(s) showing all loading Dlls.
• CreateProcess - Build and execute test(s) showing all spawned process command lines (watch the XmlSerializer spawn two processes per type!).
• DTE - Build and execute test(s) in the Visual Studio process (the extensibility object is accessible using AppDomain.CurrentDomain.GetData("DTE")).
• Abort - Abort the current test run.
• NUnit_GUI - Build and load tests using the NUnit GUI (in an external process).

Lazy Update to NUnitAddIn-0.9.576d

Here is the lazy way to update to the latest version of NUnitAddIn.

1. Close all instances if Visual Studio.
2. Execute the following from the command line.

msiexec /x {8073D8BC-7651-4ADF-9219-F67DB3C49103}
msiexec /i http://www.testdriven.net/downloads/TestDriven.NET-0.9.670-RC1.msi

That's it! Next time you launch Visual Studio, you'll find the new simplified project 'Test With...' menu. You can now launch the modified (works with most test framework versions) NUnit GUI on the selected project. Until recently NUnitAddIn would use the test engine built into the 'nunit.framework' assembly. Now the test engine has moved to 'nunit.core' (as of NUnit 2.2) it makes sense to distrubute a version of NUnit with the add-in.

If you'd like to see some of the more advanced options in action, the best place to start is the add-in's manual test-cases.  These come in the form of a test project with steps and expectations defined in the XML doc comments.  You can download the test project from here.  If you find a test-case that isn't working, please let me know (along with which OS and version of Visual Studio you're using).

NUnitAddIn 0.9.574 + Visual Studio 2003

A few people have had issues running this latest build under Visual Studio 2003.  I know it works on some machines (mine for a start!).  Peli has Visual Studio 2002, 2003 and C# Express installed and it worked on all of them.  Loren has had it working with just Visual Studio 2003 installed.  I am now pretty stumped as to why it works on some machines but not others.

If you have installed NUnitAddIn 0.9.574, please comment here and let me know if it worked.  Could you let me know that versions of Visual Studio you have installed and what .NET runtime versions.  The more reports I have the better!

Gary Feldman said:

Visual Studio knows about it, but when I try to enable it, I get "The System cannot find the file specified" with error # 8007002 (not that that's much help).

If anyone is familiar with fuslogvw or SysInternals Filemon, you know the drill. ;o)

Update: Thank you Gary Feldman and Frank Adler.  Using Filemon we can see the last file loaded was 'NUnitAddIn.ManagedAddIn.Connect.DLL' and where Fusion probed for it.  Using fuslogvw (the Fusion log viewer) I can see what the problem is.

LOG: Processing DEVPATH.
LOG: Private path hint found in configuration file: PublicAssemblies;PrivateAssemblies.
LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind).
LOG: Attempting download of new URL file:///C:/Program Files/NUnitAddIn/NUnitAddIn.ManagedAddIn.Connect.dll.
LOG: Assembly download was successful. Attempting setup of file: C:\Program Files\NUnitAddIn\NUnitAddIn.ManagedAddIn.Connect.dll
LOG: Entering run-from-source setup phase.
ERR: Error extracting manifest import from file (hr = 0x80131107).
ERR: Failed to complete setup of assembly (hr = 0x80131107). Probing terminated.

'NUnitAddIn.ManagedAddIn.Connect.dll' is auto generated when the add-in is installed.  In this case it is being compiled with .NET 2.0 which isn't compatable with Visual Studio 2003/.NET 1.1.  The installer was built with .NET 1.0.  If .NET 1.0 is installed this is used and a compatable file is generated.  If .NET 1.0 isn't installed then the newest .NET runtime is used (2.0) and an incompatable assembly is generated.  For some reason I thought a runtime with the same major version number would be used if available.  I wonder if the current behaviour is by design?

I've done a new build with ascending 'supportedRuntime's defined in the installer's .config file.  This should have the intended effect (so long you're using a version it knows about!).  I say should because Visual Studio 2003 stopped working when I uninstalled Visual C# Express.  I'm afraid I haven't been able to test it.  =o(  Please let me know if it works.

Installing NUnitAddIn-0.9.568

The previous build of NUnitAddIn (build 0.9.482) was set to expire on August 30th.  The test execution engine it uses was derived from a pre-beta version of NUnit 2.2.  This latest build has been synchronized with the final NUnit 2.2 source.  I'm hoping to contribute these changes to the NUnit project in the near future (in particular the 'nunit.framework' version independence).

Until then I recommend that you install the latest version.  This should minimise any differences with the official NUnit 2.2 release.  Alternatively you will find a version of the NUnit GUI at '%ProgramFiles%\NUnitAddIn\nunit-gui.exe'.  You will find this version is 'xcopy deployable' and will run side by side with any other NUnit versions.

As a shortcut to using 'Add or Remove Programs' to uninstall the previous version, you can execute the following from the command line.

msiexec /x {8073D8BC-7651-4ADF-9219-F67DB3C49103}

You can then just double click on NUnitAddIn-0.9.568d.msi.  Remember the install is silent (expect it to just exit).  I still need to investigate writing installer GUIs with WiX!

Release Notes for NUnitAddIn-0.9.568

Download: NUnitAddIn-0.9.568

This latest version was developed using Visual C# Express,
built using MSBuild and packaged using WiX.  It uses a
derivative of NUnit 2.2 final as its test execution engine.
The engine has been modified to work with all versions of
NUnit, csUnit and VSTS.

It has been tested with the following framework assemblies...

nunit.framework, 2.2
nunit.framework, 2.1
nunit.framework, 2.0
csUnit, 1.9.2
csUnit, 1.9.4
Microsoft.VisualStudio.QualityTools.UnitTestFramework, 8.0
NUnit.Framework, 2.1 (Mono)

It is compatible with the following versions of Visual Studio...

Visual Studio .NET 2002
Visual Studio .NET 2003
Visual Studio .NET 2005
Visual C# Express
Visual C++ Express

At the moment the installer is completely silent (expect it
to just exit when you open the MSI).

You can find more information and contact the author
using the project weblog...

http://weblogs.asp.net/nunitaddin

At the moment the best way to get to know the add-in is
by going through the following test project.  You will get a
lot more out of using the add-in if you do so.

http://www.testdriven.net/downloads/TestDriven_TestCases.zip

Each method is a manual test case with a set of steps and
expectations.  VS 2003 has been the most thoroughly.
Expect a few test cases to fail in other versions.  Your
feedback and reports are very welcome.

MC++ to C++/CLI

Stan Lippman posted a link to Moving Your Programs from Managed Extensions for C++ to C++/CLI.  A while back I was working on a MC++ language provider for Reflector.  Unfortuantely the lack of support for jagged arrays made a lot of decompiles impossible and not having automatic boxing made others a pain.  I'm looking forward to picking up the project again with C++/CLI.

More MSBuild

I'm keeping my MSBuild Bloggers and Resources up to date with the following entry.  Let me know if I've missed anything.

Klaus Aschenbrenner in Devx.com
Customize Your Builds in Visual Studio Using the Standalone MSBuild Tool

I'm still planning to write a post about compiling for .NET 1.x using MSBuild and a VS2005 solution.  I now have a trick that lets you compile against .NET 2.0 assemblies with the 1.x compilers.  Watch this space.

Fusion Changes

Junfeng Zhang has made a number of posts recently about changes in assembly probing for .NET 2.0.  Since I deal with this stuff a lot, I thought I'd better note it here to remind myself.

AppDomainSetup.DisallowApplicationBaseProbing

Assembly.Load* now apply policy

AppDomain.ApplyPolicy

Caching binding failures

CLR Managed Debugger

I did a double take on this one. A managed debugger, written in (C#) managed code!

Security Implications of InternalsVisibleTo

Nat says:

I think whenever we need to use this attribute, we should make sure that we make it internally visible to a strongly named assembly. Otherwise, this is just another crack in a pot. If we want to use it with Unit Tests, I mean that Unit Tests should be strongly named. :) Otherwise, Microsoft should make it extensible so that we can make this attribute apply only if it is a debug build. What do you think, Jamie?

I'm not sure how the current implementation works security wise. It has always been possible to do this kind of stuff using reflection. Assuming you need equivalent permissions to make these calls there isn't a problem.

Hopefully it works differently for strongly named callers. They should be able to make internal calls without unrestricted or reflection permissions.

I do like the simplicity of the current implementation. I would rather not sign my test assemblys and have to deal with strong names. I also like being able to play with the innards of 'Microsoft.Build.Engine'. ;o)