Recently whilst setting up a continuous integration environment using cruise control, I came across a problem when running NCover (Version 1.5.5) from NCoverExplorer. I entered all the usual information about profiling applications, etc... and it gave me an error.
Unhandled Exception: System.NullReferenceException: Object reference not set to an instance of an object.
Server stack trace: at NUnit.Core.SimpleTestRunner.CountTestCases(ITestFilter filter) at NUnit.Core.DelegatingTestRunner.CountTestCases(ITestFilter filter) at NUnit.Core.DelegatingTestRunner.CountTestCases(ITestFilter filter) at System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs)
at System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMessage msg, Int32 methodPtr, Boolean fExecuteInContext)
Exception rethrown at [0]: at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg) at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type) at NUnit.Core.TestRunner.CountTestCases(ITestFilter filter) at NUnit.Util.ProxyTestRunner.CountTestCases(ITestFilter filter) at NUnit.Util.AggregatingTestRunner.CountTestCases(ITestFilter filter) at NUnit.Util.AggregatingTestRunner.Run(EventListener listener, ITestFilter filter) at NUnit.ConsoleRunner.ConsoleUi.Execute(ConsoleOptions options) at NUnit.ConsoleRunner.ConsoleUi.Main(String[] args)
This had me baffled for hours. I am using Windows Server 2003 x64 Standard Edition, so I trotted off down a route of 'It has to be because I am using a 64bit windows OS'. After installing the new version of NCover (v2.0.2) which promised to work on a 64bit platform and a newer version of NUnit (2.4.2), it still did not work. I was at my whits end.
The solution was simple however.... My "application arguments" section in the NCoverExplorer NCover runner contained a path and file name to my NUnit configuration as it was not located in the default working folder. This path contained spaces and I did not enter it in quotes (I assumed the NCover Runner would be clever enough to do this for me). So, I put this in quotes and hey presto - success!
I hope this helps prevent someone else going through quite so much pain as I did!
Subscribe to:
Post Comments (Atom)
1 comment:
Hi Craig,
The reason NCoverExplorer does not put quotes around the arguments is because most often it is inappropriate to do so. For instance if calling nunit, you might specify the command arguments as myapp.dll /noshadow. In that scenario the only thing that would make sense to possibly put quotes around is "myapp.dll" as "myapp.dll /noshadow" is just going to go horribly wrong. To have NCoverExplorer parse the various arguments and work out whether they are paths or intentionally different arguments for any possible type of application is a big ask though is it not?
I would suggest that NUnit is the real culprit here, for not giving you a more meaningful error description (as you would have got the same behaviour when running from the command line without ncover at all). Did you log it with Charlie on the NUnit forums?
Glad to hear you figured it out in the end anyways...
Regards,
Grant.
Post a Comment