Hi all,
Sorry that it took soo long, but we got distracted to other topics; but now our UI tests got the focus again. I would like to duplicate issue nunit/nunit#4240 to this repo, as requested by the übergod of the project :)
We live with a large .net framework legacy codebase, where we do have the runner and the tested app using the same old .net fw version. Also, we have integration tests with winforms/QT elements, and QT started throwing AccessViolationExceptions if the non-default thread starts messing with the QT classes...
Even if we use --inprocess --workers=1 --agents=1 , and the test is configured with everything we managed to find in this area ((( [assembly: Apartment(ApartmentState.STA)][Apartment(ApartmentState.STA)] [SingleThreaded] [STAThread] ; remove all [RequiresThread] ))) ... The situation was the same: the Main thread started a new worker thread for running the test; even if setup+test+teardown was single-threaded, QT still throws AccessViolationException because a non-main thread was used ...
I saw that the command line options are parsed via ConsoleOptions.ConfigureOptions() and ConsoleRunner.MakeTestPackage() in nunit3-console.exe ... The "RunOnMainThread" command line argument is NOT processed here, at least I did not find it. I think the commit for the nunitLITE runner should be somehow backported to these methods, I guess... ( nunit/nunit#5188 )
I did some testing, and in nunit.framework.dll , class NUnitTestAssemblyRunner, method CreateTestExecutionContext() , there is the one specific line where nUnit checks the setting "RunOnMainThread" [this.Settings.TryGetValue("RunOnMainThread"....]
But this setting is not currently editable (or at least I could not find any public options for editing this via nunit3-console.exe) ... BUT I can make this setting active by attaching a debugger (e.g. dnspy, then execute nunit3-console with --workers=1 --agents=1 --inprocess ) and by setting the next statement manually so that a MainThreadWorkItemDispatcher() is indeed created.
THEN, everything was running within the main thread of the process - and no AccessViolationException came from QT... So for our problem, fixing the argument processing is enough and more than welcomed.
Thanks for looking into our problem!
Yours
Zsolt
Hi all,
Sorry that it took soo long, but we got distracted to other topics; but now our UI tests got the focus again. I would like to duplicate issue nunit/nunit#4240 to this repo, as requested by the übergod of the project :)
We live with a large .net framework legacy codebase, where we do have the runner and the tested app using the same old .net fw version. Also, we have integration tests with winforms/QT elements, and QT started throwing AccessViolationExceptions if the non-default thread starts messing with the QT classes...
Even if we use --inprocess --workers=1 --agents=1 , and the test is configured with everything we managed to find in this area ((( [assembly: Apartment(ApartmentState.STA)][Apartment(ApartmentState.STA)] [SingleThreaded] [STAThread] ; remove all [RequiresThread] ))) ... The situation was the same: the Main thread started a new worker thread for running the test; even if setup+test+teardown was single-threaded, QT still throws AccessViolationException because a non-main thread was used ...
I saw that the command line options are parsed via ConsoleOptions.ConfigureOptions() and ConsoleRunner.MakeTestPackage() in nunit3-console.exe ... The "RunOnMainThread" command line argument is NOT processed here, at least I did not find it. I think the commit for the nunitLITE runner should be somehow backported to these methods, I guess... ( nunit/nunit#5188 )
I did some testing, and in nunit.framework.dll , class NUnitTestAssemblyRunner, method CreateTestExecutionContext() , there is the one specific line where nUnit checks the setting "RunOnMainThread" [this.Settings.TryGetValue("RunOnMainThread"....]
But this setting is not currently editable (or at least I could not find any public options for editing this via nunit3-console.exe) ... BUT I can make this setting active by attaching a debugger (e.g. dnspy, then execute nunit3-console with --workers=1 --agents=1 --inprocess ) and by setting the next statement manually so that a MainThreadWorkItemDispatcher() is indeed created.
THEN, everything was running within the main thread of the process - and no AccessViolationException came from QT... So for our problem, fixing the argument processing is enough and more than welcomed.
Thanks for looking into our problem!
Yours
Zsolt