0

I was using Visual Studio 2010 with SQL database for my load tests. I wrote code in plugin to call LoadTest.Abort(exception) in LoadTest.TestFinished event when test ran after some time.

After aborted, test was stopped and "Aborted" showed up in test results window. But the weird thing is that load test was not aborted properly since it's status is still "In Progress" by looking at the database and there is no "EndTime".

Any idea why?

zerojozhan
  • 1
  • 1
  • http://stackoverflow.com/questions/1559255/whats-wrong-with-using-thread-abort – Luke Hutton May 30 '13 at 22:08
  • thanks @LukeHutton. But i think load test abort is not simply doing thread abort. – zerojozhan May 30 '13 at 22:33
  • Ok, do you have code for the `Abort`? We are not sure what tools/plugins you are using. If you can provide more details, you will probably get more of an answerable question. – Luke Hutton May 30 '13 at 22:52
  • @LukeHutton, i was using ILoadTestPlugin and the abort method from Microsoft.VisualStudio.TestTools.LoadTesting.LoadTest class. – zerojozhan May 30 '13 at 23:28

1 Answers1

0

To avoid this problem you must place your load test plugin assembly dll somewhere that the test controller can find it, specifically within one of these directories (11.0 is VS 2012; use 10.0 for VS 2010):

%programfiles(x86)%\Microsoft Visual Studio 11.0\Common7\IDE\
%programfiles(x86)%\Microsoft Visual Studio 11.0\Common7\IDE\PrivateAssemblies
%programfiles(x86)%\Microsoft Visual Studio 11.0\Common7\IDE\PrivateAssemblies\{AssemblyName}\
%programfiles(x86)%\Microsoft Visual Studio 11.0\Common7\IDE\PublicAssemblies
%programfiles(x86)%\Microsoft Visual Studio 11.0\Common7\IDE\PublicAssemblies\{AssemblyName}\
%programfiles(x86)%\Microsoft Visual Studio 11.0\Common7\IDE\DataCollectors
%programfiles(x86)%\Microsoft Visual Studio 11.0\Common7\IDE\DataCollectors\{AssemblyName}\
%programfiles(x86)%\Microsoft Visual Studio 11.0\Common7\IDE\DataCollectors\x86\
%programfiles(x86)%\Microsoft Visual Studio 11.0\Common7\IDE\DataCollectors\x86\{AssemblyName}\
%programfiles(x86)%\Microsoft Visual Studio 11.0\Common7\IDE\PrivateAssemblies\DataCollectors
%programfiles(x86)%\Microsoft Visual Studio 11.0\Common7\IDE\PrivateAssemblies\DataCollectors\{AssemblyName}\
%programfiles(x86)%\Microsoft Visual Studio 11.0\Common7\IDE\PrivateAssemblies\DataCollectors\x86\
%programfiles(x86)%\Microsoft Visual Studio 11.0\Common7\IDE\PrivateAssemblies\DataCollectors\x86\{AssemblyName}\

"Wait, WHY?" you might ask. After all, clearly the test engine knows where your plugin assembly is since it was running the plugin in the first place!

The test execution engine is actually two parts, a controller and an agent. Each runs as a separate process, and it is the agent process which runs your plugin assembly code. When your plugin calls LoadTest.Abort() with an exception, the test agent process serializes that exception (including the source of the exception - your plugin class) and tries to send it to the test controller. But the test controller doesn't know anything about your plugin (your plugin assembly is not in its references), and so it fails when trying to deserialize the exception, and the load test fails to complete properly. You can see this all play out in Windows Event Viewer.

You'll find the same requirement is needed if you write a custom load profile plugin. Your assembly dll must be in one of the listed directories or the test will fail at startup with a SerializationException: Unable to find assembly.

agentnega
  • 3,478
  • 1
  • 25
  • 31