CharliePoole

PS... the fundamental reason for the restriction is that an assertion failure has to be processed on association with a specific test result. A test result for an individual test...

Unfortunately, I'm travelling without a computer till the end of the month, so comments and suggestions are all I can give you.

It looks like the failure occurs before the assert condition is even checked, when NUnit is attempting to increment the assert count. It's a remoting exception, which apparently only occurs...

Where asserts should work is a really important and fundamental design issue but debating it won't resolve your problem in any reasonable time frame. Can you answer how they worked...

@MarkKharitonov One confusion point... you say this used to work when the source was in the same assembly as the tests. In an earlier comment, you wrote that it's also...

@mikkelbu However, in your example, I'd expect the XML to show Class1 as a non-runnable fixture. We deliberately translate the exception to a run state because that works best for...

@mikkelbu The badly named --process=Separate runs all assemblies in the same process, separate from the NUnit process. It made more sense back when Single and Separate were the only choices....

@mikkelbu This is from memory, so it may be wrong! I think we create a fake test case "Y" solely for the purpose of reporting the invalid entry. You should...

There was never any doubt that it's a bug I'm just saying it's also a misuse and won't work in general. Bear in mind that assertions in general include the...

I don't think this is a bug in NUnit. However, everything described in this issue has to do with the NUnit framework, not the console runner or engine. Consequently, I'm...