Test Adapter does not find addins

[CharliePoole]

We are trying to write an NUnit plugin for FsCheck (github.com/fsharp/fscheck). The addin works fine with the standalone test runner, although it is not shown in the addin dialog. According to this converstaion in the mailing list, this is because the addin is built with .NET 4.0:

https://groups.google.com/forum/#!topic/nunit-discuss/je0VXIsVQNQ

The addin is also written and compiled using F# (3.0).

The addin does not work with the test adapter - we've tried putting the addin and its dependencies in the addins folder where the adapter lives, as well in the folder itself. It looks like it is never loaded.

It's not clear how to go about writing an addin for NUnit that works with the standalone runner, the test adapter, the test adapter NuGet package, and Resharper.

From https://bugs.launchpad.net/nunit-vs-adapter/+bug/1193957

[CharliePoole]

The TestAdapter initialization code does not start the AddinManager service. More work will probably be needed once we start it, but that clearly has to be done for addins to be loaded.

[john-ross]

Would it be possible to generally change the loading of addins? It would be great to have addins loaded from dependent dll files as well - then it would only be necessary to add a reference to the relevant project in Visual Studio and not to change NUnit installations. With such a setup any NUnit client (stand alone gui client, visual studio adapter, ReSharper adapter, continuous integration system, etc.) would use the same configuration with the same NUnit addins.

[CharliePoole]

It's not possible to do this in the context of the Visual Studio TestAdapter project, since the adapter relies on NUnit itself to load addins. This bug relates to the fact that the adapter does not properly use the existing addin facility of NUnit.

Even so, I'll comment a bit further on your idea here...

Normally, a test assembly has no reference whatsoever to addin assemblies. NUnit does allow addins to be place within the test assembly itself, but this is only to simplify the initial development of addins. They are intended to be installed in a well-known location and accessed there by all clients.

Unfortunately, that well-known location is currently relative to the install directory for NUnit, which turns out to be a bad idea in the presence of third-party runners. If we were planning another NUnit 2.6.x release, that might be a bug to fix.

However, we plan to replace NUnit addins entirely in NUnit 3.0. Most existing functionality will be provided by user-defined attributes, which is a much simpler approach than writing addins. We will most likely reserve true addins for higher level capabilities, like adding new panels to the Gui.

If you would like to discuss the nunit 3.0 direction further, I suggest posting to the nunit-discuss group.

[giggio]

So this is not going to be fixed in 2.x?
Any idea on the dates for NUnit 3.0?

[CharliePoole]

I guess my comments were a little confusing...

1. Adding work under the adapter.
2. We won't be making changes to how they work or where they are loaded
   from in nunit 2.x.
3. The adding facility changes substantially in 3.0.

I'm expecting to have an alpha release of 3.0 in the fall.

Charlie
On May 21, 2014 9:19 PM, "Giovanni Bassi" notifications@github.com wrote:

So this is not going to be fixed in 2.x?
Any idea on the dates for NUnit 3.0?

—
Reply to this email directly or view it on GitHub/~https://github.com//issues/9#issuecomment-43801937
.

[CharliePoole]

I agree this is 3.0 only. That said, the meaning changes substantially in 3.0. We will have to decide

1. whether to support extensions
2. whether to support user extensions
3. how users can install their extensions.
   In the end, none of this has anything to do with NUnit V2 addins so a new issue should be written to refer to this one.

[CharliePoole]

Issue moved to nunit/nunit3-vs-adapter #222 via ZenHub