addins/teamcity-event-listener.dll is missing in nunit-console 3.18+

[vmayushan]

It seems that after the changes in commit 862955d, the package now includes only the following files:

nunit-project-loader.dll
nunit.engine.api.dll
nunit-v2-result-writer.dll
nunit.v2.driver.dll
nunit.core.dll
vs-project-loader.dll
nunit.core.interfaces.dll

Unfortunately, it appears that teamcity-event-listener.dll is missing, which has broken automatic test reporting in TeamCity.

@CharliePoole, could you please assist with this issue? Your help would be greatly appreciated.

Thank you!

[CharliePoole]

@vmayushan This was an intentional change on my part, but please read on...

@OsirisTerje @rprouse (please forward to anyone else who needs to comment if I have missed them)

My understanding is that we decided to continue to distribute the TeamCity extension but to stop bundling it with the NUnit.Console package. This was implemented for V4 in issue #878 and I ported that change to 3.18.

By "distribute" I mean that the TeamCity extension, maintained by JetBrains, would continue to be hosted by the NUnit Project. JetBrains would make releases as needed, as they have done all along.

By not "bundling" I mean that the NUnit.Console package, which contains a set of common extensions, should no longer include the TeamCity extension. Users wanting to use it would need to do no more than enter a command to install it.

I believe that the above was a compromise we reached, but I can't remember where the discussion took place. I can't find it very specifically stated in issue #878. It could have been in a discussion group (to which I no longer have access) or in some email between myself and Chris back when he was the engine project lead.

In any case, if that's what the group still wants to do, we're OK. If not, then it can be put back in, although we can't change what's already published.

@rprouse I'm including you in the hope you have some memory of this.

@vmayushan In case you are unaware, I'm no longer the lead of this project. In fact, I'm no longer a member of the NUnit organization. I'm just helping @OsirisTerje out for a while. So that's why I'm referring the final decision to others.

I think that somebody from the project should probably contact JetBrains about this as well. Back when I was the lead, I had a number of discussions and I thought this was the compromise we finally reached.

[OsirisTerje]

@CharliePoole I was in contact with them at the NDC Oslo conference in June, and have mentioned this to them there. They are aware of it, and want to keep it up - was the message I received. I need to now go back to them and continue following that up.

[CharliePoole]

@OsirisTerje FWIW here is my two cents worth.

I don't think it's appropriate for an independent Open Source project like NUnit to be distributing something that works with one competitor in the Continuous Integration marketplace. Originally, I thought they should remove the extension from our organization entirely. They pushed back and I felt like the compromise that allowed them to distribute it in our channel while we stopped bundling was a reasonable compromise at the time.

Frankly, I don't see the point of the NUnit.Console package at all, given that it is so easy to install extensions that you need and avoid those you don't want. However, I admit that I formed that opinion imagining that lots of people would start asking to add extensions to our distribution and that does not seem to have happened. We have little knowledge of who has written extensions.

I have thought in the past about setting up an nunit-contrib project to separate code maintained by other people from that of the team itself.

IMO continuing to bundle this will be fine only so long as no competitor of JetBrains asks for the same. It was Chris' view in the past that they could just be "grandfathered" in, but I doubt that would satisfy a competitor.

Of course, it's up to you and the rest of the team. But I would ask that you also go back and look at the decisions implemented in #878 for V4.

[CharliePoole]

@OsirisTerje

I should add, in case it's not clear, that I do think it would be OK for multiple competing CI providers to be allowed to distribute open source products that complement NUnit in their CI environment. They could have the same access to a repo in the organization for that purpose, just as we have done for JetBrains.

[vmayushan]

Our team at TeamCity was aware of the upcoming changes in NUnit Console 4.x; however, we were surprised to see them implemented in version 3.18. We are currently exploring solutions to address our users' scenarios, particularly regarding the installation of the teamcity-event-listener.dll.
While we would greatly appreciate it if you could consider rolling back these changes for NUnit Console 3.x, we understand if this is not possible.

[CharliePoole]

Ah... I was not aware you were from JetBrains or I would have answered you slightly differently. That is, my comments about installation refer to use by a developer. However, it does seem like it should be rather trivial for you to pull in the dependency on a server... it's only a matter of installing it where the engine will see and use it. Feel free to ask about that here if you think we can be of help.

[CharliePoole]

@OsirisTerje I'm leaving this on hold for now.

I think we can go two ways on this...

1. I can put the teamcity extension back into the NUnit.Console distribution for 3.18.2. In that case, I'd add a package test to make sure we can load it's latest release.

2. If JetBrains is willing to share some use cases they are trying to deal with, I can try to design something that will work in the long term, without bundling the extension.

Currently there are a few fairly critical bugs related to .NET 8.0 that I'm working on, so a 3.18.2 release is likely once I resolve them.

[vmayushan]

We would appreciate it if the TeamCity extension could be re-included in the NUnit.Console 3.18.2. This would help us maintain compatibility with our users' current setups.

In the meantime, we will work on designing and implementing a solution for installing the extension, which we plan to include in future TeamCity releases. At the moment, we still have several open questions regarding how best to achieve this.

[CharliePoole]

@vmayushan Feel free to ask any questions either here or offline. IMO, the simplest might be for the console runner to automatically install the extension when the --teamcity option is specified. It could be implemented in a general fashion internally, allowing us to auto-install any extension just by creating a new option. Just a thought.

[CharliePoole]

Pinging @OsirisTerje and @nunit team

This is still on hold with no milestone waiting for direction. Should I put it back for 3.18.3?

[OsirisTerje]

Should I put it back for 3.18.3?

Yes, I think that would be good.

[CharliePoole]

@vmayushan Ignore (deleted) comments referring to removal of the zip package. I was on the wrong branch.

[CharliePoole]

@vmayushan Release 3.18.3 will include the TeamCityEventListener extension in its zip and nuget packages at version 1.0.7 rather than the latest version of 1.0.9.

We release all extensions in zip, nuget and chocolatey packags, so that our users can access them using their preferred package management system. The teamcity maintainers appear to have stopped updating the chocolatey release back in 2019, either in error or by design.

While it would be technically possible to exclude the extension from our chocolatey package, it would require some rewriting of the underlying scripts and, more important, would be confusing to our users and yours. Users who use chocolatey are accustomed to being able to add and remove extensions at will.

Examining your repo, I see that the code to generate the chocolatey package is still there but apparently has not been run for the last two releases.

[CharliePoole]

This issue has been resolved in version 3.18.3

The release is available on:
GitHub.
NuGet packages are also available NuGet.org and
Chocolatey Packages may be found at Chocolatey.org