Fix paths in addins file for NUnit.ConsoleRunner.NetCore nuget package

[k15tfu]

cc @CharliePoole

[CharliePoole]

@k15tfu It's not immediately clear to me what you are fixing here. Can you explain either in the description of the PR or in a bug report? ALSO... what version are you finding any error in? The current build has changed substantially since the last release.

[CharliePoole]

Why the extra two layers of ..?

[k15tfu]

@CharliePoole Hi, thank you for the quick reply! After upgrading to NUnit.ConsoleRunner.NetCore v3.18.1 it no longer loads NUnit.Extension.TeamCityEventListener. As far as I can see nunit3-console.dll in NUnit.ConsoleRunner.NetCore is located under tools/net6.0/any/ but in NUnit.ConsoleRunner nunit3-console.exe is located under tools/:

$ find .nuget/packages/nunit.consolerunner/3.18.1/ .nuget/packages/nunit.consolerunner.netcore/3.18.1/ .nuget/packages/nunit.extension.teamcityeventlistener/1.0.9/ -name nunit3-console.exe -or -name nunit3-console.dll -or -name teamcity-event-listener.dll
.nuget/packages/nunit.consolerunner/3.18.1/tools/nunit3-console.exe
.nuget/packages/nunit.consolerunner.netcore/3.18.1/tools/net6.0/any/nunit3-console.dll
.nuget/packages/nunit.consolerunner.netcore/3.18.1/tools/net6.0/any/nunit3-console.exe
.nuget/packages/nunit.extension.teamcityeventlistener/1.0.9/tools/net20/teamcity-event-listener.dll
.nuget/packages/nunit.extension.teamcityeventlistener/1.0.9/tools/netstandard2.0/teamcity-event-listener.dll

Is it okay to add a new nunit.console.netcore.nuget.addins with these extra 2 layers of ../ specifically for NUnit.ConsoleRunner.NetCore, but do not modify nunit.console.nuget.addins which is also used in NUnit.ConsoleRunner?

[CharliePoole]

@k15tfu I did 3.18.0 because of an error in 3.18.0 making it difficult or impossible to install the .NET core runner as a .NET tool. Running as a .NET tool is it's primary purpose, so this was treated as a critical error.

I think that keeping the extra level of directory in the package (net6.0) was probably a mistake and it may be better to simply have the executable in the root as it is for the standard console runner.

In fact, the .NET Core runner had not been able to access extensions in the past and 3.18.1 does not test for extensibility. This is one of a number of inconsistencies between the two runners, which I would like to resolve.

For the moment, I won't merge this, but I'll take some time over the weekend to think about the alternatives and incorporate this PR or a changed version into the master for the next release. I'm not sure if this calls for a 3.18.2 release or if we will wait for 3.19 but in any case the fix needs to be accompanied by tests, which actually exercise the extensions.

[k15tfu]

@CharliePoole Please tell me if there is anything I can help you with.

[CharliePoole]

This is an area w h ere we could definitely use some help. I'm in the process of creating issues to define where the tool needs to be improved and I'll include you in them.

[CharliePoole]

Related to #1418. If we had tests to show we can load each extension then the problem would not arise.