Provide a way to install extensions as nuget packages

[CharliePoole]

Right now, there is no good way to separately install extensions. About the only thing you could do is to download a zip file, copy it to the proper location and update the addins file.

We need a mechanism to install our own extensions, either using the runner itself or a separate extension management program. The underlying mechanism could be nuget or we could provide our own - nuget would be more generally useful, so long as we can take control and have the extensions end up in a useful location.

Requirements...

• We should locate installed engines and allow the user to decide which ones get the extension.
• Either we should copy the extension to each addins directory or put it in some folder of its own and update the addins file for each engine. Alternatively, we could add a new addins file.

This is high priority because expanding the use of addins and distributing them separately depends on it.

[CharliePoole]

If the engine is installed in a project using a NuGet package, we could detect other nuget packages that implement extensions. This would work for projects that install the console runner and engine for testing as well as for our own Gui project, which installs the engine alone. This would not resolve the problem generally, since it would not provide a way to install extensions for an engine that is globally available - installed using the zip or msi - but it's a start.

[CharliePoole]

@nunit/core-team @nunit/contributors
I've done some experiments based on my comment of three days ago and I'm proposing the following approach to be used for adding extensions as nuget packages. Please give me some feedback on the approach.

1. The NUnit.Engine and NUnit.Console packages will include an addins file with the line ../../NUnit.Engine.*/tools/
2. The ExtensionService will be enhanced to parse the above entry correctly, so that every subdirectory of packages with a name matching NUnit.Engine.* will be examined by looking into it's tools subdirectory.
3. NUnit Extensions packaged via nuget must use an id of the form "NUnit.Extension.Xxxxxxx", which will cause them to be saved under packages with a matching directory name.
4. Each extension should store it's assemblies in the tools subdirectory. It may or may not have it's own .addins file included as well. If it does, that file will automatically be used to control which assemblies that are examined. If not, then all dlls in the directory will be examined for extensions.

The major work here is enhancing the logic for finding subdirectories to allow for wildcards. This is already under way. Based on manually simulating the installation, the rest of this proposal appears to work with the current code.

This is only a partial solution to the problem of installing extensions, as it only impacts those using nuget, but it seems like a good approach for that particular use case. For global installation of extensions, we will need to add some extension management code to the engine. I think the best approach is to get the nuget case working first.

[rprouse]

Sounds like a workable solution to me. For the global case, could we provide MSI's that install to the same relative path to keep the code simple?

[CharliePoole]

We could, although I think it would be nice to avoid MSI's. Another possible approach would be to have a management program that maintains these, just as we have a separate Project Editor for nunit projects. It would have to know where to put them and use the nuget api to download. I wouldn't want it to be part of the engine because of the size of the nuget core library.

[CharliePoole]

In any case, if I do the initial solution, I'll be that much smarter when I'm done and we can talk about the next step. :-)

[CharliePoole]

Changed title to reflect limited scope of this PR. We already have a more general issue about providing a user interface to manage extensions in the 3.4 milestone.

[CharliePoole]

@rprouse Here's how I figure on reorganizing the nuget packages... I'll get started, but let me know what you think:

NUnit.Engine - no change. It has never had extensions before so there is no backward compatibility issue with them.

Four extension packages:

• NUnit.Extension.NUnitProjectLoader
• NUnit.Extension.VSProjectLoader
• NUnit.Extension.NUnitV2ResultWriter
• NUnit.Extension.NUnitV2Driver
  I thought about combining these in some way, but there doesn't seem to be a point.

NUnit.ConsoleOnly package like the new console package with no extensions. I'm open to a better name than that if you can think of one.

NUnit.Console as a metapackage, including console, engine and four extensions.

I'll try to make the ConsoleOnly and Console packages depend on the engine package rather than including the engine, but it may not be possible in the short term.

Our nuget directory is getting a bit crowded so I will try to think of a better way to organize scripts.

[rprouse]

@CharliePoole that is pretty much what I was thinking. ConsoleOnly includes the V3 result writer right?

As per name, maybe NUnit.ConsoleLite? ConsoleOnly implies to me that it doesn't come with other programs (like the GUI?), not without extensions.

[CharliePoole]

@rprouse Yes, both V3 result writer and framework driver are internal. If we ever restructured them to be "extensions" I think they would still have to be bundled in any release - otherwise, we can't actually run any tests. :-)

ConsoleLite bothers me a bit becuase I see this one as the long-term way to distribute console.

When I suggested ConsoleOnly, I was under the impression that users would not see the id, but that's wrong. You see the id from VS and you see the Title when on the nuget.org site, so both have to be user-friendly. We only just introduced NUnit.Console but it's still tempting to break it. Probably not a good idea, however. I'll thnk more on this... my main effort right now is to get the V2 driver to load correctly when it's not in the addins directory.

[CharliePoole]

BTW, in my current local build, I am using NUnit.ConsoleRunner for the package without extensions. The name may be too close to the other, however.